I’m starting a new client project next week. Now, I’ve been at this for a long time—it’s consulting project #74 (& yours could be #75!). Along the way, I cobbled together a short checklist for the first days of a new engagement.
Here it is:
- understand the project,
- understand the client, &
- understand the work.
Sounds simple—and it sometimes is—but I’ve watched skilled people create problems for themselves by rushing in. Hell, I’ve been one of those people.
Understanding the project
Take as given some sort of plan or statement of work or agreed-upon outcome—which is great, but not what I’m interested in up front.
Instead, the very first thing I wonder is: who wants the results of this work to be good (also, what might ‘good’ mean for them)? And the second thing is: who is worried it will be bad (and what are they worried about)? I might host a premortem in order to get people talking specifically about the bad things that might happen. This helps me suss out who cares about what, and who else should have been included that hasn’t been (yet).
I am also drawing pictures in order to answer questions like: why this work? and why now? A round of ecocycle planning can bring this to light. Another approach is to map the value chain, which will reveal some dependencies, possibly hidden, and clarify what’s super important and what’s not.
Understanding the client
How does a client want to interact with the consultant or the consulting team? ← You would be amazed at how often consultants do not ask this.
I follow Jerry Weinberg’s advice (“Your methods of working are always open for display and discussion with your clients”) but it’s an invitation, not a demand. Some clients want to work “at the elbow” and participate in the mess from beginning to end. Others want to check in weekly, or monthly. Dial this in and you’ll know whether to work with the metaphorical garage door up or down.
When getting to know a new client, I will pay attention to what they react to in materials (documents, plans, etc.) and what it’ll take to get good feedback on those materials. I remember the client for whom we did a full style adherence pass on even the roughest drafts and sketchiest ideas before putting thing in front of them—because otherwise we’d get a sequence of comments about images being imperfectly aligned and nothing else. And that’s OK—giving thoughtful feedback is hard and people are busy. Sometimes clients, or their teams, need an idiosyncratic feedback container & review process in order to elicit the right kind of notes at the right time.
At the same time, I figure out how to make myself easy to fire. I recently ended a project 2 months early due to my client’s budget getting jerked around. This came at precisely the worst time: I was close to wrapping up, but not quite finished. Even so, I was able to hand things over in an orderly way. I’d kept things organized as we went, so the various transitions (or “knowledge transfers,” to use the unlovely jargon) were easy to make. I could focus on communication and relationship and problem-solving, rather than scrambling to claw half-baked work items together.
An old consulting boss said she never wanted her clients to create a dependency on our services. There’s always more work to do, and people mostly remember how they felt at the end of something, no matter how miserable the middle portion was. Being easy to fire means that I can always find time at the end of a project—even when they end early or suddenly—to make the ending nice and calm and appropriately bittersweet for everybody.
Understanding the work
Finally, I will begin to indulge my curiosity. Not just in the work specifically entailed in the project, but in everything surrounding it. This is the fun part! It’s also where, as my friend Andre says, “every project is a lean project.” I start this by going to where the work happens, and spending time with the lowest-status people doing the work, and paying attention. The point is to learn the process, notice where it breaks down, and find the places where success hinges on tacit knowledge. (Read my field guide on the 6 MISSED wastes for more on how.)
When people tell me things like “we don’t have a process“ or “every x, y, or z is different,” I’ll break out a work-unit routing analysis (WURA, sometimes also known as product-quantity-routing (PQR) analysis) worksheet and become a student of the variation I see and hear about. This gets me on the way towards sorting things into value streams or some other aggregation.
Despite the experience or expertise that the client presumably hired me for, in these moments the value I bring is that I can look with a beginner’s eyes and wonder with a curious mind.
Last but not least: actually doing the project
But that is—as they say—another story, and shall be told another time.