I’m a software developer at heart and I love planning. A lot of development hinges on planning; you analyse the problem, plan how you will write code to fix it and then execute the plan. My love for planning made it easier for me to transition from just being a developer to being a project manager and eventually a consultant too. They all involve planning, just of different kinds. Plans traditionally need to be created towards the start of a project, between when you divine what is needed (requirements analysis) and when you deploy millions of lines of code. It turns out that the large portion in between is rarely as linear as a developer would like it to be and as the project manager, it’s up to you to manage that mess. Traditionally, the primary weapon in your arsenal to do this is the project plan. Unfortunately it’s often misused and sometimes isn’t the right tool for the job at all. The key to solving this is to look at why and when we do the planning.

Why Do We Plan?

Map The Work

This seems like a simple question with a simple answer; to map out how and when the work will be done to meet the requirements of the project. On the face of it, this is correct and works well in straight forward use cases.

As soon as you enter a real world project though, you end up having to learn How To Draw A Horse. The requirements are rarely static, stakeholders often change their minds, other work gets prioritised or something else interferes with your best laid plan and you now have scope creep on your hands. Managing the constantly moving goal posts is made easier with lots of project management frameworks, tools and methods, which I’ll talk about in a bit.

Mapping out the work isn’t the only way a project plan is used by lots of organisations, particularly those with multiple levels of management. The secondary use of a project plan is communication.

Communication

Many organisations use a project plan as a Magna Carta, something that has been signed off and distributed up the chain, or to clients, and treated as if it is carved in stone. Wanting to change or update the project plan therefore causes a ripple effect up the chain, forcing each sub-ordinate or account manager to provide answers as to why the plan has changed and/or why the issue wasn’t foreseen in the original plan. This, as you can imagine, causes compounded pressure to be exerted onto the project manager from the multiple levels above seeking answers. This is death by project plan.

As a result, keeping the project plan up to date often becomes the driver of the project and distracts from managing the actual work. To avoid this situation we need to focus on why this happens. With each level of abstraction, project knowledge and/or domain competency is lost, thus making communication more important with each step. A project plan is used as the common denominator piece of information used to communicate across many levels. Unfortunately, this practice is predicated on the project plan being static, which we know it’s not, and hence the ensuing injustice on the poor project manager. In the same way that communication is the cause of the issue, it can also be the solution though. Communicating to stakeholders the changeable nature of a project plan from the start helps remove the dependency on a fixed project plan. This isn’t enough in itself, the need for a common denominator communication tool still exists, just on that is more up to date. Tackling this depends on when the project planning is done.

When Do We Plan?

Not Just At The Start

As well as plans being created at the start of a project, they also need to be done as things change through the course of a project. To transition mindsets away from a static project plan done at fixed points in time, many believe the project plan should be a “living document”. While the living document strategy is a step in the right direction, it is still a step within the confines of those who see projects as linear progressions. Keeping a document up to date takes away from managing the actual work and should not be the focus of a project manager. The key is to deprioritise the project plan once the project begins, or do away with it all together.

Always Be Planning

The project itself should become the living entity, ever adapting to the work that’s being done and the changing requirements. Doing so removes the dependency on the document but the communication problem still needs to be addressed. This is where the aforementioned methods and tools come riding over the hill. Methods such as agile (depending on how you use it) help to transmogrify the fluctuating maelstrom of project requirements into building blocks of linear development, without the whole thing falling apart. The planning becomes intertwined into the process at every step and is no longer a fixed piece of work done only at fixed points in the project. The tools used to manage this process can also act as the coveted communication tool needed to send information up the chain or out to clients. A multitude of online tools exist like To-do lists (Asana), Kanban boards (Trello), burn-down charts and sprint backlogs (Jira), bug-tracking (FogBugz), overall project management (Teamwork) and many others that help you manage your project while at the same time allowing you to generate reports/views to send out as project updates.

This approach frees you as the project manager to focus on managing the work and gives all stakeholders an up to date view of the work being done, thus avoiding death by project plan.