When can a project's wrong estimates be justified?

Question

This question is not about project estimation techniques, initial processes, etc. Assume everything was done correctly.

Recently, we gave an estimation for an Android application with development team. The initial estimation was 2 months. Now, when we are about to deliver the project, we will be at least 5-10 days late.

The app which we are developing is Facebook specific. It is like a 2nd FB client, something like a Facebook plugin, so the majority of our work is with Facebook and its API and guidelines. During our work, we found out that we need additional permissions from FB, and have to submit the app for review. Then it turned out that FB does not provide data we need via its API and we need to find other ways to do the work.

To sum up, Facebook permissions and guidelines hindered us in meeting the deadline. While estimating, we could not go through all the APIs, data they provide, access, requests, and permissions.

Are there any cases where wrong estimates can be justified? Should the client share the additional costs with us, or can the client blame us? I know that client estimates are important, but can we present specific cases to client and protect our rights? I did not find any professional resources that address that issue.

Answer 1

Great project management is not about hitting your targets 100% of the time. Much of our performance is probabilistic where many of the drivers of our results are out of control and very random. Missing your targets becomes a problem if it became a surprise for you as the PM and your customer. If you were monitoring properly, such as using critical path technique or earned value or earned schedule, you would have had early indicators that you were trending to be late and, as a great PM, you would have communicated this delay early and often. Obviously, it is great to meet your targets but often times it is not possible; so greatness becomes knowing before you are late, mitigating what you can, communicating early and often, and then creating resilience via your contingency plans so that recovery is less harmful.

Now, all that said, your contract with your customer becomes key on how this late project is handled. Did you have awards and penalties tied to the schedule? Were you paid under a firm fixed price, T&M, cost plus? The T&Cs of your contract has to be met. If early in your proposal you identified FB as a possible risk and built an assumption around FB's behavior and a stop loss clause of your company, then you have a case to argue to help if you have any financial loss secondary to this delay. If not, capture that as a lesson learned for your future engagements. External dependencies are always a risk factor that you need to build protections around since your ability to mitigate is near zero. Good luck!

Answer 2

The Problem

[Are] there any cases...when wrong estimates can be justified?

Estimates are not guarantees. They are "educated guesses" based on experience, historical data, and a set of assumptions. If you're being asked to "justify" your estimates, you are already playing the Blame Game™ and starting from a false premise.

You can't win the Blame Game™. Don't play it; instead, use it as a teachable moment to educate your organization about how projects should be initiated and managed.

Document Project Assumptions

Any project plan I can imagine involves making assumptions. Ideally, these assumptions should be clearly documented (and regularly updated) within the project, and clearly communicated to everyone involved.

I typically create project plans that contain an explicitly-titled assumptions section. This section calls out the underlying assumptions for the project, and identifies project prerequisites that are essential to its success. This section always notes that if the assumptions are flawed, or the prerequisites aren't met, then the entire project plan should be thoroughly reviewed to ensure that the plan remains valid.

"Why" Doesn't Really Matter

If you bid a fixed-price contract, then it doesn't matter why you took longer to complete it than expected. You'll have to eat any additional project costs, and bid better next time.

If you are on a time-and-materials contract, then it still doesn't matter why it took longer. From a client relations point of view you may certainly need to haul out your implicit assumptions to explain the variance, but the client will still generally be stuck with those extra costs unless there's been some sort of malfeasance or gross negligence on your part.

There's nothing wrong with trying to smooth things over, but it ultimately comes down to your contracting process and how well your organization manages the client engagement. A client shouldn't hear about a two-week delay after the fact; that's a communications failure, rather than a failure of the original estimation process.

Answer 3

To answer your question a generic sense - ALL estimates are wrong. Whether or not deviations are justifiable (or should be compensated) depends on the 'why' they were wrong.

To address it in a more specific way -

In the beginning of your question you said 'assume everything was done correctly' (i.e.: we were not at fault).

Later you said 'we could not go through all the API's, data they provide, access, requests, and permissions."

Why not? You said the delay was specifically due to the requirements of FB, and at the same time say you didn't review all of their requirements. Were these not available, or did you just not take the time?

The answer to that question will also give you the answer to your original question about justification.

Answer 4

Ideally, you would have done a risk analysis on the estimates that would have covered the costs of the permission issues and FB workaround.

Also if you were far from sure of the estimates, you should not offer a fixed-price. Instead use other models like time/material, tiered / phase fixed-price.

The customer hired you as an expert in the domain, and would expect you to include margins to cover unforeseen circumstances within reason (10-20% in this case).

I'd not chase the customer to pay more for this project. Rather, try and get more business from them. Meanwhile you can work on risk analysis and payment model, so you avoid this situation in the next project.