Thursday, 7 October 2010

To Plan B or Not To Plan B...

'I can't put a plan together, I wouldn't know where to start - I'm far happier just getting on with it...'

'It would be out of date as soon as we started working on it.'

'No one takes any notice of the plan anyway, they are all doing their own thing.'

Just some of the phrases I've heard as reasons for not producing a project plan. Of course plans change and of course this means producing another but let's put a few arguments forward for why you should.

I suppose the (almost) obvious one is that if you don't know how to plan, how can you 'get on with it'? Where do you start to get on with it? What do you do first? Isn't that the first thing that would go in a plan, then?

Plans fill a number of functions and are not necessarily just for the benefit of the project manager. They help others assess how well the project is doing against its targets, goals and objectives. Assuming it has any. I'm aware of a project recently that hadn't specified what the outputs would be other than that something would be 'better'. Of course the project manager claimed a success at the end of the project, but was it? There had been no plan so it was impossible to check whether tasks had been done. There were no stated tangible outcomes so it was impossible to check whether they had been achieved. The only outcome was that the process involved had to be 'better' but was that so because one or ten people thought it so? Had anyone checked to see whether anyone thought it wasn't better? Or worse?

If plans start out by listing all the things that must be done they can then be scheduled. Put in order. This can be essential if several or many people are involved and some tasks require other tasks to be completed before they can start.

Yes things will change and when they do everyone involved in delivering the project needs to know how it will affect them. So the plan has to be rehashed and the next version produced, circulated and the previous plan discarded.

The discarding of the previous plan needs to be formally dealt with. There has to be a way of knowing which version of the plan is current. Writing the words current or final version is stupid and meaningless because there is bound to come a time when they aren't. But the words will still be written on them!

So plans need version control. There will be draft plans being produced whilst previous versions are still current, so there needs to be a way of identifying a draft plan and an issed plan. There may be several iterations of a draft before it becomes an issue.

At JISC infoNet we use the following system. Each document has a suffix as the last part of the filename. d1a is a draft copy working towards issue 1 and is the first iteration. If I produce d1a and send it to someone else who changes it, they save it as d1b. Once agreed and issued it becomes version i1. If whilst everyone is working to version i1 another version becomes necessary, someone will produce draft copy d2a. That may go through iterations and amendments d2b, d2c etc. Until it becomes version i2 everyone still works to version i1.

If it is necessary to replan, then having the current working plan in front of us helps us to do that, because there is a list of all the things that need to be done and we can add new ones in the knowledge of where they are best placed and can predict how they will affect other tasks that still remain to be done. We can reschedule everyone's work (this being a draft copy until they have all agreed they are available at those times).

I had a long train journey yesterday and my second train was a little late into Birmingham meaning I missed my third train. Now if you were the train controller and your train was ten minutes late, how could you replan your journey without knowing when other trains were going to be crossing your track? In other words...from the current plan!