How IT pros can avoid bid-to-win horror shows

By David Taber, CIO |  IT Management, agile development

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.


Originally published on CIO |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness