How to Avoid the Project Management Deliverable Dance

Confession: If I counted number of times I’ve said “I think the client is expecting this…” I would be one very depressed project manager. If it were someone else’s report card I was grading, I’d give that project manager a mediocre grade.

If there were a grade for building client rapport, I’d probably score very high. In most scenarios, I’m able to push back to the client. However, the delivery process can be quite nebulous. As project managers, we need to keep our clients up to date on project progress, but not every activity results in a tangible item that they can review. We also want to serve as translators for concepts or processes that they may not have intimate knowledge. However, every contractor has slightly different processes and your client may not understand yours.

You want to make things easy for them to understand and accommodate their requests or questions, but you also don’t want to tailor the deliverables to match those of a past agency or contractor who provided services.

This year I’ve noticed I was becoming more lenient in delivery standards. Sometimes I asked my teammates to alter the presentation of their work for one client radically from how we would for others. I did this in the name of client service and process refinement. Sometimes this might even take several rounds of revisions with my teammates. I was doing a dance and it was costing my team. So I decided to get back on the straight and narrow. Here’s how.

Details, project manager, not definitions

Now when I work on proposals, RFPs or even SOWs, I look for flexibility to explain our process. Whenever I see an opportunity to elaborate, I focus on the what and why of the activity. I then close it with a statement on what the deliverable is expected to look like.

Saying “You’re going to get 50 recipes” as the outcome of a cookbook project as part of the proposal is set up for headaches. You can’t guarantee this before you’ve planned out what those 50 recipes are even going to be. It may be that you find that one crucial recipe is actually better digested as 3 smaller sub-recipes. Or adapting another recipe to be vegan can’t be resolved by just substituting ingredients and that you’ll need to write a separate set of preparation instructions as well.

No project is ever truly static. Things may not flow nicely into one another. And rarely do the deliverables we put together stay final, no matter how many times we might send over a document with “FINAL” in the file name. When you try to force your project into a defined schedule and timeline too early on in the process, you might be disabling some creativity you might have explored if you weren’t confining yourself into. You could end up burning both yours and the client’s money and time scrambling to fit things into the defined plan.

Know how to do your work, but don’t let the work define how you do it.

Own your project management role and expertise

As project manager, you own the process to making the project a reality. Your teammates were chosen based on their expertise and ability to accomplish the project. As a team, you define the appropriate way to share you work with the client.

Sometimes this means you stick with your process that you know will deliver success. Other times, your team might want to try something new.

When the client has declared that they know the right way to do things, but your team disagrees, it is your responsibility to educate the client and nudge them in the right direction. Sometimes this means we have to show models or prototypes. Or we might have to find ways to go above and beyond to explain to them what we mean. In our cookbook example, we might need to set up a test run with an unacquainted cook to prove that the complex recipe needs to be broken down further.

All this means that we might need to stray from our process and that’s okay. It’s when we start changing our process to match expectations that we don’t agree with that is not okay.

That’s where I found myself on a few projects not too long ago. I catered too much to what the client wanted while telling my teammates, “But it’s what the client expects to see.” I started to lose sight of the process that defines the product and only saw the deliverables I was obligated to produce.

Recognition of the problem was my first step in gaining back control of my projects. Reminding myself that deliverables are tools used to communicate progress brought excitement back into my projects; success is just an important measure for me as it is for the client. Make it yours and own it.