2015 Resolution: Stop Dumb Procurement Practices for Consulting Services

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.

[Related: Agile Project Management Lessons Learned From Texas Hold’em ]

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.

[Related: How to Use Agile Development to Avoid Project Failures ]

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?”

[Related: How to Make Your Enterprise as Agile as a Startup ]

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.

Let’s freeze the frame to see what’s going on. You bought a consulting project because you didn’t want to buy more employees. Fine. You’re willing to pay more because you get expertise and schedule advantages. Cool. But with an employee, the team’s incentives are almost completely aligned (absent the effect of political squabbling). Plus, with an employee there’s little issue of technology transfer: the builders are the maintainers.

The result of the adversarial relationship? Consultants deliver software that isn’t well fit for purpose, is typically formulaic (which means you don’t get any competitive advantage from it), and isn’t flexible over time. This goes double for “quick start” projects that your users will hate from the day they are deployed.

So how do we get a project that is optimized for what your business really needs? How do we get the incentives of consultants aligned as well as they would be with employees? This is the hidden strength of agile, when done in a meaningful way.

We all know that the mechanics of agile involve incremental delivery of features, sprints, continuous integration, scrum teams, and high user involvement.   Those mechanics are easy to teach, but they do little to align incentives.

Getting All Left-Coast on You

I admit it, I’m a child of the ‘60s. I lived in San Francisco in the Summer of Love and my dad hung out in a Marin County commune for a while. But I’m no more an advocate of Flower Power than Pyramid Power or even Wind Power. And I’m here to tell you that nearly all the ‘60s music was trash: still is. And don’t get me started on tie-dye.

The true magic of agile comes not from its mechanics, but from its foundation: The only way to get requirements right is to get them directly from the users during the course of the project. That means there are no specs, only stories which may expand, divide, merge, contract or even be abandoned as useless at any time during the project. The magical incantation of Agile: “stop pretending you know.”

And that means, you have to depend on trust. Every management discussion and action has to build trust across the team, so that users believe IT is on their side and everyone thinks the consultants are doing what’s best for your company. Yeah, trust.

You can still have fixed price and fixed schedule, but what Agile says is you can’t have that at the same time as fixed-deliverable. Because if you live that assumption – you don’t know what you need until the project is in process – the project team needs to focus on “what’s most important for the business now” instead of “what’s on the checklist.”

For agile to do its magic, you have to trust the team to do the right thing. Which means you need to put your very best people—users and IT—on the team for real. And your CFO needs to be briefed about why this is the best way, and how it will reduce waste. Any command-and-control management needs to release the team to do what’s best, rather than focusing on spreadsheets and what’s easily (and falsely) measured.

Can’t get past this? Maybe you’re not really ready for agile.