If you don’t spend enough time creating a development plan, you’ll be plagued with rework and the delays that come with it. On the other hand, there is a point where the return on investment in the design documentation and project plan reaches zero. The key to balancing your development time is to recognize when you’re spending too much time planning.

The logistics of planning
The adage “measure twice, cut once” definitely holds true for software development. Whether you’re working from cocktail napkins or Gantt charts, you must plan the project to ensure that everyone on your team is working towards the same goal.

But planning a project incorporates much more than simple requirements. You’ll need to review specifications, architectures, workflows, and other details to determine exactly what everyone is supposed to be doing. The amount of planning required also depends on the complexity of the final product and expected delivery date.

When designing a solution, issues can arise when you haven’t accurately gauged these factors. Realistically speaking, there is never enough time to plan out everything to the final letter, but you must realize that not all solutions require that level of detail and expect that no endeavor will get that amount of attention, even if it’s warranted.

The key to a successful balance of planning and development lies in situational awareness and flexibility to meet that situation. Just because you have a process for planning doesn’t mean it should be applied in every situation. And just because you have a short deadline doesn’t mean that planning should be cut short. Being creative and having a realistic opinion of the importance of the planning stage to your project will help you get the job done right, without having to cut twice.

Warning signs
There are a number of different viewpoints you can adopt to determine whether you’re spending more time than necessary in the planning stage. You must consider elements outside of your sphere of influence and look at things realistically.

Often the guilty culprits of an extended planning stage are tasks that are actually part of development. Other times, it may be an incorrect assumption about the development team’s abilities or an overzealous desire to control every detail. Whatever the cause, watch for these warning signs to help keep your planning at an appropriate level of detail:

  • Your planning documentation includes pseudo-code.
  • You’ve delayed initiation of the development phase.
  • You’re referencing any part of the project plan other than requirements and deliverables to present information.
  • Your work breakdown structure is in hours instead of days.
  • The information you’re presenting is too detailed to be laid out in bulleted lists.
  • You question whether your documentation will be read.
  • Your dataflow and workflow diagrams are overly complicated and won’t fit on one or two pages.
  • You’ve stopped consulting with business drivers and developers, but you’re still creating design docs or a project plan.
  • You’ve broken the project out into phases, and each phase lasts less than a month.
  • You’re replacing development phase project management responsibilities with upfront documentation.

If you’re guilty of any of these, you’re probably wasting time planning details that will work themselves out. Only in very rare cases will any of these items be required before development begins. A project is a living, growing process and won’t happen in a vacuum. No matter how much time you spend planning, something will change, and if that makes large portions of your documentation obsolete, you spent too much time creating it.

Finding the sweet spot
If you find that you tend to overplan, you may not know how to efficiently plan and still wind up with a great solution. Every project is unique, even within a single development shop, and there are a number of factors to consider when deciding how much time to budget for planning.

Spend a minute considering each of the following questions before you give a time estimate. The more discovery you must do based on the answers to these questions, the more time you need for planning. You should need only a fraction of the total planning time for actual documentation.

  • How experienced are the development team members?
  • How long have the development team members been working together?
  • Has this development shop done a similar project before?
  • Is the requested solution to perform one or a few functions, or will it be more complicated?
  • How many different types of users will be affected by this solution?
  • How many different types of systems will be involved in the solution’s deployment?
  • Will the solution be supported after deployment, or is it a one-time release?
  • What is the approximate delivery date?
  • Is the client willing to pay for planning time, or would it understand having to pay for rework?
  • Will you be involved in the project during the development phase?

Once you’ve answered these, you should have a good feel for how much time you need to allocate to planning. For example, if the team members are experienced, you can leave more decisions for after development begins. If your shop has done this type of project before, you may require very little planning—you may be able to use the existing solution as a model. If you will be involved personally during the development phase, you can omit details required for a complete handoff.

Take a realistic look at the situation surrounding the solution. The amount of time you need before development begins should be clear. Use the time you have to plan the most critical and complicated portions of the project. If it’s a long project, expect to fill in details for down the road during development of earlier phases. Whether you’ve all but written the code or not, discovery will continue as the project progresses. Learn to recognize what planning is required and timely vs. what might actually be overanalysis.

A well-balanced process
Once you’ve learned to let go of some of the details and trust the team that will be performing development work based on your plan, you’ll realize that describing everything out to the nuts and bolts isn’t required for a successful project. Remember that a project plan is only the design that the solution will follow—it’s not a blueprint that can’t be changed once work begins. Situational awareness will help you determine how much planning is required for your solution and will keep you from spending too much time at the drawing board.

How do you know when you’re spending too much time planning?

Post your warning signs of overplanning in the discussion area below or send us an e-mail.