About Us
Site Map
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Contact Us



Common Problems with the Project Plan

"Project planning is difficult because of all the different variables and unknowns that go into the process, how they integrate together, and ultimately how they relate to a moving target. There are just so many problems that it's little wonder that surveys continue to show that three-quarters of all projects fail in one of the important measurements of on-time, on-budget, or meeting all the functional requirements."

"While some problems can be mitigated, the real challenge facing project managers is that some uncertainties cannot be resolved during the planning phase. Some answers are not available, things change, and more accurate information ultimately becomes available. Uncertainty is an undeniable part of project planning and cannot be wished away, mandated away, or yelled away."

"Consider the following specific issues that can impact the accuracy of a project plan and judge how realistic it would be to overcome all future uncertainty in the collective answers - while the clock is quickly ticking during the project rescue:
  • People issues  Will the appropriate resource be found and hired according to an established timeline? Will the resource suffer through a personal problem that could impact their work on the project? Will the resource find a significantly better paying career opportunity? What if the resource is not as competent or knowledgeable as he or she appears?
  • Timeline issues  How do we accurately estimate the length of each task? Previous benchmarks are not exactly the same as the project in question. As commonly stated with financial results, past performance may not necessarily be indicative of future performance. How will all the little uncertainties in individual tasks add up in the final result?
  • Vendor issues  Will the vendor's resources buy into your tight timeline? How can you guarantee this? Is the vendor able to put your interests above their self-interest? For how long? Under what conditions? How do your different vendors work with each other?
  • Detail issues  Is too much detail being included in the project plan? Do you have enough information to go that deep? How can you confirm the accuracy of the underlying assumptions? How much work will be required to fix the details when more accurate information becomes available?
  • Prioritization issues  How do you know that other priorities will not impact your project in terms of the availability of resources in the future? How do you stop legislative issues from hurting your dependencies? What happens if a key executive changes and has a different set of priorities, but still expects the same results?
  • Policy or process issues  What happens when a developer wants a $5,000 development computer, while the CFO is not willing to sign off on it because of a $2,000 machine that could be used in the evenings? Which executive processes are making it difficult to get things done in the trenches? What if this de-motivates key resources, perhaps even causing them to leave the project? What if the resources are just de-motivated and working inefficiently? How will you even know, and what can you do about this?
  • Ignorance issues  'You don't know what you don't know.' This is perhaps the biggest cause of project failure. It is also a big contributor to most arguments. Everyone is proposing an answer, and it generally takes a lot of time to empirically prove the correct direction. Known risks have a chance of being mitigated. It's the stuff that you don't know about that can't be assessed in advance.
  • Distance issues  How do you get employees in different time zones to get involved in the project, while supporting their local customs and way of life. This is becoming even more important with the growing popularity of offshore development. How is information shared? Does it take a day just to pose a question in Asia, get an answer in North America, and then a response in Europe?"

"Not all of these will be a problem on every project. But there will always be some uncertainty about which ones to mitigate and by how much. Trying to defend against all of them would be cost prohibitive or impractical given real-world deadlines."

"The figure below shows a process for building a project rescue plan. These activities offer another level of categorization for the list of potential problems that can affect the process, as discussed in the text that follows."

Building a Project Rescue Plan
Building a Project Rescue Plan

Basic Assumptions

"Why do we make assumptions? Some people say that you should never assume anything. They insist on doing the research to be sure. By all means do this; however, as we've examined previously in this book, the act of making assumptions cannot be entirely banished. Even accepting something that two people tell you requires you to make an assumption that they both cannot be wrong. Similarly, you may make the assumptions that a business owner understands their business and can be trusted to sign off on the business requirements."

"Your goal is to rely on assumptions that are as close to being facts as possible. This requires you to dig deeper before accepting what you hear, and to get other sources, including external best practices that support the assumption."

"Project plans are based on assumptions at some level. Do everything you can to ensure that the assumptions being made are true. The team and especially the project sponsors need to agree with this and also need to accept that there must be a collective resolve to move ahead if an assumption proves to be invalid. This is an absolute requirements."

Formulating the Plan

This section describes the first step in the plan building process: Formulating the Plan. It describes the methodology, estimation, and building the core team.