Fixed bid implementation work: a marriage made in Vegas
Most of my CMS selection clients are not just looking for software. They are looking for a solution that includes software and also a hefty dose of services to configure, customize, train, and support. Typically, once we have narrowed down to a short list of products, we start looking at systems integrators that can help develop the solution. A well-executed implementation and roll-out of a marginal product usually yields better business results than a train-wreck project to implement best-fit software. You need to work with a services organization (internal or external) that can partner with you to define and develop the solution that achieves your goals.
The other day, I was talking with a friend about projects gone bad and he asked me if I ever worked on a big fixed bid project that both client and supplier felt went very well. After considering all the projects that I worked on and the projects that I hear about as an analyst, I had to say no. There was always disappointment and frustration on either or both sides (usually both). But I was able to think of many iterative time and materials relationships that benefited both sides over years of working together. I have now been out of the systems integration business long enough to say, without any personal agenda, that fixed bid systems integration work is a failed enterprise.
The best analogy that I can make is that a fixed bid contract is like marrying someone you met at a craps table on a Las Vegas vacation. I am not saying that all spontaneous Vegas marriages fail, but they definitely have the odds stacked against them. Here is why; during the sales process, both sides get wrapped up in the deal and suppress rational doubts and concerns. They force themselves to believe everything is going to work out. They force decisions and assumptions that turn into a millstone hanging around the neck of the relationship.
The supplier talks himself into believing that he fully understands all the requirements and that every detail about his approach to solving them is accurate. That is simply impossible. No matter how long the pre-sales cycle lasts, it is impossible to fully understand every requirement and bring to light every latent expectation. The client doesn't know what he wants until he sees what he doesn't want. The initial estimate may have even been trimmed down because it "looked too big." The client also assumes he fully understands the requirements and believes he is reasonably flexible about the design details. He trusts that the fixed bid contract ensures the delivery of the solution in his minds eye for the agreed upon price in the stated time frame.
After the deal is consummated, there is a short honeymoon phase where everyone seems to work together productively. This analysis phase goes smoothly because the stressful deadlines are far away and there are no concrete tests for progress. Sometimes a project can go through design without any awareness that it is horribly off course. That realization usually happens during the first development milestones when it is clear that the developer and client had significantly different understandings of the specification (if there even is one). Then things start to degrade very quickly. Both sides are stressed out and start to blame each other. Both parties feel like the other is being unreasonable. The contract that was supposed to protect everyone is turning into a handcuff connected to the most annoying person in the world. Both sides start looking for a way out.
Any successful partnership depends on both parties working collaboratively and creatively to solve problems as they come up. A fixed bid contract prevents this cooperation by making the relationship inflexible. But, you may ask, how much flexibility is realistic when a client has a limited budget and has promised a certain outcome of the project to company leadership and/or the customers? With a fixed bid contract, there is at least clear chain of blame. The business blames the project sponsor. The project sponsor blames the project manager. The project manager blames the consulting company. The consulting company blames the employees. The employees feel miserable and quality suffers. The contract provides unambiguous blaming instructions but it doesn't solve the problem. The project is delayed and other costs will be realized.
A better strategy would be to partner with the supplier to jointly design and develop the optimal solution within those budget, time, and quality constraints. Achieving this kind of solution is an iterative/incremental process. The final solution will gradually materialize as options are explored and learning occurs (see Tracer Bullets). But this kind of cooperation requires a huge amount of trust and, sadly, very few business relationships enjoy much trust at all. Especially given the perceived track record of failed technology projects.
So, how do you achieve this level of trust? It takes time. Just like it helps to date before you get married, you want to start off with some small, low risk projects. Both sides need to believe that if they work at it, the relationship will last a long time and benefit them. There also needs to be transparency and equal rewards. The systems integrator needs to be transparent about their capabilities and experience and they cannot expect a huge windfall over a single project. The systems integrator should consume project resources (budget) as if they were his own. The client should expect to pay for what he gets and not try to trick the supplier into committing to unreasonable results. As Graham Oakes says, if you do not try to the make the relationship a win-win, you will probably wind up being the one who loses.
When you are buying services, you are really buying effort — not a result. A good project team will multiply the effort you purchased with skill and experience to deliver great things (maybe even better than you originally thought you wanted). The problem is, buyers are ill-equipped to gauge skill and experience. They feel more comfortable with the illusion that they are buying tangible results. Services companies that prefer to sell results rather than effort do so by charging a high risk premium (or "value pricing") and having employees that can step up and overwork when the risk gamble is lost. So, the buyer is either overpaying or has hired an overworked team. Neither of theses options sounds particularly appealing.
If you do find yourself forced into asking for a fixed bid contract, do not assume that you can just set your calendar to the planned launch date and wait for the results. Instead, manage the project as actively as possible. Set up lots of intermediate milestones with exit criteria to test that the project is on track. If possible break up the project into multiple small fixed bid phases. For example, have a fixed bid design phase that ends with a prototype or semi-functional core of the application. Make sure that the design considers implementation budget as one of its requirements or constraints. Business owners: don't let your staff get away with throwing the systems integrator under the bus when a project fails. Make them equally accountable for the outcome of the project. If the system integrator is underperforming you should learn of it one quarter of the way into the project; not within weeks of the planned launch date. Even better, don't force your staff to come back with a fixed bid contract. Encourage the assembly of a high performing team of staff and consultants that maximizes the value of your budget.