All too often I am asked to help with a business change or transformation after it has started and is not going well. In almost all cases, a major reason it is not going well is no one described where they wanted to go, or if they did the destination was poorly defined.
These are not well-defined destinations:
- “We want to be a more effective organization.”
- “We want to be Agile.”
- “We want to be collaborative with our customers.”
- “We want to provide world-class support.”
- “We want to be a Lean Startup kind of company.”
- “We think we should be communicating better.”
- “We are going to roll-out Scrum to the whole organization.”
In fact all of these statements are solutions for some perceived problem that is not described. Since we do not know what the problem is, we do not know if any of these is the right solution, nor will we know if the problem is solved.
I always ask WHY. Why do we want to do these things? What problem are we trying to solve? What challenge are we facing? What result will we get if we apply that solution?
Here are some examples of concrete problem descriptions that will allow us to determine a well-defined destination.
- Our cycle time from proposed change to release is 6 months but the average in our industry is 3 months. We are losing business and our research suggests it is because we are often too late to market.
- Our product sales are steadily decreasing compared to competitors. Feedback from our customers is that they find our product to be harder to use than similar products.
- Our markets change quickly. We need decisions at least quarterly (monthly would be better) about product direction, but our leadership team takes 6-12 months to make a decision.
- We are getting a lot of feedback on social media that our support team members are often not solving the customer’s problems.
Can you see that with a good description of the problem or challenge that describing a destination becomes much easier?
Once we have a clear description of the problem, we want to describe relatively short term goals. What can you do this quarter or by the end of the year? This will allow us to get feedback on whether or not the solution is working, and allows us to change the approach if it is not (or we discover the solution is not sustainable over the long term).
- In 12 months we will reduce our cycle time from proposed change to release to a maximum of 5 months. Though it is infeasible to reduce the cycle time for everyone to less than that in a 12 month period, we will find one product where reducing the cycle time is likely to improve sales, and we will reduce the cycle time for that product to 3 months.
- In 3 months we will release a new version of our product that fixes the top 3 usability problems.
- We will select a product that is particularly market sensitive and work with the leadership team to get decisions quarterly throughout the coming fiscal year.
- Every month in the coming fiscal year we will provide a solution to the current number 1 problem customer support has been unable to solve. By the end of the year we will have solutions to the top 12 problems. Either they are no longer problems or we have trained our support team members in how to solve them.
With a clear description of the problem or challenge, and a clear description of the destination, we have a way to measure if we got the results we were looking for. We still have to work out how to get from problem to destination, but once we know where we are going we can find a way to get there.
In order to get to a solution, we often have to do deeper analysis of the problem. This is because the problem that we see comes from some place in a overall process that may be quite large. What part (or parts) of that larger process is causing the problem?
Let’s take the example of the cycle time from proposed change to release. Many people will assume it must be the implementation team that is not efficient. We can hire some coaches and teach them more efficient practices and that will solve the problem. But will it really?
We need to take a deeper look at the whole process. The implementation team is just one part of it. Is the problem convincing someone to fund the change? Is it how long it takes the delivery team to implement a solution? Is the problem how long it takes to release the solution once it has been implemented? Is there a quality issue?
This deeper analysis of the problem is very important or we risk applying the wrong solution. We waste time and money and still the problem is not solved.
At one company where I consulted in the past, my client had just this problem – the cycle time from proposed change to release was far longer than their industry average. They brought me in to help the delivery teams work more efficiently in order to reduce the cycle time.
I did some investigating and found that the delivery teams were already working very efficiently. The problem was in two other places. The first problem was that once a change was proposed, it took many months to get it approved and funded. That part of the process took as long as implementing the solution! The second problem was that to release the change took many months. That part of the cycle was also as long as implementing the solution. The whole focus of the process improvement work had to change, and the nature of the solution had to change.
(If you are wondering what happened … changing the release process was a long, difficult effort because there were a lot of things causing the release process to be long, each of which had to change. It was done over a period of years and the overall cycle time was reduced a lot. Changing the funding process was not even addressed until the Board of Directors fired the CEO and there was a big shake up at the top of the company. It was actually a pretty easy process to fix once there were people who wanted to fix it, and was done in a couple of months. And fixing that process had a much larger positive impact on the efficiency of the whole company.)
In conclusion: To be able to measure the effectiveness of a solution, we have to first clearly describe the problem we are trying to solve, then describe what things will be like when the problem is solved (the destination). We then do some deeper analysis to determine the actual source of the problem, and propose a solution to try. We apply the solution in a small way and measure to see if it is moving us toward our destination in a manner that is sustainable and able to be applied on a larger scale. If the answer is yes, we expand the solution to a larger part of the organization, and again measure the results. If the answer is no, we can try a different solution to see if it works better. We can also review our analysis to be sure we are solving the right problem.