views:

137

answers:

4

My situation is that I have agreed on a per-project proposal with the client. The proposal is vague, but still names functionality in a way that can be argued as to whether it's included or not, while leaving some room for interpretation. I originally pressed as much as I could to get a per-month contract, arguing that the project is mostly non-predictable, but the client refused. Being a small company, I had to fold and signed a contract on an estimate based on my group's estimations. At this point we have reached completion on about 85% of the features (we think) but we ran out of budget. We have been working for almost two years with this client in previous contracts, and we have delivered a good product that they are happy with, so we have a good standing relationship.

More info: -There has been a bit of scope-creep, but I don't think enough for me to hide behind that argument -We've been delivering partial releases about monthly. -We don't have systematic user-testing in place.

+1  A: 

Well I have yet to see a development project completed on time and under budget, but this is why you should never accept a fixed-bid contract without a clearly defined goal.

You'll need to inform the customer, but you should also have a talk with your team and see if they're willing to burn some midnight oil to try to catch up. Provide plenty of Dunkin Donuts Turbo Hot coffee and get as caught up as possible. The client will probably be more understanding if they know you are willing to haul ass to try to get back on track.

Josh Einstein
+1 for the first paragraph, but -1 for the second. Getting the team to give up their family/recreation time to cover for incorrect estimates is a horrible solution.
Andrew Shepherd
I have worked on numerous multi-million dollar projects that were both on time and on/under budget. With very little "crunch-time". Anything else is just poor management and poor judgment.
fuzzy lollipop
Kragen
@Andrew, I don't want to make too many assumptions about the team but the OP stated it's a small company. So I don't think it's at all unreasonable to come clean with the team and see if they're willing to work more hours on it if it means the difference between the company going under and saving the contract. Obviously nobody should work for free but if the client is being asked to put up more money, the least the consultants could do in return is put in some extra time. Regardless of who is at fault, I think that would be a good compromise.
Josh Einstein
@fuzzy, @kragen - I am exaggerating of course. But it is a very well known problem in our industry that requirements are rarely gathered properly or completely and many times clients can be very...well... persistent about starting early or adding features later. We can talk all we want about how that should never be allowed but the fact is money talks. In fact, a huge multi-million dollar project is probably far less likely to go over budget/schedule because with the stakes that high, there will be more careful planning.
Josh Einstein
all of that and I mean ALL of what you say is un-neccessary, agile methodologies prevent those bad patterns of behavior, and I would argue the stakes are EVEN HIGHER with a smaller company with a smaller budget because there is much less room for error. Plain and simple there is absolutely no excuse for poor software development management. Your posts are very waterfall in their arguments and you are right, waterfall projects have proven to fail time and time again, regardless of size, budget or scope because of the way they are managed.
fuzzy lollipop
@fuzzy I haven't made a single argument about any methodology one way or the other. In fact I thought I was pretty clear in my last comment that getting all the requirements up front is not practical. The fact remains the OP is in a predicament right now. "Be more Agile" doesn't help address his question or help deal with breaking the news to his client and team that they're out of money.
Josh Einstein
+2  A: 

The truth will set you free. Hiding the fact you are out of money will only compound the final outcome.

It's much better to come clean and try to work out a solution. Especially when, as you say, you have a good relationship with this client.

I'm sure if you point out there has been a little scope creep and that requirements wern't fully outlined that they will come to the party and meet you some of the way to paying for the rest of the dev. You won't get it all I don't think but anything will be better than nothing huh?

griegs
+6  A: 

You don't hide behind scope creep - you charge for it!

Charge for ANY scope creep.

from the Customer's point of view its called salami negotiating - they ask for just one more little slice, then another - next thing you know - no salami.

One of the great myths of development that developers tell themselves and often, mistakenly, the client is that there is enough padding in the estimates to absorb new requests. Learn this lesson now, there is never enough padding in the estimate to absorb even one tiny change.

Instead learn to immediately analyze and estimate the cost of the new request, provide it in writing to the customer and get their approval before starting on it.

kloucks
Great sentiment in theory, reality is sometimes harder to match, especially if the vague contract has already been agreed on and signed. +1 anyway
johnc
@johnc: yeah the immediate contract is probably a dogs breakfast at this point but it should provide enough pain that going forward the OP will bring more discipline to the negotiations
kloucks
I agree. My initial thought was, the first meeting about this with the customer will completely suck, but getting it out there will be relief in itself
johnc
+1  A: 

Well done, you've delivered 85% of the original spec and not yet gone over-budget. Or, if you want to be hard on yourself, you are now ((100/85)-1)x100% over-budget. That's still far from catastrophic.

To recover the situation, figure out your answers to the following questions:

  • If forced to, can you afford to take the hit, and spend enough of your money to finish the project ?
  • What value do you attach to future work from this client ?
  • Can you negotiate follow-on work from this project (sure as eggs is eggs requirements will have changed and what you deliver will prompt thoughts of further work) ?
  • And, if you can get follow-on work, can you structure the finances so that future payments soften the blow of (possible) losses now ?

This isn't about over-charging in future to offset under-charging in the past, it's about negotiating a better contract for both parties -- one that you are confident you can deliver and make the right amount of profit, and one that the client understands is a good price for a good delivery.

If your clients are sensible I'm sure that they would rather pay 100,000 groats (or whatever your local unit of currency might be) for a product whose quality they can bank on and whose delivery time they can rely on, than 80,000 groats for a product when they know that the delivery work is going to be squeezed for time. However, they may not be sensible and you may have to walk away from the relationship -- but that depends on its value to your company.

High Performance Mark