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.\n\n\nIf 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?\n\n\nEven 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\u2014the customer\u2014in court. Or they may go broke before they finish the project. If you blindly accept bid to win, these risks are real.\n\n\nSay 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\u2014after 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.\n\n\nFixed 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?\n\n\nWhy, then, do companies think it makes sense to accept bid to win on something that's as complicated as brain surgery\u2014software projects? Let's take a look.\n\nBid to Win in Software Projects\n\nIn 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.\n\n\nAll 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.\n\n\nIn 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.\n\n\nI'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.\n\n\nDoes 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.\n\nWhat's the Antidote for Bid to Win? Agile.\n\nWith 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).\n\n\nHere's my 12-step program. Let's call it Agile Anonymous.\n\nDon'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.\nUnderstand 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.\nLet 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. \nThe only thing you know with certainty at the outset is the calendar and the budgetary limit set by the business case. \nSince 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.\nSince the scope of control during the project will be limited, the project champion must deeply interact with the project lead every couple of weeks. \nEvery member of the entire team needs to be thinking and taking responsibility for fast decisions.\nSuccess comes in steps, not leaps. Excel at delivering small things predictably and with minimal waste.\nRuthlessly prioritize in every Scrum cycle. Half the things somebody said you'll need won't be used in real life.\nOptimize for business value delivered. Measure progress by improvements in revenue and cost, not milestones or Gantt charts.\nTrust 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.\nKnow that, with a well-designed cloud system, you can\u2014and should!\u2014add things after go-live. Use incremental additions to delight the user while lowering system cost and risk.\n\nIn 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.