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?
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.
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?
"And it ought to be remembered that there is nothing more difficult to take in hand,
more perilous to conduct, or more uncertain in its success, than to take the lead in the
introduction of a new order of things. Because the innovator has for enemies all those who
have done well under the old conditions, and lukewarm defenders in those who may do well under the new."
Nicolo Machiavelli c.1505 (trans. W. K. Marriott)
Project management training for team leaders and PMs
Please click here to go to
Project Management Book Appendix
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course