Our last installment talked about the fact that a project plan is only as good as the day you drive it off the lot. That said, it’s important for everyone in any way associated with that plan to understand a few things: 1) the overall desired outcome for what you’re planning, 2) the key milestones along the journey to get there, 3) those that truly own those milestones, and 4) how you plan on communicating changes to the plan along the way. By the way, that may have set a record for utilization of the word “plan” in one sentence.
Like any good PM, I’ll address these in order.
1) The overall desired outcome for what you’re planning. Don’t ever forget the big picture, or let anyone who’s associated with the effort forget it. How can this possibly happen, you ask? Take for example a research project I ran a year or so ago for a healthcare company interested in making a new social play that would fundamentally change customer perspectives in the face of health care reform. The team had completed all of the inputs – competitive analysis, application reviews, stakeholder and customer interviews, and was in the middle of preparing findings. During an internal review of the findings deck, it was snooze city: truly just a regurgitation of the blow-by-blow items that they had learned, and while it was all true, there wasn’t an emergent theme, vision, or new perspective, just rote analysis. I asked the team to step back and re-consider the data in the light of the project’s rather lofty goal, and while they came back with the perspective that the client should drop that vision like a hot potato, their second effort was defensible, solid, and passionate. The client, while disappointed, was at least not non-plussed, and the project achieved its desired outcome, in a sort of back-handed way. As a project manager, you have to remember that while part of your job is to maintain the budget and the timeline, it’s also quality control, at every level, strategic and tactical.
2) The key milestones along the journey to get there. This is much trickier than it sounds. It’s one thing to put a series of bullet points in a kickoff deck and watch the nodding heads, but still another to make sure that the right people are aware of what each thing means, why it’s relevant, and what their role in it is along the way. At TandemSeven, something we incorporate is a view of expected ownership across roles at our client for specific artifacts. Take for instance the super-fun Requirements Document. Folks always want to see that you are producing one, but it’s been my experience that it’s hard to assign shared culpability on the client’s side for the reviews and approvals of this critical, evolutionary tool. Instead of bullets, then, we advise on ALL the folks that will need to be present during this deliverable’s lifecycle, the percentage of time we expect to need over time from our clients, and then advise on specific review dates to help set expectations. This reduces the risk of the common response that the business team thought technology really should be owning it, or vice-versa, or some third category altogether.
3) Those that truly own those milestones. Here’s a good one: did you ever hear the one about the PM that never walked through the plan with his internal team to set expectations on ownership? So, yeah, that happened to me. Years ago, I made the Ungerian faux pas of assuming that all the team members were clear on who owned what, and since we’d worked on the kickoff deck together and presented it to the client, it was all smooth sailing from that point forward. Gosh, was I in for a surprise when I scheduled an internal review of the work flows and everyone showed up eager to see the work, but no one had done boo. While we had a lot of smart people on the team, we all came from multi-disciplinary backgrounds, and because this deliverable was happening in parallel to a few others, with each team member fully pulling their weight elsewhere, these lil’ ol’ workflows slipped through the cracks of my plan, all because I hadn’t taken a moment to confirm that Jack and/or Jill (note: not the team’s real names) should be owning them. That’s a mostly true story. And just remember that when you assume…
4) How you plan on communicating changes to the plan along the way. Last week, a client essentially asked, “so, remember when you asked us if you could interview these customers, and we said that you wouldn’t need to? Good news! We agree with you!!” The only risky part was that this alignment happened nearly a week after our desired window to perform said interviews. The answer is never “no, we can’t accommodate you” but rather “yes, but” and typically comes with a set of alternatives that the client may choose from. During this period of choice – and other situations, of course, may result in a delta to your plan – it’s critical to make everyone aware of any downstream milestone impacts, particularly ones that may involve leadership, whose calendars are often trickier to massage, even with weeks of foresight. Knowing how to deliver, escalate, and propagate this information at the front of a project is key, because change will happen along the way, and if you have a good RACI or DAI model (or some bastardization thereof) at the outset, you won’t need to get tripped up defining it in week four, and everyone on the team, especially the client, will share an understanding of the communication flow and related artifacts around that change. And big picture, this all means that you end up building a better digital mousetrap (better known as a customer experience).
And so ends our second installment. Speaking of setting expectations, did you ever hear the one about the Project Manager who didn’t really read their emails, or understand exactly what a team member was trying to do or say…?