This post is a continuation of Keys to Project Success - Part 2
Don’t Skimp on Planning
I should start off this segment by defining what I consider “planning” to be. Planning is not just scheduling, although many ‘project managers’ I’ve encountered in my career consider the creation of a project schedule the totality of their planning work. For me, planning is much, much more. Planning is determining not only the sequence of events and the expected effort involved (in other words, the schedule), and not just who of the existing team is going to do the work, but is in fact the creation of a comprehensive model of everything that will happen to achieve the goals of the project in advance of the project being executed.
What do I mean by, “a comprehensive model”? I mean that everything that needs to be determined on how all aspects of the project will execute is in that model – is part of the plan, and included in the plan document. And that includes not only a schedule at the appropriate level of detail, but also the following:
- Resource management plan: This isn’t just figuring out who to assign to what tasks, but also how you’re going to structure the team(s), an honest assessment of the team members’ capabilities as they relate to the skills needed for the project, and how you intend to bring the skill levels up for those that are lacking. What will the team structure be? Who will report into whom? What are the accountabilities of team leads? How will time-off be handled during the project? How will you source people that don’t exist within your organisation? What will you do to bring them up-to-speed? And what about the non-human resources? What do you need? Where will you get it? Does it need special environmental conditions, or require installation or some other kind of preparation for the project? How will that happen?
- Risk management plan: What is the set of mechanisms by which you will recognise and assess project risks? And if you determine that the risk to be too great, what are the steps you’ll go through to create a risk management plan for that risk, and make appropriate modifications to the overall project plan? How will you track your risks to ensure you will always be ‘on top’ of them and they will not kill your project?
- Issue management plan: You can think of issues as risk events that have happened. If you had already recognised the risk, and assessed it as significant enough to warrant its own risk management plan, which you prepared, then your issue management plan would be simply, “Put that risk’s management plan into effect if it isn’t already.” But what if you hadn’t? Then what? And how will you track issues through to resolution?
- Change management plan: Risks and issues can certainly result in significant change in a project, and so too can external forces such as the change in a client’s business requiring a change in the deliverables of the project. So what happens when there is a change? What are the steps you will execute?
- Communications plan: How will you go about ensuring that the stakeholders who care about the project remain comfortable about the project’s progress and continue to support the team? What mechanisms will you put in place?
- Quality assurance plan: What are the various practices, processes, and disciplines that you will implement throughout the various stages of the project so that the end-product is fit for use?
These are what I consider the minimum elements of a good project plan, along with an appropriately detailed schedule. Creating such a plan is not merely an exercise of pulling together some ‘stock text’ and templates, modifying a few words, and then wrapping it all up in a nice document with a table of contents. It is a thoughtful exercise of really thinking through each facet in the context of the project at hand and its goals. The result should be a pragmatic guide to everyone involved in the project, illustrating exactly how everything will work over the course of the project.