프로젝트 기초에서 알아야할 각 단계(Phase)에 대해서 계속 알아보도록 하겠습니다. 이전 글들에서는 Phase0, Phase1에 대해서 프로젝트 매니져가 숙지하여야할 내용들을 간략하게 다루었고, 이번 글 부터는 실행단계(Execution Phase)인 2단계~4단계의 내용을 알아보고자 합니다.
프로젝트의 각 단계는 아래와 같이 정의됩니다. 이중에서 Phase2 ~ Phase4 는 프로젝트를 집중적으로 실행하는 단계로 아래의 각 단계를 보고, 다시 한번 숙지하시길 바랍니다.
프로젝트의 단계 구분
- Phase 0 : Project Study
- Phase 1 : Project Planning
- Phase 2 : Process & Concept Development
- Phase 3 : Solution Development
- Phase 4 : Final Preparation
- Phase 5 : Handover
위의 단계들은 아래와 같이 집을 짓는 예시와 비교할 수 있습니다.
- Planning : 집을 짓겠다는 계획을 세우는 것, 비용, 시간, 범위 등.
- Process & Concep Development : 집에서 동선이 어떻게 될 것인지, 어떤 디자인을 원하는지 청사진을 제시하는 것. 즉, 집의 개념도를 그리는 것입니다.
- Solution Development : 집에 대한 세부 설계를 하고, 기능들을 제시하는 단계입니다.
- Final Preparation : 본격적으로 집을 건축해서 완료하는 것입니다.
- Handover : 고객에게 집을 양도하고, 사후 보수활동을 이어가는 것입니다.
![]() |
프로젝트 실행단계 |
프로젝트 2~4단계-Execution Phase:프로젝트 기초
프로젝트 킥오프 : Project Kick Off
프로젝트 실행단계에서는 킥오프 미팅을 통해서 본격적으로 프로젝트의 시작을 알리게 됩니다. 킥오프 미팅의 목적과 참석자 그리고 단계는 어떻게 구성이 되는지 알아보도록 하겠습니다.
킥오프 목적 : Project Kick-Off Objectives
Kick off 미팅의 목적은 프로젝트의 목표(goal)와 목적(objective)에 대해 설명하고 모든 프로젝트 멤버들의 역할 및 책임을 분명히 정의하고 할당하기 위함입니다. 또 다른 의미에서 중요한 것은 프로젝트에 대한 동기부여를 통해 Business owner가 프로젝트 멤버들을 독려하고 격려하는 차원이기도 합니다.
따라서, 프로젝트 매니져는 킥오프에 참석한 사람들에게 프로젝트의 각 task에 대해 이해를 도모해야하며, 계획된 내용을 누가, 언제, 무엇을 해야 하는지를 설명하고 공유해야 합니다.
- 프로젝트 킥오프 미팅을 통해 프로젝트 실행을 알린다.(phases 2-4)
- 아래의 내용이 준비 된 후 킥오프 미팅을 진행한다.
- Scope이 정의되어야 함.
- 주요 phase와 key milestone을 포함하여 프로젝트 Plan이 승인되어야 함.
- 프로젝트 핵심 인원들이 참석해야 함.
- 킥오프에서 설명되는 목표들은 다음사항을 알리는 것이다.
- 관련 개인들에게 확실한 동기부여를 하고, 한 팀으로 활동하도록 하는 것
- 전반적인 전략, 타임라인, 프로젝트의 목적과 목표들의 수행에 대해 설명하는 것
- 팀 구성원들의 role과 responsibility와 공통 목표를 분명히 하는 것
- 프로젝트 팀원들은 킥오프 미팅을 통해 다음 사항을 알아야 한다.
- 프로젝트 범위 : Project Scope
- 마일스톤 : Milestones
- 역할과 책임 : Roles and Responsibilities.
프로젝트 킥오프 미팅 참석자
프로젝트 킥오프 미팅에 참석하는 사람들은 아래와 같은 인원들로 구성될 수 있습니다.
프로젝트에 직접적으로 관련된 인원 :
- 프로젝트 오너 : Project Owner
- 프로젝트 매니져 : Project Manager
- 프로젝트 팀원 : Project Team members
필요한 경우, 프로젝트와 관련된 이해관계자들 :
- 사용자 조직의 대표 : The representatives of the user organization;
- 핵심 사용자 : Key users
- 최종 사용자 : End users
프로젝트 킥오프 미팅의 단계 :Project Kick-Off Steps
프로젝트 킥오프 미팅을 진행할 때는 아래의 내용들이 설명되어 지도록 하고, 이를 참고하여 미팅을 진행하면 됩니다. 또는 프로젝트의 특성에 따라 자유롭게 진행할 수도 있습니다.
- 모든 참석자가 함께 하도록 한다.
- 프로젝트의 목적과 목표들을 분명히 설명한다.
- 프로젝트 팀원들에게 적절한 동기부여를 한다.
- 프로젝트 팀원들에게 수행해야할 전략을 설명한다.
- 프로젝트를 위해 중요한 성공 요소들이 무엇인지 설명한다.
- 역할과 책임(R&R), 시간, 참여, 필요한 역량 등을 분명히 설명한다.
- 모든 참석자로부터의 질문에 대해 답변하고, 공통된 목표를 설명해야 한다.
- 프로젝트의 준비 단계에서 필요한 정보들이 공유되고, 의사소통 되었음을 확실히 한다.
- 이슈 사항에 대한 해결 프로세스를 설명한다.
- 커뮤니케이션을 통해 팀과 컨셉을 구성하도록 한다.
Phase 2: Process and Concept Development
이 글의 서두에 설명했듯이 이 단계는 집에 대한 개념을 잡는 것과 같다고 했습니다. 기계를 만든다면, 어떤 기능의 기계가 필요한지를 정의하는 단계가 될 것이고, 서비스라면 어떤 형태의 프로세스와 기능을 제공하는 서비스가 될 지를 정의하는 것이라 볼 수 있습니다.
- 이 단계에서는 아래와 같은 문서들이 준비가 되어져야 합니다. 추후 이 내용들은 Pilot이나 Deploy 시점에 활용됩니다.
- 컨셉(Concept) : 시스템/서비스/설비에 대한 비즈니스적 요구사항을 구체적으로 수립
- 테스트를 위한 초기계획 수립
- 다른 프로젝트나 프로세스와 연계된 개발계획
- 최종 사용자 교육계획과 문서
- 프로젝트 매니져는 관련 업데이트 내용을 프로젝트 기술서에 반영합니다.
- Progress Report와 청사진(Blueprint)를 작성합니다.
- 모든 이해관계자들과 친밀한 커뮤니케이션을 유지하도록 합니다.(특히 Steering Group)
Phase 3: Solution Development
집을 지을 때 설계도를 작성하는 단계입니다.
- 프로젝트 수행을 위해 Phase2에서 생성한 컨셉을 반영하고, 프로세스 요구사항들을 반영합니다.
- working system이나 구성요소들을 개발하고, 그 기능들을 테스트 합니다.
- 이 Solution은 초기의 요구사항에 일치되는 기능이 구현되도록 하여야합니다.
- 이 단계에서 생성되어지는 Solution은 추후, pilot/deploy 프로젝트에서 활용되어질 수 있도록 해야하며, 관련 조직들과 충분하게 유효성을 검증해야 합니다.
- 최종 테스트 계획을 완성합니다.
- Solution 실행과 관계된 문서들을 작성합니다.
- 프로젝트 적용 시점을 위한 Cutover와 Support를 위한 계획을 수립합니다.
- 프로젝트 매니져는 관련 업데이트 내용을 프로젝트 기술서에 반영합니다.
- 진행 보고서를 작성합니다.
- 이 단계에서도, 모든 이해관계자들과 친밀한 커뮤니케이션을 유지하도록 합니다.(특히 Steering Group)
Phase 4: Final Preparation
설계도가 모두 완성되고, 이제 집을 건축해서 마무리 하는 단계입니다.
- 아래내용과 함께 Final preparation을 완료:
- Testing
- End user training
- System management
- Cutover activities
- Go live를 위해 마무리 준비
- 프로젝트 매니져는 관련 업데이트 내용을 프로젝트 기술서에 반영합니다.
- 진행 보고서를 작성합니다.
- 이 단계에서도, 모든 이해관계자들과 친밀한 커뮤니케이션을 유지하도록 합니다.(특히 Steering Group)
2~4단계에서 다루어야 할 주요내용
품질보증 : Quality Assurance
프로젝트에 있어서 품질보증이란 무엇을 의미할까요? 이는 결과물이 기대치대로 도출되는지에 대한 것에 관련됩니다. 프로젝트 처음 시작시에 예상한 결과와 동일하거나 그 이상의 품질이 나온다면 성공한 프로젝트가 되는 것입니다.
따라서, 프로젝트 진행 과정에서 언제라도 Steering Group에게 결과물에 대한 품질을 보증할 수 있음을 확인시켜 주어야 합니다. 주요결과물(Major deliverables)에 대한 내용이 올바른지 그렇지 않은지에 대해 보증하기 위해서는 각 마일스톤에 대한 보고시에 결과물 리스트를 확인해야 합니다.
품질보증(Quality assurance)에 있어서는 다음 사항들이 관련됩니다.
- 프로젝트 계획
- 추진 내용과 주요 결과물의 일치를 위해 발생하는 이벤트를 재검토
- 각 단계의 마지막 부분에서 주요사항들을 점검 => Milestone Checklists를 확인함
- 테스트 및 시험을 통한 품질 확인
QA 활동들은 프로젝트 계획에서 반드시 정의 되어 있어야 합니다! 즉, 계획 단계에서 품질보증을 어떻게 할 것이고, 어떤 결과를 내어야 하는지를 명확히 정의 해야 하는 것입니다.
품질 체크포인트로서 마일스톤 :Milestones – Quality Check Points
Milestone Purpose
- Check point
- 모든 정의된 결과물들이 생성되어졌는가를 확인한다.
- 결과물의 내용, quality와 format등을 검증한다.
- Key Decision Point
- Go / No Go decision
- Commitment Point
- 프로젝트 진행을 위해 모든 관련자들의 참여를 점검한다.
마일스톤에서의 일반적 규정 : Milestone General Rules
- 프로젝트에서는 하나의 공통된 마일스톤 양식을 사용한다.
- 마일스톤은 결과물들을 위해 결정짓는 포인트이다.
- 이전 단계(Phase)에서의 활동으로부터 나온 결과물들을 통해 마일스톤이 준비되고, 정의되어져야 한다. 예를 들어, “Initial Authorization Plan”은 E2까지 이고, “Authorization Plan”은 E3까지 이다.
Checklists in Project
- 모든 프로젝트에 적용되는 것들:
- 각 Phase별 Check List / Milestone
- Project Plan Review Checklist
- Deployment 프로젝트에 적용되는 것들:
- Cutover Plan Template
- Go Live Checklist
- Handover Checklist
![]() |
품질에 대한 보증 |
프로젝트 모니터링 : Project Monitoring
프로젝트의 전반적인 상황에 대해서 모니터링은 누가 하는가?라고 질문을 던진다면, 이때까지 설명된 내용으로 추론해볼 수 있습니다. 바로, 프로젝트 매니져와 Steering Group입니다.
그렇다면 프로젝트 매니져와 Steering Group은 무엇을 통해 프로젝트의 진행 상황을 모니터링할까요? 프로젝트 모니터링의 목적과 사용되는 툴은 아래와 같은 것들이 있습니다.
- 모니터링 목적
- 잠재적인 문제들이 발생하기 전에 미리 예상하는 것이다.
- 프로젝트가 제 경로를 벗어나지 않도록 적절한 action을 명시하는 것이다.
- 모니터링 툴
- 프로젝트 툴에서 획득되는 database
- 프로젝트 진행 보고서 : Project Progress Report
프로젝트 진행사항 및 현황보고서 : Progress and Status Report
프로젝트 모니터링을 위해 제출되는 자료에는 진행사항/현황 보고서가 있습니다. 이 보고서는 다음과 같은 특징들을 가집니다.
- 프로젝트의 전체 상황을 설명한다.
- 프로젝트 매니져는 월간 단위로 Steering Group에게 보고하도록 보고서를 준비한다.
- 보고서 내용에는 계획단계의 미팅 초안과 Steering Group에 대한 안건을 다룬 내용이 포함된다.
- 표준 보고서는 다음과 같은 구조를 가진다.
- 워드 문서 : Word Document
- 부가 첨부자료 : Appendixes (Risk Management Report, Issue/Error Log)
현황 보고서의 내용 : Content of Progress and Status Report
프로젝트의 진행사항과 현황을 보고하는 자료에는 다음과 같은 내용들이 포함되도록 합니다. 보고서의 품질과 내용을 충실히 하여 Steering Group이 프로젝트의 현황을 잘 이해할 수 있도록 준비해야 합니다.
- 프로젝트 계획상의 일정, 예산과 현황을 비교해서 명시한다.
- 프로젝트 계획상의 일정 대비 업무 현황을 비교한다.
- 보고기간 동안 발생한 새로운 이슈사항들을 나타낸다.
- 프로젝트 매니져가 분석한 각 리스크 상황들을 나타낸다.
- 자원의 변화 요소를 명시한다.
- Steering Group에 의해 요구된 결정사항을 나타낸다.
- 보고 기간과 다음 보고기간 사이에 다루어야할 주요 사항들과 타 프로젝트과의 상호의존성을 나타낸다.
변화관리 : Change Control
프로젝트의 변화관리 : Change Control of the Project
- 프로젝트 기간동안 발생한 변경사항을 참조한다.(일정, 자원, 범위, 업무 등)
- 신규로 발생된 이슈, 문제, 에러등과 같은 변경 요구사항들은 반드시 이슈로그 혹은 에러로그에 기록한다.
- 프로젝트 매니져들은 변화 관리를 수행한다.
- 특별히 의사결정이 필요한 이슈사항들이 있을 수 있다.
- 프로젝트 매니져는 변화 관리에 대한 책임이 있다.
- 모든 변경사항 들은 반드시 Steering Group에 의해 승인되어야 한다.