There’s a boy scout motto, that I’m sure you’re all familiar with.
It’s simple, yet profound.
Regardless of what life throws at you, never allow yourself to be caught unaware.
I attended this PMI session Wednesday, and came away with a slightly derivative, but equally poignant motto for project management.
“Always have a ‘Plan B'”.
In web, mobile, and app development, we frequently talk about the ‘happy path’.
Its the principle that If the user does everything right and navigates through your product correctly, they’ll arrive at the right place, with the right feedback every time and your product will perform as expected.
But the ‘happy path’ is an illusion.
The series of improper clicks, unintended selections, erroneous keystrokes which can render even the most well-thought out user experience meaningless.
No one does everything right, so you’ve got to develop and test according to the ‘not-happy-path’.
In project management, the ‘happy path’ is Plan A.
It’s the plan that we all agree upon as the way to proceed.
Sponsors, beneficiaries, stakeholders, everyone signs off on Plan A, and we’re off to the races.
But what happens?
Inevitably, somewhere along the line, a milestone is missed, deliverables are delayed, unforeseen circumstances arise, and the project is in jeopardy.
You’ve got a drop date that can’t be missed.
So what do you do?
Well that’s where Plan B comes in.
Good project managers always assume that things will (not might) go wrong.
To err is human, and since we are all humanoids, erring must be factored into all (good) planning.
A Plan B is a critical component of effective project management because it acknowledges the need to have contingencies in place, in the event that your ‘happy path’ gets jacked.
The example the presenter gave at the PMI session was really good.
I can’t recall the exact details, but I’ll paraphrase.
Team A was working on a project which had a hard deadline. At some point during the project, it was decided that Team B would take over from Team A to complete the project. Needless to say, no one from Team A was happy about the decision.
During the meeting, when the change was announced, the Team B lead assured the client that everything would be done on time, “no problem.” The project manager for Team A asked if Team B needed any assistance in the transition, to which Team B demurred.
He then asked Team B’s lead if he knew (1) where Team A was on the project (he didn’t), (2) the current tools they were using to manage the project (he didn’t) and (3) whether he had a transition plan in place (he didn’t).
Sensing that Team B didn’t have a complete grasp of the magnitude of the project, Team A’s project manager proposed that the sponsor/client put certain milestones in place for Team B to meet, over the course of the upcoming week. If Team B failed to meet those milestones, the following week, Team A would reassume lead on the project, with Team B shadowing Team A on site.
Team B’s lead agreed, and then proceeded to miss the two milestones established for week 1. On Monday, of week two, Team B’s project lead contacted the client to update them on the status of the missed milestone, only to be reminded that they were due on-site to shadow Team A.
Plan B had kicked in.
Plan A – hand the project over to Team B – was the ‘happy path’. Team B was going to swoop in, pick up where Team A had left off, and deliver on time, “no problem”.
Plan B – revert to Team A – was the ‘not-so-happy-path’. In the event Team B failed, Team A would resume development and train Team B, for future projects.
Great. Now I’ve confused myself.
The moral of the story is that the project manager for Team A, had put in place a Plan B, in the event that Plan A failed, and Team B failed to deliver.
This is not to say that all plans fail.
But as Winston Churchill famously stated, “he who fails to plan, plans to fail.”
So always have a Plan B.