(공감-의지) 성공하는 프로젝트와 실패하는 프로젝트의 차이점

올해 초부터 진행했던 프로젝트가 결국 산으로 가게 되면서

너무나 많은 시간과 비용이 낭비를 보았다

책임 PM인 나에게 모든 문제와 책임이 있겠다

그 문제의 중심에는 언제나 그렇듯 우왕 좌왕 변덕쟁이 귀얇은 클라이언트가 존재해 있다.

클라이언트는 물론 그 회사의 담당자는 진행하는 비지니스를 성공적으로 하고 싶어 한다

하지만 그 과한 의욕이 오히려 독이 된다.

결과는 아무도 모른다. 그러기에 이렇게 해보면 좋을 것 같고 아니 저렇게 해보면 좋을 것 같고 요렇게 해보면 더 좋을 것 같기도 하다.

문제의 핵심은 클라이언트가 개발팀을, 그리고 PM을 신뢰하고 있는가, 스스로가 선택한 전문가 집단을 믿고 신뢰하지 않으면 도저히 설득할 수 없다.

물론, 어디서 무슨 소리를 듣고 와도 언제나 진중하게 답변을 할 수 있어야 하며 한다.

하지만, 결론은 그래서 이렇게 하면 성공(목적에 대한)하는 건가요?    이런 무식한 질문을,, 그걸 알면 내가 하지.

우린 클라이언트의 목적에 가장 가능성 있는 전략으로 접근하고 실현한다. 하지만 저런식의 질문은 곤란하다.

 

이번 프로젝트에서 가장 크게 다시한번 느꼈던 부분은

바로 프로젝트 초반에서 서로의 정확한 업무 분장과 체계 그리고 관계 정립이 되지 못했던 점 일 것 같다.

초심의 마음처럼 반성하고 매번 진지하게 시작을 보다 정교하고 세심하게 해야하겠다.

 

여기 글

[ 성공하는 프로젝트와 실패하는 프로젝트의 차이점]에서 공감을 느낀다.

 

멋진 말이다. 프로젝트 헌장!!

 

프로젝트 헌장에는 일반적으로 다음과 같은 항목들이 포함되는데, 꼭 필요한 내용만을 간결하게 기술하는 것이 좋습니다. 한마디로 ‘헌장’스럽게 만들어야 합니다.

◇ 기본 항목

  • 프로젝트의 명칭
  • 프로젝트에 대한 소개
  • 프로젝트의 목표 및 결과물
  • 프로젝트의 범위: 무엇을 포함시키고 무엇을 포함시키지 않을 것인지 표기합니다.
  • 프로젝트의 가정(Assumptions): 기술, 비즈니스, 자원, 일정 등에 대한 가정을 표기합니다. 만일 프로젝트 작업을 하면서 가정이 틀렸다고 판단되면 계획을 변경해야 할 것입니다. 변경의 정당성을 입증하기 위해 중요한 항목입니다.
  • 프로젝트의 제약(Constraints): 일정, 예산, 자원, 기술 등 프로젝트 계획을 수립하기 전부터 존재하는 각종 제약을 표기합니다. 예를 들어, 회사의 기존 제품을 반드시 재사용해야 한다거나 또는 특정 신기술을 반드시 이용해야 하는 경우가 있을 수 있습니다.

고급 항목

  • 프로젝트의 주요 마일스톤(Milestones): 주요 일정과 중간 결과물들을 표기합니다.
  • 프로젝트 조직도: 프로젝트 팀과 이해관계자들과의 관계를 다이어그램으로 표기합니다.
  • 역할 및 책임: 프로젝트 팀과 이해관계자들의 역할과 책임을 표기합니다

글 전체 보기

http://social.lge.co.kr/view/opinions/peopleware/

 

 

posted by 망차니

설정

트랙백

댓글