In part one I touched briefly on plans and forecasts. In this post about customer focus and flow for the PMO i come back to them.

Flow: don’t work in the system, work on the system

In our PMO we had plans covering about three to 15 months: there were high-level milestone plans, mid-level milestone plans and low-level detailed milestone plans.

Good high-level plans provide a clear overview and a base for conversation. But people also like plans because plans give you confidence that you know exactly what needs to be done when to achieve a certain result. They also clearly state when an activity has to start in order not to postpone all the following activities and are therefore excellent to chase development teams with. If you just manage all those activities and milestones hard enough you will follow the plan. You learn to move deviations from the plan to the change log, to highlight external dependencies early and to add risk buffers generously.

However, it requires considerable work to keep the plans updated, not to mention the explanations you need to provide whenever a milestone slips (and that’s a very common milestone behaviour). So you will soon need more people to help.

Picking one value,  I think Flow is the key one in this context. It’s what really challenges established artefacts and processes. It’s what requires another mindset, another language and another leadership.

So we needed to ask ourselves whether we shared these values.

Don’t work in the system, work on the system.

Customer Focus: Faster Feedback

Earlier, I also mentioned that Continuous Delivery was part of our agreed vision.  Another part was Faster Development in order to Shorten Time to Market and get Faster Learning Loops.

To a large extent this program was about shifting technology: we had a well-performing product live which would enable valuable A/B testing. Two main business benefits should cater for the investment. We knew we would need multiple learning phases to achieve the desired outcome. There were also external dependencies to manage.

Given the portfolio items and dependencies: how can we start harvesting benefits as soon as possible and when would that be?

We experimented with simulation to learn more and to model probability of when business benefits could be fulfilled.  This then formed forecasts that would replace the earlier detailed plans.

So, we went from clear detailed milestone plans to forecasts embracing dependencies, learning loops and uncertainty. Be careful: this change requires a master in stakeholder communication. I think our first forecast that we shared was more or less interpreted as We have absolutely no clue and it took time to find a working visualisation.

This is how we pictured our forecasts. By using words like experiment, walking skeleton and ramp-up we emphasised the need for learning and improving. We could also pedagogically show how uncertainty increased exponentially over time.

By then we had come to another level on our journey to continuous delivery and gained more confidence.  This together with our forecasts helped move daily focus to a much shorter timeframe than before: to faster feedback and customer value.