forget your password?

Why Your Project Only Needs Half a Plan

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. 

                          A Complex Plan

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.                       A Simple Plan

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 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. Half a Plan

What is your approach to creating a plan for your web project and how do you get other people to engage with it? 

You might also like:

Comments (4)

Ian Sharp

August 28, 2014 at 12.24 pm

Ben, you make a fair point. Agile projects usually don’t require detailed project plans in the same way that traditional waterfall projects do. And so it’s certainly true that in traditional waterfall projects, it’s much more likely that the detailed project plans created are incomprehensible to the stakeholders. 

Not having a plan at all might be ok for small, simple projects that don’t have a fixed scope or a critical deadline. But for other larger, more complex projects that have a hard deadline, I would recommend that a plan is mandatory, whether the project is being run waterfall or Agile.

Therefore I would advocate ‘half a plan” for all projects as without one, how will the stakeholders have confidence that project is set up to succeed? Half a plan is predominately a road map of how to get from the start to the end of a successful project. Perhaps, a release plan is not too dissimilar to half a plan anyway..


August 28, 2014 at 7.22 am

This post seems to focus very much on the traditional waterfall approach to projects as well. Would you say that only “half a plan” is needed for stakeholders in an Agile project? Or because user stories low down on the release plan tend to be more vague and larger - more like summaries, in fact - that the full release plan can be understood by most?

Ian Sharp

August 16, 2014 at 11.42 am

Sound advice Matthew. The PM will have a detailed understanding of all the tasks that need to be completed, but there’s little chance others with grasp this level of detail without considerable effort.

RAG reporting is a useful tool too. In fact, I’ve found that keeping reports as simple as possible is the best way to communicate the progress and status of a project. Someone once suggested that reporting should be as if it were for a 6 year old child, and actually, that’s not terrible advice.

Matthew Castle

August 15, 2014 at 10.06 pm

Anyone managing a project needs to take this advice on-board!

I have been in far to many Project Review Meetings where some impenetrable project plan is presented to stakeholders who have no idea what the individual tasks in the plan actually mean.

This just ends up with the project loosing credibility and fear being instilled into the stakeholders who have no idea “where we are”.

Keep a detailed backlog of tasks to track progress, just realise the audience for this is downwards, not upwards.

If you are running multiple streams of work consider just reporting a RAG status. Red - we are behind and will be delayed, Amber - we are behind but can take these corrective actions to get back on track, Green - all good, lets move on. 

This can help focus Status Update or Steering Committee meetings on the areas where decisions need to be made, helping stakeholder feel engaged with the project and in control of the inevitable compromises that need to be made.

Leave a comment