In the construction industry, it's standard practice to require fixed-price bids. When contractors are hungry, you might see a bidding war. If the contractors think there are performance bonuses, juicy follow-on jobs or lots of engineering change orders (ECOs) in store (more on this in a bit), they may be willing to bid with essentially no profit.
If the competition is really hot, they might even be willing to lose money, with a low-ball "bid to win." In this case, the customer gets the lowest possible price and a contract that guarantees the completion of the project to the spec. During the project, nobody on the customer side will have to think. They can just measure. What's not to like?
Even in the standardized world of construction codes, supply catalogs with known prices and commodity products and services, there are actually lots of ways to get hurt. Contractors may cut corners in their materials and methods, even if it's illegal. They may forget to pay their taxes or subcontractors, landing you—the customer—in court. Or they may go broke before they finish the project. If you blindly accept bid to win, these risks are real.
Say the contractor is totally legit. Why did he accept low or no profits? Because he knows a lot more about the project than you do, and he may be able to see a dozen problems that make ECOs inevitable—after all, ECOs are a great way to nail the customer (so to speak) with price increases. The contractor may also have put some escape clauses in the contract that let him charge you time and materials for unforeseen situations.
Fixed price does make sense with commoditized products and services, such as auto repair, where every procedure for every car is quantified within six minutes. But for custom services with lots of unknowns (surgery, law, even tax accounting), it just doesn't make sense. Would you really want to have a fixed-price heart surgeon?
Why, then, do companies think it makes sense to accept bid to win on something that's as complicated as brain surgery—software projects? Let's take a look.
Bid to Win in Software Projects
In the interests of maintaining control and not paying too much, it's common for clients to request a fixed-price contract. This is most pernicious in internal IT projects, where the business folks are pitting one IT team against another, or an internal team versus a consultant.
All too often, though, it's a false competition. The business team doesn't really know what it needs, doesn't understand how to state its requirements precisely enough to make for an iron-clad contract and can't really compare the business value of one part of its requirements to another, so prioritization is flaky.
In other words, the users have no solid (i.e., nonpolitical) basis for making a tradeoff or for having an iron-clad contract. In other words, the users are going to be disappointed with the project outcome. The only questions: how soon will the users notice, and in how many ways will they notice.
I'm not speaking in the abstract here. I've seen clients who fell for bid to win behavior from the internal IT team, leading to an outrageous budget and schedule overrun along with the perception that half the functionality isn't there at the end of the project. I've also seen clients take the bait from external contractors, leading to endless ECOs because of unforeseen problems in data conversion.
Does this sound like 21st century IT? Does this sound like cloud computing? It sure reminds me of mainframe projects. Talk about the Thing that Wouldn't Die.
What's the Antidote for Bid to Win? Agile.
With any good monster movie, there's some secret way to kill the creatures. Maybe the solution strategy here is more like Shaun of the Dead, where the zombies still hang around but are tamed (or at least restrained).
Here's my 12-step program. Let's call it Agile Anonymous.
- Don't delude yourself with ideas that the project team really knows the requirements, the business processes, or the economic value of improvements with enough detail to make good tradeoffs at the start of the project. And forget about rock-solid specs.
- Understand that, with any significant software project, the business requirements will change significantly during the life of the project. This makes change management vital to the project.
- Let go of the idea that you can tightly specify or control the outcome of custom software, integration, or complex data merging projects more than a few weeks out.
- The only thing you know with certainty at the outset is the calendar and the budgetary limit set by the business case.
- Since neither calendar nor money will change, the negotiating item must be the deliverables list. It's only as the project evolves that you know exactly what will be delivered.
- Since the scope of control during the project will be limited, the project champion must deeply interact with the project lead every couple of weeks.
- Every member of the entire team needs to be thinking and taking responsibility for fast decisions.
- Success comes in steps, not leaps. Excel at delivering small things predictably and with minimal waste.
- Ruthlessly prioritize in every Scrum cycle. Half the things somebody said you'll need won't be used in real life.
- Optimize for business value delivered. Measure progress by improvements in revenue and cost, not milestones or Gantt charts.
- Trust and tight communication are the only things that will actually get work done. The execution team must include both users and engineers, and they need to be constantly building respect for one another during the life of the project.
- Know that, with a well-designed cloud system, you can—and should!—add things after go-live. Use incremental additions to delight the user while lowering system cost and risk.
In most complex cloud projects, bid to win is the right answer to the wrong question. Instead of asking, "How do we get the lowest initial price?" fixate instead on the question, "How do we get the most business value with the fewest surprises?" The next part of this series will help you come up with an answer.