Reviews and More Reviews
Keeping sight of the objectives
Review when a proposal is raised
Review at the Detailed Investigation Gate
Recording agreement – quality reviews
You should always welcome reviews as they are the opportunity to correct any shortcomings or improve those things which are going well to make them even better.
‘One sees great things from the valley; only small things from the peak.’
G K CHESTERTON
- You, as project sponsor, should initiate the reviews.
- Focus on the business objectives and benefits.
- If the project is no longer viable – terminate it!
- Don’t assume performance to date is an indicator of future performance.
- Be forward looking; don’t dwell on past problems and failures.
- Agree an action plan and see it through.
Keeping sight of the objectives
Your project is underway and may have been running for a long time. The team will be immersed in the day-to-day work of building and delivering the required outputs. This is when you are in danger of losing focus on the real business objectives which initiated the project in the first place. It is vital that you lift yourself above the day-to-day workload and review whether:
- the project still serves your business objectives;
- the conditions of satisfaction are clearly understood and are being pursued;
- continuation of your project is still justified before further costs are committed to (e.g. signing a major contract);
- your project is being effectively managed and the team is confident that the project will be completed.
Such reviews are an indispensable part of good project management, reassuring you, if you are the project sponsor, that the benefits you require will in fact be realised and, if you are the project manager, giving you an independent view on the effectiveness with which you are running the project. You should always welcome reviews as they are the opportunity to correct any shortcomings or improve those things which are going well to make them even better.
If a review is to be welcomed in this way it must be conducted in an open and honest way with ‘fault’ and ‘blame’ being rarely, if ever, used. Witch hunts during the course of a project rarely benefit anyone – be tough on the problem, not on the people. If you can foster this atmosphere of trust an open and honest review will:
- give you the confidence that your money is being well spent to provide clear business benefits and that these will be achieved (or conversely that a project which is no longer viable is terminated);
- give the project manager and team confidence that what is being done is really supported by the business.
Conversely, a review conducted in an atmosphere of retribution, fear and blame will not uncover a reliable picture of the status of the project.
It is important to distinguish between a ‘review’, a ‘decision’, and a ‘progress check’. A review is when advice and comment, external to the project, is requested. Such advice may or may not be followed. A decision follows a review and is a choice between possible futures. Such a decision may draw on the collective ‘wisdom’ of the reviewers, but ultimately rests with the person making the choice. The role of the reviewers is to ensure that decision makers make informed choices. A progress check differs from a review in that it is conducted by the project manager and focusses on the execution of the project (what, when, how much) rather than its overall objective (why). In summary a review gives you the opportunity to:
- recall why you are doing the project;
- check that what you are doing is still appropriate;
- assess how you are going about it;
- confirm when it is going to be completed;
- confirm how much it will cost you;
- and …whether you still need it!
When should you have a review?
You should hold a review prior to making any key decisions affecting the future of the project. Typically these will be:
- at the Initial Investigation Gate when a proposal has been submitted;
- at the Detailed Investigation Gate when the initial business case is approved and the project is committed into your project portfolio;
- during the course of the project:
- at the gates prior to starting key stages of the project:
- Development Gate;
- Trial Gate;
- Ready for Service Gate;
- when major contracts are to be let;
- when major deliverables are to be accepted;
- during stages which are inherently risky;
- when a ‘show-stopping’ issue has been identified;
- when the risks become unacceptably high;
- at the gates prior to starting key stages of the project:
- at the ‘close’ of the project (whether completed or terminated);
- at an appropriate time after the project completion so that achievement of the benefits can be assessed (Post-Implementation Review).
Notice that all these reviews are event driven and occur when a particular point in the project has been reached. They are not driven by calendar lapse time. You should plan the reviews into the project schedule in advance except for those which are driven by unplanned events (risks and issues).
Who is accountable for ensuring a review happens?
The project sponsor is accountable for the business benefits and it is, therefore, in his/her interest that reviews take place. There is little point in the project manager completing a project on time, within budget and to the expected standard, only to find it is no longer needed. Consequently, it is the project sponsor (or higher authority, e.g. business programme sponsor) who is accountable for ensuring that all reviews take place.
You must be clear on the purpose of each review and know:
- the scope of each review (total project, subpart, etc.);
- driver for the review (the event which triggers the review);
- the names of the review manager and team members;
- evaluation criteria to be used (checklists, etc.).
Except for names and actual dates, these are all predefined in the staged framework for the gate reviews, closure review and Post-Implementation Review.
Generally, all reviews assess the deliverables, documentation and performance of the project to date. This is coupled with interviews with the project team, users, customers, third parties, suppliers and functional managers so that you can gain different perspectives on and perceptions of the project from the different stakeholders. Do also include the project manager. If the review comes up with recommendations concerning the running of the project it is important that the project manager is enrolled to implement them.
Unless included in formal gate deliverables, the review manager should record and communicate his or her findings in a brief report covering:
- the key findings from the review;
- recommendations for improvements/changes needed together with who should be actioned to implement them;
- areas where the project has performed well.
This report should be sent to the project sponsor (and project board if there is one) who should agree with the project manager which recommendations should be incorporated into the project, by when and by whom. If there are lessons which could usefully benefit other projects or which provide useful feedback on the project processes, these should be recorded and sent to the relevant people.
TERMINATING PROJECTS IS NOT INDICATIVE OF FAILURE
In some circumstances it is apparent that the project is no longer likely to meet its stated objectives and should be stopped. This may be because:
- the business need no longer exists;
- an issue has arisen which cannot be resolved;
- risks are unacceptably high;
- any prescribed criteria noted in the business case have been encountered.
Such circumstances should always be considered within any review and stopping projects as a result should not be treated as a ‘failure’.
Review when a proposal is raised
The staged framework prescribes that any proposal for a new project is formally written up, sponsored and registered at the Initial Investigation Gate. The key question facing you at this point is ‘Is this proposal worth consuming resources and money on undertaking an initial investigation?’ Is the objective compelling? While information on costs, timescale and impact may be very sketchy, it should be possible to decide if the proposal fits within the current strategy. If this is not possible, the proposal should proceed no further.
Review at the Detailed Investigation Gate
One of the key lessons of project management is that if high emphasis is placed on the early stages of a project, the likelihood of project success is increased considerably. A thorough review at the time the project is formally committed into the project portfolio (at the Detailed Investigation Gate) is, therefore, essential as it is at this point that the proposal of ‘what we want to do’ becomes a project, i.e. ‘what we are going to do’. The project sponsor is, in effect, stating he/she can be held accountable for all subsequent costs and benefits associated with the project no matter where they are spent or earned within the organisation.
The review is intended to ensure that all interested parties understand the objectives of the project, what they are accountable for during its execution and how it will affect them once it is implemented. The review should confirm that the correct project is being started at the right time; if the review finds otherwise, then the project should be terminated or postponed. (See p. 20.)
THE HEALTH CHECK
Project Workout 26.1 comprises a ‘health check’ which may be used to aid any review. This tool is designed to give an overall assessment of the supporting environment, within which the project exists together with an associated ‘risk’ rating.
Reviews during the project
Reviews during the execution of the project provide additional check points where the objectives and general ‘state of health’ of the project can be assessed.
Reviews related to stages and gates
Within the staged framework these are at the gates prior to starting new stages, for example, at the Development Gate, the Trial Gate and the Release Gate. In such cases, the review should focus on the decision to proceed with the project (or not) and, if so, check the adequacy of preparation for the next part or stage of the project.
For long stages, intermediate reviews should be planned into the project schedule. These should be event driven (i.e. a particular milestone has been reached such as signing a major contract) rather than time driven. It is good practice to plan reviews such that one is due approximately every three months. Notwithstanding this, it may also be appropriate to review a project prior to the regular quarterly business refracts. These reviews should confirm that the costs, timescales and project targets remain achievable and that the expected benefits will be delivered to the business.
Finally, the project management practices should always be assessed to confirm that they are being implemented effectively. The ‘health check’ tool included in Project Workout 26.1, later in this chapter, can be used to assist in this.
Reviews related to deliverables
When project deliverables are produced, they need to be reviewed and approved against predetermined criteria. The criteria may be documented in any convenient form; however, I have found the ‘product description’ to be a useful fall-back in the absence of anything else. A product description defines the following:
- the title or name of the deliverable;
- the purpose of the deliverable – what it is used for;
- composition – what are the components of the product? For example, if the product is a document, this would be a list of the expected chapters or sections. For a low-level component, this section will be a description of the product;
- derivation – what are the source products from which this product is derived?
- format and presentation;
- users of the deliverable;
- quality/acceptance criteria – what quality specification must the product be produced to and what quality measurements will be applied by those inspecting the finished product?
- type of quality check required – what kind of test, inspection or review is to be used to check the quality or functionality?
- quality skills/domain knowledge requirement – what quality skills/ domain knowledge is required to inspect or review and acceptance of the product?
- approval and review panels – identify the appropriate approval and review panels.
It may be appropriate to link a review of the entire project to a key project deliverable.
Reviews related to risks or issues
You cannot predict when these are needed. They are the most difficult to set up and manage as there is the persistent hope that all will come right in the end, especially if you don’t have to waste time doing a review! Realism, honesty and openness are what are called for. The project manager needs to recognise when circumstances are conspiring against the project and the project sponsor needs to be made aware. The project sponsor also needs to recognise that the benefits he/she seeks may not be realised through this project. In such cases it is important to focus on why the project was started and look at what else could be done to meet those same objectives.
Project closure review
A project can be closed either when it has been completed or if it is terminated. (Any review may lead to termination!) It is important that a project is closed down in a controlled way and that all accountabilities relating to it are discharged and lessons learned. The closure review aims to fulfil this and is described more fully in Chapters 10 and 27. It should:
- review the efficiency of the project in terms of meeting the original time, cost and resource targets;
- confirm that the benefits have been built into the business forecast;
- record and communicate any lessons which can be beneficial to future projects.
As far as the project sponsor is concerned, either the project has been completed and he/she can now expect to benefit from it, or the project has been terminated. In the latter case, this may be because the original business need no longer exists, but, if it does, the project sponsor will need to take action to address the unresolved business need which initiated the project in the first place.
Post-Implementation Review
Between three to six months after the project has been completed, you should undertake a formal review to assess whether the project has, in fact, met its stated business objectives or is on course to achieve them. This is called a Post-Implementation Review (see also Chapter 11). It should:
- assess the benefits which have already been achieved and compare them with those originally planned;
- assess how well the outputs for the project are working in practice;
- make recommendations for corrective actions (if any);
- record and communicate any lessons which may be useful for future projects.
It is important that the review is considered from the differing viewpoints of the various stakeholders involved, for example:
They will all have their own opinions as to whether the project was successful or not.
Recording agreement – quality reviews
Obtaining agreement to key deliverables during the project is essential. However, it can often prove to be a difficult task to:
- identify those who need to be involved;
- engage them in taking time to address the review;
- be certain that a review has, in fact, been done.
For these reasons, it is often useful to follow a formal process for checking, agreeing and documenting the review and acceptance of project deliverables. This is key for final deliverables, but applies just as much to intermediate deliverables (i.e. those developed during the project) which set the ‘agenda’ for the next stage of work to be formally reviewed and signed off. Unless this is done, there is a danger that work may proceed on a premise which does not have the support of the users or other stakeholders.
The following is a recommended procedure where alternative formal ‘quality processes’ have not been adopted.
Standard record for reviews and approvals
A standard form (such as given in Figure 26.1) may be used instead of an e-mail, memo or letter as it provides a concise and recognisable document which clearly states what is required of the recipient. For example, some individuals may receive a deliverable for comment on particular points only, while others will receive a ‘final’ deliverable and will be required to accept (approve) it.
The project documentation should list the key deliverables from the project, stating who has responsibility for reviewing and accepting them. If a deliverable is not readily portable, alternative methods of review (demonstrations, tests, etc.) should be arranged.
Procedure
- The originator of the deliverable (or project manager) sends the deliverable under cover of a request form (with Part A completed) to the reviewer.
- The reviewer carries out the action noted under ‘review and sign-off criteria’, completes Part B of the form and returns it to the originator. It is not usually necessary to have a real signature, as e-mail or electronic signatures are generally adequate in most organisations.
26.1 PROJECT HEALTH CHECK
This tool is a useful analytical device to assess the current ‘health’ of a project. It looks at the full project environment and using a set of key questions results in an assessment of the overall risk associated with the project. As such it fulfils two roles:
- as a checklist;
- as a tool to indicate where a project manager’s efforts should be directed.
It is recommended that the ‘health check’ is carried out as a part of every project review and at least quarterly. Expect a higher level of risk at the start of the project. An Excel version of this tool is on the CD-ROM.
Instructions
| 1 | Score each statement with a grading –4 to +4: | ||
| –4 –2 0 +2 +4 |
= = = = = |
strongly disagree or don’t know disagree neutral agree strongly agree |
|
| 2 | Enter the total score from each section in the summary section. | ||
| 3 | Add the scores together. | ||
| 4 | Use the key to assess the overall health of your project and hence the risk associated with it. | ||
Key: degree of risk
(Adapted with the kind permission of the Strategic Management Group, based on the Project Implementation Profile by Jeffrey K Pinto and Dennis P Slavin.)