Synesthesia

How can visual models improve the flow of work during programme shaping?

This is the sixth post in a series about applying the lessons of lean (especially lean software development) to the shaping phase of programme management.

In previous posts I have talked about amplifying learning, the application of the ideas of flow and a value stream to programme shaping, and touched on sources of “waste” in the typical programme environment.

In this post I want to talk a bit about (visual) models.

I’ve found two sorts of model useful when pulling together a programme – models of the shaping process itself, and models of the programme design.

Modelling the Programme Shaping Process

In previous posts I’ve talked about looking for flow in the programme shaping process. Every organisation, and to some extent every programme, will have a different flow for the shaping process.

For most this will involve some number of iterations of capturing and designing information, creating programme artifacts, and seeking approval from various stakeholders.  I have talked about keeping work-in-progress to a minimum, and the classic tool for managing that is a kanban board.

Modelling the Programme Design

The other area where models are vital is in describing how the programme will work and what it will deliver – in other words, the design of the programme itself. Programme documentation has always been a way of sharing a model of how things will work and what will be achieved, but I think there are lessons we can learn from other disciplines to make the documentation more useful.

Many traditional programme documents are heavy on words and light on diagrams. Words are vital for providing detail, but they are not the best choice for communicating the relationships between concepts, nor for illustrating causal chains (for example from enabling projects to capabilities to benefits to outcomes).

I’m suggesting that as programme managers we can usefully make more use of visual models to augment our programme documentation, and to model the relationships between different parts of the documentation.

There are specialist tools (e.g. ChangeDirector) which make extensive use of graphical techniques, however not every organisation will have access to these. I have had some success in using general purpose UML modelling tools to support programme shaping work, and it’s an area I am actively exploring further. One background project that I hope to blog more on later is the creation of a UML Profile for Programme Management

I’d like to hear from other programme managers about their experience with visual modelling.

Picture credit: David Larabee

I’ve just been reading a couple of articles on this topic in the online version of Architecture and Governance Magazine. (registration required to read full article text).

In Business Capability Modeling: Theory & Practice, author Leonard Greski gives a good overview of the process steps:

Business capabilities can be modeled using a variety of simple techniques, using low-cost tools. There are four steps to create a capability model:

1. Develop the capability hierarchy.
2. Identify key relationships between capabilities and other planning elements.
3. Develop demand models for the capabilities.
4. Develop financial models for the capabilities.

The “how” of the approach seems to be similar to most modelling approaches – capture a hierarchical decomposition of objects and identify cross-relationships using matrices.

Of particular interest is the “what” – this approach is focused very much on identifying the characteristics of a business that create value (for customers or shareholders), and identifying the resources, investments and cashflows that underpin them. I can see this approach would be very useful in situations such as programme blueprint creation – identifying the desired future shape of the organisation.

In the second article Business Capability Modelling: Building the Hierarchy Leonard dives more deeeply into the “How” of the first two steps. I look forward to reading the next article, which presumably will look at steps 3 and 4.

(NB I’ve looked for a blog by Leonard, but can’t find one, hence linking to his LinkedIn profile.)