CRM Tips: The Fixed Price is Not Right

You may not practice Agile but know that CRM system deployments are best done in an incremental, user-centered style

Comments

Imagine a CRM consulting project with inadequately specified requirements, no clear internal project manager, and ill-defined success criteria. Your consultant bids it on a time and materials (T&M) basis. You're in a rush, no time for a detailed RFP - you know the consultant can do the job, but you need a budgetary number to get approval. We've all been through this drill: somebody brilliant suggests that this has to be fixed price, it'll be easier to get project approval and manage to conclusion that way. You know, just like it would be when buying servers.

In CRM projects of any size, unknowns and unpleasant surprises can account for 25 per cent of the effort.

But you're not buying servers: you're buying services. While 80% of CRM projects are formulaic and could be bid as a "standard project," the other 80% of the project work is not only a one-off, but an unknown. Nobody actually knows the requirements, or the ramifications of "something simple," or the shape of your data, or the tricky parts of external interfaces. You may think you're signing up for a three-hour tour, but you're on the way to Gilligan's Island.

What if Fixed Price is a Lose-Lose deal?

While fixed price projects are easy to measure, the simplistic calendar-and-budget approach misses the point. Will the project result in any value to the business? Did it satisfy the letter of the requirements without solving any real problems? Let's look at this a little deeper.

You don't want to pay too much, so you get competitive bids. But all consultant have a powerful incentive to bid too high: they need the wiggle room to manage the risk of scope creep, weak project management, and ambiguous success criteria. This is particularly endemic in CRM projects that have to satisfy right-brained types in Sales and Marketing.

Look at it from the consultants' economic perspective: a fixed price project must be more profitable to compensate for the extra risk. Listen to Alan Weiss, the dean of high-profit consultancies: he insists that his followers always bid fixed price because that's the only way to make real money. Only fixed price lets vendors hide costs and margins.

Let's say you get lucky. Your consultant made a low fixed price bid. You win...except you don't. The consultants will be spending all their time during the project trying to figure out how to deliver as little as possible and develop some engineering change orders (ECOs) or other tricks to get you to pay more on their money-losing bid.

Now let's say the consultant is a saint. They don't try to upsell you, and they eat the losses on the project. What happens next? They lose their talent. And no, those people won't come to work for you. So all the institutional knowledge they brought and the business process expertise they developed for you on the project is gone. You get to pay for the learning curve all over again.

What do you think the chances are that the consultant's bid is within 10% of the effort required to make your team happy? Or that you had the foresight to tell the consultant at least 90% of your actual requirements before the statement of work? And what about the rubber yardstick of satisfying your users? Do you really think you can do that consistently, even when your own staff hasn't even analyzed your database before getting the bid?

Fixed Price Discovery, T&M Tasks

A common solution for these issues is to have the discovery and detailed requirements setting phase of the engagement be fixed price (perhaps 10% of the expected project value), with the actual implementation tasks as T&M. Even if the follow-on tasks are done as fixed price, this is a good step forward in containing risk on both sides of the table.

This approach provides incentives for both the consultant and the internal project manager to manage scope creep, make sensible tradeoffs, and apply some "value engineering." But there's still the issue of the unknown: the subtle data corruption or the API glitch or the political subterfuge coming from the Sales team (who - for reasons that are never clear - subtly oppose the project). In CRM projects of any size, these unknowns and unpleasant surprises can account for 25% of the effort.

Still think your team's initial task estimation is within 10% of the optimal outcome (where the users are actually satisfied, but without unneeded bells and whistles)?

There's an old adage in politics, "If you can get the other side working on the wrong question, it doesn't matter what answer they come up with." Maybe "how do I get it done at for $X" is asking the wrong question. All too often, the word "it" isn't tightly defined, guaranteeing a suboptimal answer. And the unspoken issue is trust and tight management.

Agile Fixed Price?

You may not practice Agile in your organization. Fine. But know that CRM system deployments are best done in this incremental, user-centered style. Salesforce.com and SugarCRM even build their products that way.

If an incremental deployment style is the right way to do CRM, how does that fit with a fixed price project? Agile projects do have fixed budgets and schedules - in fact, proper Agile projects have a better record of meeting those targets than conventional IT projects do. But Agile projects dont have a pre-determined set of features for any specific delivery.

The requirement "cards" and "stories" are continuously evaluated and re-prioritized through the life of the project. Why? Because the business doesn't really know what's going to be valuable until it sees it, or even uses it for a while. In a perverse way, Agile is an ideal fit for CRM work precisely because the details and ramifications of your requirements are seldom known until the project is underway.

So an Agile project would have fixed price and a time-boxed schedule, but a variable set of deliverables. You get the most valuable deliverables that could be produced for a given budget, but you don't get a fixed SOW.

Making Agile work for consulting engagements will require the same project management skills and attitude adjustment that it does for internal projects. But most consultants are living the Agile lifestyle already - the authors of the Agile Manifesto were consultants. So maybe the right question to be asking here isn't "how do we get it for $X?" but "given our fixed resources, how do we get the business payback from CRM in the fastest way?"

David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.