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).

The business side of Scrum however is almost blank. Only assigning a Product Owner is not enough. There’s a lot more to projects than only the Product Backlog and ownership of the Product Owner. That’s why there is so much discussion concerning the implementation of Scrum. You do need to fill in the gaps.

The most obvious gap with Scrum is the management of stakeholders.

With Scrum there’s only a Product Owner. This task can be delegated to someone else (the ‘proxy Product Owner’) or to multiple persons. The problem here is that Scrum needs a ‘single wringable neck’, which is difficult when it’s not one person or when the actual ownership lies somewhere else.

Then there’s the problem of the differences in interests. PRINCE2 makes the distinction between Senior User and Executive. The Senior User is the ultimate user, the person whom will accept and use the finished product. The Executive is responsible for the Business Case. He needs to balance costs and benefits. (By the way, the Business Case is a gap in itself!). Only in small projects these roles can be combined, in that case the Product Owner is both. In most projects the roles can not be combined. That creates a problem with Scrum. A process needs to be in place to manage differences in interests.  Scrum does not have such a process.

Another example occurs with projects with a commercial customer/supplier relationship. If there’s some risk involved then the party whom bares the risk needs some kind of control. Not only on an operational level but also on the executive level. Scrum does provide some level of control with the Burndown charts and Product Backlog, but there’s no process in place to manage progress and issues on an executive level.

These gaps are manageable. Also there is not a single solution that fits all. A lot of Scrum Masters (or project managers) have found a lot of solutions to cope with stakeholders. For me PRINCE2 complements Scrum very well. I use Scrum for the Delivery process and PRINCE2 for everything else. The team doesn’t notice PRINCE2 at all, they use Scrum. The customer notices the differences compared to a traditional PRINCE2  project, but the main processes remain the same. So again, Scrum sucks at some areas but combined with PRINCE2, I couldn’t live without it.

First of all, let me ask you another question. “Do Scrum projects have a business case?”

Well of course they do. Every project has a business case. A “reason why”, a “justification of”, a specific goal. Sometimes a business case only exists in the mind of the business executives, sometimes an elaborate analysis has led to a business case document.

As stated in my previous post projects tend to align to the measurement system and it is wise to align the measurement system to the business case. The same applies to Scrum projects. It does not help when the business case is not defined explicitly.

Within the PRINCE2 project management method the business case plays an important role. Unified Process also uses a Business Case. Scrum doesn’t have it, but if there is really good teamwork going on then probably the business case is clear anyhow.

So, does a Scrum project need a business case?
I would say yes. It plays an essential role to maintain focus on what is important. Even when teamwork is great it still helps a lot. It also can help managing the customers expectations.

At the same time I think the Business Case should be agile. It is of no use to spend too much time on analysis or describing the solution. That would not be agile and probably not effective. To me an Agile Business Case resembles a User Story. It describes the need of the customer and defines the boundaries of the solution/product, it does not describe the solution itself.

There is a very powerful tool to create and maintain focus on project and that is the progress report. The progress report is used to communicate the progress to the project board or senior executive/supplier/user; on scope, budget, time and risks (and sometimes quality). Implicitly it is a kind of measurement system. The success of the project is measured by this progress report. Of course people tend to deliver what is measured, in other words, projects tend to align to the measurement system.

The big question is “does the measurement system reflect the project goal“?
In my experience this is often not the case.

The project’s goal is expressed in the underlying business case. If the business case is not defined explicitly then it still exists implicitly. (There is a reason why the project was funded). The business case should not only describe the development phase of the product (the project itself) but also the production phase of the product (maintenance, support). A common business case is that process improvements lead to a decrease in costs in production.  The costs of the project will then break even in X years.

The problem with a business case is that very often it is defined only once, before the start of a project. When the project commences the business case is never looked at again. That is a shame because the business case not only defines the validity of the project, it is also a very good tool to keep the project aligned on the end result.

In fact, in fixed-price projects, there are at least two business cases. One for the customer and one for each supplier. The customer wants a new product or process improvement. The supplier wants to make a profit on the project. Depending on the amount of “transparency” the project manager should have two progress reports, one on the customers business case and one internally for the supplier. The first focused on the customers goals, the second one on profit.