Project Management

Many companies use a structured approach to project-management. Typically they use a documented method like Prince 2 because that makes it easier to hire new people who already understand at least the basics. But few small or medium-size organisations apply Prince 2 strictly, they usually take some shortcuts and use something that could be called "Prince Lite."

This usually works well enough provided whoever designed the shortcuts and the people that follow them understand what has been left out. Structured methods like Prince 2 work by splitting the task into a series of manageable chunks and documenting what questions you need answers to at each stage. As long as you have the right answers by the time you need them how and when you got them is not too important. The risk is that you may find that you missed collecting some information and when you eventually get it you find that some of your past decisions were wrong.

Structured project management does have overheads in the amount of time and effort needed to compile all of the documentation. But what this wins you is insurance against cock-ups. Make sure that the whole organisation knows and accepts this. Put some effort into communicating this to everyone. The message needs to come from the very top of the management tree. Every manager needs to understand that it is their job to make sure that there are sufficient resources, including the human kind, to cover that overhead.

Projects are like novels, they usually have a beginning a middle and an end. Unlike writing a novel you have to understand all three before you start.

The Beginning

The start of the project is to establish what the project is intended to achieve. List all of the things that you expect the project team to do and make sure that you have, or can get, all of the resources you need. Don't start until you have firm commitments from people with the authority to make those commitments. In particular make sure that all of the people on the team get a commitment from their line-managers. If you don't then your team member is likely to get sucked away to do their "day-job" at the least convenient time. Make sure that you understand in advance whether your team members are likely to be busier at certain times. Running finance projects during year-end can be tricky.

The Middle

If a project is bigger than one person can comprehend in its entirety it needs to be broken down into tasks. Understand which tasks are dependent on the completion of which other tasks. The traditional way of documenting this is a Gantt chart. You don't need fancy software to put one together but something like Microsoft Project does make it very much easier. There are also some freeware products but if you expect to be swapping files with people on different sites make sure that you all have compatible software.

When you plot out all of the tasks you may find that some of them make up a "Critical Path." This is the shortest possible path between the start of the project and its end. If any task on the critical path takes longer than expected then the whole project will take longer than expected. Keep an eye on these tasks.

The End

You need to understand what defines the end of the project right from day one. There needs to be a list of all of the tasks that must be completed. Equally important is a list of the things that the project does not include. If you don't have that in black and white at the start of the project you risk people sneaking in additional tasks to meet their own objectives. This confuses the team, extends the life of the project and bumps up the budget. If anyone proposes adding in anything that is on the exclusion list make sure that they have authority to commit whatever additional resources that this takes. If it costs money only accept changes from people who have budget authority.

It's worth working backwards from your success criteria when you build a project plan. What are the pre-requisites for success? What are the pre-requisites of those pre-requisites? Hopefully the plan extending from the start will meet up with the plan extending backwards from the end. If not then you are in trouble!

The project isn't finished when you reach its objectives. You need to take some time to understand what went well and what didn't. What would you do differently next time? The technical term for this is "lessons learned." The lesson you usually learn is not to do it again. Teachers call this a "learning experience."

Bernard Peek