I was once a team leader in a large project. At that time I wasn’t yet a project manager, but the project did indeed have someone with that title. I expected him to ask to see my plan, because that’s what project managers do, isn’t it?
His answer surprised me. “I’m not interested in your plan. But I’d like to help you produce one.”
I asked him what tools he would like me to use – again, isn’t that what project managers are supposed to do for a living? “I don’t care. Just invite me to your team meeting and we’ll do some planning.”
What happened next was a team workshop, in which we spent a lot of time coming up with a messy diagram on a whiteboard. It had activities, deliverables and arrows, and some dates. The PM challenged us to define the objectives, and constantly asked about dependencies. He didn’t do any “planning” that I could see – he just asked us tough questions.
At the end of the meeting we had a rather ugly diagram, but it was one that we were all happy with. I asked whether he would be turning it into an MS Project plan. “No, but you can if you want. As far as I’m concerned you’ve done the planning. You now have a high-quality plan that your team has bought into. As I said before I really don’t care how you document it.”
I learnt a lot from that PM – in fact, he became a role model for me. His point, of course, is that the planning process itself is what matters, and it matters far more than the plan. It matters because:
- The team does the planning. Not the project manager.
- The team thinks through the issues, and comes up with their own solutions.
- The team now owns the plan, and are committed to delivering against it.
I wouldn’t personally go quite to the extreme of not caring about the subsequent plan. It is an important baseline – something to track against – and it is an essential communications tool.
When I look at a project plan, the things that interest me are:
- Does it demonstrate how the project delivers against the project scope – is there a clear linkage?
- Are the dependencies properly shown?
- Is it likely to be understood by the intended audience (including team members and senior stakeholders)?
- Is it up-to-date?
I also like to ask how the plan was produced, and how it is maintained. To what degree are the team involved?
The form of the plan doesn’t matter. It can be MS Project, Powerpoint, Excel, or a squiggly diagram on a whiteboard. Just as long as the team regards it as being their plan.