Project Management Book

"If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it."

Chapter 14 - Project Management Routemap

We have covered a lot of ground - to some readers familiar territory, to others much will have been new. Particularly for the latter, let us see how some of the major themes we have covered might come together and wrap around a project.

Project Management Routemap

Project Management Book

Project Management Book

One morning you're driving in to work and you have a mega-brilliant idea: you envision a new IT system that would make your company a fortune. What would you do when you got into the office? (No, not resign, it wasn't that good an idea.) You discuss the idea with a few people and everyone agrees it is a great idea.

And there it might end were it not for the fact that you are a natural, entrepreneurial project manager.

Project Management Book

You approach a senior manager who you think would make an ideal project sponsor. The first question he asks you is "what would such a project cost?" But you're not falling for that. You tell him you've got no idea. "OK," he says, "how much would it cost to find out what it would cost?" You're ready for that one. You tell him it will cost £60K to do a proper project definition. Which implies, does it not, that in preparation for your pitch you did a fair bit of preliminary planning for the project definition stage.

The senior manager can't authorise £60K so he takes his great idea (yes, his great idea!) to whoever does authorise project expenditure - maybe the Board of Directors - and they approve a speculative investment of £60K to research and define this potential money-spinning project. Our senior manager has now acquired the mantle of sponsor.

Meanwhile, in anticipation of Board approval, you have been rushing around finalising the project definition plan.

Project Management Book

Project definition is going to take 10 weeks. Twenty five people will need to be involved and they are owned by 10 different managers. This is not 25 people full time for 10 weeks. Maybe there will be 2 or 3 full time people to drive it through, business experts spending a few days defining high level needs, IT guys assessing options and feasibility and doing some estimating, and Finance guys helping you build the financial justification, etc.

You spend a day or so building the project definition stage plan and twisting managers' arms to get them to agree to make the necessary people available. You write the stage agreement for the project definition stage which summarises the plan, says what you're going to deliver (PDD, business case, project plan, etc) and documents which managers will provide what resources - and you get those managers to sign it.

You invite the sponsor to pop down and have a chat with your project definition team. The sponsor tells them that his(!) vision is in their hands, that he thinks the project could have big benefits for the company and asks to be kept informed.

Work starts in earnest to give the vision substance, to define the (potential) project. First, was the vision actually just an hallucination? Setting enthusiasm aside, the team step back and ask: is there really an opportunity here, was it really such a good idea? Depending upon the circumstances, this could entail market research, competitive analysis, assessing workload savings or any number of other ways of establishing that the need/opportunity is real.

But the sober reflection only strengthens the realisation that this is a very good idea indeed - there is an opportunity for the company to make a lot of money.

Having established the opportunity exists, you set aside the eureka solution you imagined in your car that morning and you consider how else the need might be met. Buy a package? Modify an existing IT system? Develop a new system? Adopt a manual approach? Outsource? Having brainstormed loads of whacky and some sensible solutions, you conclude the best bet would be to write a new IT system from the ground up.

You now start to consult potential users (key ones' time having been committed via the stage agreement). They all think it's a terrific idea and Marketing say "wow, and could it do this sort of thing as well..?" and HR say: "ah, and if it could do this... we could use it for..." and Finance say "and could it also...". Everyone you speak to has something they would like included in this new system. You realise you have a tiger by the tail and it dawns on you that to try and do everything everyone would like in one go would result in a never-ending big bang disaster project.

So what do you do? You break it into releases and have those tough negotiations: "sorry, Marketing, your stuff will be in Release 3 (maybe)". The scope of Release 1 thus begins to emerge from the mist. Perhaps you now do some high level process modelling to try and get a clearer view of the things you are going to include in Release 1. That helps you understand what it will take fully to analyse the detailed requirements for those things so that you can start to do some estimating and planning for the Requirements Analysis step.

If you're smart (let's assume you are) one of your project definition team is the person who will work for you as project leader (if the project gets the go ahead) and he has time in the project definition plan to help you do the planning of the project proper. The scope of Release 1 is now fairly well pinned down so you and your project leader rough out the high level plan for Release 1 on the back of an envelope and reckon three management stages would be appropriate: Stage 1 Requirements and UFD, Stage 2 IT Technical Design, Build and Unit Test and Stage 3 System and User Test and Implementation. The IT guys come up with some estimates, you use some rules of thumb to work out what the user costs might therefore be, think about the risks and 'unexpected' costs you might end up incurring in the project then get the whole estimate looked over by project support and the man hours translated into money by Finance and conclude Release 1 will cost around £1M - including bags of contingency given the number of unknowns there are at this stage. The users on your project definition team estimate the bottom line benefit that will accrue to the company from the new system and think it will be at least £1M a year. A pay back within 12 months - pretty good.

You go and see the sponsor and tell him what you think Release 1 will cost. He says: "How much?" but he approaches the Board who approve in principle a £1M budget for Release 1.

It starts to become clear who you will need on the project steering committee, who would make a good project user manager, etc, so you sit down with those people and describe the roles you'd like them to fulfil, get their backing for the project, agreement to scope, etc. You and the project leader flesh out the plan for Stage 1 (Requirements and UFD) and start to get outline resource agreements with relevant line managers. You set the Finance guys to work building the formal project business case.

You are now in week 8 of the 10 week project definition stage. You hold a (pre-planned) project definition workshop (PDW). Sponsor, steering committee members and project role players all attend.

You run through scope, roles, plans, estimates, resource requirements, risks, how you'll manage issues and changes, what you'll communicate to whom, what might be in Releases 2 and 3 and so on, and due to your assiduous lobbying prior to the meeting everyone present agrees to everything (if only it were so - in practice there will be issues to resolve despite all the lobbying).

Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
This book must not be copied either as is or in modified form to any website or other medium

Home   Sitemap   Contact Us   Project Management Articles   Project Management Book