프로젝트는 구성의 복잡도 및 범위 등에 따라 타임라인이 정해지게 되는데, 빠른 프로젝트는 4주에서 길게 호흡을 가져가는 프로젝트는 6개월 이상으로 길어진다. (산업군에 따라서 n년 이상의 프로젝트가 있기도 하겠지만 내가 진행하는 SAAS 프로젝트는 이미 플랫폼이 구축된 상태라 다른 시스템과의 연동만 없다면 빠르게 마무리 되는 편이다.)
각각의 라이프사이클에 맞춰 모든 일정이 마무리되고 아무 문제없이 프로젝트가 순항한다면 얼마나 좋을까?
프로젝트는 말 그대로 기존의 프로세스에서 벗어나 새로운 시스템 또는 프로세스의 도입이기에 기존에 비즈니스에서 가지고 있던 프로세스를 잘 이해하고 적용할 수 있는 부분은 적용하되 적용되지 못하는 부분은 빠르게 의사결정을 해서 빼내야 한다.
주요 의사 결정사항이 있다면, 관련된 이해관계자와 함께 논의되어야 한다. 일부 담당자와 미팅을 하거나 논의를 하게 되면 추후에 예상치 못한 부분으로 프로젝트 블로커가 발생할 수 있기 때문이다. 따라서 프로젝트 관리를 잘 하기 위해서는 적시에 커뮤니케이션을 진행하고 타임라인을 조정하는 것이 중요하다.
또한, 예상치 못한 이슈 등이 발생했을 때 Project Manager 로서의 역할이 중요해진다. 진행하는 액티비티의 우선순위를 변경한다던가 일정을 변경하여 프로젝트가 큰 틀안에서 벗어나지 않도록 예의주시해야 한다. 프로젝트 타임라인이 조금 늦어지더라도 적시에 커뮤니케이션 하는 것, 그리고 정확한 정보를 제공하는 것은 그 어떤 것보다 중요하다고 할 수 있다.
프로젝트 라이프사이클(Project Lifecycle)
- 킥오프미팅 (Kickoff Meeting)
- 리뷰미팅 (Review Meeting)
- UAT (User Acceptance Testing)
- 교육 (Train the Trainer / End User Training)
- 운영환경 배포 (Deployment)
프로젝트의 진척상황을 관련 이해관계자(Stakeholder)에게 매주 주간보고(Weekly Status Report) 형태로 공유하게 된다.
Weekly Status Report 는 아래 샘플과 비슷하게 입력된다.
- 프로젝트명
- 보고날짜
- 타임라인 및 현황
- 금주 진행내역
- 차주 예정내역
- 리스크/이슈 - 해결방안
- 주요 일정 공유
위의 Weekly Status Report 는 주로 메일의 형태로 이해관계자(Stakeholders)와 공유되는데, 프로젝트 구성원들은 Weekly Status Meeting을 통해 위의 내용을 리뷰하며 프로젝트 현황에 대해 얼라이먼트를 맺는다.
Weekly Status Meeting : 매주 프로젝트 구성원들이 모여 프로젝트의 타임라인별 진행 현황 및 주요 한 액티비티의 날짜 확정하기도 하며, 이슈나 특정 아이템이 있다면 짚어 나가는 미팅
프로젝트 타임라인에 맞게 어느 정도 진행 되었는지, 어떤 내용이 진행되었고 그 다음 단계로 나가기 위해 추가적으로 결정되어야 할 사항은 무엇인지 짚어나간다. 미팅 없이 메일로만 커뮤니케이션 할 수 있다고는 하나 감정이 없는 텍스트로만 의사소통을 진행하다보면 그에 대한 이해도가 달라 가끔 오해를 불러 일으키기도 한다.
보통 30분 정도 진행하며, 필요한 경우엔 추가적으로 논의할 내용을 더 이야기 나누기도 한다. 5번의 이메일을 주고 받는 것 보다 1번의 짧은 콜이나 미팅이 더 효율적이기 때문에!
예전에 일을 할때는 열정이 없어서인지 수동적이었다. 내게 주어진 일이니까 기존에 해 오던 방식 그대로 인수인계를 받고 거의 그대로 업무를 유지하면 되었으므로. 회사에서도 나에게 원하는 것은 그 뿐이었으니까. (톱니바퀴 같은 조직 사회에서 나는 작은 부품 같다는 생각을 종종 했었다.)
그런데 컨설턴트 업무를 하고 V사에 입사하면서 부터는 이전의 방법으로는 능률이 나지 않고 스트레스만 늘었다. '기존의 방식' 이라는 것 자체가 없고 컨설턴트 각각의 스타일이 있었고 기술적으로 궁금한 것이 있다면 사내 네트워크 망을 통해서 지식인(?) 처럼 묻고 답하는 것이 문화인 이 곳. 1년이 지나고 2년이 지나서면서 서서히 익숙해졌고 어느 순간 마음가짐을 달리하기 시작했다. 능동적인 내가 되는 것으로! 계속해서 Why? 라는 물음을 던진다. 이 업무는 왜 하는 것일까? 조금 더 효율적으로 할 수 없을까? 이 자료는 왜 만드는 것일까? 이전 버전의 문서를 봤을 때 고객이 이해하기 쉽지 않았겠다. 템플릿에 추가 설명을 기입하고 컬러태깅을 하여 가시성을 높이는 것이 좋겠다. 등등 꼬리 질문이 생기고 계속해서 이아디어가 떠올랐다.
이 글이 도움이 되었다면 ♥ 공감 부탁 드립니다 :)
댓글도 언제나 환영입니다.
1. 킥오프 미팅 (Kickoff Meeting) - 프로젝트 라이프 사이클
소개팅과 같은 만남에서도 그렇고 비즈니스 관계에서도 처음 만나는 자리에는 조금 더 신경을 쓰는 것이 당연지사. 좋은 인상을 남기기 위해서는 외적인 부분도 중요하겠지만 비즈니스의 첫 단
lailaworld.tistory.com
2. 알파 리뷰 (Alpha Review) - 프로젝트 라이프 사이클
킥오프미팅(Kickoff Meeting)으로 프로젝트를 시작하고 나서 고객의 요청사항이 수집되면 솔루션 개발이 본격적으로 시작된다. SaaS(Solution as a Service) 서비스 내에서의 솔루션 개발은 플랫폼 내에서 �
lailaworld.tistory.com
Weekly Status Meeting - 프로젝트 라이프 사이클
프로젝트는 구성의 복잡도 및 범위 등에 따라 타임라인이 정해지게 되는데, 빠른 프로젝트는 4주에서 길게 호흡을 가져가는 프로젝트는 6개월 이상으로 길어진다. (산업군에 따라서 n년 이상의 �
lailaworld.tistory.com
3. 베타 리뷰 (Beta Review) - 프로젝트 라이프 사이클
알파 리뷰 중에 수집된 요청사항을 기반으로 수정된 버전의 솔루션을 구축하고 샘플 데이터(Sample Data)를 업로드한다. 90% 정도 완성된 시스템을 기반으로 최종 리뷰 하는 세션을 베타 리뷰라 칭��
lailaworld.tistory.com
4. UAT (User Acceptance Testing) - 프로젝트 라이프 사이클
프로젝트 착수 미팅부터 개발을 완료하는 단계에 이르렀다. 최종 요구사항을 기반으로 업데이트된 시스템을 실제로 고객이 사용해볼 수 있도록 구성해 테스트하는 시간을 UAT (User Acceptance Testing
lailaworld.tistory.com
5. 교육/트레이닝(Training) - 프로젝트 라이프 사이클
UAT 의 Sign-Off 가 끝나면 모든게 다 끝난 느낌이다. 그러나 끝날 때 까지 끝난게 아니다. (정말 그렇다.) 프로젝트팀으로서는 마무리 단계지만 비즈니스팀 입장에서는 시스템에 대한 첫 대면이자 �
lailaworld.tistory.com
'Work > 🐷미국 IT기업 적응기' 카테고리의 다른 글
Stage3. 베타 리뷰 (Beta Review) [프로젝트 라이프사이클] (0) | 2020.09.09 |
---|---|
2년 동안 매니저가 5번이나 바뀐 이유 (0) | 2020.08.31 |
Stage2. 알파 리뷰 (Alpha Review) [프로젝트 라이프사이클] (0) | 2020.08.23 |
이론없이 경험으로 배운 프로젝트 관리 (0) | 2020.08.18 |
핑크 슬립(Pink Slip)이 일깨워 준 업무를 바라보는 태도의 변화 (0) | 2020.08.15 |