How IT pros can avoid bid-to-win horror shows
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 Agile Anonymous.
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.
David Taber is the author of the new Prentice Hall book, " Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years of experience in high tech, including 10 years at the VP level or above.
Follow everything from CIO.com on Twitter @CIOonline.
Read more about project management in CIO's Project Management Drilldown.