Planning Checklist

Construct a realistic plan that can be used to estimate a project and then track it to completion.

This is a long checklist, especially when you view it with all this commentary. However, before you decide that it's all too much effort, consider this: your project plan will determine how good (or bad) life will be for you and your team over the next few months. It's worth putting some effort into, and worth double checking.

A good project plan relies on two elements: suitable input and good planning practices. In addition the plan has to be actively used throughout the project, for both scheduling work and tracking progress.

Planning Inputs

The old saying "Garbage-In, Garbage-Out" applies to project plans too.

  • Project Scope Set

    The project has a clearly defined scope and subsidiary objectives.

    A scope statement allows someone to quickly determine if a given requirement should possibly be implemented by this project. Consider this project scope statement:

    Implement the Life9000 policy administration system with the minimum changes necessary to operate with the company's range of products.
    This is a good statement because it clearly excludes activities such as upgrading the accounting system, except as far as is required to meed the goal of implementing the policy administration system. It also effectively gives the project authority over all implementation activities, including making 'necessary' modifications to the policy administration system. It is also worth noting that there is some fuzziness in this scope statement: it is not self-evident which changes are 'necessary'. The clarification of this fuzziness is left to the statement of objectives and/or the requirements.

    Ideally, a scope statement should be available in a business case or other document that has been approved by senior managment. If a scope is not available, then you must create one for the purposes of the project plan.

  • Detailed Requirements Available

    The project requirements are detailed enough to do an initial design.

  • Initial Design Available

    An initial design has been done in enough detail to create a plan from.

    A software development project is best planned from a design, even if it is just an initial design, created for planning purposes only. Requirements must be available in enough detail to do this initial design.

  • Requirements Stability Known

    It is known how likely it is for project requirements to change over time, and by how much.

    Often plans are drawn up early in the project lifecycle, when requirements may not be firm, even if they are detailed. This is fine, so long as everyone is aware how much requirements may change.

    One approach to dealing with unstable requirements is to allow extra risk factor in the plan for requirements change. Another approach is to reserve the right to change the project plan, including delivery date, as requirements change.

  • Known Outages Planned For

    Events that will take team member's time away from the project have been allowed for in the project plan.

    From time to time, there will be 'outages' in a project that can be planned for. Holidays, trainging, monthly division meetings and server upgrades would fall into this category.

Planning Practices

  • Development Team Have Input

    The development team are involved in all aspects of the estimation process.

    It is not always possible to involve the whole development team with every aspect of the development. However, at least some key team members should be present to help plan work for the project.

    The development team should have the major input as how long it will take to develop the system. As project manager, your job is to ensure that the development estimates are reasonable, adding time to cover risk that you might see.

    Note: Historically, developers are an optimistic bunch and are not given to over-estimation. However, there are exceptions, and you will need to get to know your development team's style.

  • Person Responsible For Each Item Signs Off Estimate

    The person who will be implementing each part of the system agrees to take responsibility for implementing it in the time estimated.

    While not usually a formal sign off, it is important that the developer have the confidence about the estimates they are expected to work to. A developer may be confident because they gave the estimate themselves. On the other hand, a developer may trust the estimation of a senior developer. Either way, a plan works best if individuals commit to performing each task in the time planned.

  • Project Manager Signs Off Each Estimate

    The Project Manager agrees that each item is estimated realistically.

    Since you have responsibility for bringing the project to completion in the time specified by the plan, it is important that you have some degree of confidence in each item of the plan.

    If you are not confident of the individual estimations, on what do you base your confidence in the overall plan? One answer might be that the plan has enough allocated for 'contingency' to give you an adequate comfort level.

  • High Risk and High Value Items Brought Forward

    The plan identifies high risk and high value tasks and brings them as far forward as possible.

    It makes sense to do the risky items first, since it gives you more time to fix problems if things go wrong.

    Similarly, it makes sense to do items that add a lot of business value first, since the project can then more quickly demonstrate to the customer that it is meeting their needs.

  • Time Allocated For Standard Tasks

    The plan allocates sensible amounts of time for Requirements, Design, Development, Test and Deployment.

    The above list represents the standard kinds of things any software development project needs to do. Check that your project plan has time for all of them. Most plans allocate time to development, but it is suprising how many leave out one or more of the others, often causing confusion and panic.

  • Deliveries Scheduled Every 2-3 weeks

    The project plan delivers to the client at regular interverals (2 to 3 weeks).

    A project with many, regular deliveries is inherently simpler to control than one that produces nothing until the very end.

    Each delivery is a concrete milestone that is visibly met or not met. Regular deliveries also allow users to give constructive feedback sooner that they otherwise would.

    Another reason is that a project with a regular stream of deliveries is likely to experience less integration, test and deployment problems at the end of the project, as most of the problems will have been encountered along the way.

  • Assumptions and Dependencies Documented

    All assumptions made and external dependencies specified in the plan are explicitly documented.

    Because plans are drawn up early on in the project lifecycle, there will be many unknowns, and assumptions need to be made in order to produce a schedule. These assumptions must be documented as part of the plan so that the plan can be modified appropriately should the assumption turn out to be false.

    A special kind of assumption is the external dependency, where the project plan assumes that some task external to the project is complete by a certain point in the project's progress. An example of a dependency is: "Windows 2000 rollout complete before System Testing begins."

  • Development Activities Traceable to Requirements

    Every development activity can be traced - perhaps via the design - to a business requirement.

    Developers and designers sometimes introduce technical 'requirements' on to a project that do not actually contribute to the business success of the project. Essentially, no matter how 'nice' something is, it should not be done unless there is a clear business benefit that is within the scope of the project.

    An example of this is the inevitable collection of 'framework' components that spring up around many object-oriented developments. One test to determine if a given framework type component is necessary is to ask if it will bring a benefit in the current project. If the benefits would only accrue in a future project, then delay the implementation of the framework component to that future project.

    This is not to say that all 'techy' tasks should be dismissed out of hand, but things that are necessary should be sold to the business on the basis of benefit to the business and included in the business requirements for the project.

  • Risks Addressed

    The plan addresses risk in a comprehensive manner.

    The management of risk is a big topic and there is another checklist or six lurking in this point. The kinds of things that you should be looking at in any project are:

    • An effort made to identify the biggest risks to on-time, on-budget delivery.
    • The effect of the risk on the project, should the event occur, is estimated.
    • Estimates of how likely each risk is to occur.
    • An appropriate mitigation strategy for each risk has been identified and included in the plan - even if it is only to allow extra time in the schedule.

Plan Usage

  • Plan Understandable

    The plan is presented in such a way that it can be understood by everybody who is expected to use it.

    An effectively communicated plan is a great help to the project manager because it allows individuals within the team to take more responsibility for keeping to the schedule. For instance, a developer who will not finish a task on the date planned is more likely to let you know if they can see the effect that will have on the schedule. A clear, open plan also allows everyone to have input to the plan. An example is that a tester, if she can see when each function is due to be developed, might see an opportunity to begin testing earlier than expected. Because of these things, a well communicated plan gives senior managment confidence that the team as a whole knows what they are doing, and can work together to bring about the project's goals.

  • Track Against Plan

    The project's progress is tracked against the plan.

    The plan is updated regularly with the project's progress. It is a good idea to track the project weekly, so that the weekly project report includes an accurate picture of progress.

  • Plan Changes with Circumstances

    The project plan is revised as necessary in order to meet the project budget and timeframe.

    Because projects are large efforts that involve many variables, unexpected things happen from time to time. A good project manager will allow for minor perturbations in the plan. However when something major occurs - such as missing the finish date of a critical task - the plan must be changed to take this into account.

© 2003-2006 Alan Green