Is Your Project Plan a Useful Tool or a Treasure Map?

3642387-treasure-mapAs all project managers know, for a project to be successful, it must have a good plan. The plan must be rigorous yet reasonable, well researched but realistic. A project without a plan is not going to succeed – accept maybe by accident or luck. But does it then follow that just because a project has the “best plan ever” that the project will succeed?

Of course not. But I have witnessed project managers who are so committed to the plan that they actually put the project at risk. How can that be? By treating the plan like a treasure map. If I just follow each step of the plan to the letter, I will reach ‘X’ – where ‘X marks the spot’ of a successful project. It sounds a little silly when you say it like that, but it’s a useful image to consider when examining your project plan. Will the plan serve as a useful tool to manage the time, activities, and resources needed to successfully fulfill the project objective? Or is it a tightly scheduled forced march to a predetermined conclusion?

I once had a client that insisted that every minute of every hour was scheduled in the project plan, and that no changes to the plan were allowed without executive approval. I tried to show her how unrealistic that kind of planning was, but she had been burned in the past with unsuccessful projects, and believed that this kind of rigid planning was the only way to protect herself from another failure. Unfortunately, it had the opposite effect, and as the project dragged on, tasks got further and further behind. Following a project plan that is too rigid will certainly lead you to where you plan to go, but it may take you where you needed to go. How can you tell if your project plan is a treasure map?

There are no future planning tasks. Have you detail planned the entire project, from initiation to delivery, up front? Even before you’ve completed your analysis, decisions, or designs? If you’ve done this project before – meaning you are specifically replicating a previous effort, like building a boat, then that’s fine. You know the recipe; you know the resources. But if this project has any unknowns, any problems to be solved, or anything new to learn – don’t assume that you know how it is going to go. This doesn’t mean not to plan, but use planning packages. Create decision tasks followed by planning tasks – this allows you to detail plan based on the results of research or design, and the decisions that have been made. It’s these subtle adjustments to the plan that allow the project work to dictate where you go rather than forcing the project along the path you set at the beginning.

There is no breathing/thinking room. Have you detail planned every hour, every day, every week for your project team? I’ve seen this so many times, and it never succeeds. People need time to think, to react to changes, to deal with unexpected events. So how do you build this time in? There are a number of techniques. One can be to set your resource management settings to only schedule 80% of each resources’ time. Another is to put time based packages into each phase that you assign to each resources as needed. I call these packages research or analysis time – and they are defined as time for evaluating, communicating, and sharing project activities. In addition to thinking time, I also encourage this time to be used to break down silos and build relationships among the project team.

Risk management activities are not built into the plan. If you are maintaining a risk log, but are not including risk mitigation tasks in your plan, then your plan is incomplete. The whole point of mitigating risks is to manage the risks and issues that arise during the project. If you haven’t made room for managing risks in your plan, then it is too rigid to be a good management tool. A treasure map plan by default assumes that no risk will alter the plan. Be aggressive about deploying resources to manage risks as part of your project plan.

There is no mechanism for reacting to alternatives. This often goes hand in hand with not including planning packages throughout the project, a plan that doesn’t leave room to adjust to interim results is too rigid. What does this mean? In one traditional waterfall methodology, for example, there is an analysis phase, where requirements are clarified and refined, and alternative resolutions are researched and selected. Then there is a design phase which takes the results of the analysis and designs the details to be developed. Then the development phase results from the design phase, and so on.  Have you ever constructed an entire detailed project plan before the analysis phase even begins? You build it based on a large (and often undocumented) set of assumptions, but then you have to shoe-horn the later phases in to fit the initial plan? There is an alternative – Plan the phases based on the results of the previous phase. Build planning packages to account for constraints, milestones, resources, and risks, and then expand the packages as you arrive at the identification and selection of each alternative.