7 hints to increase your planning reliability in product management

Regardless of whether the roadmap is results-oriented or requirements-oriented — there is no ongoing business in which there are no deadlines. Even without externally imposed deadlines, there is an understandable desire for reliable planning of relevant content. Marketing and sales activities, international rollouts or joint release activities with other teams can be such reasons.

Depending on the complexity of the organization or product, this can be easy or more challenging. However, there are numerous ways to increase planning reliability at various levels. To do this, we partly use the project management toolbox:

1. Separate Discovery from Implementation

The work of turning assumptions into certainty should not suffer for planning certainty. Discovery activities must therefore take place. Unfortunately, this work and its outcomes cannot be planned well. New findings sometimes make ideas seem pointless, sometimes they have to be reconsidered or even better opportunities are discovered. This takes varying amounts of effort or time.

The only way to address this is to separate this work into a separate, simultaneous and preceding work stream. The more complex and risky the discovery, the more time is required in advance. The implementation roadmap thus consists of solutions that have largely been thought through, with few surprises left to be expected.

2. Keeping effort estimates on track

If estimates of teams deviate significantly from reality, the maturity level must be increased. Otherwise, despite all other measures, it will not be possible to establish a reliable planning process. Typical measures that help here:

• Ensure measurability and correct measurement, visualize for all and discuss outliers.
• Estimate topics in smaller units (e.g. via story mapping).
• Explore risk factors before estimation (plan for them if necessary).
• Modify estimation procedures or adapt/calibrate depending on the topic.

3. Use Critical Chain Management

The use of the critical chain method can help enormously. It’s worth going deeper into this. In summary, there are 2 essential aspects:

• The critical path — the one that defines the total runtime — is prioritised. This means that the whole team is focused on not letting this path fall behind.
• The individual tasks/stories are estimated without buffers (50% probability that the effort will be larger or smaller). Depending on the required degree of certainty in the planning, the total buffer is set at the end instead. This has two advantages: firstly, psychologically, because buffers are almost always used up within tasks. On the other hand, in the course of implementation, the relation of progress versus buffer consumption results in an increasingly better interpolation of the remaining runtime. In this way, it is still possible to intervene at an early stage.

4. Tackle implementation risks and dependencies at the beginning.

Risks that manifest themselves in assumptions or those that are necessary for a good estimate should be addressed before implementation anyway. Nevertheless, not all risks or dependencies can be avoided in advance. In that case, they must be planned as early as possible in the implementation process. There are three reasons for this:

• The earlier risks occur, the more likely it is that something can be done to mitigate them.
• At an early stage, only part of the costs has been spent. Changes or abortions are therefore cheaper.
• When communicating with stakeholders, it is better to communicate risk impacts as early as possible and not toward the end of the projected deadline.

5. Plan team availabilities with care

Illnesses or disproportionate support workloads are difficult to plan. But serial appointments, holidays, training, project work or other reasons for absences in the team should be. A statistical average of unplannable events can also help to come as close as possible to reality. These absences also increase planning reliability.

6. No 100% planning of critical activities

Development teams usually work on various activities in parallel. Technical debt reduction, support, bug fixing, small optimizations, discovery, etc. Many of these activities are of little relevance to external stakeholders and can serve as short-term slack. In tense periods we reduce these activities somewhat, while in relaxed periods we increase them. On average, over a longer period, the work planned here has to be done of course.

7. Mutual help between teams

If several teams are in place, it is seldom the case that all teams have the same bottlenecks. As delays are caused by bottlenecks on the critical path, teams may therefore be able to assist each other with manpower or know-how to achieve a better overall common optimum. The premise is that the support can be provided efficiently enough to really accelerate the critical path.

First published on Medium by Traian Kaiser