Project Management Step by Step: The Proven, Practical Guide to Running a Successful Project, Every Time - page 36

Key tips

• Consider whether the deliverables from your project need to be tested and implemented, and if they do how you are going to do this.

• Be prepared, if necessary, to provide some support to your customer for a short period after the deliverables have been implemented.

• Control the release of people from the project.

• Don't forget to celebrate your success!

• Build your Project Plan and Project Budget to include the necessary tasks in this chapter.

• If you are running late, or short of budget, avoid the temptation to skip these tasks.

References

• This subject is more related to development approaches (such as software development or engineering development) than pure project management, but is essential to good project delivery. A few specific references are:

  The Definitive Guide to Project Management (Financial Times Prentice Hall) by Sebastian Nokes et al ., 2003, Chapters 10 “11.

  The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 2003, Chapters 8 “11, 27.

Conclusion

Now you have completed Project Management: Step by Step , and if you follow the steps in this book you can manage a project. There is a little more information in the Appendix and a glossary to reference.

You started in Chapter 1 by building up your vocabulary and understanding of simple project management concepts. Then in Chapter 2 you learnt how to clearly define the objective of a project in a Project Definition. By following the activities in Chapter 3 you learnt how to build a Project Plan, and by following Chapter 4 you saw how to manage a project. Chapter 5 showed you how to ensure your project finishes successfully. Supporting these chapters were the 'Key drivers for success', which highlight the best styles of working to achieve your project goals.

There is much more about being a really great project manager, who can deliver the largest and most complex of projects. However in most situations, what is in this book, if applied well, will greatly enhance your chances of success. Reference the material here as often as you need to.

The more you practise, the better your skills as a project manager will become. And in the end, project management is a practical rather than a theoretical subject. Review what happened after every project and learn from your successes and your mistakes. When you have the opportunity, observe others and learn from them too.

For now though you have completed this step-by-step guide, and you can call yourself a Project Manager. Good luck and enjoy it!

Appendix

This appendix provides some additional information that may be useful to you in running a project, but which is not core to project management. The topics here typically do not impact simple or smaller projects, however it is useful to have a summary understanding of them.

Collecting requirements

For some projects, once you know what the deliverables are, you have all the information you need to develop them. For others, you need a series of more detailed information about the deliverables that together precisely specify the deliverables. This more detailed information is called requirements, and the complete collection of requirements is called the requirements catalogue or requirements specification. For example, in the office re-fit case study used in Chapters 2, 3 and 4, the project scope included putting new furniture into the office, such as desks and chairs. This was enough information to allow the project to be planned and managed. However, there could be some very specific additional detailed information, such as the type of chairs required, the number of drawers needed for each desk and so on. These more detailed pieces of information are examples of requirements.

Some very large or complex projects have thousands and thousands of requirements; moreover in large businesses there is a specialist discipline, business analysis, whose role is primarily to analyse business problems and develop the requirements list necessary to overcome them. It is beyond the scope of this book to give a detailed description of what is in itself a complex and specialist discipline. In large projects, for example in software development, one of the first major stages of the project is often to collect requirements, which can take many weeks in its own right.

There may be some situations in which you want to collect more detailed requirements than you would include in the Project Definition, but do not need to go to the extent of employing professional business analysts. (Remember the information in the Project Definition was there so you could scope the project, not so you know every detail of every requirement.) The aim is to get an exhaustive set of requirements that goes beyond the limited scoping information in the Project Definition and which fully defines the deliverables.

The way to develop requirements is through a series of structured interviews with your customers, to gauge exactly what it is they want from the project. If you ask people what they want delivered, they may go on giving you far more requirements than you can possibly deliver. So it is important to understand that every requirement typically adds some time and some cost to the project. Therefore when people are giving you requirements, you should understand whether these are:

• Mandatory. The project will not be complete without them, and your customer will not be satisfied without them. Unless all the mandatory requirements are met by the end deliverables from the project, it is a failure.

• Nice to have. Whilst not mandatory, these are requirements the customer really wants you to fulfil, and unless there is a good reason, usually in terms of unacceptable extra cost or time to the project, you will try to deliver these as well.

• Optional. Requirements the customer wants you to fulfil if it is reasonably straightforward, but will not be too worried if you cannot.

A simple example requirements catalogue is shown in Table A.1.

Table A.1. Example of a simple requirements catalogue

No.	Requirement description	M	N t H	O
1	Each member of staff will have a suitable office chair that conforms to our business standards
2	Each member of staff will have a desk with an integrated drawer unit, space to work on and space for a full sized PC.
3	Each member of staff will have additional storage space for two archive boxes near their desk.
4	For every four members of staff there will be an additional chair for visitors .
5	There will be five additional tables which can take up to four chairs for informal meetings.
6	The six secretaries' desks will have a second drawer unit to account for the additional paper work they deal with.
Key: M = Mandatory: NtH = Nice to Have; O = Optional