Project Management Book

...chapter 14 continued

Just before the system is due to go live you present to the sponsor and show you've delivered what you promised, users have been trained, help desks are raring to go - you really are ready to cutover. You show the evidence that testing has finished. You predict around 20 bugs will emerge during the first 3 months of live running and make the point that you would have expected 50 or more bugs if the users had not got involved in the requirements and the UFD inspections and simulations. The final cost is £1.22M, well within the final budget of £1.3M. The sponsor gives permission for the system to go live.

You feed back to the line managers of people who have worked on the project to ensure their project performance is reflected in their next appraisal. At the post project party the sponsor visibly pays for the drinks. A month or so after cutover, when it's clear the system works properly and there aren't too many bugs a large bonus cheque finds its way into you bank account and smaller ones into the bank accounts of team members.

Six months down the line the post implementation review shows that the idea you had in the car that morning was indeed as good as it seemed - the system has resulted in extra business cascading in.

Meanwhile, Release 2 started up under another manager in parallel with Release 1 build. Although the original PDD suggested what might be in Release 2, nine months on the world has changed and the Release 2 project definition could conclude it should contain quite different things. You hope the manager of Release 2 follows your lead and invests in getting it right in the early stages. The danger is he thinks Release 2 will be easy because you made Release 1 look easy, not put in the effort you did, deliver a poor quality Release 2 and undermine the system's reputation and yours. But one hopes Release 2 will be as well managed as Relesae 1 and will be another successful project.

That's how large-ish projects might look, what about smaller ones?

Small projects

If you're lucky your project will look more like the one below. A couple of days is sufficient to define and plan the project, rather than ten week's work. A single side of A4 suffices as the PDD/stage agreement/plan combined. The sponsor says: "Yes, that's exactly what I want you to do." You tell him how it's going every now and again. At the end you say: "there it is, boss." He says: "thank you." And that's it.

Whether it is at one extreme as simple as this or at the other extreme as complicated as the earlier chart, or even much more complicated than that, it is exactly the same in principle. The great skill of the project manager is scaling the controls to the need of the project rather than laying the same bureaucratic structures on all projects whether they need them or not.

Conclusion

Well, there we are. Wasn't difficult, was it?

The only snag is that no project is ever quite like the one in the text book - this one or any other. Why? Because each project is unique - they are all different - so short of there being an infinite number of text books you probably won't find one that speaks directly to you about your project.

In much the same way, the Highway Code won't tell you how to do your specific journey from Little Snoring to Auchtermuchty. But adhering broadly to the Highway Code's principles will make it more likely you'll arrive in one piece. The same with projects: adhering broadly to good project management principles will make it more likely you'll succeed.

We hope, having read this book, you have a good understanding of how IT projects should be set up and run. If you have colleagues who would benefit from a similar understanding perhaps you would like to suggest they attend our project management course?

Please click here to go to Project Management Book Appendix

Privacy Policy and Cookies