Multiple Horizons of Planning, principle #2

We are building big… systems we need to move from predicative to empirical planning!!

Introduction

We don’t want a big Integrated Master Schedule (IMS) to build systems….. they are not Agile. But it takes a view of the big picture to deliver a satellite, submarine, or aircraft. In an era where technology continually advances, the development of large safety-critical cyber-physical systems (CPS) has become increasingly complex. These systems, which merge the digital and physical worlds, are pivotal in domains such as autonomous vehicles, aerospace, healthcare, and industrial automation. Ensuring the safety and reliability of such systems is paramount, and one effective strategy to achieve this is by implementing multiple horizons of planning.

The second principle

The second principle in Industrial DevOps is to implement multiple horizons of planning as illustrated below. How is this different than a single multi-year integrated master schedule?? Good question, the answer is empirical data. For small application we may be able to plan one two-week sprint at a time and then adjust. If we are building a satellite, we are building a system that is most likely going to extend to years in development. However, we still want to build in small slices to get empirical data that we can use to inform both the schedule and cost. A typical sprint or iteration is one to two weeks, as we complete work against the plan over these time frames, we can get empirical data regarding the completion of the work and associated rework. If we use a simple example, for example if I plan to complete 10 widgets over a two-week sprint and I complete only 7 widgets we can assume that after 6 sprints in the quarter, we will be 70% complete. However, if we use the data after the first or second sprint to adjust the plan against the quarter, we will deliver closer to plan at the end of the quarter and at the end of the year. If we look at the data this approach provides predictability.

Delivering multiple horizons is recursive.

I am told that recursion is not a term used outside of software development. But when we build systems in an iterative and incremental approach, we are using recursion to deliver those systems. We enter each horizon of planning from sprint to multi-year with a plan and close each time box with a demonstration of what was completed and validated. We use the feedback from each of the demonstrations and retrospectives to update the plan for the next time horizon. There are typically 10 days in a sprint, 6 sprints in a quarter, 4 quarter in a year and so on. The goal is that we are using the metrics from each time horizon to inform the next time horizon and increase the predictability of the customer outcome we are trying to achieve.

Conclusion

I love Harry Potter, I love Magic!! However if you are looking to identify predictability in delivery use the data at your disposal. What was you plan? What was your actuals? How close were these two data points? If they are far apart it is likely you are trying to use magic to deliver and I don’t know about you but I never received my letter from Hogwarts.