In a consulting project – particularly when implementing custom software –customers feel that they should be in charge. They are paying the bills, and only they know what “the right outcome” needs to be. So the consultant should be following client directives throughout the project, unless there’s a valid technical or “best practices” reason to do otherwise. And that all works out just fine, as long as the client is willing to pay all the bills for all the hours involved, without protest.
Does that last sentence sound like you? I didn’t think so.
Let’s take a deeper look. The paragraph above is the purest case of time and materials, where the consultant is selling you “just hours” that you are free to use as wisely or stupidly as you please. Most clients want more than that, so that the consultant takes responsibility for executing a plan and completing deliverables.
In a project of any complexity, though, the deliverables have clear dependencies on client assets, decisions and efforts. So the success of the project will depend on cooperative activities. This means that the project – and in particular the project management – is a joint responsibility. Consequently, budget, schedule, quality, performance, and feature sets are a matter of tradeoffs and negotiations. Unless you have a ton of time or money, you’re not going to get everything everybody wants. In these hybrid “T&M” projects, the bid is in the form of hourly fees with an authorized maximum, and it’s up to the twin project managers (one for the client, one for the consultant) to get the most satisfying compromise.
There are two fatal flaws in this model, both having to do with managing expectations. First, clients need to understand that they are unlikely to get every deliverable without some compromise – particularly in custom software, where nobody knows exactly what’s involved until the project is more than half done. Second, the project lead on the consultant side must actively manage expectations during every client meeting. If the project lead on the client side is weak – technically or politically – s/he will not successfully propagate the realities of prioritization and negotiation to executives in the client organization. This means the project is in trouble before it starts … and, worse, the trouble can be totally invisible to the client until it’s way too late.
[ Related: Is your vendor smarter than a 5th grader?]
So let’s say you don’t want any of that: You want to write a spec, pay a price and just wait for the consultant to deliver. Can-do: It’s called fixed price.
I’ve lived in a fixed-price world, and it can actually work pretty well. But most clients don’t understand the implications of a fixed-price engagement for them.
- The project can involve very little creativity or real innovation, because those involve risks that can’t be quantified at bid-time. For example, configuring a SaaS application or installing a sub-network fits fine with fixed price. But things get dicier when it comes to something like a greenfield accounting system install … and system conversions or clever business processes are way over the line. While a sophisticated project can have fixed-price elements, it will need to have T&M elements that will muddle the “sign and forget” nature of a fixed-price project.
- The project must have an incredibly tight spec, where the client describes the required features in detail. This means a lot of homework on both sides prior to bidding, and a strong tendency towards waterfall projects that limit efficiency and flexibility.
- The consultant must put “fences” around deliverables to limit risk. For example, instead of saying “sales reports,” the bid will say something like, “up to six current pipeline reports and one commission report that covers just the current month.” This makes the bid process more expensive for the consultant (as they have to dream up all the fence verbiage) and more irritating to the client (as they don’t know what the fence verbiage means or how it will impact them).
- The consultant is likely to put exclusive responsibility on the client for items such as data quality, record conversion, and required facilities. The consultant is likely to put an amazing array of “outs” to trigger change- orders and T&M tasks.
- Project management will be dominated by the consultant, even when there is a joint activity. This means you need to comply with their schedule and processes, unless explicitly stipulated otherwise in the spec and bid. (Of course, to the degree your organization has special process needs, or wants to deviate from the consultant’s advice, the bid [and inevitable change-orders] will reflect that with a higher price.)
- The consultant will probably require sign offs at several stages, and has an incentive to apply time pressure at each approval cycle.
- The consultant will try to substitute offsite and offshore resources at every possible opportunity. You can stipulate specific resources and on-site percentages, but that will only drive the bid cost up.
- Every time you discover something new during the project, change-orders will be coming. Just like with construction projects, even simplifying a deliverable item will need paperwork and may not reduce the budget or bring in the schedule.
There is no free lunch
You’re going to be paying for a lot of lunches in your project: People will be eating. The only issue is how well are the charges hidden in the bid.
By necessity, a fixed price or hybrid T&M project will have a more complicated contract and statement of work. If you want simple contracts, you’ll find them only in pure T&M projects. But no matter what form your project bid takes, make sure your lawyers read both the main agreement and the statement of work (or related attachments, no matter how they are named). The clever consultant will scatter the sneakier stipulations all over the place, hoping that the contract reviewer will doze off before connecting the dots. In the immortal words of Tom Waits, “the large print giveth and the small print taketh away.”
Want to know my firm’s top 10 sneaky contract stipulations? Maybe next week. On second thought, they’re a trade secret.
This story, "Why the customer is not always right" was originally published by CIO.