Project Controls

Purpose of Control

Control is all about decision-making, and is the central role of all management, but specifically project management. The purpose of control is to ensure that the project:-

Project Controls ensure that, for each level of the Project Management Team, the next level up of management can:

Project Controls must also cover capturing information on changes from outside the project and taking the necessary actions.

Project Controls Overview

There are various levels of control in the project. Most Project Controls in PROMISE are event-driven, including all the decision-making ones. There are some time-driven Project Controls such as regular progress feedback. At the project level there is overall control by the Project Board, which receives information from the Project Manager (and any assurance roles appointed) and has control over whether the project continues, stops or changes direction or scope.

PROMISE applies the concept of 'management by exception' where the Project Board is concerned. That is, having approved a Stage Plan, the Project Board is kept informed by reports during the stage. There is no need for 'progress meetings' during the stage. The Project Board knows that the Project Manager will inform them immediately if any exception situation is forecast.

The major Project Controls for the Project Board are:

The Project Board must also monitor the environment outside the project and bring to the notice of those concerned, such as the Project Manager, any changes which affect the project.

The Project Manager has control on a day-to-day basis within a stage and can make adjustments as long as the stage and project stay within the tolerances defined by the Project Board and the adjustments do not change the Business Case. The Project Manager is responsible for monitoring progress, and may be assisted by project support roles if these have been appointed.

Planned achievement includes the required quality of products. The aim is to detect problems early while they can be corrected at least cost. Action should be taken in respect of any deviation from plan that is forecast to be outside tolerance.

The what, why, who, how and when questions must be answered satisfactorily before the project proceeds beyond Kick Off.

Progress is monitored against plans, with control actions if adjustments are needed. The Project Management Team is kept informed at their various levels by reports and assessments.

There is a controlled close to ensure that the project does not drift on for ever, but does not finish until the Project Manager can satisfy the Project Board that the objectives specified in the Project Foundation Document have been achieved.

Controlled Start

Project Start-up

Project Start-up is an important pre-requisite of project control. Project Start-up contains the work that PROMISE requires is done before the project can begin. Its functions are to:

 

Project Kick Off is likely to be a short stage in comparison with the other project stages, but the approval of the Project Board is needed before it can be done. Project Start-up must, therefore, create a plan for the Kick Off Stage that the Project Board can examine in order to understand the required commitment more clearly. The plan should include a statement of any Project Controls and reports that the Project Board is to receive, so that the Project Board is assured in advance that the stage will be under its control.

As the creation of the Project Directive is out of the control of the project, it often falls short of providing all the information that the project needs. Start-up gives the Project Manager the opportunity to flesh it out into a full Project Directive and thus present the objectives of the project to the Project Board at the Project Kick Off Meeting for its agreement. Where the project is part of a programme, the programme should provide a complete Project Directive, thus removing the need to produce it during Start-up.

Project Kick Off

The purpose of Project Kick Off is to ensure that before significant resource is spent on the project, everything involved in the project is agreed on:

 

These questions are answered in the Project Foundation Document, which is the main product from the stage.

Another product of the Kick Off Stage is the Next Stage Plan, so that if the Project Board is satisfied with the Project Foundation Document, it can also approve progress into the next stage without further delay.

Once approved at the end of the Project Kick Off Stage, the Project Foundation Document is 'frozen'. It is now a reference document to show the original basis of the project. At the end of the project it can be measured against final expectations and results to assess the success of the project and to check, for example, that any changes to the Project Plan were made in a controlled manner. It is an essential part of the audit trail on how the project has been managed.

But changes do occur, and it would be wrong not to record the impact of those changes and keep the Project Management Team 'up to date', so further versions of the most volatile parts of the Project Foundation Document are created as changes occur. Again, this forms part of the audit trail, showing any moves away from the information in the Project Foundation Document, when and why this happened, what the impact of the change was. The most volatile parts of the Project Foundation Document are:

As later versions of these are created, they are kept in the management section of the Project filing.

These volatile parts will be updated throughout the project, at least at the end of each stage.

To summarise, the main purpose of the Project Foundation Document is to pull the information together to answer the questions

 

 

Stage Selection

According to its size and level of risk, the Project Board decides to break the project into a number of stages. This is agreed during the Kick Off Stage. The breakdown of the project into stages is discussed in the Stages chapter.

The end of each stage is a major control point for the Project Board (see End Stage Assessment), thus the selection of the number of stages and their timing in the project life cycle is an important control for the Project Board.

Controlled progress

During the project there is a need to ensure that the project stays in line with the expectations defined in the Project Foundation Document and the current Stage Plan.

Tolerance

No project ever goes 100% to plan. Even with a good plan, some things will go a little slower than planned, or cost a little more; other things will go more quickly, cost a little less. Such variations will occur all the way through a plan. Although the Project Board agreed a plan with the Project Manager, it doesn't want the Project Manager to be constantly running back to it, saying 'I've spent a pound more than I planned this week' or 'I'm a day late this week'. On the other hand, the Project Board doesn't want progress to deviate wildly from the plan without being told and being able to react. So where is the dividing line between differences which are permissible and those which require Project Board intervention? The dividing line is called Tolerance.

The two standard elements to tolerance are:

Tolerance is the permissible deviation from a Stage or Project Plan without bringing the deviation to the attention of the Project Board (or higher authority if the deviation is at project level). Separate tolerance figures should be given for time and cost.

Tolerances for the project as a whole should be set by corporate or programme management in the Project Directive (or ascertained by the Chairman during Start-up, to be entered into the Project Directive). Based on these overall figures the Project Board agrees with the Project Manager a tolerance for each stage, once the Stage Plan has been produced.

If the tolerance for a stage is forecast to be exceeded, the Project Board may set new tolerances around the new forecast as long as these are within the constraints of the overall project figures. Where the forecast is for the project tolerance to be exceeded, the Project Board must refer the matter back to corporate or programme management for a decision.

Product Descriptions

A description of each product is written down before that product is developed/ obtained, even before it is planned, to ensure that the individual people know:

Within PROMISE, the Product Description is contained in the User Requirements Document (URD). It is written as part of the planning process. A Product Description defines such elements as the content of a product to be delivered by the project, standards to be used in its creation, and the quality criteria to be applied. Not only is this information essential for the creator, but the Product Description also forms the initial checklist for checking the quality of the finished product.

All Product Descriptions must be approved. In formal terms they are approved by the Project Board. If the assurance roles of the Project Board members are delegated, the assurance of the Product Descriptions may be one of the authorities to be delegated.

Project Issues

As part of control there must be a procedure that caters for possible deviations from specification. These deviations occur for many reasons:

 

Apart from deviation possibilities, there will also be a need for an avenue into the project for questions or concerns. All of these need a procedure to control them and their effect on the project. In PROMISE all such inputs are handled by the Project Issue procedure.

This procedure ensures that all such questions, problems, concerns or suggestions are answered, but that nothing is undertaken without the knowledge of the appropriate level of management, including the Project Board. Apart from controlling possible changes, it provides a formal entry point through which all questions or requests can be raised.

The Project Issue procedure logs and handles all Project Issues raised during the life of the project. The procedure provides knowledge of the status of all Project Issues, control over their processing and a feedback to the originator on any actions taken.

Change Control

Every project must have a procedure to handle change. Without change control there is no project control.

All requested changes are logged as Project Issues. The procedure includes impact assessment of the request, prioritisation, decision-making and action.

Risk Log

The management of risk is an important control throughout the project.

A log is kept of all identified risks, their analysis, countermeasures and status. This begins at the start of the project and continues until the project closes. All risks are frequently reviewed. As a minimum risks are re-assessed at the end of each stage, but they should also be reviewed as part of the assessment of stage progress.

There is a separate chapter on the management of risk.

Checkpoint

A Checkpoint is a time-driven control when the status of work in a stage or of a team is ascertained. It involves the people carrying out the work and is triggered by either the Project Manager or the Team Manager, whoever is the more appropriate. In larger projects the participants might be the Project Manager, Team Managers and project support people. It may or may not be a formal meeting.

A specific aim of a Checkpoint is to check all aspects of the project against the plans to ensure that there are no nasty surprises hiding. Useful questions are 'What is not going to plan?' and 'What is likely not to go to plan?'

The information gathered at a Checkpoint is recorded for the Project Manager and forms the basis of the Highlight Report. Checkpoints should be taken as frequently as the Project Manager requires in order to maintain control over progress. They may coincide with the Project Manager's need to consider re-planning.

A Checkpoint can also be used for the downward dissemination of information from the Project Board, corporate or programme management to team members.

Planning and Re-Planning

Plans are, to a certain extent, guesswork. Activities do not always go as planned. Resources do not always perform as expected. Unplanned activities may emerge. The Project Manager needs to compare the plan regularly against latest information and be ready to re-plan. Failure to re-plan, or re-planning too seldom, can leave it too late to recover from problems. There is, however, a danger of reacting too early or too frequently to the status of non-critical activities. Small deviations may correct themselves and the Project Manager may spend too much time in re-planning rather than in monitoring. When and how often to re-plan will depend on the size and criticality of the project, and is a matter for the Project Manager's judgement. Re-planning is needed at stage boundaries and when Exceptions arise.

Highlight Report

A Highlight Report is sent by the Project Manager to the Project Board during a stage at a frequency dictated by the Project Board. The frequency depends on such factors as the length and perceived risk of the stage. Typically the report might be sent fortnightly or monthly.

The Project Board has the right to define the content of the Highlight Report. Minimally it should contain statements about:

The Project Board may also ask for a copy of the Stage Plan (or parts of it), showing actual progress to date in terms of activities and cost, plus reports on any other item in the stage that it feels is important. Whatever the content, the style should be concise. Instead of a copy of the Stage Plan the Project Board may prefer to receive an updated copy of the Product Checklist, showing status and any revised dates. Often the frequency of Highlight Reports is defined for the whole project in the Project Foundation Document, but the frequency can be varied for different stages. For example, the Kick Off Stage is normally very short, and the Project Board may request either no Highlight Reports or a lower frequency.

A Highlight Report's purpose is to allow the Project Board to 'manage by exception' between End Stage Assessments. The Project Board is aware of the Stage Plan to which it is committed, and of the tolerance margins that it agreed with the Project Manager. The Highlight Reports confirm that progress is being made within those tolerances. Early warning of any possible problems is reported to the Project Board via the Highlight Report. The Project Board can react to any problems that are reported, as formally or informally as it feels is necessary.

Exception Report

An Exception Report is a warning from the Project Manager to the Project Board that the Stage (or Project) Plan will deviate outside its tolerance margins. It is a wise precaution for the Project Manager to document the report.

There are situations where it is the tolerance for the whole project that is at risk, and not just that for the stage. For example, information may be found which shows that a major equipment expenditure, which is to be made much later in the project, will greatly exceed current expectations and take the project outside tolerance.

An Exception Report describes a forecast deviation, provides an analysis of both the exception and the options for the way forward, and identifies the recommended option.

Where the project is part of a programme, exception situations may occur because of changes or problems at the project or programme level. Examples would be a business change or the late delivery of an externally purchased product that may impact the whole programme or just a single project. Changes in end dates or to the specification of products to be delivered by the project are likely to have a knock-on effect in the programme. To avoid duplication of effort and to save time, those exception situations likely to impact more than a single project within a programme should be co-ordinated at programme level.

End Stage Assessment

Part of the philosophy of breaking the project into stages is that the Project Board only commits to one stage at a time. At the end of that stage the Project Board takes a good look at the project to decide if it wishes to proceed to the next stage. This review is called an End Stage Assessment. According to such factors as project size, criticality and risk situation, the End Stage Assessment may be formal or informal. However it is done, the End Stage Assessment is a mandatory control point at the end of each stage. The assessment approves the work to date and provides authority to proceed to the next stage. A stage should not be considered complete until it has received this formal approval.

An End Stage Assessment has the specific objectives to:

The Project Board has the right to refuse to approve the Next Stage Plan if it is unhappy with any of the aspects mentioned in the list above. It can either ask the Project Manager to re-think the Next Stage Plan, force closure of the project, or refer the problem to corporate or programme management if the problem is beyond its remit.

End Stage Report

The End Stage Report is the vehicle through which the Project Manager informs the Project Board of the results of a stage. The Project Board can compare the results in terms of products, cost and time against the Stage Plan that it approved.

The End Stage Report contains all the information described for an End Stage Assessment, except the approval to proceed to the next stage. It forms a record which can be audited at any time in the project, giving a summary of what happened in a stage, the impact on the Project Plan, Business Case and risks, and why decisions about the future of the project were made.

Mid Stage Assessment

A Mid Stage Assessment is held between the Project Board and Project Manager after an Exception Report. If any of the Project Board's assurance responsibilities have been delegated, the people to whom assurance has been delegated would also participate. Its purpose is for the Project Manager to present an Exception Plan to the Project Board and obtain its approval for implementation of the plan. As with the End Stage Assessment, it may be formal or informal according to the size, criticality and risk of the project.

The content of an Exception Plan is the same as that of other PROMISE plans.

Every exception has an impact on the stage, project, Business Case and risks. The recommended option will also have an impact on the same items. The Project Board must consider both sets of impact.

Controlled Close

Before the Project Board allows the project to close (unless the project has been prematurely terminated), it has the control to ensure that:

At Project Closure the Project Board must confirm in writing (for the project management file) its acceptance that the project has been completed. If necessary, these statements can be qualified, e.g. that the products have been delivered with minor deficiencies which can be rectified later.

The following information is generated at the close of the project that leads to control actions by the Project Board.

End Project Notification

The End Project Notification advises all those who have provided resources or services to the project that the project is coming to an end.

Lessons Learned Report

The Lessons Learned Report is created within the project to disseminate useful lessons learned during the project for the benefit of other projects.

It covers management, specialist and quality processes, techniques and tools, what worked well and what caused problems. It is a useful control as part of the functions of an independent quality assurance or similar group.

The Lessons Learned Report is gradually built up (and acted on) during the project and handed over as one of the products at Project Closure.

Follow-on Action Recommendations

At the close of the project there may be a number of actions left undone. For example, there may have been a number of Requests For Change which the Project Board decided not to implement during the project, but which were not rejected; not all expected products may have been handed over, or there may be some known problems with what has been delivered.

The Follow-on Action recommendations document any unfinished business and allow the Project Board to direct them to the person or group whose job it will be to have the recommendations considered for action after the current project has ended.

End Project Report

The End Project Report is similar to the End Stage Report, but covers the entire project. The End Project Report reviews actual achievements against the Project Foundation Document. Where possible the achievement by the project of the benefits anticipated in the Business Case is reviewed. Any changes that were made after the Project Foundation Document was agreed are identified, and their impact on Project Plan, Business Case and risks is assessed.

The report provides statistics on Project Issues and their impact on the project, plus statistics on the quality of work carried out.

Post Implementation Review

The Post Implementation Review occurs outside the project.

Normally many products need time in use before the achievement of their expected benefits can be measured. This measurement after a period of use is an activity called a Post Implementation Review. At Project Closure a plan is agreed on when and how achievement of benefits can be measured.

A Post Implementation Review occurs after the project has closed. Any corrective work identified by the Post Implementation Review would be done during product use and maintenance. Any problems may not be with the product, but organisational ones, needing such solutions as retraining.