프로젝트 관리자의 100가지 룰

프로젝트 관리자

1.      모든 관련 관리자를 방문한다.

2.      발주자의 중점 강조 부분을 알아야 한다.

3.      Tool은 변해도 관리의 원칙은 변치 않는다.

4.      공정한 대우를 한다.

5.      식은 열정, 미그적거림, 나약한 PM은 부적격하다.

6.      다음 과제를 기다리는 자가 되어야 한다.

7.      문제 해결은 자신이 해야 한다.

8.      장미의 향을 맡기 위해서는 머무름이 필요하다.

9.      HOW보다는 WHAT을 알아야 한다.

10.   성공한 모든 관리자는 유능하다고 할 수 없다.

11.   모든 사람을 귀중히 여기라.

12.   너무 완고한 고집을 하지 말라.

13.   자신이 직접 모든 것을 해서는 안된다.

14.   팀원의 기술과 실력에 의한 성공만이 있다.

 

초기작업

15.   문제의 씨앗은 항상 초기에 제거해야 한다.

 

의사소통

16.   모든 사안은 Partner와 미리 대화를 거쳐서 결정한다.

17.   적임자를 찾은 후 대화를 못하는 것은 죽은 것이다.

18.   국제 회의시 오해의 소지가 없게 대화를 배려한다.

19.   꾸준한 관리 교육 참여가 신 관리자를 만든다.

 

사람

20.   원하는 품질 유지토록 관리 해야 한다.

21.   적용전에 과거의 관리를 평가해 보고 사용한다.

22.   문서작성자, 검토자 보다도 실제 작업할 팀원이 중요하다.

23.   대부분의 문제는 사람에 있다.

24.   일에 중독자가 되지 않도록 팀원을 관리 한다.

25.   최하위 작업자의 지원을 받을 수 있도록 하라.

26.   부적절한 팀원이 있을시는 신중히 검토후 전배를 고려한다.

27.   불필요한 작업을 최소화 해준다.

28.   감시가 능사는 아니다. 함께 해결한다.

29.   보상이 동기 부여를 촉진 시킨다.

30.   작업 성과를 공개한다.

31.   난이도가 어려운 일은 생산성이 낮다.

32.   일의 목적 및 기대사항을 파악하는 것이 중요하다.

33.   추가 투입인원이 필요시 음식에 소금넣듯이 조금씩 추가적으로 투입하라.

 

검토와 보고

34.   검토와 검토자를 선정하고 절차를 수립한다.

35.   꼭 검토가 필요한 자료만을 대상으로 한다.

36.   숨김없이 사실에 입각한 검토를 받는다.

37.   외부 검토자와는 일정조정이 매우 어려우므로 급박한 일정에 대비 하도록 항상 준비한다.

38.   공개 석상에서 팀원을 공격하지 않는다.

39.   검토는 검토자를 위한게 아니고 제출자를 위함이다.

40.   작업 수행 회의는 6명 정도가 적당하다.

41.   검토대상 자료는 단순하고 명확해야 한다.

42.   서면 보고에만 의존하는 관리는 실패 가능이 높다.

43.   문서화된 자료가 현재를 모두 반영하고 있지는 않다.

44.   잘된 월간보고는 년간보고를 필요로 하지 않는다.

45.   상세한 내용의 설명이 필요시에는 한다.

46.   장래의 작업을 대폭 절감시켜줄 사안에 대해서만 철저한 주장을 경주 한다.

 

계약자와 계약절차

47.   프로젝트 관리자는 계약의 주된 주체이다.

48.   프로젝트 관리는 스코어로 관리되어서 보상한다.

49.   계약자와 관련한 인원의 도덕성이 중요하다.

50.   계약자와 우호적인 관계는 좋으나 계약자와의 지지자 관계는 업무 수행에 방해가 된다.

51.   모든 팀원은 비용에 관계한다. 계약자와의 1:1접촉은 유의한다.

52.   계약자는 프로젝트 관리자가 만만하게 보일 때 자격 미달자를 투입하는 경향이 있다.

53.   가능하면 합의된 계획을 바꾸지 않아야 한다.

54.   고객의 만족을 일정, 비용, 우수한 결과물에 있음을 숙지하고 있어야 한다.

 

기술자와 과학자

55.   기술자는 미로와 퍼즐을 좋아 하므로 특히 단순한 설계를 하도록 유의해서 리드한다.

56.   기술자는 낙천주의자 경향이 있으므로 문제를 조기에 느끼지 못하기에 일정과 비용 커브로써 징후를 파악해야 한다.

57.   문제를 해결할 수 있는 자원은 프로젝트 팀내에 있는 자원이 가장 적임자들이다.

58.   고객중에는 과학자도 있다는 것을 명심해서 보고시에 참조한다.

59.   대부분의 과학자는 신임을 갖을 때 합리적이다.

 

하드웨어

60.   사소한 변경도 운영환경을 변화 시킬수 있다.

61.   설계의 이해 부족이 구성 스펙의 이해 부족을 초래한다.

 

컴퓨터와 소프트웨어

62.   최신의 기법을 사용않는 것은 큰 실수이지만 컴퓨터가 생각을 대신해 주리라는 기대는 더 큰 실수이다.

63.   새로운 Version이 아무리 완벽해도 Old Version은 관리하고 있어야 한다.

64.   지식은 시뮬레이션과 테스팅을 통해서 향상된다. 그러나 컴퓨터 모델은 어떤 입력자료의 내용이 잘못된 것인지 감춘다.

65.   과거의 실경험에 의한 기술 습득 방법 대신 최근에는 컴퓨터가 확인만 해주지 말해 주지는 않는다.

 

Senior 관리자, 프로그램 사무실, 기타

66.   상위 관리자에게 궁금한 사항이 있으면 항상 문의하면 놀랄만한 것을 얻을 수 있다.

67.   자신의 관리 기법 특징을 알고 있어야 한다.

68.   경영진의 의견이 틀리고 나의 의견이 맞다고 생각 될때에는 주저말고 주장하고 그래도 경영진이 결정을 내리면 경영진의 의견을 따르고 성공 실현을 위해서 최선을 다하라.

69.   자신이 결정 할수 있는 것은 반드시 자신이 하지 경영층에 묻지 않는다.

70.   프로그램 관리자와는 한 팀웍으로써 일해야 한다.

71.   의사 결정을 하는 당사자와는 공식 비 공식적으로 항상 대화를 나눌 수 있는 길을 유지해야 한다.

 

프로그램 훈련, Budgeting, Estimating

72.   초창기 수립된 자금, 일정에 근거해서 예산, 리스크, 실패불용, 납기내의 사항들을 만족시키는 예술을 강요 당하고 있다.

73.   과거 실패 프로젝트는 실수에 있었던게 아니고 부실한 예측에 원인이 있었다.

74.   모든 문제를 적기에 해결 하려고 하면 일정상에 비상용 시간을 확보해 두어야 한다.

75.   Fixed Price계약 하에서는 엄격한 범위 관리가 필수적이다.

76.   동원 가능한 자원제공처를 가능한 많이 확보하고 있어야 한다.

77.   최소한의 내용만 비밀 사항으로 분류해야 팀원의 시야를 넓일 수 있다.

78.   자신의 팀이 가지고 있는 장점을 부각 시켜라.

79.   항상 내년에는 충분한 예산과 일정을 확보할 수 있을 것이라면 내년을 50년 후가 될수도 있다.

 

고객

80.   고객을 누구이고 그들의 목적은 무엇인지 항상 염두에 둔다.

81.   관리 지침이 현실과 맞지 않을 시에는 보완해서 향상 시킨다.

 

의사결정

82.   조기에 한 잘못된 결정은 쉽게 고칠수 있으나 늦게 결정한 옳은 결정을 바로 잡을 수 없다.

83.   그냥 기다리는것 자체가 해결책이 될때도 있다.

84.   실 상황에 근거해서 의사결정을 해야 한다.

 

Professional Ethics and Integrity

85.   자기의 부하가 자기를 믿을 때 나의 정직을 말해준다.

86.   자신의 경영자를 약하게 하는 것은 장기적으로 결국을 자신에게 이득이 되지 못한다.

 

프로젝트 관리와 팀웍

87.   모든팀은 보스 보다는 코치를 필요로 한다. 항상 코치는 선수를 부르고 있어야 한다.

88.   높은 스트레스를 받는 작업중에는 반드시 구체적인 작업 관리를 해야 한다.

89.   부족한 지원 보다는 행운을 믿는게 좋을수도 있다.

90.   팀원이 잘못된 정보로 인해서 틀린 결론에 도달한 것을 놀라지 않는다.

91.   관련 모든 고객을 기쁘게 할수있는 것이 관리자의 할 일 이다.

 

Treating과 실패 회피법

92.   실패한 경우의 예(a,b,c)

a)      알려진 모든것을 포함하고 있는 항목만으로 일정을 결정한다.

b)      아는 사실만을 기로하고 모든 이론을 Check한다.

c)      자백하기 전에는 자료를 비판하지 않는다.

d)      결론을 성급하게 내리지 않는다.

e)      멈춰야 할 시점을 안다.

93.   성공과 실패 교훈을 적극 활용 한다.

94.   리스크가 큰것은 대안과 비상계힉을 작성해야 한다. 실수는 용납가능 하지만 실패는 용인될 수 없다.

95.   완료된 모든 인증과 테스팅에도 불구하고 부분적인 문제는 있었다는 것을 이해한다. 대비하는 것은 단지 안전 장치에 불과하다.

96.   경험도 좋지만 실제 테스팅이 더욱 좋다.

97.   실패를 두려워 하면 성공 할 수 없다.

98.   팀의 가장 큰 힘 중의 하나는 잘못할 수도 있다는 사실을 모든 팀원이 알고 있는 것이다.

99.   여분의 하드웨어를 갖고 실패에 대비하는 것은 허구에 그칠 수 있다.

100. 고객에게 용서를 빌지 말고 앞으로 집행할 계획을 수립해서 제시하라.

출처 : Tong - 미니아빠님의 PM통