How Project Planning Got in the Way of Project Success

Project planning for the sake of project planning impedes project successWhat can happen when project planning becomes solely a technical, process-oriented, contractual activity with little concern for overall project success or the people involved on the project? Let me set the stage for a project planning horror story with the following thought – common sense is not so common.

The contractual requirement was innocuous enough. It made sense and was completely doable. In fact, our firm’s Project Manager welcomed it as a great way to force a periodic plan review with the client executive team and make any necessary adjustments.

According to the contract, the IT contractor (our firm) was to deliver an initial project plan for the entire project, along with a detailed plan for the first three months. The requirement for the detailed plan, if I remember correctly, was to have no task greater than 40 hours duration, and resource leveling to the point that no staff person was over-scheduled.

At the end of the first quarter and each subsequent quarter we were to submit an updated project plan as a formal deliverable. The updated plan was to compare actuals to estimates for the just completed quarter. It was to include necessary adjustments for the remainder of the project based on current progress. And, as noted above, it was to task out the next quarter at the not-to-exceed 40-hour task level with the strict resource leveling requirements.

As an aside, my personal preference would have been to negotiate this requirement to deliver each detailed task plan for the upcoming phase rather than the upcoming quarter. This would prevent major project plan deliverable updates from occurring at awkward points during the project execution.

All went well for the first two or three quarters until the project plan began to increase in size with the addition of each quarter’s detail. It didn’t take long before the plan became a bulky mass of more than 10,000 linked tasks. The project management software that was mandated was not as robust as today’s versions. It would fail while baselining or resource leveling, or at inexplicable random moments. Our project scheduler was soon working around the clock to deliver the plan updates on time.

As the plan became larger and more unwieldy, the client’s Quality Assurance (QA) advisor (who was tasked with the quarterly review of the plan) took longer and longer to review the plan and provide his feedback. Our team was often deep into the next quarter before we received his comments.

This presented a huge logistical problem for our team. The QA reviewer would insist on adjustments to activities and tasks for the next quarter (the quarter that was currently well underway) that were in progress or already completed. He would present long, dogmatic arguments about whether our team was linking tasks correctly or using lag and lead times appropriately, but would have few substantive observations about the tasks and activities themselves. At one point he delivered his review so far into the next quarter that he requested we stop work until we adjusted the plan to his liking and it caught up to where we were in the process. Imagine sidelining 75 staff to satisfy one person’s preferences. It became evident to our Project Manager that his reviews were based on what he had read in books and not from personal experience or best practice.

There’s more to this story, but you get the picture. It should have never got to this point, but it did. In his mind, it was more important to have perfection in the plan (according to his narrow interpretation of the contract) than have the project completed on time. It was more important that the next quarter’s detail conform to his view than alleviate the frustrations of project staff whose efforts were being disrupted by his antics. This included the client staff loaned to the project.

He was the type of individual who would rather be right than be successful. And the client’s key stakeholders abdicated their responsibility to move the project forward. They allowed him and his one-sided interpretation of the contractual requirements for this one deliverable to put the entire project at risk.

Our firm eventually worked its way out of this quagmire. But the project suffered for our delayed action in dealing with this impediment to success.

Common sense is not so common.

Merv Jersak
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.

To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit


52 Project Management Success Tips from Merv Jersak  •  Copyright ©2020. All rights reserved.