The Toyota philosophy knows the concept of Poka-yoke, ‘mistake proofing a device by preventing, correcting, or drawing attention to human errors as they occur’. Poka-yoke is a means of building quality into the device since it prevents making mistakes. It doesn’t only have an effect downstream. In combination with ‘stop the line’ (stopping production and finding the root cause of defects) this also works upstream.

Maria Montessori, the inventor of the Montessori Method (child education), uses the same concept. The Montessori Material has a build in ‘control of error’. The children work with the material but don’t need the teachers assistance to check their own work. The check is build in.

Agile IT knows concepts like continuous integration, test automation and tracing and logging to build quality within the development process and within the IT solution. Guessing whether the solution works is not necessary, nor a lengthy manual testing phase. You get instant feedback on the quality of the solution. (Of course test automation does have it’s price). When the solution has gone into production, build in tracing and logging helps locating and fixing problems.

All three cases share the concept of ‘quality build in’, but that’s not the true connection. The true advantage of ‘quality build in’ lies in increasing the learning capacity.

The effectiveness of the learning process is greatly influenced by the feedback cycle. We need feedback to determine if what we do is right. The shorter the feedback cycle, the better. Building quality into the process and product shortens the feedback cycle substantially.

The true connection between the Montessori Method, The Toyota Way and Agile IT is that all three are learning processes.

The problem with complexity is that it creates unpredictability. We do not like unpredictability because both customer and supplier want to have a successful business case and need to know in advance whether the project is going to deliver within the boundaries as defined by the business case.

The classical, non agile, approach to unpredictability is to do more analysis upfront and follow a rigid change management method, usually combined with a large requirements document, contract and project plan. The assumption is that by doing a lot of thinking most of the potential problems can be addressed and that the few other loose ends can be managed effectively by change management.

I’m afraid this assumption is wrong. Not only because we continuously underestimate the number of changes during the project and are very poor in predicting the future. The larger problem is that the contract has become the project’s goal, not the underlying business case. This potentially creates a severe misalignment between customer and supplier.

Every time something unexpected happens there are two points of view.

The customer reasons from his needs, towards an ideal situation. From that point of view it is likely that changes are needed. Changes are considered necessary and an opportunity to create a better solution.

The supplier reasons from the contract (deal). Changes are considered a bad thing. It means that all the thinking didn’t create the desired results (a smooth and predictable project process). In most organisations projects are considered to be successful if the project is finished within the set boundaries of time, costs and scope (quality). It means that someone has to tell upper management that things do not go according to plan. It is in the interest of the project management team to reduce the amount of changes, to steer the project towards the boundaries set by the contract.

Though this misalignment happens in lots of projects, I do not think it is that difficult to turn the situation around. It requires an other mindset.

First you need to make clear within the supplier’s organisation that a project is successful when the underlying business case is successful. This means that time, scope and costs may change, it does not necessarily cause a problem.

Secondly I would advise the following action plan for each potential change:

• Determine the ideal situation
  Talk to the customer and ask for his needs. (In fact, don’t wait for his initiative and make some suggestions yourself).

• Look at the contract
  Only then determine what has been agreed upon by contract or project plan and determine the gap between deal and ideal.

• Change management
  Determine the right course of action. This can be something operational (managed by the project manager) or something on the project board level or both.

Thirdly, it is also wise to repeat this process frequently, even when there are no problems. It is an excellent process to keep the project healthy, to prevent unspoken assumptions and expectations. It also is a nice fit to the concept of learning and improving.

Of course you agile project managers already know all of this.
For you guys I have an additional suggestion. This process can also be applied to any situation where people need to work or live together. Between you and your team, between the team and Product Owner and yes, even at home between you and your partner.

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.