Forget templates and schedules - understanding is the key

I'm out here in India with a very small charity. The founders have a bit of background in large corporates (or large charity organisations, which can basically be seen to operate in a similar way) but the majority of the rest of their staff have no such background. They all have training in social development, but that's it. The problem is that they're being asked to be project managers.

Project Management is a skill. It's not something that comes naturally to everyone (some would probably say anyone!). You need training and experience. I'm not claiming to be the perfect project manager by the way, far from it, but I've learnt a lot from some very good people over the years.

So where do you start when you are literally beginning from scratch. These people are already running projects, they are (nominally) planning, creating status reports and budgets - but it's all so ad-hoc and disorganised that most of it appears fairly worthless. It's a house of cards, all four corners are shaking and you've got to pick one to strengthen first!

The approach I'm taking is to not ask them to change anything. Yet. I want to get them starting to think like project managers a bit more. We're starting regular review meetings with each Project Co-ordinator to discuss the state of the project. These meetings will be asking them the sort of questions I would expect to see answered by default in status reports, project plans etc. "Are you on track to finish in time?", "What issues are you facing at the moment?", "What is your plan for next month?", "What is the reason for this difference in the budget?". The problem is that at the moment they don't see the benefit in answering those questions, so there is no thought given to them at all. These artefacts are produced because they have to, not because they are seen as useful.

You need to understand why you're performing a task before you can commit to it. Asking someone to produce a report in another template, or update their budget more regularly doesn't achieve anything if they don't know why they're being asked to do it.So that's what we're focussing on first - understanding the why. We'll get to the how and the what later.

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!