Why You Should Estimate Client Delays in Project Budgets

Project delays are like traffic delays. Expect and plan for themSeveral years ago, my Project Manager taught me what he called the “John Smith” factor of determining a project budget. John Smith (not his real name) was our client, and he was the most indecisive client I have ever experienced. How do you provide solid budget estimates when your main client is unable to make a decision?

Whenever John asked for a system enhancement or a major change to existing functionality, my Project Manager would methodically estimate the cost of the Change Request. Once satisfied with the final result, he would then double the estimate, or apply some other “John Smith” factor. My manager explained to me that it was easier to provide a higher estimate at the outset of the work to be undertaken than to debate the cost of delays due to John Smith’s indecisiveness during the execution of the activity.

Perhaps not the best way to provide a project budget to a client, but it worked for John Smith (and others like him). We know that a project budget is basically an aggregation of the cost estimates of all of the work packages contained in the proposed project schedule. Significant attention goes into the development of the cost estimates for each activity within a work package. The project schedule, resource calendars, scope baseline, the basis of estimates, and even the risk register become foundational inputs into the development of the final project budget.

Yet how often does the project budget, created even before the project begins, assume that staff will follow the project schedule exactly, that the teams will deliver exactly according to the resource estimates, and that the client will behave exactly as the project plan expects them to behave? Project life just doesn’t work like that. The project budget needs to recognize that.

As I noted in my previous article, “This is Why Project Staff Need to Understand Cost Estimation,”  one of my former managers was fond of saying, “You don’t wake up one day and find that the project is three months behind. The project has been slipping one hour and one day at a time.”

Knowing the Client

I worked for several years for a very capable, very successful Project Manager. There was rarely a project situation that he had not previously encountered. In fact, there was rarely a project situation that he could not deal with, even if he hadn’t encountered it before. When it came to project budgeting, he would use some very simple techniques to put a budget in place that was acceptable to the client, while at the same time recognizing that project staff or client staff did not always perform perfectly.

On one occasion, we were developing the project budget for a fixed-price effort for a client organization with which he had substantial experience. He understood the client as being very knowledgeable, but his previous experience with the client staff showed them to procrastinate on important decisions. We developed the budget according to all of our best estimating techniques and created a graph of anticipated project expenditures over time.

My Project Manager pointed to the month where the project costs peaked and said, “Add two more months equivalent to this (peak) cost to the project budget.”

He explained it this way. Knowing this client as well as he did, he anticipated that they would begin to drag their feet towards the end of the project at the very point that we were at peak staff and peak cost. They would start questioning every decision they had made along the way. Every day the client delayed us, that we were not able to clearly justify as a client-caused delay, was a day’s worth of staffing and other resource costs that we could not get back. So, knowing this client, my manager insisted on a two-month, peak-resource contingency.

Now that made a lot of sense to me. In project execution it is important to maintain scope control with the client. But how often have we seen client-caused schedule slippages for which the client would not take responsibility, nor pay for the project delay?

  • Would it not, therefore, be wise to have some contingency?
  • Wouldn’t that be better than trying to reduce the inevitable schedule slippage at the expense of delivery staff working long days and weekends?

This example, and the earlier “John Smith” example go beyond the process and technical aspects of developing a project budget. Additionally, they take into account the people aspects of project management. Clients who are not experienced in project delivery can, by their actions or inaction, slow the project down. This is a very real factor in managing projects. Client staff who are extremely detail-oriented, or overly demanding, or prone to changing their minds, are a very real factor that we as Project Managers must deal with. The delays caused by such behavior cannot be readily mitigated each time they occur by issuing a Project Change Request. Building in contingency or management reserves in anticipation of these factors is good project management. Contingency and/or management reserves protect project staff from having to make up the inevitable shortfalls with long nights and lost weekends.

I mentioned earlier that finalizing the project budget involves aggregating the estimate from all of the work packages included in the project schedule. However, that simple cost estimate aggregation is not always a good indication of the final total budget. In fact, this is a form of bottom-up estimating that when viewed as an aggregation often appears inflated.

In my own experience, as various teams develop the discrete estimates for their work packages, they do so independently of project activities that are not in their area of responsibility. As such, they do not take into account economies of scale, shared resources across activities, or other such realities of project execution. The resulting aggregation is over-estimated.

Over-estimating a project budget can be as detrimental as under-estimating it. In a competitive situation, over-estimating can result in losing the bid. For internal IT organizations, over-estimating can result in reallocation of scarce dollars from one area of the organization to your project, which is not looked upon kindly when discovered much later. Alternatively, it can result in cancellation of the project. Neither of these are readily tolerated in the organization. There are very real human factors tied to these types of scenarios.

This is where that age-old tool called expert judgment comes in

Staff who have delivered similar projects in the past understand that the cost and accuracy of activity estimates, and hence project budgets, can vary widely. They bring with them knowledge and historical information to determine whether the cost model for the project is reasonable. Their experience in the types of situations that can occur on such projects, particularly those that can have a negative bearing on the project budget, is invaluable. Their expert judgment should be a final review of how the project budget was developed.

Whether developing a project budget as part of a fixed-price bid, or providing a project budget internally to executive management, Project Managers will be expected to deliver the project according to that budget. Taking past experience into account, understanding that the project will not be delivered exactly according to the project plan, and taking the people aspects of project management into account, are all necessary to have a greater likelihood of success.


Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.