Friday, June 20, 2008

Surefire Strategy #10 For Producing A Consulting Project Train Wreck - "Have Faith That Everyone Will Know What This Project Was All About At The End"

So here we are folks, the first of my proven strategies for ensuring that your consulting project never actually delivers a single ounce of value for your client. And remember, the key is to ultimately identify the antithesis of this strategy and implement THAT instead! Surreal I know but then the writer of this blog is British and very much a fan of all things Monty Python.

The "Have Faith That Everyone Will Know What This Project Was All About At The End" strategy refers to the approach of never actually letting the client in on the secret of what you are planning to deliver by the project's end. These projects generally start out well enough but invariably reach a point where client and consultant have a conversation something like the one below:

CLIENT PROJECT SPONSOR: Thanks for meeting with me at short notice, Jim, but I have a concern about something. I’m sure it’ll only take a minute to clear up.

CONSULTANT PROJECT MANAGER: Sure, Susan. What’s the problem?

CLIENT PROJECT SPONSOR: Well, I dropped in on Rob this morning to get an update on the project and he showed me the Phase 1 deliverable document you guys have just finished. I was a bit confused. It wasn’t quite what I expected.

CONSULTANT PROJECT MANAGER: Really? In what way?

CLIENT PROJECT SPONSOR: Well quite frankly I’d been expecting more from eight weeks of work than a PowerPoint document with a few tables on observations and issues. Didn’t we talk about “as is” process flows? And what about the item level savings analysis? All I saw were some industry average percentages applied to the same numbers our accounts payable group gave you in June. There’s more detail behind what Rob showed me, right?

CONSULTANT PROJECT MANAGER: Hmmm, well not really Susan. I think we talked about process flows being something that could be done in some situations but that what made more sense here was working with stakeholders to get to key issues. We’d then structure the to-be vision to directly address these issues. As for the savings analysis, well we always said that the ability to go the item level would hinge on being able to collect the data. Unfortunately we just couldn’t get the data from the field so we had to use the accounts payable numbers.

CLIENT PROJECT SPONSOR: I have to admit, Jim, I’m not happy about this. I had a very different picture of where we would be at this stage of the project. Until I feel expectations have been better met I’m going to delay signing off on the Phase 1 deliverable. Let’s pull the project team together at 2 o’ clock and figure out how to fill in the missing pieces.

What eventually transpired in the project above? Susan found out in the meeting that the field had indeed been unable to provide the required data and that the smartest and most resourceful consultant in the world would never have been able to generate the “promised” item level savings analysis. And the as-is process flows? If producing these flows had been expressed as a must-have requirement at the beginning of the project it had never been documented. Susan ultimately became resigned to the fact that she had no clear grounds to deny payment to the consultants for the Phase 1 work. What she did do, however, was to exercise her right to terminate the project before embarking upon Phase 2. Losers all round – the client received no value from its perspective and the consultant lost the remaining revenue as well as the chance to ever do business with that particular client again.

What went wrong? First, it is clear that the major work products and deliverables for this project were not clearly defined up front. It was the responsibility of Jim to provide clear and unambiguous definitions of these to Susan before the start of the project. It would then have been clear whether or not process flows were to be produced or not. Secondly, expectations were not set with the client about potential project risks and the impact of these risks on project deliverables. If Jim had explained to Susan up front about the risk and impact of not being able to collect the item data then Susan could have made an informed decision about whether to move forward with the project or not. But because the risks were never explained she never had the chance to make that decision.

The takeaway from the above is:

Always define clear and unambiguous work products and deliverables for your project and, in addition, set clear expectations about potential project risks and the impact of these risks upon the work products and deliverables.

In other words, AVOID AT ALL COSTS Surefire Strategy #10 for Producing a Consulting Project Train Wreck – “Have Faith That Everyone Will Know What This Project Is All About At The End”!! Implement the antithesis of Strategy #10 instead! Get the idea? Good!

Coming next week – Surefire Strategy #9 for Producing a Consulting Project Train Wreck:

“Sub Out Major Parts of the Work, Get On With Other Stuff Then Check In With The Contractor At The End”

2 comments:

Anonymous said...

Funny Mark but quite true, and sage advice I would say. This consultant has been involved in one or two projects like this. Of course the customer takes some responsibility for making sure they know what they are buying. But overall I would agree the consultant should adress these issues up front to avoid problems. Was it a real project by the way, or a illustrative example?

Mark Usher said...

Thanks for the comment, Bryan. Yes it is a 2-way street - the client does need to exercise purchasing best practices by clearly understanding the deliverables she is contracting for. On the assumption the consultant wants to ensure value and grow more business with existing accounts, though, it makes sense to be pro-active. Was it a real example? Let's say it's an amalgam of several horror stories I have been either personally involved in or have direct knowledge of....