The digital transformation brings with it great change. It may sound trivial. But it’s not. In reality, for companies this change is a tsunami of numerous development, innovation and reorientation projects. For many of these projects, the actual objective is not very clear - and neither are the strategies that are supposed to achieve the objective. It is exactly at this stage that agile planning techniques truly shine. Agile projects do not aim for a comprehensive and detailed master plan, but rather represent a flexible planning framework for addressing new conditions as the project progresses. The term “wave planning” plays a prominent role in this context. It organizes transformation, design or implementation objectives into realization waves. But what does this mean in concrete terms?
What exactly is wave planning?
Wikipedia and the Project Management Institute (PMI) define wave planning as follows:
“Rolling-wave planning is the process of project planning in waves as the project proceeds and later details become clearer … Work to be done in the near term is based on high-level assumptions; also, high-level milestones are set. As the project progresses, the risks, assumptions, and milestones originally identified become more defined and reliable.”
Therefore this process is essentially about making rolling and prompt decisions as to which issues and task packages will be implemented in a project in the next time window. Instead of a rigid and completely thought-out project process, this approach focuses on:
- What makes the most sense at this time?
- What will offer the most benefit in the next month?
- How do we have to respond to sudden developments (resource situation, customer feedback or similar)?
In a way, the project is managed on sight; there is a long-term focus, but it is reached through many flexible implementation waves.
Therefore, wave planning contrasts with, or at least can be considered as a supplement to, classic project planning. The planning and realization of key projects in “waves” means, among other things, that stakeholders are highly integrated into the process, that planning assumptions are defined and permanently updated, and in particular that demanding large objectives (with all of the associated complexity) are divided into manageable parts.
Imagine, for example, that a medium-sized equipment manufacturer wants to do the following in addition to his core business:
- first, establish new digital models,
- second, place a new platform in the market, and
- third, realize the corresponding after-sales services as new additional revenues.
Previously, these issues would have been developed on a conceptual basis over a period of one to two years, followed by a roll-out process. Today, it is much more adequate to think about these three objectives from the end customer's point of view, define the benefits to the same, collect many new ideas, try out different technologies and then implement partial objectives in small steps (waves).
The example shows three different projects of an initiative, which in this (typical) case want to access many joint resources. While agile management in projects has already been a topic of discussion for some time, my primary aim is to direct the focus on agile management between projects. In that moment, managers take on a special role. Many of my business partners, and many of our customers, such as the previously mentioned medium-sized equipment manufacturer, are aiming for an agile organization. It is viewed as a decisive factor in the response to changing markets. Agility - not just in projects but especially the agile management of and between projects - is a good way of demonstrating that management and the entire company are serious about achieving agile organizations. Therefore, the decision-makers can – and must – take on a model function and take the employees (and teams) along with them.
Specifically, this means creating a management and organizational structure in which agile implementation takes center stage. In this way, the relevant stakeholders can be closely involved - by design. They must decide on priorities, as well as project and product focus areas, at relatively short intervals (for example: a tested new platform is not working, how can employees be quickly transferred to other projects - but only for a short time?). This alone creates a situation of a constant exchange of information about the planned changes. Wave planning is change management. Managers are getting more removed from daily activities, but are much closer to the developments and changes.
A proven method in this context has been to organize the decision-makers into so-called Wave Steering Committees. They decide, at rather short intervals (e.g. every two weeks), about directions and priorities, and the distribution of financial and personnel resources. Solutions can be found quickly in the case of unexpected resource conflicts, or if employees who were promised are not available for the next planned project section (wave) after all – in this way, the medium-sized equipment manufacturer obtains results much more quickly. Although not necessarily in the places he might have expected.
How do I achieve my objective, and which requirements must be observed?
Please note the success factors for an effective wave planning approach:
- Not every project is suitable for wave planning!
Foundation projects, building and infrastructure projects should not proceed in waves but rather in the conventional manner, namely as a “waterfall”. On the other hand, transformation projects, the introduction of new services (whether digital or other), or even the expansion of the business with new business models, are particularly suited for wave planning. It becomes even more interesting when the company is working on several of these large projects at the same time, because these situations typically lead to conflicts over resources, hence fights over the same employees who are wanted in different projects. There are discussions as to how existing budgets will be distributed over which of the projects, or at what amounts. In this case, wave planning can be used for quick decision-making between projects, for example if there are problems in the project (technology not available yet, approvals still outstanding, supplier no longer available and similar). - Create diverse and heterogeneous teams!
Wave planning requires dedicated planning teams that should consist of employees from very different departments and with a range of experience. Ideally, these employees come from different business units, programs and locations. The planning teams combine planning with stakeholder and management alignment, and initiate decisions regarding the direction and priorities at an early stage. On a functional level, knowledge about customers, expertise in the customer journey / customer experience, analytics and IT should be consolidated to allow for thinking in terms of integrated solutions (from the customer's point of view). - Nominate potential wave leads early on!
The various implementation waves need a dedicated lead, someone who pushes the milestone objective with energy and technical expertise – such candidates are especially sought-after resources, so they must be secured! - Permanently rebalance between scope and backlog: at the beginning and then over and over again – it is all about collecting knowledge!
All of the ideas + everything you want to do + everything that should be done from the viewpoint of the employees finds its way into the backlog, the central working memory of the project. At the same time, everything is strictly prioritized – only very few contents make their way into the backlog and the respective scope: a wave then consists exactly of the implementation of the respective scope. Even if wave planning aims for the immediate provision of results – your storage space for future tasks should reach at least six months into the future. - Define parameters for each wave!
The starting point of each wave consists of specific initiatives starting with the customer journey (example above: How can our equipment manufacturer simplify the ordering process with the new platform, and increase the customer experience?). A business case is defined for the selected initiative – as a section in the customer journey: What is the outcome (more orders, bigger orders), and which initiative delivers the greatest benefits for the customer or the greatest value for the company (additional revenues)? In this context, the budget represents a specification, the framework for further planning; i.e. the budget is not “calculated” from the planned tasks but is already coordinated/approved ahead of time. The budget is the starting point and not the end point of the planning process.
