• Project, Programme and Portfolio Management
• No comments

PHASES & GATES.

To begin designing a project management framework, the first thing you need is a project lifecycle. I have seen many examples of such a thing, and often it is all that exists. A lifecycle alone does not constitute a project management framework, but it is an essential top level, underneath which underlying processes can be defined. Frequently something well-presented is produced that is, in fact, unworkable.

In this post I will discuss how the lifecycle should be clear in terms of phases (or stages), with gates acting as decision points between them, i.e. not within them. As always, simplicity will greatly help successful application.

Key takeaways Define a project lifecycle that has a few meaningful phases (or stages) with control gates between each of them. Include phases for each of the following: capturing ideas for consideration defining potential projects to enable a robust decision on whether to go ahead setting up projects in a way that will ensure success working to plans to create project deliverables closing projects after putting in place plans to realise the benefits Define gate criteria for each control gate, including the development and review of a PID (including Business Case)

Introducing the five key phases

There is rarely a good case to differ significantly from the following, although alternative terminology might be preferred:

Concept Phase

This is the phase during which ideas or possible future projects are captured with minimal information; just enough to clearly explain the idea, in fact. It requires a simple mechanism by which the information can be captured, preferably in a standard way and in a central place. It is logical to call the output of this phase the Concept Brief, which is then the input to Gate 1 where a decision is required as to whether or not the concept (or idea) is worthy of consideration.

Below is a short list of proposed fields to include in a Concept Brief template:

Field Name	Description
Title	A meaningful definitive description of this deliverable.
Parent Of	References to any deliverables that it is a parent of (if applicable).
Child Of	A reference to the deliverable that it is a child of (if applicable).
Purpose	The purpose that it will fulfil.
Format	The medium and/or structure of it.
Quality Acceptance Criteria	The measurable quality requirements, including any ranges of acceptability (tolerances).
Quality Measurement Method	How its quality will be measured.
Quality Approver(s)	The individual who is the authority to approve that that it is of acceptable quality.
Status	In Progress / Completed / Accepted / Rejected
Date Accepted	A record of when it was approved.
Notes	To record any discussion points.
Related Tasks	References to related tasks in the plan.

Note that, if tendering to win a potential project for an external customer, this phase would be when enough early information is gathered in order to decide whether or not to tender at Gate 1. In such cases it may be more appropriate to rename the Concept Brief as a Contract Brief.

 

Definition Phase

During this phase, enough further information is gathered to enable the organisation to decide whether to take it forward as a full project (at Gate 2). It is logical to develop the Concept Brief into a Project Definition for this purpose by including:

• Benefits
• Costs
• Deliverables
• Plan (high level)
• Risks

Note that the benefits and costs are the key components of a Business Case, which provides the commercial justification for doing the project. This justification is best illustrated by calculating the time- phased additional revenue that is expected against the time-phased planned costs, which should include both the project costs and any ongoing post-project costs. This will enable both the time until payback is achieved and the effect on cash-flow to be calculated. Not all projects are justifiable in terms of payback alone, of course, as some of the benefits may be indirect or intangible, but these should also be included in the Business Case.

At this time, enough detailing and effort should be applied in order that there is sufficient confidence in all of the information to support a ‘Go/NoGo’ decision.

I recommend extending the Concept Brief template to include the following fields in a single combined Brief/Definition/Initiation template (which then removes the need for any copying and pasting from one document to another):

Field Name	Description
Project Sponsor	The individual who is backing the proposal and will be accountable for delivery of the project if it goes ahead.
Project Manager	The individual who is to define the proposed project and will manage it if it goes ahead.
Business Case
Financial Benefits	A description of how the project will directly contribute to profitability, with an estimated value.
Non- Financial Benefits	A description of how the project will indirectly contribute to profitability.
Project Costs	A breakdown of the estimated costs of doing the project.
Ongoing Costs	A breakdown of the estimated post-project costs.
Return on Investment	A time-phased profile of the financial benefits versus the project and ongoing costs.
Deliverables	A list of the 'special' deliverables that will be created by the project, and their quality acceptance criteria.
Plan (high level)	A time-phased overview of the proposed project schedule and its resource requirements.
Risks	A list of the risks to the success of the project (as planned).

Note that, if tendering to win a potential project for an external customer, this would be the phase during which the tender is compiled, issued and further negotiated. If won, then contract acceptance would coincide with Gate 2. In such cases it might be better to refer to the Definition Document as a Tender Document.

 

Initiation Phase

If the project has passed through Gate 2 to the Initiation phase, then the organisation has committed to delivering the project, based on consideration of the expected benefits versus the estimated costs, so it is important that there is good confidence in the data provided on these as well as the plan to deliver and the risks to delivering. This phase should therefore be used wisely to ensure that the information contained in the Project Definition is sound and realistic, as part of developing it into the Project Initiation Document (PID). To this end, the expected quality of the deliverable(s) should be well defined and agreed with the customer(s), and the plan reviewed and revised to ensure it includes activities to ensure this is achieved and verified. The risks should be reviewed in light of the improved clarity and in relation to the revised plan, and additional mitigation and contingency tasks added to the plan, if appropriate.

Also within this phase, the initial project team should be assembled and the project outlined to them by communicating the full details of the PID to them, although it may be preferable or necessary to exclude the costs. The project team members should be made aware of their project responsibilities (which can be defined within generic roles and responsibilities to apply to all projects) and may include formal responsibilities for deliverables, but should certainly include completing planned tasks within the estimated time (and possibly effort), to defined and/or agreed quality expectations.

Agreement of project team members to estimates and quality requirements should therefore be sought during the Initiation phase, as part of verifying the plan, risks and achievability of quality expectations. Any risks to achieving these expectations, highlighted by project team members, should be shared with the customer(s) with a view to agreeing revisions.

Passage through Gate 3 should be given only if there is clarity (and agreement) of what is going to be delivered (to well defined quality criteria) by whom, and there is a realistic plan to do so within acceptable cost and timing estimates (with well-considered and acceptable risks). The project now has strong foundations upon which it can be delivered.

 

Delivery Phase

This is the ‘doing’ phase. In principle, the project team should simply be carrying out the plan but, given the nature of projects, there is of course a tendency for some things ‘not going to plan’. The purpose of risk management is to minimise the effects of this, but it is still likely that problems will arise which will need to be dealt with through issue management. This will require revisions to the plan that, in any case, needs to be tracked on an ongoing basis in relation to project progress. It is essential to do this as only by updating the plan in relation to real progress and reviewing the uncompleted tasks, is it possible to remain confident that the project can be completed to expected timescales and to be able to communicate what the revised timings of each task are to project team members.

Passage through Gate 4 is based upon acceptance by the customer that the deliverables have been completed to acceptable quality, in relation to the defined and agreed expectations.

It is worth noting that there may be numerous design and development iteration stages within the Delivery phase. Whether this is the case or not, it is worth considering adding project-specific gates into the plan, especially prior to committing to spending money externally on hardware or services. These can be denoted as Gates 3A, 3B, etc.

 

Closure Phase

The purpose of the Closure phase is to bring the project to a controlled conclusion so that it does not continue indefinitely, consuming valuable resources that could otherwise be made available for other work. There will be project artefacts that need to be archived, scrapped or returned.

For the benefit of future projects, it is useful to learn from each individual project by summarising the project performance, in terms of timing cost and quality, and capturing what did and did not go well. It is useful to provide a template for capturing this information, as a Project Closure Report, that can then be made easily accessible to appropriate people within the organisation. This should include the following fields:

Field Name	Description
Report Date	The date that the report was produced.
Status Date	The date at which the project was statused (usually the end of a week or month).
Project ID	A unique identifier or code.
Project Name	A short meaningful definitive description of the project.
Project Sponsor	The individual who is the designated project sponsor.
Project Manager	The individual who is the designated project manager.
Project Schedule RAG	The project level schedule indicator (calculated either from the schedule RAGs of the key milestones or from the earned value bases schedule variance).
Project Cost RAG	The project level cost indicator (calculated either from the variance from the project budget or from the earned vale based cost variance).
Project Quality RAG	The project level quality indicator (manually set).
EVM Schedule Variance	The calculated earned value bases schedule variance.
EVM Cost Variance	The calculated earned value bases cost variance.
Project Risk RAG	The project level risk indicator (possibly calculated from the risk RAGs of the individual project risks).
Number of open red risks	The calculated total of the individual risks that are open and calculated to be red (post-mitigation).
Number of open amber risks	The calculated total of the individual risks that are open and calculated to be amber (post-mitigation).
Number of open green risks	The calculated total of the individual risks that are open and calculated to be green (post-mitigation).
Project Issue RAG	The project level issue indicator (possibly calculated from the issue RAGs of the individual project issues).
Number of red issues	The calculated total of the individual issues that are calculated to be red.
Number of amber issues	The calculated total of the individual issues that are calculated to be amber.
Number of green issues	The calculated total of the individual issues that are calculated to be green.

It is usual that the project is closed when the deliverables have been produced but before the benefits of the project have been realised, which may not be expected until many months later, as reflected in the Business Case. A further review should therefore be scheduled, outside of the project plan, as part of closing the project, to check that the benefits have been realised.

 

Gate Criteria

It is important to be clear about what the criteria are for passing through each gate. To this end, it is helpful to provide templates for the items that are to be presented at each gate. For the early phases, this can simply be a Concept Brief that is developed into a Project Definition and then developed further into a Project Initiation Document (PID).

At each subsequent gate thereafter, including project-specific gates within the Delivery phase, the PID should be reviewed to confirm that the Business Case (benefits versus costs) is still sound and that the plan to produce the deliverables is still realistic, based on the risks to it and any current issues.

At Gate 4, a mechanism for capturing and presenting acceptance, or sign-off, of the deliverables should be provided.

 

Let’s talk Are you just starting to define a project lifecycle? I am conveniently based in Milton Keynes and have a very good track record of implementing simple frameworks (of processes, tools and templates) into small and large businesses throughout the UK, across many industries, which greatly improve value from investments. Get in touch or call me on 07725 950775