2015 Resolution: Stop Dumb Procurement Practices, Part 2

As I said last time, too many companies are selecting and procuring software consulting projects the way they did in 1990. Time for a re-think, particularly for customer-facing and CRM software projects.

The discussion from last time was about definition and measurement—the foundation of the project. Now it’s time to look at other phases of your procurement process with a skeptical eye.

Heresy No.1: Why Are You Talking to a Sales Rep?

You know the joke: how do you know when a sales rep is lying—whenever his lips move. There’s a more profound joke embodied in Seth Godin’s book “All Marketers Are Liars,” in which he states that marketers never lie, they simply create the conditions under which the consumer can make up believable fictions. The power of narrative and “the customer journey.” Ugh.

There’s a little book you might have noticed, “Lying” by Sam Harris, that makes a simple but profound point: all lies have costs, and adults spend too much of their time lying to coworkers, vendors, bosses, family, and even themselves. Dan Ariely’s work in behavioral economics indicates that most adults lie several times a day, and any “savings” involved with lying are a false economy.

If a sales rep’s incentives are “to get the deal” and get the most money they can out of you, how exactly does a conversation with them help you? Really good sales reps provide actionable information that help you make a reasonable decision…but those are really rare. Most sales reps are too busy creating an information bubble around you to cause a favorable decision before the quarter-end.

At my firm, we took Thomas Watson’s maxim “everybody sells” to its logical extreme: since everybody sells, there’s no reason to have anybody in the organization who only sells. I want the guy who dreams up a ridiculous project plan to have to deliver on it. So, the project lead writes the proposal. And everyone on the team works with the customer to come up with a plan that can be executed.

I will get tons of hate mail from sales reps of all kinds and from consultancies that—for scalability and growth reasons—have sales organizations. But clients, ask yourselves: how is it in your interest to promote the scalability and growth of your consultants?

So, heresy No. 1 is…don’t take a meeting with sales. Insist that your pre-contract meetings be with the team that’s going to deliver your project. Which brings us to…

Heresy No. 2: Why Are You Accepting Interchangeable Parts?

Consultants are individuals, with technical talents and “soft skills” that vary widely. Consultants are only interchangeable to an extent, and each transition involves learning-curve effects for both you and the consultant. This goes double for any project involving industry expertise: experience with your competitors and supply chain, and knowledge of business processes and regulatory realities of your marketplace.

So in making your decision about which consultancy to use, nail down the individuals who will be on the team at each phase. It should never be “developer 3 in Hyderabad,” but a specific name with a particular resume. Understand in advance when the transitions will occur, and bake them into the project plan. Get commitments in the contract about talent swap-outs, and make reasonable allowances for the unforeseeable (illness, family crisis, etc.).

Think Hollywood: there are specific penalty clauses if a star flakes out.

I will get even more hate mail from conventional consultancies that—for scalability, cost control, and growth reasons—use talent pools and swap individuals in and out of the team. But clients, ask yourselves how that is in your interest.

That said, be flexible about “employees vs. subs” from your consultancies. If the individuals who are willing to truly commit to a project happen to be subcontractors, who cares as long as they are excellent? I’ve seen million-dollar projects where none of the people on the team actually worked for the consulting firm. A little weird, but definitely manageable.

Heresy No. 3: Why Are You Doing Discovery After the Project is Approved?

Your project approval and procurement process almost certainly assumes that the budget and schedule are fixed. During the initial phase of the project, you are going to discover requirements and business process implications. If you’re lucky, you won’t discover much new after the first 10% of the project funds are expended. (If you’re unlucky or are in a rapidly evolving organization, you may be in process discovery all the way through the project. Yummy.)

Other than bureaucratic simplicity, why are you doing approval of the whole project in one pass? Doesn’t this just beg for an incremental ($10 word: tranche-based) approval system? The project (and its political implications) will be much better understood after all the user interviews, business process analysis, and existing-system assessment have been done. It’ll save you money (and reduce the risk of embarrassment) if you spend seriously on discovery, assessments, and architecture before you approve the budget for the whole project.

That’s the way it works with building construction: you will spend easily 15% of your budget before you select the general contractor or even think about breaking ground. At any time during that pre-natal stage, you may choose to re-define or entirely abandon the project. And that’s in the highly predictable, repeatable domain of hardware (really big iron). In tricky software projects, be willing to over-invest in discovery.

This is not to say you can cut off discovery after the first phase. New things will inevitably crop up during the project, and it’s in your interest to do mid-course corrections. Which brings us to the final heresy…

Heresy No. 4: Why Are You Focusing on the Bid Price?

If your project is basically a commodity, or you’re really just “contracting out” some tasks, the project bid price is meaningful. But if your software project is intended to give your company a competitive advantage in a core business process, it must be managed as a one-of-a-kind, never-done-it-before project. Because that’s what it will be.

For strategic projects, the bid price is just a bunch of negotiated guesses. With manifold unknowns and evolving business realities, “the project” is just the first phase of a journey. And the total cost of ownership (particularly when your crummy UI wastes user time and irritates users) will dwarf that initial project bid. Lowering TCO is why we push clients toward Agile: lose all the “nice to haves” and do only the highest-priority things with excellence and user responsiveness.

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

The uncertainty of Agile may scare your management, but it’s much preferable to the certainty of bloatware and high TCO produced by traditional procurement and management processes.