Eschew Boilerplate March 16, 2009Posted by Chuck Musciano in Leadership.
Tags: Boilerplate, Consulting
I spent eighteen months as a private consultant, providing executive-level IT consulting to a variety of clients along the east coast. Having been a consumer of consulting services prior to this phase of my career, I learned a great deal about being a provider of said services. Even though I’m back on the other side of the table, those lessons stick with me.
Part of high-end consulting is the “deliverable.” Beyond the stellar day-to-day advice provided by the consultant, the deliverable is supposed to provide a tangible copy of the wisdom delivered during the engagement. Some deliverables actually accomplish this goal; most fall horribly short.
A good deliverable is a completely custom document with two principal sections. The first section should capture everything the consultant learned about the client, with particular focus on the information pertinent to the specific engagement. Understanding a client’s overall business is important, but understanding the specifics of the problem at hand is crucial. This section tells the client that the consultant was listening, asked the right questions, and learned the right things to actually be useful.
The second section is the meat of the deliverable. It should provide detailed, specific information and solutions germane to the problem at hand. It should build on the specifics in the first section, and provide solutions and advice that actually apply to the difficulties being faced by the client. This section tells the client that the consultant actually provided value and is worth whatever they were paid.
Sadly, most deliverables are just reams of boilerplate. Most of this boilerplate tends to address “best practices” for the problem at hand. “Best practices” is a consulting term that means “Things I found on Google.” Anyone (and I mean anyone) can find best practices for anything (and I mean anything) with nothing more than a browser and a spare lunch hour. A little cutting and pasting, a few fancy templates, and—tada!—it’s a deliverable!
Here’s a simple illustration. You’ve engaged me as a consultant to help you select your next car. After meeting with you and your family for several days at an obscene hourly rate (plus travel and expenses), I provide a thick document that outlines the best practices in selecting a vehicle. These practices include sage advice like “if you have a lot of things to haul around, consider a truck” and “if you need to take long trips as a family look for a minivan” and “environmental concerns lead many buyers to select smaller, more fuel-efficient vehicles.” Would you be happy with this kind of advice? Would you pay thousands of dollars for it?
On the other hand, a good deliverable would describe your family, along with your short- and long-term travel needs. It might discuss your lifestyle and income. After laying that groundwork, it would suggest three specific models that would meet your needs, along with dealer contact information and recommended pricing. Sound like a better answer? I thought so.
Whenever I receive a deliverable from a consultant, I like to see how many times I can write “duh!” in the margin. Each obvious fact or meaningless observation gets a “duh!” on the side. I’ll forgive any consultant a few of these, but if you are averaging more than one for every three pages, the deliverable (and your invoice) go in the trash.
All consultants are expensive. Good ones earn their keep and prove it with solid deliverables. The rest get shown the door. (Duh!) That’s a best practice I’ll leave you with, for free.