Lean PPM step 5: The demand – capacity game at Digitec /Galaxus

In this blog I talk about the challenging task of the demand – capacity balance in PPM, or the problem of who works on what and do we have the required and capable staff members available at the right point in time. This is an omnipresent problem. We never have the perfect capacity to satisfy the current demand. So we have either too many resources or a bottleneck anywhere in our organization.

In classical PPM the balance is addressed by breaking down the work to resource level (work breakdown structure) in a first step and then – based on an effort estimation – the assignment of work to resources. The uncertainty that corrupts upfront planning are estimations based on assumptions instead of historical data and the effect of risks that materialize in the course of the projects.

The lean and agile PPM approach is not to break down all (!) the work right from beginning, i.e. avoiding big upfront decompositions and specification. Instead decomposition is done ongoing, so that at every point in time there are work packages that can be pulled by resources while work in the mid-term future may be still remind on a coarse grained level of specification. The PPM process cares for that at every time there are enough work packages available so that all resources can pull an appropriate package for further decomposition or implementation. The feedback about the speed the work packages are driven to the desired outcome (done criteria) is collected as historical data for estimation for the yet undone work packages. This leads to more reliable estimations, followed by a higher probability about milestones. As well changes imply less impact. Reason is that the ongoing decomposition of larger work packages into smaller work packages allows as well an ongoing adaption of the solution space to the changes in the problem space based on current findings and feedback. As side effect less effort is invested into upfront specifications that require rework in case of changes and materialized risks.

The core problem that demand and capacity never match perfectly is the same in a lean and agile approach. The core improvements of the lean and agile PPM compared to the classical PPM are more reliable estimations, the ongoing adaption based on fast feedback and less rework in obsolete upfront specification. As very positive side effect the feedback loops establish a better understanding and alignment to the strategy (if there is any 😉 ) The fundamental change is the switch from a classical push system (work packages are pushed to resources) to a pull system (resources pull work packages) together with feedback loops.

At Digitec / Galaxus we follow the lean and agile approach. But how does that work in reality? What are the “resources” we talk about and what is a “work package” that a “resource” pulls? Lets see how theory is put into practice.

1. The functional departments like product management, marketing or logistics. The core responsibility of these departments is to run our business, to be operative and productive. But additional these departments are responsible to improve and develop themselves either to implement the company strategy or to increase productivity. This is where the demand emerges. This is as well a conflict for the departments because any effort invested into specification (of the demand) reduces the capacity required to run the business. It is the responsibility of the top management to set goals and staff the departments in a way that they can deal positively with this conflict and have enough capacity to satisfy the specification part of their own demand. This is a serious topic – but out of scope of this blog. Many companies fail exactly here.
2. The engineering and infrastructure teams. In my personal view these are the scrum and techniques teams. These are the experts responsible to develop and run the system(s) that automate and support the business processes on customer side and within the departments. This includes subject matter experts in the departments as well as business analysts or requirements engineers that – at least in my recommendation – are part of the scrum teams. These teams always are a bottleneck – at least in a dynamic and innovative company. Reason is that a dynamic and innovative company has multiple more ideas (creating demand) than by economic constraints limited investment power. So these teams are typically seen as the capacity side of the company, disregarding that these teams create as well demand to improve and refactor the system itself. Again, it is a responsibility of top management to set goals and staff the teams appropriate.
3. The “product” or “program” management team. This a bit a special team. Partially it is a virtual team. It is neither demand nor capacity. It is neutral. The responsibility of this team is an optimize-the-whole mindset, a neutral position between demand and capacity. At Digitec / Galaxus the heart of this team is the Business Development team. This is a real team (not a virtual), an organizational unit of individuals with the job description project manager. In my point of view the complete (virtual) team has additional members: the top management responsible to define and communicate the strategy; stakeholder from departments and from engineering requesting their demand and by giving feedback about their current capacity situation.

From my point of view a project or program management holding a neutral position between the demand side, capacity side and the strategy side is a success factor for a company. Beside the responsibility to implement the strategy of the company by executing the projects, the core success factor is to find the right balance for every single project. This is done by organizational implemented feedback loops between the stakeholders of the demand side, the capacity side and the strategy definition organ. My team, the Business Development team at Digitec / Galaxus feels responsible as guards of a healthy organism that develops in a sustainable path towards the agreed vision.

At  Digitec / Galaxus the demand comes from the departments using the innovation process in form of initiatives. This maturing process of an idea to initiative is supported and guided by a project manager. The project manager starts to work with the stakeholders from the department(s) and with engineering as soon as a department proposes an initiative to the innovation board (see: The life cycle of an initiative – step 4). The responsibility of a project manager is to drive an initiative from idea to closure through the life cycle within the right balance between demand and capacity and aligned to the strategy. The alignment to strategy includes prioritization responsibility where the business development team proposes to the innovation board and reflects the decisions of the board back into the development teams and departments.

The organizational implemented feedback loops are

• The monthly innovation board meeting itself. Goal of this meeting is 1. closing the feedback loop between top management all others about the progress and potential risks and existing impediments and 2. prioritization of the initiatives for the next round based on feedback from departments and engineering and 3. rating of new ideas coming from departments.
• A weekly standup meeting of the business development team to identify conflicts in the demand-capacity-strategy alignment game so these conflicts can be addressed in a next step.
• The bi-weekly Scrum meetings in the engineering teams
• A bi-weekly program level backlog refinement meeting where business analyst discuss the upcoming sprints on a cross-team level.

The most interesting meeting (scrum terminology: event) is the innovation board meeting.

The core responsibility of the innovation board meeting is the management of the initiatives Kanban board. This board corresponds with the Kanban board idea in the scaled agile framework managing the business and architectural epics. In the innovation board meeting we discuss the progress of our initiatives, collect feedback, draw out decisions about movements and priorities of initiatives. Input of this meeting is the feedback of departments and engineering about the currents status, existing risks and impediments, changes compared to the last meeting and proposal for the next round. The company strategy is omnipresent to the members in this meeting. The capacity – demand balance is addressed only in case of concrete conflicts or in case an initiative gets into discussion because of any impediments. The time an initiative rests in a specific status on its way through the Kanban board is influenced by the position in the Kanban board. An initiative on top of a lane (high priority) gets more capacity then an initiative below. To carry this out is completely under control of the teams working on this initiative. The board gets the feedback about the progress made and iff there are impediments or decisions to take. As the Kanban lanes do have a WIP limit (currently 16 for the “approved” and “in progress” lane) a new initiative can be moved to the next status only in case a free slot is available. The members of the innovation board meeting do have a transparent view how the teams plan their capacity by looking into the epic and scrum boards of the teams.

My team, the neutral Business Development team representing the PPM care within our weekly standup meeting about the feedback from all stakeholders about progress, conflicts and impediments of any kind. The proceeding of our meeting is pretty close to a daily scrum. As things change slower on initiative level then on story level, a weekly standup is sufficient to close the feedback loop. The two meetings before and after the innovation board meeting do have a special agenda. The pre-innovation board meeting agrees about feedback and proposals for the innovation board including new ideas coming from departments. The post-innovation board meeting works with decisions taken and identifies future measures to execute the decisions in PPM.

This setup of meetings in PPM basically works fine. Nevertheless we identified some flaws in the current setup we will address in the near future. The identified flaws are:

• The monthly rhythm of the innovation board meeting is very fast. This fast rhythm stresses the departments. Every four weeks changes in prioritization may happen and decisions about ideas are taken. That is a fast rhythm for departments. We think about to experiment with a six week period. The drawback of a six week period is a loss in flexibility and feedback. An experiment will evaluate benefits against drawbacks.
• The bi-weekly program level backlog refinement period is too short. This meeting does not add that much value to the team backlog refinement as it 1. covers the identical time horizon and 2. Is a business analyst meeting only with lack of feedback from departments and stakeholders. We think about to align this meeting as follow up to the innovation board meeting. Additional we plan to invite stakeholders from departments and engineering as well to close a direct feedback loop working with the strategic decisions taken by the innovation board. This meeting corresponds in some kind with the release planning meeting idea in the scaled agile framework (SAFe). The difference is that we do not prepare a release. The agenda of the meeting is similar to the SAFe idea. Different is the frequency of one month instead of three months in SAFe and the duration of half a day instead of two days.
• The direct feedback about required capacity from departments in the initiative is distributed over too many individuals. No direct feedback loop between these individuals exists. The work on initiatives requires capacity from departments. We face situations where several initiative consume capacity in departments in parallel. This leads to conflicts if more effort and involvement is required as estimated. For sure we get the feedback and we prefer to invest into the high priority initiative first, but the feedback loop is indirect going over the project managers driving the initiatives. If the project managers do not share this information, capacity conflicts may escalate. We plan to address this as well with the redefinition of our bi-weekly program level backlog refinement. The new setup shall close a direct feedback loop through all involved teams.

Currently we are living a sub-optimal solution to visualize a capacity usage over all teams (departments, Business Development and engineering): My team established and maintains an Excel worksheet forecasting capacity consumption on key person and team level (from an initiative point of view) based on the feedback from teams and individuals. Yes, establishing an Excel worksheet is typically the sign for a sub-optimal local solution and an existing impediment. So this Excel is a strong hint to improve the process for capacity feedback from departments. This is one very important reason for the refactoring of the bi-weekly program level backlog refinement meeting. We are convinced that an improved program level backlog refinement meeting will close the feedback loop about capacity consumption far more efficient than any Excel worksheet or any resource management software.

While this blog discusses our demand – capacity game more on a high-level view, my next blog will dive deeper into the capacity game on program and team level, especially in engineering.