Final Thoughts on Planning

Here are some final tips on how to improve your planning on your next project:

• Make planning a team event, and make it fun. If planning isn’t fun, your team won’t want to spend as much time doing it. Making planning fun means that replanning every iteration should also be fun and painless and thus, something your team will want to engage in regularly.

• Keep planning simple. Plans that generate extremely complex results are more complex to communicate and understand. Keep your plans simple and the results of the planning activities easy to consume by all members of your team.

• Don’t forget to revisit your plans every iteration. We want to put some degree of emphasis on planning activities before we start developing our software, but always keep in mind that this process should continue throughout the life of your project.

• Stay flexible and expect change. If there is a single universal constant in software engineering, it is change. Don’t run from it. Embrace it when it meets you, and it will be your friend.

We just listed some aspects of planning that should help make it more successful, but what are some planning mistakes you can make to debunk the value of planning on your projects? In D. J. Reifer’s Software Management Seventh Edition (IEEE Computer Society, 2006), Steve McConnell provided some perspective on this in his article “The Nine Deadly Sins of Project Planning,” which we will summarize here:

• No planning at all This one seems a bit obvious; however, you might be surprised at how common this mistake is. Many organizations rush to implementation without considering the impact on the entire team. Many people have mistakenly thought that Agile software development methodologies reinforce this premise, but it is simply not true.

• Not planning enough You should take into consideration aspects of your project such as sick time, training, vacations, or staff turnover. Try to start your planning activities with some real-life assumptions that force you to account for some of the minute details that might cause huge problems if not uncovered early.

• Failure to plan for risk Attention to risks drive further work in either risk preventative activities or risk contingency actives. In any case, risks must be dealt with continually throughout a project.

• Using the same plan for every project Not every project is created equally. Many organizations assume this and use standard project templates to drive all projects regardless of the project constraints or type.

• Allowing your plan to diverge from reality On a good project, your team has done enough planning to do a great job developing the product. On a great project, project planning continues right up until deployment, updating project plans along the way.

• Planning too much detail too soon Don’t try to get into too much detail unless that detail provides you or your customer with value. For example, many organizations use a document-based planning approach, that is, planning is complete when the document that contains the plans are complete. The team focuses on filling out the missing sections of the plan instead of on the value they are providing to the project team as a result of planning.

• Planning to catch up later If your projects get behind schedule, don’t assume that you will eventually catch up. It just doesn’t happen. When you are behind, you should stop and try to account for why you are behind and rethink your plans.

• Not learning from past planning sins There are three types of people in the world: ignorant people who do not learn from their mistakes, smart people who learn from their mistakes, and wise people who learn from the mistakes of others. You should try to be smart and learn how to adapt your planning techniques over time.

Cohn extends the list of why planning fails with the following points:

• Planning is by activity rather than feature. Too many plans focus on the completion of tasks rather than the completion of features.

• Activities do not finish early. Air expands to fill its container, and so do tasks in an estimate. Do not plan for some tasks to finish earlier than you have estimated; if you do, it probably demonstrates that you haven’t estimated well enough.

• Activities are not independent. Some activities can be done in parallel and some cannot. Make sure that you understand the dependencies between your activities and incorporate these into your planning mindset.

• Multitasking causes delays. Clark and Wheelwrite in Managing New Product and Process Development: Text and Cases (The Free Press, 1993) demonstrated that people are most effective when they are multitasking on two tasks and greatly decreasing in productivity as the number of tasks being multitasked increases. Just because someone may be 75 percent utilized on a project does not mean she will be able to carry an additional 25 percent of the workload.

• Features are not developed by priority. Feature prioritization should drive the release schedule because it reflects customer value at the time of the planning activity.

• Uncertainty is ignored. Uncertainty drives the amount of buffer you add to your tasks, iterations, and projects. When estimating, you should incorporate methods of planning that consider uncertainty.

• Estimates become commitments. Estimates are just what they are, a best guess. Commitments cannot be made on best guesses alone