Project Estimation is off by 50% or More! Who is Responsible for Vague Requirements?

Question

I've just started doing some small contracts for the first time, and I'm working on a project with a person responsible for dealing with the client and analyzing requirements.

In this case, there was a slight incompleteness in one of the project requirements, and this small change makes a huge change in the time that will be needed to implement the requirements (perhaps doubling or tripling the workload).

Who is at fault? Is it the customer for not specifying the requirement, the requirements analyst for not being explicit, or the programmer for not poking holes in it?

More importantly, who is responsible here? Will we have to implement the new requirement without asking for extra compensation?

(If it changes anything, nothing has been signed, there is only a verbal agreement).

Answer 1

First, consider yourself lucky that you haven't yet signed the formal agreement. It's a lot easier to bring up bad news to a client early on than it is at the end, when the client is ready to take delivery.

At such an early stage, you shouldn't need to just eat the cost. At this point the client hasn't lost anything. If they want to get the project done cheaper, they could choose to go with another vendor.

However, even if you had signed the agreement and were 25%, 50%, 75% of the way to what you believed to be project completion, it's still best to immediately let the client know the situation so that they can let their stakeholders know the situation and adapt their plans.

Don't focus on who is at fault, focus instead on communicating the issue to the client and getting on the same page. Focus on solutions.

However, since your question is about who is at fault, it's everyone. The client is just as responsible as you are to make sure that the details are hashed out. They're paying for the project, and if there are details that were omitted, they are partially responsible. After all, it's their money, so they should make sure it's being spent wisely and that the value they receive is fair.

That's not to say that you're not responsible either. You're getting paid for the work, and it's your responsibility, and your colleague's responsibility, to make sure you get compensated fairly and can follow through with the requirements.

Answer 2

Missing or incomplete requirements is one of about 1,000,000,000 random variables that will impact you during the course of a complex project, both favorable and unfavorably affecting your cost and schedule estimates. Many of these variables, you won't even see and, thus, will not have any opportunity to ask who is at fault on this exchange.

This is project management.

This is why there are tools and techniques to cope with stochastic variations in our work. First, this is exactly why you should not be providing single point, deterministic estimates. Provide instead your best case, your worst case, and the probabilistic distribution that rests on top of that range. Second, analyze your project with all of those probabilistic distributions using simulation. Third, do risk management analysis so that you can schedule in your mitigation and contingency items--and their costs--for known unknowns.

We target and price a single point when we pass it along to the client, but you will know where that single point is on your distribution and you will have the resources to cope if things do not go your way.

Who is at fault? No one! None of us can predict with any degree of accuracy the future. There is always variability in our performance. And there is always uncertainty in our plans.

So, focusing on this nit is a waste of your time. It sounds like you have more interesting issues on which to work with your estimating, planning, and risk management processes and techniques.

Answer 3

It has been my experience that the best requirement documents specify all the requirements (except for those that aren't specified). Other specify the important requirements and leave the rest unspecified. In either case, it is usually the unspecified requirements that increase the cost (however measured). The design process should be padded to allow for a reasonable amount of unspecified requirements.

Scope creep is another way that requirements get added to an existing project. After all it won't cost much to add the new feature now, but it will cost a lot later. I've seen a developer work a solid month programming a screen so that the reset button was disabled if the screen was edited back to it original content.

Unstable requirements also increase costs. The worst case I saw was when the same feature was added Monday, Wednesday, and Friday. (Tuesday and Thursday the feature was removed.) This occurred 18 months into a 6 month project.

A fourth area of requirements change is when the original requirements were incorrect. This should be dealt with quickly to ensure the project gets back on track with minimal rework.

In all cases you are dealing with requirements change. As other have noted, this should be managed and communicated to the client as soon as possible.

Answer 4

I will agree with JMort that you should count yourself lucky that you caught this so early. In this case you do still have the ability to go back and renegotiate without it being contentious.

As for who's at fault - the blame lies with both you (your company) and the client. Somewhere in the process parties from both sides got together and negotiated this. And at some point the client said "we've told you everything and explained our requirements completely", and someone from your side said "thanks, we understand completely and have no more questions".

This is why it's SO critical that going into a project you have a written agreement and a detailed scope document, so that later when these issues come up (notice I said 'when', not 'if') you have something to fall back on.

Answer 5

As with others, I agree that it is no one's fault. The blame could easily be spread around like a nice layer of peanut butter.

And as with others, I agree that figuring out who's at fault is the wrong approach. Finding out who left the barn door open is not going to get the livestock back in the barn. Cowboy up and get out their to herd them all back in. Focus on the solution.

To this I want to add two things:

1- What will you do differently next time?: One of the marks of a great project management leader is that they look ahead to the next time. They ask "how do we make sure this doesn't happen again." We all know the old saying "fool me once, shame on you. Fool me twice, shame on me." Failure is OKAY! What isn't is not learning from it.

2- As the PM it is our fault: No, I'm not saying you should toss yourself on the sword. But in the "Responsible Authority Gorilla" I talk about how we PMs need to step up and take responsiblity. Even when we are not "in charge" we have a responsiblity to lead and make the project suceed. So when their is a failure, we need to look long and hard at ourselves and find out how we can make sure we don't miss this failure in the future.

Answer 6

When we face any kind of problems, there is always a trap: finding a person responsable. Human nature turns often that person into scapegoat paying alone for a collective misunderstanding or mistake. So I would avoid trying to find a responsable right away. I would concentrate now on finding a solution. I would talk as soon as possible to the person who is in charge of contacting your client or/and even call the client myself. Understanding clearly the requirements of a client seems easy, but sometimes you think you know what the other person think. Or you agree on something that is percieved very differently from either sides. So do not be afraid to insist and ask as many questions as you like. Make your client understand that you want to get it right at first. Having a good start in your project is the key of your success. I prefer having a rush at the biginning that in the end. It is a nightmare to find to late you need something you did not planned at first.