3

Something that occurs quite often in outsourced software projects is the vendor underestimates the complexity or learning curve associated with an agreed-upon statement of work, and wants to increase the cost halfway through the project when they realize they underestimated.

My question is - Is there a fair way of deciding when the vendor should "eat" the unforeseen level of effort and when the customer should, indeed, pay more?

4 Answers 4

3

TL;DR

Contract disputes are a way to manage financial risk to the company, not schedule risk. As a purely practical matter, you can't really transfer schedule risk away through contractual means, no matter what the contract may say.

In the short term, your immediate options will be based on a business analysis of your company's needs and alternatives. Also, keep in mind that the selected option is more likely to be based on political decisions by senior management than anything else.

Identify the options and associated costs, and present them to management for a decision. Then focus on fixing your processes for the future.

Brooks' Law Applies Here

Is there a fair way of deciding when the vendor should "eat" the unforeseen level of effort and when the customer should, indeed, pay more?

While some answers may address this legalistically, or discuss the benefits of the agile principle of customer collaboration over contract negotiation, at heart you're simply asking the wrong question.

The pragmatic question in any such dispute should be: Do I need the outcome more than I need the original agreement or payment terms? At the end of the day, while both sides can assign blame, affix responsibility, or lawyer up, none of these things actually get work done. Even if you're willing to walk away from your relationship with the vendor, you are then faced with hard choices about who will do the work, how soon they can actually deliver it, or whether you can get the end result you need at all.

Brooks' Law often applies here, because your project is likely already late. Disputing contracts, switching vendors, or seeking alternative solutions at this point may make your project even later. Whether or not this is acceptable from a business point of view is ultimately a strategic or risk management decision, rather than strictly a contractual one.

Fix Your Process and Controls

You can't really undo the damage at this point, because all your options will either cost more, reduce scope or quality, or delay your product delivery. Maybe all of the above. However, you can analyze the process failure, and aim to do better next time.

In most such cases, the problem isn't actually contractual. The real issue is that the business didn't learn about a problem until it was too late. Agile processes address this through continuous collaboration, transparency, and tight inspect-and-adapt cycles.

It's generally much better to implement fail-fast project controls so that you can either adjust the project or terminate it early before incurring excessive sunk costs or finding yourself facing the dilemma of whether or not to chase sunk costs. Whatever process or control failure allowed the project to reach this juncture without lots of forewarning that your budget or target dates were at risk is flawed, and should be adjusted.

At the end of the day, even if the company "outsourced" the work on its software project, someone internal to the company is still responsible for the delivery of that project. Pragmatically speaking, if that person breaks the project, they get to keep both halves.

1

If you want to fix price really, and there is low trust among you and vendor yet, then you need to document your Scope and its price together with your vendor -- as detailed as possible. In such case, it will be much easier to judge whether everything bought is delivered or not in the end.

So, good approach is to have some short Elaboration phase (aka Sprint Zero) during which your vendor (or your company) can specify requirements and also mitigate main Technical Risks (results of the mitigation should be also delivered to you in form of Prototype or analysis documentation). For $100k project $10-20k Elaboration is pretty enough ($100k total).

Also, during the phase you should be ready to work very much with the team every day (because it's short) -- clarify requirements and help resolving risks (finding compromises on technical solutions and Scope options, for example).

And during project you should ask for often demos (every 2 weeks at least), where you should check what guys deliver. Not only quickly looking on their screenshare, but also go to the server where it's installed and check thoroughly that everything is fine and progress is good. And refining rest of scope -- but trying not to add new functionality in Scope (what always happens), but finding Minimal Viable Product features really.

Drawbacks of Elaboration phase approach are following:

  1. It costs.
  2. It is very difficult to think over all design solutions for the whole project so early for you and vendor.
  3. There will always be conflicting things, or things specified not precisely enough in the spec.

So, it's not silver bullet. But still useful instrument to get initial agreements in written format. Also, it allows vendor to relax a bit and produce more accurate estimate -- i.e. take responsibility and commit on it.

If the first project is successful, and vendor gains your trust, then for its future phases the Discovery can be even cheaper, or you can move to T&M model to lower bureaucracy and your own costs for the project.

About risk mitigation see also "The Rational Unified Process Made Easy" -- great book about balance of Waterfall and Agile approaches.

When you should allow vendor to increase project price (or ask you to remove low-priority features):

  • When a truly unexpected risk strikes. For example, some integration problems with 3rd party you provide.
  • When you change your requirements a lot.
  • When he should update your legacy code -- often developers need 1-2 months to get familiar with legacy good enough to provide accurate estimates.

This is more matter of negotiations ofcourse -- there should be constructive communication around costs and scope -- try to understand vendor's points of view, make sure he understands yours, try to learn from him, don't try to implement everything during the project -- be ready to big cuts of functionality. And everything should be fine in the end!

0

I infer from your question that the contract type in this context is a firm fixed price model. If so, the seller is on the hook for completion of the contracted scope no matter the financial loss the seller experiences, except when explicit stop loss criteria in the contract have been met. If stop loss language was poorly written or absent, then there is no trigger a seller can use to have the buyer come back to the table.

That said, the reality is that if the seller is in a serious loss situation, the work or its quality is in jeopardy and no one really wins. It is in the buyer's best interest to sit back down with the seller and work out a more reasonable deal in order to keep the project going so everyone wins. The risk here is that the buyer can lose confidence and stop the work for cause, possibly litigate for damages, and ruin the seller's reputation in the industry.

So the best solution is, when estimating work that is quite unknown or with heavy risks or a FoAK (first of a kind), to use a different type of contract model, such as Time and Materials or Cost Plus Fee.

0

This usually happens when Project Scope document is not prepared well. As a software engineer, we sometimes miss to put important functionalities and they come up as unforseen. And it comes very necessary to work on sub-routines/functions which are underlying the given software specifications.

Ask the vendor to:

  • Raise a documented change request
  • Explain the need to put additional efforts

After all this, you pay more only if it makes sense to you.

You shouldn't pay if it there is any mistake or delay in delivery previously documented functionality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.