Why successful outcomes are so elusive
A lot of projects are tick list successes and business failures, says columnist Dan Morris. Here’s why many to most improvement projects are actually fairly unfocused.
The fact is that no matter what you do, you will always deliver something. If you move, you will always go somewhere. If you shoot a gun into the air, the bullet will land someplace. Every action results in some change. Physics 101 tells us that! So how does this apply to BPM?
Most projects, large and small, have a list of requirements that they try to deliver. This list may even have KPIs and other performance measurement requirements. It may have standards and it may even have compliance targets. But, it is a list. It simply defines things that the team will try to deliver – given constraints.
As with any list, there are hundreds of different ways to deliver each of the requirements on the list. In defining success, how each is delivered is secondary to the fact that the team can tick them off, one by one, until all are "delivered". And, this success can even be proven in some cases through measurement – the deliverable meets the terms of the requirement. Success! Frankly, there was a time when I agreed with this approach.
Following this approach each item is addressed in some way and the requirement is ticked off. When all are ticked off, the project is over and it is declared a success.
But a lot of projects are tick list successes and business failures. We say in defense that the requirements were all delivered. We can prove that – all the requirements on the tick list were checked off. We may even say that we had a mixed business and technical team so everyone had input into the solution. OK, true, but if that were the answer, why do we still have opinion-based success evaluation? And given measureable targets, why do so many projects fail? – even with certified project managers.
The real issue is that the result is too technical or too complex or too something. The outcome of the project does not work the way people want it to. And worse, there is often a lack of cohesion in the resulting business operation’s activity making work more chaotic. But all the requirements have been ticked off the list and yet, the gulf between the business and IT, and now between the company and its customers, often just gets worse as we try to make things better.
No wonder there is so much frustration and so little trust in what projects will deliver in many companies.
The fact is that a list of requirements is not a vision. It is not a true target. No list of anything can possibly define what the new business operation will look like – how it will work and how each person will do their job. The missing part of the approach is obvious when you think about it. This is a clearly defined outcome state with models and supporting information that support the requirements list. It is the target – operating definition that turns vision into reality. It says there is one outcome and this is it. All the requirements must work together to deliver this outcome and all the paths taken to get to the outcome state must solve problems, deliver competitive advantage, efficiency improvement, effectiveness improvement, quality improvement, and customer interaction improvement. This forces a new type of holistic view as the team must consider all the above points and meld business change, data use, IT application change, culture change, and customer experience change together into a cohesive new design that delivers not a list of ticks on the requirements list, but a new vision or operational outcome.
Because of this distinction, I find that many to most improvement projects are actually fairly unfocused. The simple fact is that most of the time requirements deal with "what" and not "how". The "how’s" let us determine the way the "what "will work. It is this reality that allows multiple teams who might do the same project to come up with different solutions. The fact is that "how" we wind up doing the work or meeting a requirement defines the outcome state.
Different "how’s" mean different outcomes!
This simple fact is the reason I say that, if we don’t define the outcome first we have no real target. We will have an outcome that is dictated by the composite of the solutions used to deliver each of the requirements. A composite that is not defined or planned. So who really knows what business solution will be delivered and if it will be acceptable or not – until it is delivered and used.
The real questions in defining the outcome are: "What do you specifically want to get out of any change?" and "Once the change is completed, how do you envision the operation to work?" And, these questions should be answered while the requirements are being defined because the requirements must support the outcome or the project will be out of alignment with expectations.
The reality of change
The fact is that even if a company has a strategy and a plan to implement strategy, the individual departments will usually simply evolve in response to problems, legal change, new technology, and a lot of other events or drivers. Here evolution is taking place through narrowly focused work – without a clear picture of how all the changes will fit together or what the overall result will be.
In life and in all change, you can easily be directed by the pressure of the moment. Problems are addressed and the business evolves. The simple fact is that without a defined outcome for each change, the result will be unpredictable – you may fix the problem but hurt the overall operation. While this can take time to build in small changes, the result from big changes, such as transformation or major projects, can be seen as soon as they are released.
Transformation and improvement today
To a large degree this problem plagues business improvement and transformation. You start with a goal of improvement or of solving a problem and then you move right into mapping and improving. You get a solution made of many smaller improvements and it may make things better or solve the problem. That is unquestionably good – right? The answer is maybe.
In the 1990’s there was a common belief that business operations had about 40% of waste or fat in them. This was widely believed without any studies or anything other than gut reaction to some popular articles. So the target was to reduce staff by 40%. In some cases the prediction was right and in some cases the change gutted the operation.
An example is a large insurance company that called my company in to redesign its operations and reduce cost by cutting staff. They wanted to eliminate the standard 40% of their expensive staff – in this case, actuaries.
I asked if they planned to grow their business or if the business was shrinking. They responded that they were growing rapidly. I next asked how long it took them to build a good actuary. They said seven years.
Ok, well how did they know that they had an excess of actuaries? Were these people just standing around with little to do? The answer was no, they were working, but they felt that with more automation and some redesign, efficiency could be improved and they would be able to reduce head count.
I then talked to them about what cutting almost half of a skill that took seven years to build would do to their growth plans. Even with efficiency gains, in a growing operation, the needs for this skill would increase, but they would then face a shortage for seven or eight years or find themselves hiring new trained people who still had to learn their policies and procedure – but would likely cost them more money.
The bottom line is that they did not cut actuaries.
The issue, though, is one of not understanding how everything fits together and what the probable consequences of a seemingly good change might be. They did not understand the consequences and its impact on their ability to support their operational and growth visions.
But I only have to fix a problem! Why do I need all the extra work?
In reality, if a problem is small enough, you don’t need BPM or a BPMS or even Visio. Just fix it and have done with it. But most projects are bigger and require a more formal approach with consideration from the affected business operations, IT, maybe production, maybe finance, maybe legal, maybe logistics, and the list goes on. Today, these different groups are contacted as needed and there is really no shared agreement on the desired outcome of the project – just what is on the list of requirements (and often not even that).
I propose a different starting point. I believe in a holistic approach that begins with a study to define a desired business outcome state and identify who (business area and managers) will need to be involved to deliver it. The goal of this study is to bring everyone onto the same page and get everyone to agree on the project’s outcome, their role, the priority they will need to give it, and what the end result or outcome should be. But this is also often not performed.
And, that is too bad. Because it virtually insures that there will not be a common understanding of the outcomes that are to be delivered or the business model that will be built.
My experience shows that a clear definition of the project’s goals is only the starting point. From the goals the team must create a vision and a design of what the finished new business will look like and how it will operate. This is an outcome model. Once this outcome model is defined, the next consideration should be its alignment with the business operating model defined by the company’s strategy. Any significant business change should really include this alignment step to insure optimal contribution to the company.
The outcome model shows what the business operation and IT support will look like (how it will operate) if the goals of the project are delivered. This outcome model can be defined by operational, performance characteristics, and customer interaction definitions that describe the business after the change.
This offers a clear definition of how the business should operate from multiple perspectives – process, people, technology, finance, customer experience, and with others it touches. When the outcomes of these perspective considerations are taken together the result is a definition of how the business will operate when the change is completed. Knowing this, a new "future state" business operating model can be designed.
The picture that is described through this work is a conceptual model that will guide the definition and construction of a future business operation’s processes. This picture is itself defined as a series of capabilities that are needed to deliver this business picture. The capabilities are in turn aligned to processes that actually deliver the work needed to provide a stated product or service.
When aligned, they work together to define the operation at a future point in time.
Managing by outcomes
What outcome does any manager want from a change? Obviously the answer will usually change for each manager you talk to. This is true even if there is a list of approved requirements. This means there are no clear outcome goals or consensus on what "improvement" or "transformation" will deliver. So what is the real target – what is the real outcome of doing something expected to be?
In "Alice in Wonderland" Alice is confronted with a similar problem. She doesn’t really know where she is and she doesn’t know what to do or where to go. But she wants to do something. So she is at a crossroad and meets the Cheshire Cat. She asks, "Which way should I go?" To which the cat answers, "That depends a great deal on where you want to get to". Alice says that she doesn’t know. The wise Cheshire Cat then says, "Then it doesn’t matter which path you take."
So Alice doesn’t have a defined outcome. But she does have requirements for the journey built around her need to avoid the Queen, her guards and the Jabberwocky.
Clearly any path will take you some place – it’s easy to get to an unknown destination (any place will do). The simple fact is that every path ends in a different solution. And many paths can meet certain requirements. Each will have a different outcome and each will result in a different business model. I submit that "where you want to go to" doesn’t just refer to hitting a goal or list of requirements. It refers to a new end state, a new operation or operating model – the implementation of a given outcome.
How many of our change and transformation projects are just like this? However, if we first define the outcome state that we want to deliver, we can clearly define our target and then focus on what it will take to move from where we are today to this new business model.
Outcome evolution
Any outcome design is a moving target. The understanding of what may define "optimal" today may be different than it will be in a year.
The market changes, the technology changes, and the business changes. Any project that is truly transformative will take some time. Many take more than a year and some more than two years. So the defined outcome for these larger projects should be reviewed and evaluated at least on an annual basis to see how they may need to be reconsidered.
The other fact in these larger projects is that the solution will not be one step – wait until we are all finished and then everything will change. The delivery is more likely to be through an orchestrated series of incremental sub-projects. These increments will need to be designed to deliver a component of the overall outcome – so eventually they fit together like a puzzle. These deliverables must also be aligned to the delivery of requirements and the resolution of problems which will be part of the final outcome of the project.
Within each increment, the project team may want to work with the IT team to divide the business change into a group of small IT supported Agile Sprints. In this way, the new increment in the development and deployment of the changes leading to the outcome state will themselves be divided into controlled small components for rapid delivery.
Each increment will thus deliver a part of the overall construction of the outcome. This also allows the team to adjust the requirements and deliverables as the outcome evolves to deliver an optimal operation given the evolving business environment and technical capabilities of the company.
Remember Alice
Like many companies, Alice was at a crossroad. She wanted to move – to do something. But she wasn’t certain what the outcome of that move should be and thus not certain of the path she should take. If she was able to see the end point or the outcome and understand the consequences of each option, she then could have chosen the best path for her to take – given the constraints and requirements that she would need to deal with.
I have once again tried to give you something to think about – a different approach with different concerns. As always please share your ideas with me.