This article provides an overview of the Phase/Gate project lifecycle steps I have used when defining or improving a business process that involves information technology (IT) for process automation. The Phase/Gate process ensures that cross-functional stakeholders are aligned and in sync throughout the project's duration.
The Keys to Project Management Effectiveness
The project manager's role is to provide leadership throughout the project lifecycle so everyone knows their role and responsibilities to the project. The methodology outlined below will help you define, plan and execute your project to its successful completion. The keys to a project manager's success can be summarized as follows:
- Strong project leadership
- Effective stakeholder engagement
- Well defined project charter and requirements
- Well defined Project Lifecycle that includes governance, change management, and risk management processes and the discipline to follow it.
Major Steps in the Phase/Gate Project Lifecycle
A repeatable project lifecycle with agreed phases, gates and deliverables adds to the effectiveness of the project team. After going through the project lifecycle once or twice, stakeholders become familiar with the process and know what is expected from them.
A project lifecycle consists of several phases, and each phase ends with a gate that must be approved before continuing to the next phase. Gates ensure that all deliverables are complete and that all stakeholders agree on the scope, plan, resource requirements, etc. and are committed to continue to the next phase. An example is shown in the diagram below with phases outlined in boxes, and gates representing by the diamonds.
Project success revolves around understanding the stakeholders. The project manager must engage them early and keep them involved and informed throughout the project lifecycle. As a project manager, you must understand how all stakeholders are impacted, how each benefits, and you need to assess their level of support for a project. Sometimes an impacted stakeholder perceives no direct benefit in return for their effort, so their support must be garnered through influence and persuasion. Identify at least one executive sponsor that will endorse and fund the project.
Let’s go through each of the phase/gate pairs with a brief description and keys to success.
Proposal Phase: Create a project proposal that describes what is to be accomplished and the benefits that will be realized. Be as quantitative as possible, and include the metrics that will be used to quantify the benefit. For instance, if the benefit is to increase productivity of responding to customer quote requests, include specific numbers. “Customer quote capacity will increase by approximately 50%, from the current throughput of 20 quotes per day to about 30 quotes per day”.
A project proposal should be fairly high level. Its purpose is to establish value and priority compared to other project opportunities, and you don’t want to sink a lot of time and resources into a proposal that might not be approved. The proposal should include an accurate estimate of time, resources and funds that will be needed to get through the next phase. A more accurate estimate of the entire project will be possible after the discovery work is completed during the Concept Phase.
Proposal Commit Gate: Decision makers will use the project proposal to understand the cost/benefit of a project and the funding commitment to pursue it to the next gate. This will be weighed with the opportunity costs of alternative business activities. If approved, the project moves into the Concept Phase.
Concept Phase: The primary deliverable of the Concept Phase is the project’s charter. The charter describes the project and outlines the role of major stakeholders and the governance process. If a solution is to be implemented in multiple phases, the charter can map out what is included in each phase. A good Project Charter includes:
- The scope and high level requirements
- The benefits and metrics for verifying that benefits have been realized
- Stakeholder roles and responsibilities
- An initial cost estimate
- The governance and reporting process
- Project change management process
- Risk management process
Governance includes an escalation process in case of need for conflict resolution or a decision impasse. The reporting process defines how stakeholders and decision makers will be informed on project status. Project change management defines the change control and approval process to maintain stakeholder awareness and agreement throughout the project.
Stakeholder assessment should be completed in the concept phase to understand all the impacted and supporting roles involved with the project. Assessment includes reaching out to understand each function’s level of impact, their level of commitment—or not—for the project, and identification of people that will be representing each function on the project team.
At this point the detailed requirements and solution are not yet known, so an accurate schedule and budget are not really possible. Provide a high level cost estimate and timeframe to help decision makers understand the approximate scale of the project, and provide an accurate estimate for what it will take to get through the Planning Phase for requirements development and project planning.
Concept Commit Gate: At this gate the Project Charter is approved.
Planning Phase: Requirements are defined and documented in detail, and the detailed project plan is formalized.
Requirements: For large and complex projects, plan and document your requirements development effort in a “Requirements development and management plan”. It identifies necessary resources, and establishes a schedule to work toward. As you go through the discovery process, you may find new areas that need to be explored and defined, and if so, revise your plan accordingly.
Start assessing requirements by evaluating “As-is” process diagrams. If process diagrams don’t exist, it is a very valuable exercise for the team to create them so everyone understands and agrees on their current process. If process diagrams already exist, it is helpful to review them with the team to verify they are current and everyone agrees on their accuracy. The processes should be well defined before work for supporting automation is started.
When defining requirements, start with what you like and want to keep from the existing processes and tools. Think about where the current challenges are, what can be improved, and what can be dropped. It is best to put requirements in terms of what is needed—not how it is going to be implemented. You are not defining the solution yet, and it is best to leave options open for different solutions that might be used to satisfy the requirements. A requirements matrix is invaluable to track requirements through functional specification to solution design and then testing. Assign each requirement a number in the Requirements Document, and use the same numbering scheme for the Functional Specification, Solution Design and Test cases.
Project Plan: Planning can proceed and evolve in parallel with requirements definition; however, solid plans are dependent upon well-defined requirements. Typical project plans include:
- Requirements development and management plan
- Resource requirements
- Financial plan
- Procurement management plan
- Quality & testing plan
- Organizational change management plan (training, roll-out, adoption)
- Ongoing risk management
- Communications plan
- Project Change Management
(refer to and extend, if needed, what is in the Project Charter)
Project plans must be documented and reviewed/approved by impacted stakeholders. I prefer to maintain separate smaller documents, each with its own change log, instead of one large project plan document. Plans are dynamic and become more detailed as a project progresses through the project lifecycle. Parts of the overall project plan will be completed only after the final solution is decided and those details are known.
Plan Commit Gate: Approval of the requirements and the project plan document(s) is a major project lifecycle milestone. These deliverables should be complete with an updated budget and schedule for approval by all major stakeholders and decision makers.
Solution Design: It starts with creating the “To-be” process diagram. Two or three alternatives should be considered, and one of the alternatives should have no (or minimal) IT changes. Designing the solution should be an iterative process where mockups, proof of concepts, etc. are shared with end users to verify suitability and make adjustments based on their input. If there are discoveries that impact requirements, then the requirements document—and any downstream deliverables—need to be updated to reflect any changes. Changes need to be recorded and approved by stakeholders impacted by those changes.
Solution Design review: For IT projects, I’ll have two review meetings: one for detailed technical review, which is often too technical for business side stakeholders; and a second, less technical review for business oriented stakeholders.
Execute Commit Gate: At this milestone, the solution design is complete and all plans should be well defined and vetted with stakeholders. The project budget and schedule are firm by now and the required funding and resource needs should be accurate for the duration of the project. Once approved, the project moves into the Build Phase.
Build Phase: This is pure execution to implement the solution. New equipment and software are purchased and installed, custom software is developed, and all the customization, interfaces and integrations are tied together. In parallel, rollout planning is underway, training is being developed and test cases are being created. Manage the risk log carefully and be ready to drive mitigation plans as needed.
Sometimes it doesn't come together as planned and project changes need to be made. Changes can affect scope such that some requirements have to be scaled back, pushed out or altogether "descoped". Alternatively, changes to the schedule or budget might be needed. Whatever changes are made, the impacts must be clearly communicated and the pertinent project documents updated and approved by impacted stakeholders. Keep Stakeholder’s informed and engaged.
Delivery Commit Gate: The name, “Delivery Commit”, reflects that the “Go-Live” delivery date can be committed with a high level of confidence. At this point the system is fully implemented and ready for QA (Quality Assurance) testing followed by UAT (User Acceptance Testing). Unit testing and system integration testing have already been completed and documented by the IT development team. Training material and job aids should be completed, or if not, a firm deadline committed so they are ready in time for UAT.
Validate Phase: The Validation Phase starts with robust “QA testing” to verify the system meets requirements and functions properly within the corporate IT environment. Finally, UAT is performed by the stakeholders. UAT testing is completed when UAT exit criteria are met and users approve with sign-off that the system meets their needs as defined in the Requirements Document. UAT should include any training materials and job aids that will be available for users to learn and use the system. UAT is NOT the time for discovery and adding of new requirements. Having stakeholders engaged throughout the project lifecycle will prevent surprises in UAT.
Readiness Review Gate: The Validate Phase concludes with the Readiness Review Gate to ensure that everything is completed and ready for release. Systems have been tested and issues resolved, UAT is completed and signed off, training and support teams are ready and all preparations to deploy are on track.
Deploy Phase: This is when the new process and supporting systems are released for users to start using them. Organizational Change Management (Organizational Adoption) plans have been underway for weeks as you and the project team have been building awareness of the upcoming changes. Perhaps training is already underway so people are ready to start using the new process and system at Go-Live. Your deployment plan explains in detail how users will be brought up on the new system. Include a training and rollout schedule and a communication plan so impacted stakeholders are aware of what they need to do to be prepared.
It is wise to allow for a breaking in period with IT development staff available in case issues need to be resolved after Go-live, so reserve some time in their schedule—and budget!—to allow for that.
Transition Gate: This marks the end of the deployment phase and the transfer of the process and supporting tools from the project team to the sustaining operations group.
Sustaining Phase: Just after transition the project is closed, and it is important to wrap it up properly. Finalize and archive any documents, complete the transition to the sustaining support organization, complete a post project assessment and document any lessons learned. It is also valuable to do mid project assessments with the team to take advantage of any lessons learned that can be applied for the duration of the project. Celebrate the success of the project and acknowledge the contributions and achievements of the team members.
The effective project manager is skilled in communication, organization and planning. The project manager leads the project team by coordinating stakeholder collaboration, encouraging the team to make decisions, monitoring project risks and driving corrective action where needed. A reusable project lifecycle that employs best practices with lessons learned from past project experiences enables a high level of project management effectiveness.