The step-by-step guide: Step 4 Managing delivery

The step-by-step guide:
Step 4 Managing delivery

Step 4.1 Start the project

Projects do not start by themselves just because you want them to, or because you have developed a plan. Projects require a push to get started. This push is something you, as the project manager, must give the project team.

Before you give your project this push, it is usually worth having a final conversation with your project customer, to:

Confirm the Project Definition and that there are no last-minute changes.
Clarify the implications of the Project Plan. Make sure the customer understands and accepts what the project will cost and how long it will take (including contingency).
Confirm that you have access to the resources you need and it is OK for you now to start using them.

Once this is done it is time to get the project started. The push you give a project is to communicate with everyone involved in the project. Each person in the project team needs to know:

What their role on the project is, and what tasks you are expecting them to do in what order.
When they need to do these tasks.
What resources they will have access to in order to complete their work.
How you expect them to keep you updated on progress.

At this stage it is also worth asking all members of the project team for any issues, concerns, ideas and suggestions. (It is not too late to change the plan if someone has an idea of how to do it better.) It is also important to try and motivate and excite people about the project, as well-motivated people are much more likely to work hard and deliver the result you want.

For a small project this can be done by talking individually to each project team member. For a large project it is useful to run a meeting called a mobilisation session. This is a meeting in which you bring the whole team together and explain the Project Definition, the Project Plan, make sure everyone knows their roles, and respond to any questions people have.

Now the project is rolling!

Step 4.2 Plan your day

You have a complete Project Definition, a good Project Plan and a Project Budget. You have briefed the project team and they are now working. So what do you do on a day-to-day basis? The funny thing is that you are about to manage a piece of work which is planned out step by step in your Project Plan, but the one thing that is not planned in the same way is your job as the project manager. Do not be under any misapprehension though there is plenty to do!

Your job is to make sure that everything that needs to happen, to keep the project going towards the desired end result, happens. Anything can occur on a project and you should start every day by thinking:

What things are causing most difficulty to the project now (typically related to progress and issues)?
What are the things that are most likely to cause problems to the project in future (normally relating to risks and changes)?
What actions are my responsibility to undertake?
Which are the most important things that I need to resolve now?

Having thought this through, you know what you need to overcome so you can plan out what you are going to do today. This will need to be prioritised and changed on an ongoing basis as different issues occur and they will occur every day.

For a project manager it is important to understand that you are not personally responsible for doing everything (unless it is a one-person project) there is a project team. But you are responsible for ensuring that everything happens, and that someone in this team does everything that needs to be done. Your role is like the conductor of an orchestra: you play no instrument, but unless you do your work, the sound from the orchestra will be a cacophony and not the wonderful concert desired.

You know your objective, it is very clear. You know how you will get there, this is also very clear. On top of this, you have a set of tools and techniques to allow you to manage the project. The remainder of this chapter gives you the tools to do what the project manager needs to do:

Steps 4.3 to 4.7 are ways to give yourself the information to make decisions about what you need to focus on.
Steps 4.8 to 4.10 are how you go about doing things once you know what they are.

Step 4.3 Collect information and reports

As your project progresses you need to collect various information so that you can determine what you should be doing as the project manager. If you are working on a project, by yourself and for yourself, then this will happen automatically as the project goes along. However, when there are many people working on a project, you need to put effort into collecting information from them as the work progresses.

Some information will come to you naturally on a day-to-day basis as you interact with people and ask them to do things. However, it is good practice to have a formal update meeting once a week with the members of your project team. You should try to make this meeting as short as possible so it does not get in the way of working on the project. The information you want from each team member is:

What they did in the last week. Was it as planned, and what was produced?
What they plan to do in the next week. Does that match the project plan?
Are there any new issues, risks or changes they need to raise?
What is the progress on any issues, risks or changes they are working on?

Following this meeting you are in a position to report to your customer. You need to consolidate the information from all the people in the project and only provide the key information to the customer, consisting of:

Overall project status are you on track or not?
If not, what will you do to bring the project back on track?
Your current view of the likely outcome of the project.
An overview of what was done last week and what will be done next week.
Any decisions you need from the customer for example approvals to changes.

A simple progress report should be produced which is at most one page of A4. A suitable example of a report format is shown in Table 4.1.

Table 4.1. Example of a project report
PROJECT REPORT		Project Name: Office Re-fit Project
		Reporting period: Week commencing 18 July
Project on track?	No 2 weeks late currently		Estimated completion date	26 August
			Estimated completion budget	355,000
Description of status		- The project generally is running well with few critical issues or problems. However the initial delay in finding a suitable contractor has not been recovered and we continue to run 2 weeks late. In addition, the contractor has advised us that our initial estimates for time to fit the offices were overly optimistic and so we now estimate a completion date of 26 August. This is within our overall contingency, but does give concern that if any unforeseen problems arise we may be late. - However, the contractor's work is slightly cheaper than expected. - If the proposed change to expand the project to 110 staff rather than the current 100 is approved, the project will be extended by a further 4 days and 22k.
Main actions done this week		- Removal of old furniture. - Fitted carpets.
Main actions to be completed next week		- PCs will be delivered. - Start installation of software on PCs.
Issues to be aware of		- Desks cost has risen to 400 per desk, meaning an increase in costs of 10k.
Risks to be aware of		- Risk of late delivery of furniture. - Risk of late delivery of PCs (due next week, but no sign of them yet!). However, will not immediately impact critical path.
Approvals required		- Change raised to expand project to 110 desks.

Although this report is very short and simple, it provides most customers with all the information they need to have a sufficient understanding of the project status. The aim is not to overload your customer with detailed information, but to provide enough to give a good idea of status, to avoid them getting any surprises if there are problems with the project, and to give them confidence that the project is in safe hands!

Step 4.4 Monitor and manage progress

The project manager should be monitoring the progress of the project continuously. This will happen informally all the time as you work on the project, and once a week formally with the project team in your review meeting. The basic process for monitoring and managing progress is to look at what tasks are completed, and what should have been completed and then ask yourself the following series of questions:

Are you on schedule or not, relative to the plan? Are there any trends you are worried about?
If there is any slippage, what is the impact? Are the late tasks on the critical path or not?
How much time are you late? So how much do you need to recover to bring yourself back on track? Are you likely to slip beyond your contingency time?
What options are there for recovering this time?
Which option is best?

Key drivers for success 4: Drive progress relentlessly

A project has a defined objective which is meant to be complete within a pre-defined amount of time. On some days you will find the project team are successful in moving the project forward, on other days they will be less so. Perhaps the task they are doing is complex, or a difficult issue has arisen, or simply the team is not motivated on that day. No one works flat-out all the time, but in your role as the project manager you need to ensure that progress is being made all the time.

When you relax and do not push the project team to keep delivering, they will also tend to relax and progress will slow down. Usually if the odd day or two is lost it can be recovered, but if you are not careful you will be starting a trend for the project to be late.

When slippage has occurred, there are an infinite variety of actions you can take. The actions you choose will depend on the specific situation you are in, but typically include:

Getting your team to do subsequent tasks more quickly. This is often the simplest way of recovering time. It is not always possible, but often if you ask people to focus on your project and put in a little more effort, some slippage can be recovered. If you work to keep the project team motivated and interested in the project, they will often automatically make up for any slippage that occurs. This only really works if you are tracking your project closely and you need the team to catch up a small amount of time, such as a few days.
Accepting the slippage and using some contingency. This is a valid option, but even if you are going to use up some of your contingency you should see if there is another way of recovering the time.
Adding more resources. This sometimes works, but it means you may convert a slippage in time into extra budget.
Looking at alternative ways to do what you are trying to do. There are lots of ways projects can be done differently. If you look at the tasks are there any that can be shortened? Or can any dependencies be removed so tasks can be done sooner?
Changing the project in some way. If you reduce your scope and deliver less, the project can sometimes be done more quickly. This should not be done lightly and always requires your customer's approval, but if you really are going to be late you should ask your customer: 'Would you prefer the project to be late, or on time but deliver less?'
Doing nothing. Accept the slippage and be late. This is a possible option and sometimes you have no choice, but it is not always acceptable to your project customer. If you keep doing this you should ask yourself what value you are actually adding as the project manager.

Key drivers for success 5: Be flexible and creative

Although the progress of a project follows a well-defined plan, the reality is that day-to-day working is very dynamic and constantly raising challenges. You must respond flexibly to the challenges that arise, and recognise if what you are doing is not working, as there is certainly another approach that will work better. When problems arise that seem intractable, try to think in different ways and usually you will find a way around them. Also don't forget to use the project team when there is a problem, asking everyone in the team for solutions will often throw up innovative and practical solutions.

The best project managers adopt the attitude that all problems can be solved, and that by thinking and rapidly applying that thinking, all projects can be successful. This is not to say they do impossible things, but by being flexible and creative in overcoming obstacles on projects, they get around most problems.

A good project manager faces challenges such as late tasks with the attitude that there is always a solution, and actively seeks to find and implement it.

Step 4.5 Identify and resolve issues

At the start of a project you should have very few issues. If there are any, they should have been documented as problems in your Project Definition. However, issues will arise as the project progresses. Unforeseen problems have a habit of occurring; in fact one of the most important tasks of a project manager is in ensuring such problems are resolved. Success in a project is not about having no problems it is about delivering in spite of them! What differentiates really good project managers from average ones is the ability to overcome problems rather than accepting them as facts of life.

As issues are identified they should be reported to you. This should be done by all members of the project team as soon as they are identified. To be sure you are aware of all problems, ask all team members at the weekly review session if there are any new issues. You must keep on top of issues, as the number of them can build up. A large project may have tens or even hundreds of issues.

Once you become aware of issues, document them in an issues log, which provides a simple tool to allow you to manage them. For every issue identify:

What the issue is.
When it was identified.
What impact it is having on the project.
Who is going to resolve the issue? This person is usually called the issue owner.
What the action to resolve the issue is.
When it needs to be resolved by.
When the next update on progress to fix the issue is due.
Whether it is open (still a problem to the project) or closed (it has been resolved and is no longer a problem). This is shown on the issues log as 'O' for open, and 'C' for closed.

An example of part of an issues log for the office re-fit project is shown in Table 4.2.

Table 4.2. Example of an issues log
PROJECT ISSUE LOG			Project Name: Office Re-fit Project
			Last Updated: 8 July
No.	Issue description	When identified	Impact on project	Owner	Action to resolve	Date to be resolved	Update due	O/C
1	We do not have agreement about the version of software to load on the PCs.	31 May	Unless this is agreed we cannot order the correct software and this will delay the project.	Mike	Arrange session with interested parties and decide on software.	17 June	N/A	C
2	There are only two sets of keys for the office and as they are security keys we cannot easily get more cut.	31 May	Without easy access to the office for all staff involved in the project, as and when they require, we risk slowing down progress.	Dave	Allocate one member of the project team to be on site during all office hours. Immediately start process of getting additional keys cut and allocate to nominated team members.	14 June	Confirm who is going to be on site all the time.	C
3	Mike's wife has been taken ill and he needs to take some time off to look after his children.	10 June	We cannot progress on task 4 on the project without Mike's skills, and this will delay completion.	Project Manager	Source contract IT staff to support task whilst Mike is off.	4 July	27 June Met temps and candidate selected.	C
4	The lift has broken down and we cannot get furniture to 3rd floor offices.	16 June	We cannot progress with task 3 on the plan and without this being completed we will delay the project.	Project Manager	Chase lift maintenance crew. Offer extra payment if they come in overnight to fix. In interim contract 3 4 removal staff to carry desks upstairs.	20 June	19 June Confirm repair complete.	C
5	The desks cost more than expected.	21 June	The desks are 400 each rather than 300, resulting in a 10k over-spend. We have sufficient contingency budget to cover this so if it cannot be resolved we will accept higher cost.	Dave	Try to: negotiate discount with supplier. Seek alternative supplier (though not expected to be successful at this time). However if not possible, order desks at higher price as this is on the critical path.	27 June	Desks ordered at higher cost.	C
6	The carpet has been delivered but we are 150m² short.	5 July	We cannot complete upstairs offices without this.	Dave	Carpet the area we can and start to install in those areas. Chase supplier for additional carpet and hold back all payment until it arrives.	21 July	14 July Dave to report to project manager on progress.	O
7	There is insufficient phone cabling for 100 desk phones.	6 July	We will not be able to install all 100 phones as requested.	Dave	Get quote from contractor to put additional cabling in place and then initiate work.	1 August (or will delay installation).	13 July Return quote from contractor.	O
8	The PC supplier can only provide 90 PCs in the first batch.	8 July	We need 100 PCs for all the staff, and so 10 staff will be without PCs.	Mike	Take the first batch of 90. The remaining 10 are not required until late July get commitment to this from supplier. If necessary we can overlap tasks 4.5 and 4.6 and start installing those PCs we have.	29 July	22 July Update on status of order.	O

You should manage the actions in the issues log like any other task on the project and ensure they are being progressed. It is best to review this log on a daily basis to make sure issues are being resolved. Regularly contact owners of issues and ask them to confirm progress is being made. If an issue is having a major impact on the project, or actions are due for completion in the next day or two, phone whoever is responsible for the action daily and make sure it is done. At your weekly review meeting check that the owners are undertaking their actions. Important information in this table is the 'Date to be resolved', which needs to be treated as if it is a task end date on the plan and should not slip. Additionally, because some issues do take several weeks to resolve, by putting information in the 'Update due' column, you can start to ensure that progress is being made even if the issue is not fully resolved.

A sign of a project in trouble is when issues do not get resolved and the list keeps on getting longer and longer.

Remember your job is to manage the project not to do everything. So although you can own some issues, you should not be the owner of all of them unless it is a one-man project team.

Step 4.6 Identify and manage risks

At the beginning of a project, think of all the risks that exist and prioritise them by the impact and likelihood, as described in the section 'Risks' at the start of this chapter. Start by reviewing the assumptions in your Project Definition and decide if any of these add significant risk to your project.

For larger projects, a good way to do this is to run a brainstorm with the project team as part of the mobilisation session. Once you have this initial log, you need to keep it updated. If additional risks are identified, they should be reported to you. At your weekly review session ask all team members if there are any new risks.

Once you become aware of risks, then you should document them in a risk log. For every risk identify:

What the risk is.
What is the likelihood of it occurring.
What the impact will be, if it occurs.
What its overall priority is.
Who is responsible for managing this risk.
What the next action to resolve this risk is.
When any actions need to be completed.
What the current status of the risk is.

An example of a risk log is given in Table 4.3.

Table 4.3. Example of a risks log
PROJECT RISK LOG		Project Name: Office Re-fit Project
		Last Updated: 18 July
No.	Risk	Likelihood	Impact	Priority	Owner	Proposed action	Date to be actioned	Current status
1	This is an unfamiliar project to plan and experience is limited and therefore there is a risk of underestimating time and budget.	M (2)	M (2)	4	Project Manager	We have put some contingency into the plan to reduce the likelihood of this risk.	No action manage as part of project.	As part of normal progress updates.
2	The project extends beyond the time at which the existing offices have to be evacuated, and the new office is not ready for staff. The current date we must leave the existing office is 1 October.	L (1)	H (3)	3	Project Manager	With sufficient contingency this has a low likelihood. However we must keep monitoring the situation. With two months' notice the landlord will extend existing offices at a premium price for an additional one month. We must decide by 1 August whether this is necessary.	Decision meeting scheduled for 22 July	Open and still a risk. Try to resolve this week and decide whether to have extension or not.
3	The office we are taking over is in an old building and has been vacant for some time. We have assumed there are no significant problems which will need to be resolved.	M (2)	H (3)	6	Dave	Perform full survey of office before finalising plan and committing to timescales.	3 June	Closed.
4	In our original plan we have assumed the existing telephony PABX will have sufficient capacity and functionality.	M	H	6	Adam	Test existing PABX and check compatibility with supplier. Consider raising a change to the project to include upgrading the PABX.	Must be resolved by 29 July.	Open testing due this week. Change request prepared in case required.
5	We need to switch off the electricity for a few hours, which requires agreement of all other tenants in building. This may be difficult to get.	L	M	2	Contractor	Monitor situation.		Open
6	Concern that the new desk furniture will not be liked by the staff, creating a bad feeling about the move of offices.	L	L	1	Dave	No action required.		Closed
7	The new phone handsets we have bought are not suitable for the new building.	L	H	3	Adam	Test handsets in building and ensure calls can be made.		Closed
8	The existing cupboard space within the office is insufficient for our needs. We do not intend to install any new cupboards.	L	L	1	Dave	No action current understanding is that it is enough. If a problem there is space for additional cupboards.		Monitor
9	We do not have the landlord's permission for the work we intend to carry out.	L	H	3	Project Manager	Resolve via facilities ensure we have evidence of full approval.		Closed

You should manage the actions in the risk log like any other task on the project and ensure they are being completed. At your weekly review meeting check that this is happening.

Step 4.7 Manage changes

As the project progresses, it is common for the understanding of the end goal to improve, and as a result for it to become apparent that something on the project needs to change. Alternatively, the customer may decide that the end deliverables are not now what is needed and he or she desires to change them. Unless changes are controlled, you will not know what the outcome of the project will be. The project may be late or it could fail or if change is continuous, the project may simply never finish. The way to control changes is via a change management process.

The change management process uses a change control form. Once changes have been identified they should be documented with the following information:

Document what the change is.
Describe why the change is being proposed.
Identify when the change needs to be accepted by, if it is to work.
Identify the impact of the change will it change the length of the project, or the cost? Does it change the level of quality or risk?
Note what the proposed action with regard to this change is.
Keep track of the current status of the change: it can either be 'in review'; it can be 'accepted' (i.e. it is agreed and has been built into plans); or 'rejected' (i.e. the project will continue unchanged).
Sign off from the customer to the change.

An example of a completed change form is given in Table 4.4.

Table 4.4. Example of a change form
PROJECT CHANGE	Project Name: Office Re-fit Project
	Last Updated: 16 July
Description of proposed change
The current project will deliver desks and PC facilities for 100 staff. This change would increase, by an additional 10 desks, to 110.
Reason for change
This would provide the opportunity to shut down the small office in London Road, which has 10 staff in it. Originally this was not viable as the lease is for a further two years. However, the landlord has agreed he will allow us to move out early without penalty so he can re-develop the site. There is floor-space in the new office and if done, we will save the rental on the London Road office from 1 November.
When this needs to be agreed by	22 July
Impact on the project
Timescale: +4 days
Cost: 20k for furniture, fitting and PCs, 2k for additional labour.
Other: Some minor risk implications. PCs are arriving next week; we think an additional 10 can be sourced quickly. The furniture was ordered about two weeka ago and will arrive in two weeks. The supplier has indicated he can provide the additional 10 within a couple of days of completing the main order, as long as he receives the order by 25 July.
Proposed action
We propose that this change is accepted. The timescale impact is minimal, and cost is modest compared to savings.
Status	In review	Rejected	Accepted
Status
Customer approval	not yet approved for review this week
Date of customer approval	not yet approved for review this week

As part of your weekly review with your customer, you should go through the proposed changes and how they will impact the project. Your customer should then decide whether to accept or reject them. If the change is accepted, it needs to be explained to other project team members and, where necessary, the Project Plan and Project Budget must be updated.

For big projects, or those which have a lot of changes, you may need to keep track of all the changes in a change log. An example of a change log is given in Table 4.5.

Table 4.5. Example of a change log
PROJECT CHANGE LOG		Project Name: Office Re-fit Project
		Last Updated: 25 July
No.	Change description		Owner	Current status	Update due
1	Include refitting of all cupboard space in office		Dave	Rejected	n/a
2	Change PC specification to flat screen		Mike	Accepted	n/a
3	Expansion to 110 desks		Dave	In review	29/07
4	Expansion of project to include upgrading telephony PABX		Dave	In review	29/07

Step 4.8 Take action to ensure the project's success

By performing the previous parts of Step 4 you understand your project's progress, you understand issues and risks and the changes that are being asked for. You have all the information you need to manage the project, but managing a project is not simply about understanding it, it is about taking action.

Key drivers for success 6: Be the project manager!

There are always lots of things to do on a project: tasks that need to be completed, issues that need to be resolved, risk and changes that need to be analysed, and customers who need to be briefed on progress. There is sometimes a temptation for the project manager to get involved in doing the work and not focus on managing it.

The title project manager is a deliberate one it is not project doer, project team member, or project worker. The role is to manage the project and it is an essential role. If people simply work on a project without someone looking over, co-ordinating, directing and controlling all the different activities it is unlikely to be a success unless it is a very simple task.

Of course you may be working on a project by yourself, or it may be a very small project, in which case you do not have a full-time project manager, and you will get involved in doing the tasks on the plan as well. However, even in this situation, do not confuse the work of doing tasks with managing the project.

A good analogy is with the conductor of an orchestra. No-one expects a great conductor to pick up an instrument halfway through a concert and start playing. Everyone understands that his or her role is to conduct, and that this is a critical role. The same should be true for a project manager, your role is to manage the project and this is an essential role.

Action can take many forms: you may need to ask permission to access a building; you may need to phone someone to check they are doing the work they are meant to be doing; you may need to buy some stationery for the project team; you may need to hire a contractor to get some work done more quickly; you may need to talk to a project team member to motivate them to work faster, and so on. The actions will cover the spectrum from large and complex tasks through to simple, quick acts. Whatever the actions are, they do not just need to be decided upon and planned, you need to make sure they happen!

Some project managers have the false impression that project management is about monitoring and reporting, with some supporting administration. These are important parts of project management, but the key role of the project manager is to keep progress going on the project and to take whatever actions are necessary to keep this happening.

The action you take depends on what the information you have collected shows. You must assess it all and decide what needs to be done and implement the action in the most appropriate manner. Project management processes and tools show when you need to take action (for example, to recover time so you are not late or to overcome issues) but they cannot tell you how to do this. Now is the time to use your common sense and experience to come up with solutions and having determined solutions, to implement them.

Table 4.6 shows some examples of typical problems on projects and what actions can be taken to overcome them.

Table 4.6. Examples of project actions to overcome common problems
Typical problems	Constructive actions
When the project team starts to create a deliverable, they find the definition provided by the customer is not clear enough.	Get the project team to succinctly define the area(s) of ambiguity. Arrange a short workshop with the customer to clarify all ambiguous definitions.
When the project team starts to create a deliverable, they find that it cannot easily be created in the way it is defined without significant delay or cost.	Generate three versions of the Project Plan, Budget and Definition: A revised plan and budget for the deliverable as described A revised definition to meet the original cost and time. A recommended balance between the two. Present the options to the customer and agree which to follow.
A member of the project team is unavailable due to illness and it is unclear how long the individual will be unavailable for.	Assume the illness will last, i.e. do not be over optimistic on speed of recovery. Assess the impact on the project of not having this person. If impact is significant then look for alternative ways of getting the work done: Can you get another person easily? Is it possible for other team members to do the work, possibly paying for overtime? Can you find and use a contractor? Is it possible to buy a service in from an external company? Select best option and implement.
The project is running late.	Determine if the delay in progress is important or not (some lateness may not be a problem, it depends on the individual situation). Review the plan and determine if the time can be recovered as the project progresses, or by using contingency. Identify other options to recover time. Assess if any option is viable and which is best. Implement chosen option.

Step 4.9 Keep your customer informed

The nature of projects is such that sometimes there will be problems. An unforeseen issue will arise which jeopardises the project, or a risk happens that you cannot do anything about. As the project manager, your job is to try and stop this happening and if it does happen, to minimise the impact on the project. However well you apply structure, rigour and good discipline, you are not a miracle worker and sometimes the project will be late or over-spent.

One of the key differences between a good project manager and a poor one is that a good project manager makes sure that a project delivers no surprises. If the project goes wrong, there should at least have been a prediction that it might go wrong (this is the purpose of the risk log). And when it goes wrong, your customer should know; it should not be a secret. Although giving bad news about a project is never a pleasant thing to do, hiding it and leaving your customer with a potentially bigger problem is far worse.

Often customers are very happy with projects that are late compared to the original plan, or a little over-spent. However, this is only true when they have been kept informed, and understand why it is late and more expensive. Through good information flows, as the project progresses, the customer should be briefed if the project is expected to be late.

Key drivers for success 7: Communicate continuously

Project management is at its heart about people management. It is about listening and understanding what your customer wants, explaining what you want people to do, instructing the team on the order of tasks, and watching for problems as they arise.

Although project management requires you to sit by yourself sometimes, to think through what needs to be done and the best way to do it, it is work that relies on the constant and continuous interaction with people. The best project managers spend a large proportion of their time communicating with customers, the project team, and anyone who can impact progress on the project. This ongoing action of listening and talking is key to successful project management.

Step 4.10 Update the Project Plan or Project Budget

The Project Plan and the Project Budget are your predictions at the start of the project of what it will take to deliver the project. As such, your success is about meeting the timescale and the budget agreed. However, the plan and budget are also tools to help you manage the project as it happens. In some situations the plan or the budget become so different from reality that you need to update them. This should be an uncommon occurrence as what you are effectively doing is changing the way you will deliver the project. You are also changing the basis of measurement of the project.

If any change you make moves a milestone on the plan, alters the overall timescale or changes the budget for a project, you must agree it with the project customer.

The times to make changes are:

If you realise that there is a better way to complete the project. This does sometimes happen and is obviously a good thing!
When you implement agreed changes. If a customer agrees to a change that results in the timeline or budget for the project changing, then the plan or budget must be updated to reflect this.
When the issue(s) becomes unresolvable in the timescale or budget originally allocated and there is a significant resulting overrun in time or money. Changing the plan or budget is not something to be done lightly, and should be done with a heavy heart, but occasionally it is necessary.

When the plan or budget does need to be updated, then go through the relevant parts of Chapter 2 again.

Top of Page