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 meas- urement 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 occasion- ally it is necessary.
When the plan or budget does need to be updated, then go through the relevant parts of Chapter 2 again.
Key tips
● Remember, slippage occurs one day at a time. Keep on top of progress. You do not suddenly become two weeks late, you become two weeks late one day at a time.
● To understand your progress, you should look at your absolute posi- tion relative to the plan, and the trend in progress.
● Contingency should not be used up faster than a project is progressing.
● After identification, risks and issues should have actions allocated to a project team member to resolve them. This action should be managed like any other task on a project with a target date for completion.
● Do not let change happen to a project in an uncontrolled manner.
● Project management is about taking action to overcome anything that gets in the way of meeting your objectives.
● Good project managers ensure their customers know how the project is progressing on a regular basis.
● The likelihood of success in projects will be increased not only by following the correct process, and understanding what a project manager needs to do, but by applying this knowledge in the most constructive way. Be hands-on, communicate regularly, and manage your customer’s expectations.
REFERENCES
● Copies of the report, risk, issue and change forms in MS-Word and MS Excel format can be downloaded from the web site at
http://www.pearson-books.com
● As this subject is core to project management, almost any book on the subject will cover this, although some are better than others.
Some books of several hundred pages simple cover one topic, such as risk management, but this level of expertise is really only required in very specialised situations. Some optional references to try are:
The Project Workout(Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999 Chapters 21–25.
The Project Manager: Mastering the Art of Delivery(Financial Times Prentice Hall) by Richard Newton, 2005, Chapters 5, 7 and 10.
The Definitive Guide to Project Management(Financial Times Prentice Hall) by S. Nokes et al., 2003, Chapters 4–7.
Practical Project Management: Tips, Tactics and Tools(Wiley) by Harvey A. Levine, 2002, Chapters 4–8.
TO DO NOW
● Get ready to start your project. Are you comfortable to run a mobil- isation session for the project team? It’s worth planning this out fully. Do it well and you will have a motivated and energised project team; do it badly and confidence in your skills as the project
manager may be dented.
● Get your project administration clear. Make sure you have all the paperwork and forms you need, know how to use them, and are clear about who on the project team has access to them. Will you send forms out by e-mail, make them available on a web site, or use hard copy paper versions only?
● Plan out your personal schedule and how you will manage actions, issues, risks, changes and progress.
● Make sure the project team members have the meetings you want them to attend in their diaries.
● Make sure your customer is available regularly to discuss issues and progress. Forward book an hour a week in their diary. Even if you don’t know precisely what you will use it for, you will find you have plenty to discuss every week.
Complete your project
Step 5
5.1 Test the deliverables 5.2 Implement deliverables
5.3 Provide support to your customers 5.4 Release resources
5.5 Review for next time 5.6 Celebrate!
1: Understand the basics
2: Define the ‘why’ and the ‘what’
3: Create your Project Plan
4: Manage delivery
5: Complete your project
THIS CHAPTER COVERS:
● How to finish a project – which encompasses ensuring the deliver- ables are complete, correct and usable by your customer.
The activities described in this chapter are performed at the end of a project. However, the tasks described take time and use up resources, and so they need to be included in the Project Plan. Hence in Chapter 3, I proposed reviewing the contents of this chapter to ensure the tasks are planned in advance. The tasks in this chapter are often essential to a successful project, and so they need to be built into project plans and budgets.
Setting the scene
Suppose you have been running a project to write a small piece of computer software for a business. The project team of five people has worked on this for six weeks and has just completed writing the soft- ware. Is your project over?
No. There are still some things to do. First, just because you have written the software, it does not mean it works properly – the software has to be tested. Once it is tested you may have greater confidence that it works, but will your customer be able to use it? Normally you have to spend some time installing it onto your customer’s computers and showing them how to use it, and possibly running some structured training – in other words, the software has to be implemented. Having implemented the software, a few days later they may have some additional questions or they may identify a bug that your testing did not pick up. So it is usually good practice to provide some support to your customer for a limited period after the deliverables have been handed over, to answer their questions and fix any faults they find.
Now you can start to close your project down. The project team can be
‘released’, that is let go to work on another project to develop some other software. But you probably don’t want them all to go at once. They THE CENTRAL POINT IS:
● Successful projects end in a controlled way, with the project manager making sure all the loose ends are tidied up. This often requires testing the deliverables, and making sure your customer understands how to use them.
should be let go at different times, as the relevant parts of the project complete. Also, any money you have not spent from your Project Budget needs to be given back to your customer.
If you are never going to run a project again perhaps you can stop now.
However, if you think you might run projects in future, it is worth reviewing this whole software development project – what did you do really well, and what could have been done better? If you know what to do better and what was done well, when you start to develop your next piece of software you should do it even more successfully.
If the project was a success and your customer was happy with the soft- ware you developed, it may be worth having a small celebration. You deserve it, after all you have completed a project!
Introduction to completing your project
If you have followed steps 1 to 4 in this book, you should now have a successfully running project. However, one of the things that really differentiates the average project manager from the outstanding one who is always in demand, is the way the manager ends a project. Success in projects is not simply about producing deliverables, it is about producing deliverables and giving them over to your customer in the best way possible and making sure they can be used to meet the ‘why’
defined in your Project Definition.
The way you need to complete your project does vary considerably, depending on the nature of the project and the deliverables. There are many factors to consider when ending a project, most of which you will be aware of simply through common sense. However, there are some critical steps for some projects, which are regularly forgotten:
1.Test the deliverables.Do they work, and do they work as expected?
This does not apply to all deliverables. But deliverables like
computer software, a new telephone system, a new machine and so on should be tested to ensure they work properly.
2.Help the customer to use the deliverables.Some deliverables need to be explained to people, or implemented for them. On some
Again, this does not apply to all deliverables. For example, if your deliverable is a report, then customers usually don’t need to be shown how to use it. However, some deliverables are not so obvious to use – so if you have a new computer system, people need to be trained in it. A new office layout may need to be
explained to the staff moving into it. New ways of working, such as revised processes and procedures, may require you not only to train people in how to use them, but also to convince them that the new processes are an improvement. If your deliverable is a new business policy or set of rules, you will need to educate staff on the new policy, and you may also need to explain the implications of the rules or policy and how they impact all aspects of their work. A new machine in a factory will require the operators to be trained.
Whatever your deliverables, you must consider what help the final users and customers may need to gain the full benefit from it.
3.Support the customer whilst they get used to the deliverables, and for a short period when they find out if they are working properly.
Some deliverables require support even if a customer has been trained how to use them. This may be because they are particularly complicated or because some problems do not immediately show up. So for example, with new computer software, it is usual for customers to find bugs after it has been implemented which the developers have to fix. Similarly if some building work is done for a customer, it is common for them to pull together ‘snagging’ lists of all the small things that are not quite right with the building.
The nature of the tasks you need to carry out in step 5 of the project will vary, depending on the type of project and the nature of the deliverables.
So this section is less a list of specific instructions and more a set of questions to ask yourself. By asking the questions in this chapter you should be able to derive the tasks you need to do relevant to the specific situation. (There is also some more detailed supporting information in the Appendix.)
The step-by-step guide