How to make a software project plan that actually works

Making a project plan for software development is one thing, but making it work is another. You've probably seen lots of software project plans in your day. They all look the same with their pretty Gantt charts and lovely blue annotations, don't they? Yet, do you know the failure rate of these pretty Gantt charts? That number is an unbelievable 78% according to one study in 2009 (the same group found a failure of 84% in IT projects in 1994!). This humongous failure number keeps coming up in studies after studies, here’s one by another very respected group - McKinsey-Oxford study for IT projects

Given these huge failure numbers we have to accept the reality of difficulty of making a software project plan that works. Over the years we at Kaz Software have worked on numerous software projects, for hundreds of companies around the world and we know from first hand experience how difficult this is. There are hundreds of variables that you should be thinking of when making a reliable project plan - from obvious ones like requirements, business priorities, resource availability to unexpected ones like language barriers, paperwork, compliance issue, etc. On today’s post I’d like to share some of the things we have learnt about making a better project plan - not perfect, maybe perfection isn’t possible, but a better one at least!

Decide on a project timeline and set deadlines

The first step is to decide how long your project will take. One month, three months, six months? Or maybe you can't put an exact number on it because you aren't yet sure what the project entails. That's fine too - just be as accurate as you can. The point is to be realistic, to have all the information available at that point in time and make the best possible guesses based on that information. If you know the requirements will change frequently, set deadlines for each round of revisions. If you think your team members are bad at estimating their time, maybe give yourselves a longer timeframe. Set deadlines that are achievable but challenging. Don't be too optimistic or you'll end up disappointing yourself and everyone around you when things don't go as planned.

Create a list of tasks with a democratic estimation

This is where you break down the requirements into smaller areas, features and then eventually tasks. Make sure you about break large, vague tasks into smaller tasks with deadlines that are based on the time estimates. Breaking down the larger tasks into smaller tasks are relatively easy, especially if you have experienced resources in your team. Where it gets extremely hard is the time estimation of tasks. Most developers will either overestimate or underestimate time cost for a task. This is just a fact of life. Our solution has always been to use democracy to find the time cost number - effectively asking all members of the team to discuss and come up with a time estimate rather than relying on a single person (the developer who is likely to do the task). This may sound counter productive, as the task will be done by a single developer at the end of the day - but somehow the democratization of this process gives much better result.

“Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.”

— Joel Spolsky

On this point I’d like to note another very effective way of getting time estimates - which is to look at historical success and failure rates of estimates per developer and based on that decide if the developer typically over or under estimates and then add or subtract based on that data. This idea was very effectively put into use in Joel’s FogBugz product - and he called it evidence based scheduling. You do need a platform like FogBugz to make this happen, and even then you need to have enough historical data with the same developers to make it really work.

Write down the resources needed for each task

This is where you list who's expertise is required to complete each task and what kind of equipment will be used. If the skills required for a task is not available in your team, plan for it - how you will fill up the gap, what steps you'll need to take to have that skill available at the right time. Some of those steps may be tasks themselves that you have to add to your project plan.

Set up milestones that you'll need to meet

Milestones let you know how much progress you've made and if everything is on track with your timeline. You can set up intermediate deadlines as well if you're not afraid of breaking your work into smaller chunks. If you have a long term project, it may be better to set up milestones at the beginning so that you'll know how much you can do every week or every month.

Make sure your plan is achievable by breaking it into small enough chunks so that you can achieve them one by one. Divide and conquer is the the only way to solve the complex problems in a software project. If you decide to take on something big, it can quickly become overwhelming. Try breaking your project into smaller pieces and figure out how long each one should take.

Stick with it!

Don't give up when things get tough! You're almost there! This is the most important tip of them all. If you have failures, delays, setbacks just know that that is a fact of life for all software projects. You just have to have the patience to stay with your plan, make changes as needed to adapt to the delays and move things forward. Software projects never go as planned, and one of the greatest sign of a good plan is that it has the ability to absorb the changes as they happen. And the one most important skill of a software leader is the the ability to stick with the plan.

Remember that a software project is a process, and it can be thought of as a linear progression from one phase to the next. Plan out how you will go from start to finish with milestones in between. Use your resources effectively by having the right people on the job for specific tasks, making sure you have access to special equipment or resources.

Let’s break these horrible failure stats. Good luck!