Basically VSM works like this:

1. Determine the definition of Customer Value.
   Define what product or service is/should be delivered and determine its properties.
   Do this from the customer point of view.
2. Define the current VSM.
   Draw the entire process including both the flow of products, information and time.
3. Determine ‘waste’ (or muda in Japanese) and draw the future VSM.
   Each process step that doesn’t add Customer Value is waste. Each step that doesn’t add value but is necessary in order to create value is ‘necessary waste’. Each step that doesn’t add value and also isn’t necessary is completely redundant.
4. Optimize the current process and repeat.
   Eliminate redundant steps, optimize ‘necessary waste’.

The most difficult and critical part in VSM is firstly determining the definition of Customer Value and secondly determining ‘necessary waste’. Especially in change processes it is of the essence that everyone participating in the change is aware of it’s goals. I’ve seen too often that change processes (or projects) are sub-optimized because project-specific processes or goals have taken precedence over the goal the change process initially was created for.

Let me give you an example with an average ICT project.

Customer Value

What is the Customer Value that the project creates?

Is it design documentation, is it software? Or is it software as an enabler for business processes? I think it is none of the above. It should be software as a business enabler, but not at all costs or without any limit on delivery date.
The projects Customer Value is defined by the projects Business Case (which should contain the definition of the Customer Value, but also costs, benefits, time, etc).

Necessary waste

What activities or project products can be considered to be necessary waste?

Design documentation could be considered necessary waste. The design itself does not create value. It does not enable business processes directly, software does. Some value might be found when considering software maintenance.  If maintenance isn’t possible without documentation then there is some value there. If the software can not be maintained properly then, in time, the software does not enable business processes anymore. The thing is that other solutions exists that enable software maintenance. An automated test harness for example is a better approach.
Is documentation necessary  for knowledge transfer between customer and programmer? In short, the answer is no. Knowledge transfer on paper is very ineffective. Between customer and created software at least 75% of knowledge is lost. Just discussing the requirements and features and building mock ups are far better methods for knowledge transfer.

How about project management? Does giving orders and creating plans create value?
Project management is definitely waste.  It is necessary, but clearly it’s an activity that should be made as ‘lean’ as possible. My personal goal as a project manager is to make no decisions and generally do nothing at all. Why? Because this is only possible when the project runs perfectly, when the goal is clear, the processes are effective and everyone knows what to do. Here’s where the lean Scrum process adds value. Also PRINCE2 supports this goal with management by exception and with tolerances that enable delegation of tasks and responsibilities.

ICT project VSM

So how would a current and future ICT project VSM look like?
Of course that map would be completely different for each project. The interesting part is which activities are considered necessary waste and what optimizations are proposed. VSM is useful in making the definition of Customer Value transparent and applying that definition to each step in the change process. The discussions that arise should result in process improvements, in making the change process more effective. With an iterative approach discussing the VSM could be done after each iteration, so that change process improvement becomes a natural thing within the change process. It also fits perfectly within the Scrum and PRINCE2 methods (‘Sprint Retrospective’ and ‘Lessons Learned’ respectively).

However, in ‘normal’ PRINCE2 projects, I’ve seldom seen a real Lessons Learned session. Sometimes the project manager quickly creates a Lessons Learned document near the end of the project because the document is part of the deliverables. The actual learning doesn’t take place, not just because of the mindset at the time but also because the project is finished.

To be fair to the people involved it’s quite difficult to actually benefit from Lessons Learned when using waterfall or when using lengthy iterations. In what way can Lessons Learned from the design phase be applied to the build phase? If something has gone wrong you do feel the pain, but nothing can be done about it.

PRINCE2 argues that these Lessons Learned should be documented for future use, so that the next project might benefit. That may be true, but I haven’t seen it happen yet. Even if the documents are read, knowledge transfer by writing documents is quite useless. If the same people do the next project there’s a chance that lessons are learned.

What really matters in projects is transforming Lessons Learned to actions within a short time frame. Otherwise the Lessons are not Learned.

Here’s where Scrum comes in. When PRINCE2 is combined with Scrum it suddenly becomes easy to learn from mistakes. Here’s why.

• Each Scrum iteration is done by the same people, delivers the same kind of products and uses the same methods and processes. Lessons Learned from the previous iteration are immediately transformed to changes in the next iteration’s approach. Furthermore, the team can track problems and changes over multiple iterations and really improve things.
• Each day the team has the Daily Scrum meeting in which progress and impediments are discussed. It only takes a day to notice problems and (hopefully) there’s plenty of time to do something about it.

That’s one of the things I love about Scrum.