Why does a software development project need a project plan?
I expect a wide range of answers to this question and no doubt many of them have merit. But what is vital, is that a plan communicates what is going to be done and when. A project plans needs to be shared, understood and hopefully agreed by everyone involved in the project. A plan should not just be used by the project manager, it’s an essential communication tool for the whole project team and project's stakeholders.
A project plan is the product of considered investigation, experience, estimates and assumptions. Every plan for a software development project is unique and there are a myriad of factors that will influence it’s successful execution. The value that can be gained from a project plan depends on the thought and work that goes into constructing it in the first place.
And so what is the best way to start building a project plan?
Some PMs start building the plan from the ground upwards, itemizing all the activities, estimating the effort and then putting each activity on a timeline in sequential order. This approach although unquestionably comprehensive can have some drawbacks unless each task is carefully structured within identifiable project stages or within discreet development cycles. It's a time consuming exercise and it doesn’t serve the start up stage of a project as best it might. The issue is that project sponsors are most unlikely to review the detail of this type of project plan. If you’re lucky they’ll scan over it, they might glaze over or they may just glance at it and say it looks great. But this type of detailed plan is unlikely to simply convey the key message. And the key message is; what needs to be done and when does it need doing.
To present the overall plan to stakeholders so that they understand it, and for them to provide constructive feedback, the plan needs to be kept simple. And by simple, I’m suggesting a single page that can be digested in seconds. Instead of detailing all the activities, only present the main project phases or key development cycles and key milestones, for example when a major new feature is expected to launch.
People can engage with this sort of overview plan. They can comment and advise on it and this is exactly what you want. The best plans are are built collaboratively with other people suggesting changes that the PM might otherwise have never considered. A project plan that can be successfully socialized is an effective plan.
But it doesn’t end there. Surely you didn't think it would be that simple did you? A detailed plan of all the activities is also required but these details are only required for the phase that is just about to start. For example, when the project is nearing it launch deployment stage, itemizing all the technical undertakings, all the content preparation work and the communication activities will help make the stage to go smoothly. The value in a detailed plan is gained by the exercise of bringing all the required activities together in a single place. This detailed plan can also be shared, but only with those that need or want to know. Attempting to plan in detail all the activities for project stages that are a long time into the future has little value in the short term and is often compromised by planning fatigue. And the further into the future that you try to plan, the less reliable the plans are likely to be anyway.
We should have a simple summary plan that fits onto a single page which shows the big picture of the project. It serves as the main planning communication tool for everyone involved. And for the project stage we’re currently running, we'll have a detailed plan and at the same time, we'll be preparing the next detailed plan for the stage just ahead of us.
The summary and detailed plans can be separate plans or if you’ve some skills with a specialized planning tool then you may be able to hide the details of a plan within a summary view. Tools such as Smartsheet.com are pretty good at creating summary plans while still containing the detail. But such planning tools can take a little time to learn how to use.
I call this approach to project planning "creating half a plan.” It’s not too much and it’s not too little – it’s just right.
What is your approach to creating a plan for your web project and how do you get other people to engage with it?