Rolling wave planning

Failing to plan is planning to fail

While failing to plan is planning to fail, planning at the wrong time is a waste of valuable time, effort and money.
With lean and agile projects the trick is to plan at the appropriate level of detail and the right time to give the greatest benefit. We use the concepts of rolling wave planning and planning horizons that enable us to plan enough in order to get started, then we continuing with the cycle of delivery and planning. This process enables the project team to learn as they go along respond to change and provide the right capability for the organisation to achieve the required outputs and realise the needed benefits.

Image showing the relationship of planning effort, development, delivery and the core processes

The blue planning circles represent the effort put into continuous and iterative planning over the whole project.
Each yellow circle represents the development & delivery of the minimum viable product (MVP) to deliver the capability that will enable your business to deliver a minimum viable service with each iteration building on the previous iteration until you have all the capability to deliver a complete service.

Image showing the relationship of planning, development, delivery and the core processes

The above image illustrates that in each of the seven core processes there is an element of planning for the project. The objective here is to use the time we allocate to planning as effectively and efficiently as possible.

  • Too much planning at any point will result in waste and sunk costs when the plans are changed.
  • Too little planning will result in a failed project.

  • Comparing pure Up-Front planning with rolling wave (continuous) planning

    Image showing a scenario with up-fronnt planning

    With pure up-front planning that is often adopted in waterfall type projects, most of the planning is done at the beginning of the project. This means to a certain extent you are defining requirements without the benefit of knowledge gained as the project progresses. Once the development process starts and you discover that some of the requirements are not valid, you need to spend more time defining new requirements based on what you have learned.

    From a project perspective we use a planning process that optimises the use of time allocated to planning. The objective with the rolling wave planning method described here is that at least 95% of the time used for planning and defining requirements will fulfil business, architectural or infrastructure needs that result in a product or service that gives the required capability.

    There are reports from internationally recognised agencies that find it is not uncommon for projects to only deliver 30% of requirements that have been documented.This implies that such organisations must waste a lot of time and effort that could be better used in delivery or some other value adding activity.

    The product based planning model we use facilitates transparency, assessment and adaptability ensuring that the project output will fulfil the required business outcomes and needs.

    Quick overview of the planning done in each core process

    Starting a Project

    The “Starting a Project” process delivers the outline business case that includes a benefits map and the outline project plan for the planning and initiating process. The business case document should describe the issues that the business needs to develop new capabilities to resolve.
    You need enough information to enable the decision makers to determine if there is a viable project to go ahead and plan for.

    Planning & Initiating

    The “Planning & Initiating” process can be used to deliver important management products or tailor those that currently exist such as:
    Documented work processes (Defined in the discovery sub-process or phase)
    Requirements documentation (Defined in the design sub-process or phase)
    Designs (For digital projects)
    Risk management strategy
    Quality management strategy
    Change management strategy
    Communication management strategy

    The product requirements also need to be developed in enough detail to achieve the following:
    An understanding of which components can be sub-divided, using the product breakdown structure so that you do not spend time working on functionality that is dependent on other functionality that will be built later in the project lifecycle.
    An understanding of how you can deliver the most business value early on, visualise this with a road map or flow diagram.
    The technical experts can take decisions and define requirements on architecture and infrastructure requirements
    Definition of transitional requirements needed in situations where you are transferring from one system to another. This is work that needs to be done purely to accommodate the transition.

    To be lean and agile the trick here is to identify what will be worked on within the current planning horizon and define those components to the appropriate level of detail. Anything outside the planning horizon make a note of it, but do not go into too much detail if you do not have too. The chances are that you are likely to make changes as the project progresses. From the requirements development process you can create the backlog and critical chain schedules etc.

    In addition to the above mentioned outputs from this core process you will also have an updated business case based on the increased knowledge from further developing the functional and non-functional requirements.

    Managing a Stage Boundary

    The “Managing a Stage Boundary” process delivers a detailed plan for the next management stage and the higher level project plan is updated to reflect any changes at that level. The plan created as an activity of this process will be excecuted, monitored, controlled and adjusted in the “Controlling a Management Stage” and the “Managing Product Delivery” core process activities.

    At the beginning of the project there will be a plan on which order to build functionality and component products. As the project progresses and based on lessons learned the team will develop their knowledge and may want to change the original plans and some of the requirements so that they can deliver better business value.
    Other changes to the project plan such as a change in resources may also be necessary, you can include this in the plan for the next stage and make sure that all concerned are well informed.
    We use the planning sub-process within the “Managing a Stage Boundary” core process to include changes and ensure they support the overall objectives then submit the plan to the decision makers for approval.
    By following this process we are agile in that we are responding to change yet at the same time maintain good governance.

    Managing Product Delivery

    For many people “Managing Product Delivery” is the core process that they identify with. Planning is carried out by the production team and the project manager’s role is primarily in a facilitator role. From a planning perspective the project manager should listen, observe and get feedback from the activities in this process as this information will inform future planning efforts.
    At the beginning of each iteration, or each Monday morning the team will look at the activities they have allocated for the coming period and have a quick planning session on the important aspects of each activity. Those activities that require more detailed planning may have a special break-out session for further planning.
    For many agile teams there is the well-known morning stand-up for each person to give a quick report on what they have done the day before and what they will do today. This is also an opportunity to announce any changes in the days plan.
    One of the activities in this process is to carry out quality reviews and acceptance tests on work done. If it is found that some of the work is not being accepted then we need to make a plan to address this situation.
    We can also measure the production rate of work done, from this information we can calculate the velocity of the team and estimate how much work to plan for future iterations or sprints.
    As part of this core process you also have the retrospective where the team discusses and plans how they can improve the work processes.

    Read more on Managing Product Delivery.

    Facilitating & Controlling Project Delivery

    The “Facilitating & Controlling Project Delivery” and the “Managing Product Delivery” activities are interrelated.The “Facilitating & Controlling Project Delivery” core process is primarily for project management activities and the “Managing Product Delivery” is primarily for product development activities within an iteration.
    The “Facilitating & Controlling Project Delivery” process as the name suggests is primarily a facilitation and control process that involves keeping stakeholders communicating as well as monitoring and reporting on progress. This core process also involves activities to allow for adjustments to plans within the set tolerances for the management stage. The primary planning activity here is preparing or updating the work items (User Scenarios and Acceptance Tests) that will be included in the next work package, iteration or sprint.
    Please note the terms work package, iteration or sprint are being used loosely here and refer to the same concept.

    Project managers can facilitate other peoples planning by monitoring how the project is progressing and then informing people when they are likely to be needed on the project. This is especially important for resources that have other responsibilities outside the project.
    As a project manager you will be looking for anything that will prevent the smooth flow of work in the production team and taking action to remove those constraints or at least mitigating them as much as possible.

    Useful Tips
    Critical chain scheduling with project buffers is a very useful tool for monitoring progress and planning when to take action to resolve issues.
    Kanban boards can be used for monitoring flow and identifying when an activity is running late and needs more attention.
    Burndown charts and cumulative flow diagrams are also useful monitoring tools. Information from these tools can inform future planning

    Closing a Project

    Most of the planning relating to the Closing a Project process will have been done prior to starting this process. There should still be daily some form of planning/review to make necessary adjustments for the days work and to ensure that the project is closed properly.

    Comments are closed.