With more than 30 years in technology consulting, I feel I can safely make a few observations about the field. The first is, alas, I'm growing old with the industry. The second is that I've had quite a lot of experience with customer/consulting relationships over the years, both good and bad, from my early days in statistical consulting to my current position in professional services management at OpenBI.
As such, I hope I have a bit of wisdom to share with InfoWorld readers regarding the recent article, "7 dirty consultant tricks (and how to avoid them)."
[ Read the original InfoWorld article 7 dirty consultant tricks (and how to avoid them) and see what the buzz is about. | Learn how to avoid IT's biggest money wasters -- and how to assemble your crackerjack A-Team for IT special ops. ]
The article takes on the consulting profession, especially IT consultants, for tricks often deployed to "extract money from their clients." Among the shady practices identified: bidding low and billing high; misleading customers about the makeup of the consulting team; dragging out projects to rack up more billable hours; and selling the latest "solutions" to customers, regardless of whether they're pertinent for customer needs. These four, along with the three other tricks identified, provide the foundation for what reads like a broad indictment of IT consulting.
As a practicing consultant who's proud of my profession, I don't feel dirty tricks are nearly as prevalent as the article suggests. Moreover, I don't see our industry as a necessary evil, but instead as a fundamental contributor to the IT ecosystem. Few companies choose to maintain a permanent IT staff with the broad range of tech expertise and bandwidth to meet unexpected user demands and new development initiatives. Consultants are essential contributors to the well-being of IT.
That said, during my career, I've seen six of the seven tricks "successfully" executed by services firms. Of course, there are some less than reputable consultancies, just as there are less than reputable customers. The biggest problem for consumers of consulting, though, derives from lack of oversight of the consulting relationship -- from the sales process to contract negotiations to project delivery and sign-off. The good news is that most of the problems are avoidable. With proper negotiation, contracting, and oversight, most dirty tricks simply go away.
Indeed, the risks of tricks two through seven can be effectively neutralized by a combination of tight contract specifications and capable project governance. No way should a savvy buying team be tripped up by consultancies that push the latest and greatest or lack the expertise they purport to have. Simple (but detailed) reference checks would expose the puffery.
Similarly, no way should a consulting company be contractually able to take hostages, accept kickbacks, or fall victim to double dipping. A standard master service agreement should protect the buyer. And no way should a contract be finalized without knowledge and approval of the top consultants to be assigned to the project, thus minimizing the B-team risk. Finally, I've seen plenty of experienced customer project managers effectively manage consultant attempts at stalling.
In fact, when I classify the tricks, I see the first, bidding low and billing high, as a greater risk than all others combined -- and not just because of shady consulting practices. Requirements known at bid time can be very different than those implemented in design and build, even when both parties act in good faith. Bid and bill may diverge for reasons other than dirty trickster consultants.
In response to the article, let me propose a turnabout that reframes "bid low, bill high" and notes six "unwise practices" that cause conflict between customers and consultants -- plus one experience-based recommendation for consulting colleagues.
Unwise practice No. 1: Inflexible contractual terms
Prospects often think they can minimize consulting risk by negotiating a fixed-bid contract with their chosen services provider. In theory, they'd know their costs upfront and the consultancy would be on the hook to deliver to the specifications. But fixed-bid projects often play out differently than expected, with problems that go beyond bidding low and billing high.
It's generally a fallacy for consumers to assume consulting firms are loathe to sign fixed-bid contracts. Indeed, with a solid understanding of requirements and contractual terms that address risk on both sides, savvy consultancies welcome the opportunity. Given a carefully crafted statement of work with a payment premium for risk, the fixed-bid contract should be more lucrative to consultancies than time and materials -- if executed properly. In fact, with BI (business intelligence) projects, I generally find that customers rather than consultancies tend to hesitate on fixed bid.
Unlike with transaction apps, BI requirements tend to grow as customers begin to understand the possibilities. Success with BI is often manifested with reactions like "Aha, I see what you've given me. Great stuff! Can you now give me this, that, and the other"? But this, that, and the other are generally not part of initial requirements, hence a change order -- or, perhaps, a phase two. A next phase is almost always welcome by the consultancy and is generally a sign that the customer is appreciating the value of and growing in its deployment of business intelligence.
Two years ago, OpenBI engaged with a prospect who sought a fixed bid for development of a BI reporting and dashboard application. The firm presented us with a document that purportedly contained all application requirements. With little information outside this document, we put together a statement of work for a 15-week fixed-bid effort that included the following provisos to minimize our exposure to the unknowns not addressed in the known scope:
- All requirements would be solidified during the first three weeks of the project. After that period, new requirements would necessitate a change order.
- The prospect would accept the out-of-the-box look and feel provided by the BI platform -- that is, we would not "skin" the application to dramatically change its appearance.
- The data sourced from the transaction systems had to be reasonably clean. A big data purification effort would result in a change order.
After a few rounds of negotiations, the prospect's COO decided that a fixed bid might, in fact, be too risky for his company and proposed instead a tightly controlled time and materials engagement with weekly status meetings and limits of 40 billable hours per week for consultants. This turned out to be a very prudent decision, saving the project from what we later learned would have been change order hell.
There's a saying in the BI world that the project doesn't start until the key user first sees a prototype with real data. That was certainly the case here. Not only did the company decide it wanted a snazzier, nonstandard look and feel that would have to be further specified and programmed, the prototype brought out many new business requirements and highlighted less than stellar data quality.
The key user? None other than the CEO. With a tight time and materials contract in place, we were able to continue without interruption as new needs surfaced rather than slowing down with an arduous -- and expensive -- change order process. The customer's consulting manager did a great job holding our feet to the fire throughout -- annoyingly so, I thought at the time. Overall, the engagement was extended a month, and the customer, though not thrilled with an additional 15 percent expenditure, was quite satisfied with the application. The customer also understood that what was delivered was a lot different than what was initially contracted. Both sides now enthusiastically reference each other as partners.
It's been our experience that fixed-bid contracts are generally not an effective safeguard against vague requirements and, thus, not an effective risk management device for customers. Companies who use fixed bid in this way usually don't get what they want and risk change order nightmares. Instead of a win-win, a lose-lose relationship ensues.
Unwise practice No. 2: Evaluating prospective consultants by their hourly rates
Rather than judging suitors on the total cost of consulting services to deliver a given basket of functionality, consumers are often boxed in by limits on the hourly rates of the consultants they engage. Low rates fly under the radar, while those above a threshold are often non grata, regardless of quality and productivity.
The fact that it might take a $50-per-hour consultant three times as long to complete a task as a $100-per-hour candidate is irrelevant with this thinking. Many times, the low-rate consultants end up collaborating for long periods with inefficient, combined customer/consultant project teams, resulting in a bigger management investment from customers.
What's needed is an evaluation process that measures the total cost of delivery, including opportunity costs, for specific functionality -- and a recognition that "burn rate" does not equal "value generation rate." Our advice to customers: Always look to minimize cost for demonstrated quality rather than risk an unknown quality for minimal cost. In short, understand your risk-reward equation and make a rational decision.
A new contracts administrator for a recent customer initially fumed over the average rates for our 12-week, 3-person BI platform app/dev proposal in contrast to those of another vendor for a 3-year, 12-person Java development project -- an apples-to-oranges comparison. Fortunately, the company's BI lead succeeded in persuading management that we offered expertise well worth a short-term "premium."
Unwise practice No. 3: Insisting that prospective consultants "prove" project ROI
Our consultancy is still occasionally tasked by prospects to demonstrate the "ROI of BI," although this requirement comes up much less often than it did 10 years ago. It's a legitimate business question to ask, but it can also be a red flag that the initiative doesn't have proper backing within the firm.
If the ROI question arises and the engagement is sponsored by IT rather than business, there may be problems ahead. To IT, BI is often just another application, much akin to order processing or SCM. Most successful BI deployments, though, are driven from key evidenced-based business practitioners who aspire to drive decision making with data and analytics. Successful BI deployments, for example, find ROI in the business through these criteria:
- The value of more timely data for decisions
- Improvements to the bottom line from better decisions
- The value of having analytics/reports they didn't have before, though it's often difficult to quantify "smarter" business
- The value sometimes serendipitously arising from a single insight (such as finding an unexpected pattern of fraud)
While we certainly help the business calibrate the costs and benefits of the improved decisions, taking ROI out of the business context is a mistake that signals business and IT are not aligned. It goes without saying that ideal situation is a partnership of the business, IT, and the consultancies.
Unwise practice No. 4: Expecting free, unlimited pre-sales consulting
Author, consultant and Harvard adjunct professor David Maister offers strong advice for professional services firms: Never respond to an RFP unless you have an in-house coach guiding your sales process. While we're less adamant than Maister, there are good reasons not to be just another pretty proposal. The likelihood of an unknown emerging in the process to win a bid is practically nil, and the main competitor is often not another consultancy, but rather no project at all.
We can think of four RFPs we were invited to participate in the last year, of which we submitted one proposal. Three of the four (including the one we submitted) didn't transition to full-scale projects, but instead to either a much less grand task or to no engagement at all. The fourth was awarded to a friend of the firm from a field of 12 applicants.
Companies sometimes issue RFPs as a means to educate themselves about different solutions. They then decide what to do after reading responses, often changing their minds when they see the price tags. We recently declined a small company's request to respond to an RFP, offering instead a few hours of free consulting with our top architect to discuss options and costs. Over the course of the discussion, the CEO acknowledged his company couldn't afford the solution he'd asked for in the RFP -- but in the end asked if we'd respond anyway.
Above and beyond RFPs, it's important for busy consultancies to parcel out their presales wisdom prudently. For example, OpenBI often gets inquiries from .Net shops about open source business intelligence platforms. While we're always willing to have technical discussions with these firms, we know full well that no .Net company we've ever prospected has opted for an OSBI solution. Given that "predictive" model, it's unwise for us to invest too heavily with such opportunities.
Unwise practice No. 5: The handling of confidentiality, IP, and noncompetition terms