Monday, 8 March 2010

Planning to make a plan

One of the things I see continuously in this job is plans. Microsoft Project plans. Some are good. The majority of them are very bad. The ones that are good have a good structure, milestones, dependencies and have obviously had a lot of thought put into them. That makes them particularly uninteresting for the purpose of this blog!


My aim for this post is to talk about the poor plans, and specifically one aspect on them - lack of conceptual plans.


Let us take a step back for a moment. Imagine a world for a project manager that is essentially perfect. You have complete control of the resources working for you. You can accurately quantify all of the work that is to be performed, you can build in an adequate contingency level and don't have to worry about costs. Sounds perfect right? Wrong. You've missed something - your dependencies. Every project has them, regardless of how self contained it may seem. It might be talking to the business, it may be getting sign-off from the customer that what you have delivered fits the requirements, but eventually you will have to go outside your project team, and that's when things go screwy.


You see, the biggest mistake most project managers make (and I do mean biggest) is to jump straight into dumping a plan into MS Project. Wrong! You can't do it like that. Or if you do, you need to be very lucky!


The first, and absolutely most important aspect of writing a project plan is to create a conceptual plan first. This needs to show the following:

  • The major deliverable artefacts of the project
  • The workstream responsible for the delivery of that artefact
  • Dependencies for that artefact
The simplest way to do this is with a simple flow diagram. One box per artefact, lines to show dependencies, colours to signify workstreams. Once you've produced this, give it to your workstreams to review, you'll be amazed at how much discussion comes out of something so simple; how many dependencies you hadn't considered; how many artefacts you missed originally.

Now imagine you hadn't performed this task. Each workstream has gone off and produced a project plan to no agreed overall plan. Plan A has included a dependency on Plan B that Plan B isn't even aware of. Project Manager C thinks Project Manager D is responsible for Artefact Z and things are falling through the gaps all over the place.

So when you next kick off a project, or are asked to create a project plan, ask yourself "where's the conceptual plan" - it might just save you a whole load of trouble!