Most companies have long-standing traditions in the way they buy consulting services for software projects. Even though nearly all the best practices of software development have changed over the last decade, too many companies are trying to buy agile projects using “rules of the road” that feel like 1990 or even earlier.
I’m a consultant and I fully admit my bias. But the point of this article isn’t my self-interest: It’s yours. So let’s look at what you want at the end of the project, and optimize that from the outset. It’s easy to say “I just want the project done as cheaply as possible and as early as possible.” Yeah, right. And the problem?
- The word “project” is ill-defined, even if you think you’ve got solid project requirement documents (PRD) and RFP documents. Actually nailing down exactly what you want the project to be—and exactly what you don’t want it to be—before the project has begun? It’s an amazingly time-consuming and painful experience. And the decades-long track record of clairvoyance in software projects is pretty poor, because too many business realities change over the life of the project, and too many things you thought you needed at the beginning turn out to be wild-goose chases.
- Not only is your rock-solid project definition going to cause building some stuff that’s a waste, it’s going to miss doing some things that are important. Projects involve discovery of process issues, business rules, and tradeoffs that were hidden when you were writing all those specs before it began. Any interesting project is going to involve exploratory surgery, and perhaps some soul=searching.
- Over the life of the software you’re creating—in the years after the project is over—you may well spend more modifying and maintaining that code than you did building it. So creating internal capabilities to support and evolve the “project” are a key factor in responsiveness and TCO. But most “project” definitions do not include this. Same thing with internationalization, architectural future-proofing, and other oft-neglected areas of infrastructure.
The bottom line is that the project outcome you actually want is not what you can specify in advance. But most procurement processes still focus on fixed-price, fixed-deliverable, fixed-schedule projects. Works for commodities, works for hardware. But for custom software projects, it’s a classic case of magical thinking, the kind endlessly documented in Dilbert.
So let’s dig into the effects of the PRD/RFP/fixed-price process on your project outcomes. The intelligent consulting firm knows that they don’t know what the requirements really are any better than you do, but they have to pretend that (1) they do, and (2) that they can deliver with predictability. So they must pad their bids to deal with that uncertainty.
The intelligent client collects several bids and has to trade off price for quality and delivery risk, but unintelligently wastes time speculating in an effort to answer the wrong question. And that question is, “what’s going to be cheapest and make me look good at the time we sign the contract?”
But the right question is, “what’s going to produce the best long-term outcome for my company?”
Well then, the contract gets signed and about 34 milliseconds later (the time it takes for the synapses to process “it’s signed”) a contractuallyenforced adversarial relationship begins. Sure, you both want to finish the project and avoid unpleasantness … but the consultant needs to minimize costs and you need to maximize output. So for the life of the project, your incentives are diametrically opposed to the consultant’s. And trust? Well, the only thing you can really trust is that the other side is incented to behave like the other side.