A project plan isn’t enough
- December 12th, 2010
- By Tom Woodman
- Write comment
I was introduced to a new friend this week. She works in the new media and so we got to talking about this blog series on change. I laid out my desire to have us all manage calendar data in a way that makes them publish-able and subscribe-able. She was familiar with the notion and uses Google Calendar to manage her calendar and her boyfriend’s calendar.
She asked the obvious question. “Do you have a plan, or are you just figuring it out as you go along?”
My answer is that I have a plan and the plan involves figuring it out as I go along. Let me explain.
Plan: A scheme, program, or method worked out beforehand for the accomplishment of an objective.
Classically-trained project managers are taught to put together a project plan, often using Microsoft Project or some such software showing milestones and requisite tasks for accomplishing the objective. The plan presents itself hierarchically, resources get assigned to each task. Each task can be marked complete. Tasks have dependencies to other tasks that indicate order of operations.
In past projects, I’ve found this approach alone wasn’t helping me navigate complex landscapes in the workplace. Here’s why.
Creating this kind of project plan assumes the plan can be known in advance – complete with tasks, milestones and resources. In my experience, this is seldom the case. We are not clear about what needs to be done until after we’ve started the project in earnest and begun to make commitments. The vision — and commitments to bring it to fruition — is revealed as part of a collaborative process.
But, most Plans have a single owner. All updates to the plan need to be channeled through the project manager. The project manager becomes a slave to the updates, gets sick of making them, and the plan quickly becomes out of sync. Updating the plan is tedious and, generally, thankless since its viewed by only a few persons at most. So, what typically happens is that the plan is almost immediately out of touch with the realities of the change initiative. Controlled by a single individual, the file can’t keep up with the dynamics of dialog, commitments and task completion.
Another problem is that the Plan presents itself in a linear, step-wise fashion. But, the people’s reality of a project is as a wave form with emotional highs as we make progress and lows as we struggle to let go. We establish a shared vision, agree on a course of action and then revise it. We collect key stakeholders, begin work, then realize the need for more stakeholders. Always, this forward and back motion between the steps.
The plan is also thought of as a completed entity. But, what is required to engage others is for them to have a share of the planning and visioning throughout the process. We need others to make commitments to tasks, make mistakes, and then course correct. Agility, adaptability must be modeled throughout. It’s not a phase we do and then stop doing. It’s a mindset we’re after — that the collaboration comes first.
Since the Plan is complete, we don’t need to consider it anymore. Whoever didn’t provide input is just out of luck. This in turn produces a lack of ownership among those that feel left out. The plan creates an arbitrary attachment between milestones and dates where the ebb and flow of dialog makes it difficult to really know when a milestone is actually reached.
Stale, cold, lifeless. The Plan isn’t connected to the process. The action is happening in dialog, questioning, imagining, learning, letting go.
What we need is something that can keep up with the activity stream and inform next actions. Something that connects moments of the project and strengthens the bonds of thought over time. Next post, we’ll look at how we can plan to be agile using a framework that expands our collaborative capacity.


