MarkStringer.github.io

Project Management is About Value Stream Transfer

Pay attention because this is a genuine revelation. I think I’ve come up with a way of thinking about project managementment which is both useful and reassuring.

Value Stream? What Value Stream?

When people talk about lean, they talk about value stream management. When people talk about the software value stream they talk about reducing wait times, removing steps where no value is added, and trying to reduce the amount of time from when a piece of work is begun to when it is finished. But this isn’t the value stream I’m talking about. I’m talking about two other value streams.

  1. The funding value stream
  2. The product value stream

The funding value stream

Mr A completes a bid for product X. It might be a written proposal. It might be a conversation. It might be a presentation. It might be an ongoing campaign of persuasion over a period of months or years. Ms B (and the board) agree to give Mr A the money for product X. The result is project Q.

Being paid for writing things, putting together presentations and saying things is the funding value stream. To be good at getting value out of this value stream takes a specific set of skills - paiting an attractive picture of how the world will be when product Q exits.

The product value stream

At the beginning of a project the product value stream doesn’t exist. And it has to be constructed. This isn’t the software development value stream. It’s not the process of turning requirements into software, it’s the process of turning the using of software into value (it might be money, but I’ve worked in government where it’s other values like justice, safety).

Transitioning Value Streams is Hard

Mr A is comfortable with the funding value stream. From the very start, news from the product value stream is likely to be disconcerting and threatening, if not downright terrifying. An agile approach to software development, especially a Scrum approach highlights obstacles which are preventing development right from the beginning. Often the kinds of problems which are highlighted are what I’ve previously categorised as “bricks without straw” problems. That is, these are problems which, if they aren’t addressed, mean that the product simply can’t be made. Sometimes this is relatively simple lack of resources: the team don’t have the tools that they need or there isn’t a team. Sometimes it’s more of a logistical challenge - the people that we need to talk to make this product that will make their lives much better are way to busy or valuable or expensive to talk to us.

Working Software

Continuous engagement with customers, clients and users