프로젝트를 망치는 15가지 방법

폴 사이먼은 사랑하는 사람을 떠나보내는 50가지 방법에 대한 노래를 불렀다. 프로젝트에도 마찬가지다. IT 프로젝트를 망치는 방법이 50가지는 족히 될 것이다.

1. 작업 기술서가 형편없거나 존재하지 않는다. "프로젝트 범위를 제대로 정의하지 않아 문제에 직면한 많은 프로젝트를 목격했다"고 마이크로 포커스(Micro Focus) 기업인 볼랜드의 책임 프로젝트 관리자 브라이언 팽맨이 말했다.

그는 "최선의 기획 노력에도 불구하고 변화가 불가피하기 때문에 먼저 명확한 작업 기술서를 작성하는 것은 실제로 무엇을 달성할지에 관해 고객과 합의를 이끌어 내는데 있어서 필수적이다"라며, "제대로 작성하지 않은 작업 기술서는 (또는 그 부재는) 해결이 어려운 모호성으로 귀결되고 프로젝트가 언제 끝날지 절대로 알 수 없을 것이다"라고 덧붙였다.

2. 사전에 기대치를 설정하지 않는다. 프로젝트를 망치는 핵심적인 방법 중 하나는 프로젝트 초기에 로드맵을 작성하지 않고 모든 이해당사자들을 위한 프로젝트 요건과 기대치를 정의하지 않는 것이다.

자산관리 ERP(Enterprise Resource Planniong)을 위한 SOA(Service-Oriented Architecture)를 제공하는 앱트리서티(Apptricity)의 CEO 팀 가르시아는 이와 관련 다음과 같이 전했다.

“이 때문에 우리가 프로젝트를 시작하기 전에 고객팀과 프로젝트팀의 모든 구성원이 우리가 무엇을 할 것이며 우리가 할 일이 끝났다는 것을 어떻게 알 수 있는지 등 기본적인 2가지 사실을 명확히 이해하고 문서로 작성하도록 한다. 이런 문제에 대한 해답을 문서로 작성하지 않으면, 프로젝트가 처음부터 위험해진다."

3. 경영진의 지지를 확보하지 않는다. "후원자의 후원을 확보하지 않고 프로젝트를 실행하는 것은 생산적이지 못할 뿐 아니라 재난으로 가는 지름길이다"라고 온디맨드 PPM(Project Portfolio Management) 솔루션을 제공하는 댑티브(Daptiv)의 COO 브래드 클락은 말했다.

그는 "프로젝트가 원하는 방향으로 진행되고 기관의 지원을 얻기 위해서는 후원자와 모든 것을 공유해야 한다"라고 조언했다.

4. 프로젝트 규모에 상관 없이 똑같은 방법론을 적용한다. "대부분의 프로젝트 관리 방법론은 기업 IT 프로젝트를 위한 핵심적인 일련의 표준적인 과업 및 결과물을 포함하고 있다"라고 코칭 및 컨설팅 기업 인투액션(Intuaction)의 컨설턴트 로버트 롱리가 말했다.

그는 이어 "하지만 대부분의 방법론은 특정 규모(예 - 100만 달러 이상)의 프로젝트를 중심으로 수립되어 있다. 10만 달러짜리 프로젝트에 일반적인 접근방식을 시도한다면 실제 프로젝트를 진행하는 것보다 결과물을 도출하는데 더 많은 비용이 발생한다는 것을 알게 될 것"이라고 경고했다.

5. 팀 구성원의 과도한 업무. "팀 구성원들은 기계가 아니다."고 클라우드 기반의 협업 및 프로젝트 관리기업 팀박스(Teambox)의 CEO 댄 숀바움은 강조했다.

그는 "각 구성원에게 어느 정도의 업무가 할당되는지 주의를 기울인다. 한 명의 구성원에게 업무가 과도하게 집중되면, 최종 제품에 문제가 생긴다. 팀의 강점을 활용하고 가능한 한 업무부담을 분산시킨다. 이를 통해 팀을 구할 수 있다"라고 말했다.

6. 정보 공유를 기다리거나 원치 않는다. "프로젝트의 후반까지 사용자 및 이해당사자들에게 결과를 제공하지 않는 폭포수 접근방식은 위험을 유발하며 때로는 실망스러운 결과를 도출한다"라고 가르시아가 말했다.

그는 이어 "사용자들은 실제로 보고 만지며 사용해 볼 때까지 스스로 무엇을 원하는지 모르는 경우가 많다"면서, 프로젝트 관리와 관련해서는 민첩하면서 반복적인 접근방식을 권장한다고 전했다 그는 "반복적인 프로젝트는 가장 필수적이고 복잡한 구성요소를 먼저 제공한 후에 짧고 신속하게 결과를 제공한다"라고 말했다.

7. 명확하게 정의된 의사결정 과정이 없다. "사용자 참여와 피드백이 중요하긴 하지만 성공적인 프로젝트 또한 명확하게 정의된 의사결정 과정이 필요하다."고 가르시아가 말했다. "프로젝트팀은 변화를 수용해야 하지만 변화결정은 권위 있는 승인, 합의, 문서가 있어야 한다. 그 과정과 명령체계를 이해하면 모두가 동일한 각본대로 움직이게 된다."

8. 프로젝트 관리 소프트웨어 시스템을 사용하지 않는다. "엑셀 스프레드시트 때문에 프로젝트 관리자는 일일이 개입하면서 '사서 고생하는' 상태 업데이트를 지속할 수 밖에 없다."고 디지털 자산관리 소프트웨어 개발사 에볼핀 소프트웨어(evolphin Software)의 CEO 브라이언 에이헌(Brian Ahearn)이 말했다.

"프로젝트 관리자는 과업이 완료될 때마다 매번 프로젝트 상태를 자동으로 업데이트하고 과업이 기한을 넘긴 경우 알려주며 완전한 최신의 프로젝트 상태 보고서를 제공하는 솔루션이 필요하다."고 그가 말했다. "최고의 툴은 프로젝트 관리자를 수고스러운 보고작업으로부터 자유롭게 하여 중요한 과업에 더 많은 시간을 쓸 수 있도록 한다."

9. 범위가 유동적이다 (또는 과도하게 변경된다). "느슨하게 정의된 불확실한 프로젝트 범위, 불완전한 뜻밖의 사실, 빈번한 변경 요청으로 인해 일정이 연장되고 비용이 증가하며 상황이 악화되며 팀의 동기가 저해되며 고객이 만족하지 않을 수 있다"고 고급 소프트웨어 개발기업 나가로(Nagarro)의 프로젝트 관리 부사장 샌딥 아난드가 말했다.

범위를 확정하기 위해서는 "프로젝트 목표를 반드시 이해하고 결과물을 정의하며 프로젝트를 매일 모니터링 해야 한다"라고 그는 설명했다. 그는 이어 변경 요청은 프로젝트에 있어서 불가피한 부분이며, 따라서 "범위 변경을 위한 예상을 편성하고 변경 요청을 수용하기 위한 프로세스를 정의하는 것"이 좋다고 전했다.

10. "아니오"라고 말하기를 꺼려한다. 좋은 프로젝트 관리자가 되기 위해서는 "교육을 받은 조언자"가 되어야 한다고 현장 서비스관리 소프트웨어 및 솔루션을 제공하는 TOA 테크놀로지스(TOA Technologies)의 고객운영 부사장 마커스 리마크가 말했다.

그는 "이는 기업, 프로젝트, 최종 사용자 또는 고객의 최대 이익을 실현하지 않는 요청에 대해 '아니오'라고 답할 수 있어야 함을 뜻한다. 거절하고 건설적인 대안을 제시하는 방법을 알면 프로젝트가 탈선하거나 지연되는 상황을 방지할 수 있다”라고 전했다.

11. 팀 워크가 부족하다. 비즈니스 솔루션 제공업체 포스 3(Force 3)의 프로젝트 관리 책임자 힐러리 앳킨슨은 팀 워크를 강조하며 다음과 같이 말했다.

"모든 프로젝트에는 업무를 성공적으로 완수하기 위해 함께 일해야 하는 팀이 존재한다. 프로젝트 관리자는 팀, 프로세스, 솔루션의 핵심이다. 하지만 많은 젊은 또는 새로운 프로젝트 관리자들이 팀과 협의하지 않고 승인을 받지 않은 채 의사를 결정한다. 의사소통과 승인이 없다면 프로젝트를 망치게 된다. 프로젝트 관리자는 팀 없이 프로젝트 일정, 예산, 또는 범위를 관리할 수 없다."

thevenworks.com의 소유주이자 베테랑 경영컨설턴트인 고든 베니야드는 이와 관련해 다음과 같은 조언을 남겼다. “프로젝트가 '기업 프로젝트'보다는 '우리의 프로젝트'가 되는 것이다. 그리고 목표 달성에 초점을 맞추는 대신에 [팀 구성원들 또는 전체 팀들이] 책임을 전가할 다른 대상을 찾는데 시간을 보내면서 자신의 입장을 방어하거나 다른 팀과 협력하기를 거부하게 된다."
베니야드는 이어 "마치 방어팀이 공격팀을 나무라고 공격팀이 방어팀을 나무라면서 코치는 심판을 비난하는 어줍잖은 스포츠팀과 같다. 그들은 잠시 승리를 망각한 것이다"라고 말했다.

12. 형편없는 의사소통. 앳킨슨은 "프로젝트 관리자의 중요한 책임사항 중 하나는 의사를 소통하는 것이다. 의사소통을 통해 팀 구성원 모두는 현 상태, 다음 단계, 문제점 등을 파악할 수 있다"라고 강조했다.

그는 하지만 "프로젝트 관리자들이 의사소통을 위해 시간을 할애하기에 너무 많은 일상적인 과업을 관리하고 있다고 느끼는 경우가 많다"면서 "이것은 중대한 실수이며 프로젝트를 망치기도 한다. PM이 회의록, 상태 보고서, 후속 이메일을 제공하지 않으면 지연, 충돌, 프로젝트 실패의 확률이 높아지게 된다"라고 말했다.

13. 너무 길고 빈번한 상태 회의. 온라인 프로젝트 관리 제공기업 리퀴드플래너(LiquidPlanner)의 CEO 리즈 피어스는 "상태 회의보다 팀의 시간을 더 낭비적인 활동은 없다. 물론, 일부 중요한 정보도 있지만 대부분의 정보는 대부분 협업시스템을 통해 손쉽게 공유할 수 있다"라고 강조했다.
그녀는 다음과 같이 조언했다. "팀 회의는 의사결정을 위해 아껴둔다. 예를 들어, 애자일(Agile)팀은 문제점을 신속하게 발견하고 제거하는데 유용한 일간 '조회'를 실시하고 있다. 리퀴드 플래너에서는 주당 2회의 간단한 회의를 진행한다. 우리는 여기에서 새로운 업무를 검토하고 담당자를 할당하며 우선순위가 높은 업무에 팀의 초점을 다시 맞춘다. 이것이 우리의 포괄적인 '인박스(Inbox)'를 처리하고 결과물을 지속적으로 확인하는 방법이다."

14. 품질을 고려하지 않는다. "적당주의”. "일정 또는 예상 압박 등 다양한 요소들 때문에 QA(Quality Assurance)에 대한 노력을 소홀히 하기 십상이다"라고 국제 비즈니스 및 IT 컨설팅 기업 네오리스(Neoris)의 비즈니스 컨설팅 책임 관리자 세르지오 로웬버그는 말하며, 하지만 "적절한 QA가 없다면 최종 제품이 형편없을 수 밖에 없다"라고 경고했다.
그는 "품질 기준이 떨어지면 프로젝트는 재작업, 법적 책임, 마진 감소 등 부정적인 결과를 경험하게 될 것이다"면서, 프로젝트 관리팀은 "오류방지 비용이 수정비용보다 낮다는 것"을 이해해야 한다고 강조했다.

15. 과거의 실수로부터 배우지 않는다. "모든 완성된 프로젝트 계획에는 발견하지 못한 풍부한 지식이 내재되어 있다"라 피어스가 말했다.

그녀는 프로젝트 완료 시기가 1개월이나 지연되었는가? 우리의 초기 사양은 얼마나 포괄적이었는가? 우리의 팀은 과업을 얼마나 정확하게 예측했는가? 프로젝트 관리툴을 사용할 때의 이점은 이런 질문에 대한 답을 제시할 수 있는 데이터에 접근할 수 있는 능력이다. 팀이 자기개발에 의지가 있다면 후기 프로젝트 분석에 몇 시간을 할애하여 상당한 결과물을 얻을 수 있을 것"이라고 조언했다.