Project Planning

Work In Progress

Project Planning

A project is the embodiment of one or more goals and one or more deliverables.

Plans should therefore start with one or more levels of GOAL (the why), then move on to one or more levels of DELIVERABLE (the what) and then finally on to levels of TASKs and ACTIVITYs (the how).

Only when plans get to more detailed levels should they become TASK/ACTIVITY lists. This is probably the biggest and most common mistake in project planning. If you go straight into task lists you are bound to miss things out, the plans are therefore immediately wrong and, because they quickly become full of detail, it becomes almost impossible to keep the project on track.

By leading the plan with goals and deliverables, even if things are missed (which is far less likely), the essence and reasoning behind why you are doing the project is captured at the top levels and so it is much easer to direct and manage.

Another common failing with project planning is to fail to baseline a project plan because it is not "Correct". Well, I've news - project plans are never Correct. It is far more important to have a project plan that people can follow and improve.

If you follow the principals of having goal and deliverable lead project plans, you will find that it is generally much easier to gain agreement from all sides on the plan outline. If you can get this baselined you can then let other people go off and do the more detailed planning for their areas of expertise (if appropriate), adding to the overall plan in controlled steps.

When creating deliverable elements of the plan, ask the question: Does the deliverable support the parent goal?

When creating task/activity elements of the plan, ask the question: Does the task/activity support the parent deliverable?

In addition to the goal->deliverable->task/activity hierarchy, you should also add external and environment dependencies.

Understanding the real needs

One fundamental thing that, in my experience, cripples projects is the failure to get a true understanding of the real requirements even before the project gets going. At this point, there is likely to be a gap of understanding between business and technical leaders of the project which needs to be filled before all of the true requirements can be captured and presented in a way that is understandable to all.

One powerful way to combat this is to appoint an independent 3rd party as a facilitator.

This person can then build communications bridges and help both sides present all of the requirements to each other.

The formal name for this is a "Requirements Assessment" and it will involve interviewing all of the stakeholders (probably individually as well as in group workshops).

The person appointed to do this work needs to understand people (e.g. psychology and politics) more than either the business or technical issues. Though they will still need at least a basic understanding of these as well.

Project Size and Complexity

One of the largest bariers to project success is that of project size and complexity. It is now generally recognised that projects should be less than 12 months long, preferably less than 6 months if they are to have a reasonable chance at hitting their objectives.

There are a number of reasons for this, some of which relate to the capability of humans and our ability to handle complexity, others relate to the rapid rate of change that most organisations face.

One way to reduce the size and complexity of larger projects is to split a "project" into separate projects along the divides of analysis, design and development/test/implementation. Typically, large IT projects combine all of these stages but this makes the project very large and unweildy. Most industries already split these elements into different but related projects so that the "project" as was now becomes a programme of work.

IT Development Projects

Whilst not a developer, I came across an article on Dynamic Systems Development Method (DSDM) recently. I was interested to note that this follows the same principals of being deliverable/product led.

Here is a brief summary of some of the principals of DSDM: active user involvement is essential, DSDM teams must be empowered to make decisions, the focus must be frequent delivery of products, the main criterion for acceptance of deliverables is fitness for business purpose, iterative and incremental development is needed to achieve a good business solution, all changes during development are reversible, requirements are baselined at a high level, testing is integrated throughout the lifecycle, co-operation and collaboration is essential between all stakeholders

Need examples of good and bad project plans.

If you have any thoughts on this, please get in touch.