Project controls

Clear controls are needed to describe how the project will be kept on track so that it stands a greater likelihood of meeting its stakeholders' expectations. The project controls section describes the following measures.

Project controls: meetings and reporting

This section describes the way in which various control mechanisms will be used to make sure that progress and forecast information is clearly communicated and that corrective action can be taken when necessary.

Although the communications plan will have identified that some meetings and reports will be necessary, this section must describe how they will keep the project on track.

It is usual for the section to include a table (see Table 8.14).

Project controls: escalation management

This section describes what constitutes a significant issue and what

Table 8.14 Meetings and reporting

Control

Participants

Timing

Input

Output

Project

PMT, PSG,

At end of

Agenda, business

Record of actions and

initiation

PM

initiation

case, project

decisions, including

meeting

stage

governance report,

approval to continue

user requirements

document, solution

design document,

next stage plan

Team meeting

PM, team

Every week

Agenda, timesheets or Record of actions and

leaders

records of progress,

decisions, project

draft project forecast

forecast report

report

Scheduled

PSG, PM

Just before

Agenda, business

Record of actions and

project

end of each

case, updated project

decisions, including

steering group

stage

plan, next stage plan

approval to continue

meeting

Unscheduled

PSG, PM

Exceptional

Agenda, business

Record of actions and

project

circumstances

case, notification

decisions, including

steering group

report, revised project approval to continue

meeting

plan, revised stage

plan

project closure

PSG, PM

At end of

Agenda, business

Record of actions and

meeting

closure stage

case, project closure

decisions, including

report

approval to close

project

Lessons

Varies

After closure

Agenda, project

Lessons learned

learned review

stage

closure report

report, action plan

Benefits

PMT, PSG

As described in

Agenda, draft benefits

Record of actions and

realisation

Sponsor

business case

realisation report

decisions, benefits

review

realisation report

actions should be taken if one arises. Escalation conditions for time, cost and benefits margin should be described (see example overleaf).

Escalation conditions

The project steering group will be subject to the following escalation conditions:

E Time +/- 4 weeks E Cost +/- 50,000 E Margin +/- 100,000

If a breach of these escalation conditions is forecast, the project steering group must immediately alert the portfolio management team and present a notification report on which corrective decisions will be based.

The project manager will be subject to the following escalation conditions:

If a breach of these escalation conditions is forecast, the project manager must immediately alert the project steering group and present a notification report on which corrective decisions will be based.

The team leaders will be subject to the following escalation conditions:

If a breach of these escalation conditions is forecast, the team leader must immediately alert the project manager and present an action plan on which corrective decisions will be based.

The notification report should describe:

E the circumstances that have caused the project to be forecast being outside the agreed escalation conditions; E options to address the variance;

E the effect of each option on the project plan/business case; E the preferred option.

Project controls: change control

This section describes how changes will be dealt with if and when they arise (see example opposite).

Change control

Baseline

The basis on which any requests for changes to requirements or functionality will be assessed are the following documents:

E Business case v1.0

E Project governance report v1.0

E User requirements document v1.0

E Solution design document v1.0

Contingency

A contingency fund has been identified as follows:

Risk mitigation 23,300a

Change management 1,000b

Approved changes 52,000c

Total 76,300

a Identified from the risk register.

b Based on 3 person-days needed to assess the effect of any changes during the life of the project. c Based on an assessment of the changes applied to previous, similar projects.

Process

Should anyone consider a change to the baseline (described above) is needed, the matter will be subject to this change management process. Any item raised in this way will be referred to as a change request. Problems that have arisen will be treated in the same way. New and existing change requests will be reviewed at the weekly meeting between the project manager and the team leaders.

These four steps will be taken, using the organisation's standard pro-forma for identification, assessment, effect and conclusion:

E Change request identification. A change request may be identified by anyone inside or outside the project. E Change request analysis. The change request will be described fully by the person who has raised it. If further supporting information is needed, this may be provided by a developer, a customer and/or the project manager. E Change request impact assessment. The change request will be measured against the baseline to decide whether or not it represents a deviation. The contingency change management fund will pay for the necessary assessment.

E Conclusion and decision. The conclusion must clearly and unequivocally state whether:

- the change request is a deviation from the baseline;

- its inclusion would take the project outside the escalation conditions.

If the change request is considered worthy of inclusion and can be accommodated within the agreed escalation conditions and approved changes to contingency funds, the project manager can approve the change.

If the change request is considered to be worthy of inclusion but causes the project to be forecast to be completed outside the agreed escalation conditions, the project steering group can approve the change, drawing on the approved changes contingency fund.

If the change request is considered to be worthy of inclusion and falls outside the project steering group's escalation conditions, it must be referred to the portfolio management team.

Responsibilities

This change management process will be facilitated by the project manager. All other responsibilities are identified above.

Project controls: configuration control

This section describes how the project will maintain control of the products it creates. These questions are a guide to what should be included:

e Which products are to be subject to control?

e Who owns them?

e Where will the products be held?

e How will back-ups be taken?

e How will security be ensured?

e How will the products be distributed and redistributed?

e How will versions be controlled?

e Which version will constitute the baseline?

e How will checks be made to make sure that all products are where they should be?

Project controls: quality control

This section describes the tests that will be conducted to increase the likelihood of delivering an outcome that meets expectations. It can be broken into two:

e Product quality tests. This section will describe any special tests to be conducted on particular products. For instance, the solution design document may need a formal review by the solution design committee to make sure it conforms to the organisation's strategic objectives. The form of special tests should also be described more fully. For example, the formal quality review process may be outlined so that senior managers know its depth and value before committing the money necessary to fund it. e Project quality tests. This section describes tests that will be conducted at stages on large projects or ones that involve many products. For instance, a new computer system may undergo system testing, operational acceptance testing and user acceptance testing. The approach to such tests should be described and the project steering group given the opportunity to decide whether they are prepared to allow the time and money needed to accommodate these quality controls.

Project controls: risk and issue management

This section describes how risks and issues will be managed. It must adequately describe:

e how risks and issues will be identified and prioritised;

e the criteria for assigning ownership;

e how mitigating actions will be planned;

e how progress will be monitored and controlled;

e the process by which contingency funds may be drawn.

An example is as follows.

Risk and issue management

Risk and issue identification

Risks will be identified first during the creation of the project outline. An initial risk identification meeting will be held during the initiation stage. The results will be included in both the emerging business case and project governance report as a risk register.

Issues may be identified at any time and by anyone. They will be documented and processed in the same way as a change request.

Risk owners

Risks will be ranked according to their risk factor (see page 85). Those with a factor of 110 will be assigned automatically to the portfolio management team; those with a factor between 57 and 90 will be assigned to the project steering group; those with a factor between 21 and 56 will be assigned to the project manager; and those with a factor of 20 or below will be assigned to the project team.

Risk mitigation

Mitigations will be identified for every risk. Mitigations will be assessed for their potential cost in terms of money and/or time. The summary of all mitigation costs will be included in the contingency budget (see change control, page 163).

Risk management

The risk register will be reappraised at every project controls management meeting. The reappraisal will:

E identify new risks/issues; E reassess existing risks/issues.

Use of contingency funds

The contingency budget may be drawn upon to mitigate risks, provided those risks have had a contingency sum set aside for mitigation.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment