This is the second post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.

Here I am using “programme” in the widest sense – to borrow a definition from MSP2007 “a temporary, flexible, organisation created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives”.

The core of all lean approaches is to identify the value stream – what activities take place to generate value from the process. For example, in software development, what sequence of activities has to happen to create production applications which deliver benefit to the customer? So how do we map that to the early, often “messy” stages of a programme?

Standing back from the detail of a programme, we can see that it is (like any business activity) an investment of time and money to move the organisation closer to its goals. I think you can structure the problem as a series of steps from the strategic to the specific:

  1. What challenges does the organisation face, and what objectives will it adopt?
  2. What areas of change would make good programmes?
  3. What would a specific programme address?
  4. What specific benefits will the programme deliver?
  5. What does the programme have to do to deliver the benefits?
  6. (and then down into the projects and business change activities)

Many commentators would suggest that (1) is the province of strategy development and that (2) is the realm of Portfolio Management, but for the moment I’m going to elide them together – I’m trying to find the flow of value rather than establish discipline boundaries. Having said that, most of us who get involved in programmes can usually only monitor (1), so I think there is a fairly natural (albeit fuzzy) line between (1) and (2).

In terms of the programme shaping flow, we can start to see a series of intermediate products at increasing levels of detail, requiring increasing investments of time, money and resources, and which eventually (should) generate benefits that flow back up the tree. Before we can identify the value chain associated with all this activity, we need to determine how the organisation will assess value. It seems to me that the clue is in the definition of what a programme delivers – “outcomes and benefits” – and the key to evaluating those is benefits realisation management. It won’t surprise anyone when I say that in my opinion benefits mapping and related analysis is at the heart of an effective portfolio and programme process.

So the second clue about finding the value stream is to focus on benefits at each stage.

The third element is to decide how we recognise “good” quality at each stage – i.e. something that delivers value to the stake-holder. Sadly, we have no equivalent of the software world’s automated unit, integration and user tests for programme artifacts, so we need to turn instead to guidance such as MSP 2007 Appendix D “Programme Health Checks”, OGC Gateway reviews, or any other audit and evaluation approach used within an organisation. To optimise our value stream we have to optimise the flow of our work products through those constraints.

In the next article I’ll start to explore the concept of waste in our context.