The Benefit Delivery Model circa 2007

So in a fit of nostalgia I was going through some work I created back in 2007 and one slide within a pack on   a formal Quality Gate Process stuck in my mind.  Whilst a lot of the world has moved away from the formalised and regimented QMS / Gate structures and approval boards with endless paperwork having a stranglehold on project delivery, the underlying principal still stands:

Benefit comes from Process Improvement, not from IT.

I realise this is stating the obvious to some, but for me it was worth just mentally re-visiting that statement.  We can build the most technically elegant and "bleeding-edge" platforms, the most wonderful UI's and the fastest responding architecture in the land, however unless it is improving something tangible for the business, there is no real point in investing in it.

Whilst my slide above was for an audience in a Government organisation who liked Prince2 and SSADM type processes, it still stands up just as well in the Agile world.  Every single user story can be considered to be its own little business case (if written correctly) with the benefits clearly stated, and the acceptance criteria clearly defined - Benefit really does come from Process Improvement, not from IT.

Product Owner Problems

In my current project the business faces an interesting conundrum with Product Owners.

We are specifying and [hopefully] building a Demand Forecasting solution for a large Supply Chain and there is ultimately a large amount of complexity within it.  The complexity comes from the integration of Demand, Supply and Inventory data and the ability to accurately forecast and model future Demand at SKU level upwards, then turn that into Supply and Inventory forecasts (let alone optimize them).

Thankfully I have a good bunch of talented Supply Chain individuals who understand their subject and can give me requirements in a granular and Agile manner (I have a 300 Epic backlog so far). These people can define at an intricate level how they need their system to work in a Supply Chain context and what they expect from their product.

So why is this a problem?  Ultimately a Demand Forecasting solution has very little to do with Supply Chain and an awful lot to do with Analytics, Algorithms and Data.  I have a Product Owner who can tell me in detail what he needs his demand forecast chart to look like and how it is to behave, but can tell me very little about how it is actually calculated from an underlying analytical perspective.

Suddenly a conversation about what does "best fit" or "most appropriate calculation" opens the doors to a need to understand Simple Moving Average, Geometric Moving Average, Triangular Moving Average, Parabolic Moving Average, Double Moving Average, Exponential Moving Average, Holt's Double Exponential, Holt Winter's Additive, Holt Winter's Multiplicative, Additive Decomposition, Multiplicative Decomposition, Sparse Series Croston's Exponential, Economic Time-series Forecasting, Linear Trend / Regression, Linear Trend And Additive Seasonality, Wavelet Forecasting, Polynomial, Haar Denoising, Fractal Projection, and Fourier Transforms.

My Supply Chain Product Owner now needs to be a Statistician from Cranfield University! Simple sounding user stories suddenly have a deep weight of underlying mathematical understanding needed and the "emerging architecture" becomes one of building a statistical analysis package rather than something for planning how many widgets to buy.

Today I do not have an answer to this one, however the first development iteration is in three weeks time so I've got some time to get an approach sorted out.