프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다. - 품질관리 - 범위관리 - 위기관리 - 통합관리 - 일정관리 - 원가관리 - 인력관리 - 의사결정 - 구매관리 모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다. 프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다. 물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다. 이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다. 가능성.... Project Management - A systems approa..
지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다. 이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다. 다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다. 5. 사소해 보이는 문제도 '이슈화' 하자 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다. 이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다. 이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행..
2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다. 4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다. 1. 업무 변경 관리로 프로젝트 성공률을 높이자. 첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다. 방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요 변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요. 단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미..
프로젝트가 실패하는 가장 큰 요인은 바로 발생할 수 있는 문제점들을 드러내서 함께 논의하지 않고 나중에 해결하면 되겠지... 하는 안일한 생각으로 방치하기 때문이지 않을까 합니다. 그래서 이러한 문제점을 체계적으로 관리할 수 있는 위험관리에 대해서 정리해보려고 합니다. 위험관리를 포함한 품질관리와 관련된 규격으로는 TL 9000이 있습니다. ISO 9000이란 규격은 많이 들어 보셨을 텐데요.. TL 9000은 ISO 9000에 비해 IT 분야에 특화되어 있고, 품질기획/프로젝트계획/구성관리계획등 계획에 초점을 맞추고 있습니다. Telecommunication Leader 9000의 약어로 QuEST 포럼에서 ISO 9001을 기반으로 1999년 제정했으며, IT 분야의 특성에 따라 하드웨어/소프트웨어/..
바라바시가 쓴 링크라는 책에서는 웹에서의 visibility에 대해 이야기 하고 있습니다. 웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다. 웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요.. 다음으로 서점에 가서 책을 살 때 여러분은 어떤 것을 중점적으로 보나요? 물론 상품평이 좋고, 유명한 책을 고르겠죠.. ^^ 저의 경우는 글자 크기와 폰트를 봅니다. 책을 읽는데 부담이 없어야 하기 때문이죠.. 어떤 분은 그림이나 표가 많은 책을 산다고 합니다. 글로 주절주절 적어놓은 것보다 하나의 그림이 더 많은 이야기를 해주고 있으니까요..
프로젝트를 진행할 때, 현업에서 사용하는 방법론은 여러가지가 있습니다. 방법론!! 몇몇 사람들 특히 개발자들은 방법론은 쓸데없는 것이고 개발에 전혀 도움이 되지 않는다고 이야기 합니다. 저 역시도 RUP, 마르미, 이노베이터 등의 방법론을 토대로 프로젝트를 진행해 본 경험이 있습니다만, 솔직히 방법론이 무용지물이라는 생각을 해본 적이 꽤 있습니다. 이유는 바로 방법론에 맞추어 개발하고 산출물을 만드는 것이 아니라, 프로젝트 완료 시점에 방법론의 산출물을 한꺼번에 작성하거나 초기에 대충 작성해 놓고 나중에 한꺼번에 변경하는 것이 문제가 되는 것이었습니다. 그러다보니 오히려 방법론이 개발팀에 있어서는 짐이 되는 것이죠.. 또, 방법론은 모든 프로젝트를 염두에 두고 만들어 놓은 것이므로.. 프로젝트의 특성에 ..
데드라인 톰 디마르코 지음, 김덕규, 류미경 옮김/인사이트 "프로젝트 관리" 관련 포스트에서 가끔 인용했던 톰 디마르코(Tom DeMarco)의 '데드라인'을 소개합니다. 일단, 딱딱한 "프로젝트 관리"를 소설 형식으로 쉽게 이야기하고 있습니다. 그래서 읽기가 편하고, 내용이 어렵지 않고, 설명도 잘 되어 있습니다. 물론, "프로젝트 관리"에 초점을 맞추다보니, 소설 내용이 작위적이면서 개연성이 없기는 합니다. 어차피 재미있는 소설책을 원한게 아니었으므로 큰 문제는 없다고 봅니다. 각 장(章)의 마지막에 "프로젝트 관리"에서 중요한 내용을 요약한 부분이 있는데, 참고 자료로 활용 가치가 있습니다. 요약 내용 중 일부를 발췌해서 올립니다. 모든 일에 변화가 필요합니다. 하지만, 사람들은 변화를 쉽게 받아들..