Deliverables

If you’ve been consulting for more than a week, you’ve likely heard a client ask, “What are your deliverables for the project?” Sometimes, you get that question even after you and the client have agreed on project objectives, tasks, and expected value.

Some clients (and consultants too) just aren’t comfortable unless there are compulsory deliverables for you to dutifully create, package, and submit for approval. I’ve seen some consultants agree to tie their fees to the client’s acceptance of interim work product. That makes about as much sense as paying for part of a haircut before the barber has finished cutting your hair.

I know that complex projects and many IT initiatives need formal milestones with reviews of what you have accomplished. But too often, a deliverable, which is supposed to be a means to an end, becomes an end in itself.

It’s common to see project teams fixating on how they’re going to put together deliverables to gain the client’s approval, instead of focusing on the underlying success of the project. It’s not hard to find failed projects that have a long paper trail of approved deliverables.

Few things divert you from the real goals of a client project more than slavish dedication to creating deliverables, which can end up being of dubious value anyway. Change happens during any project, so a deliverable may not be relevant by the time you finish it.

Sure, it’s essential to measure progress. Just be sure that you don’t equate project success with meeting requirements for deliverables. Once you confuse the two, you’ve lost sight of why the client hired you in the first place, and it won’t take your client long to figure that out.