The immediate answer is “of course” continuous improvement is a good thing. What fool would say that it is not? That was once my answer.
But is this really an “unequivocal, yes”?
Like many good things, I have found that it can also become a bad thing. I now believe that there is a problem with the way continuous improvement is often approached - that can hurt companies in the long run.
The problem is that most continuous improvement is generally delivered through narrowly focused changes. These projects usually provide fairly immediate benefit – things get better in a narrow area of the business – a problem is fixed.
That is obviously good.
However, I have found that the combined impact of multiple localized small improvements can be negative. This negative impact happens slowly and is often not associated with improvement projects – each, in itself, was good.
Are you sure your ‘improvement’ isn’t causing disruption somewhere?
The problem is that over time these localized improvements can deliver results that actually conflict with one another in a workflow or a process. Also each improvement will have a direct impact (good) and an indirect impact (maybe, bad) that is seldom considered. Both types of impact will have a ripple effect on the business, the way people do work and the way information systems support business.
The fact is that most changes are either just made to the business or made through more formal focused changes to IT systems. They are made to help the requester and to be fair, IT applications changes are often analyzed to see if they will cause problems with the application and to see if the change will impact other applications.
However, business changes are seldom analyzed for their impact on other business units or to the way a company works with internal and external collaborative partners.
Unfortunately, time has shown that even small changes can each cause disruptions in the way work is performed. These small changes are usually ignored. People just make do and get by. But these individually insignificant disruptions add to create a growing imbalance in the business operation – the way people work and in the way applications and data are used.
This imbalance can eventually seriously impair operational effectiveness and efficiency, and compliance with regulation. It can also require the addition of manual work to make the workflow function at an acceptable level of performance.
This is an inevitable slow evolution to operational mediocrity.
Any business operation will have some elasticity and be able to absorb a certain amount of change. I find that this is generally related to the creativity of the business area’s managers and the flexibility of staff in adjusting to changes. But there comes a point where elasticity is exceeded and the operation starts to become ineffective and inefficient.
I refer to this point as “operational thrashing”.
Works gets done, but it is a messy process. However, reaching this point happens slowly and it is often not noticed until staff needs to be added or quality becomes an issue.
If this is allowed to happen, continuous improvement can yield less than favorable results.
What makes continuous change dangerous?
Every company is changing continuously. Like taxes, no one can avoid it for long. The issue is that much of the change is unplanned, focused on a specific issue, and meant to get around problems caused by such things as other changes in the business unit, work volume increase, IT support deficiencies, regulation changes, reporting requirements, and the effect of changes in other parts of the business.
These changes just happen and they happen every day. Do they improve the operation? Arguably they do since they get around problems. Do they introduce inefficiency and ineffectiveness? Yes, they do. Are they destructive? Yes, they are. But, are they needed? Yes, they are, since the company would have many more problems without them.
The real issue is that they are uncontrolled and while they are needed, they can introduce quality problems into the operation. While these changes lead to operational issues, introduce manual activity, and lead to error, they are necessary and they will be necessary until technology finds a way to support very rapid, low cost, low impact business change.
Add to this somewhat chaotic change environment, the ripple effect of planned narrowly focused improvements. While these small projects each provide some benefit, the project teams usually pay little attention to upstream or downstream workflow or process impact. This adds to an accumulating impact that will eventually ripple through the operation as a growing inefficiency.
BPMS supported BPM is a step in the right direction, but it requires set up time and investment. However, once in place it does deliver low cost rapid change. But even using BPM, if changes are still focused on isolated issues they will still introduce minor inconsistencies. When taken together, these inconsistencies will still eventually result in a slow degradation of performance. I call this the “mediocrity cycle”.
Unlike unplanned change, most planned and managed changes are the foundation for a company’s continuous improvement effort. When applied in an ongoing manner, they are in fact beneficial and continuous.
But - the infamous “but”! - when they are narrowly focused and fail to consider the real impact of the changes on other parts of the work and on other parts of the business, they will begin to change the work in unthought-of ways.
Scope is the king in these projects. Budgets are tight and only absolutely necessary work can be applied included in the project – so as little as possible is really changed in any project. That is the problem.
Scoping Consideration
This scope limitation issue can be a real problem. This is different than the inclusion of additional “unnecessary” business areas or work to the scope needed to make the change. It is also different from the “taboo” issue of “scope creep” – the constant addition of requirements or considerations to a project once the scope has been agreed upon. But with BPMS supported BPM any scope requires more flexibility than the notorious “freezing” of requirements while the solution is built. So a new perspective is needed.
To avoid this scope creep, most improvement projects are performed in the same manner as if the project manager had “blinders” on.
For younger readers, “blinders” were put on horses – those things we see on either side of the horses eyes. Their purpose was to stop the horse from seeing anything but what is straight ahead – they limit the field of vision or scope of vision. The horse cannot see to either side so it just keeps moving forward. Project scope is the same idea. It limits what the project manager can look at and stops him or her from straying to either side or outside their field of vision – so they keep moving down the prescribed path.
But sometimes that causes problems. Without being able to see to either side, accidents cannot be avoided and it is easy to set up conditions for problems that will happen in the future. In doing this, they can drive unintended consequences in other areas – the ripple effect.
The fact is that nothing in any company works in isolation. Everything is connected and every change in one area can cause changes to work in other areas of the business. However, these connections are not always apparent and finding them often requires an analysis of workflow and connections across organization boundaries. This takes investigation and analysis time – and time is one thing that is in short supply in most projects. So this investigation is one of the things that are often dropped from consideration.
But is it really optional?
Now please don’t misunderstand me. I am not saying that scope definition is a bad thing. I am simply saying that the scope should be adjusted to include consideration for an analysis of both upstream and downstream impact for any change in the process and its workflows. Why? Because it is these impacts that introduce operational issues outside of scope as some actions/input/rules/deliverables are changed. So is this consideration of such a low value that it should be optional?
Natural degradation of processes
The fact is that even small changes chip away at the validity of business rules/performance standards, the ability to monitor compliance, and the ability to be both effective and efficient. That is just a fact.
The reason is that a process is normally tens to hundreds of tasks long. Each process often involves multiple business units and many are complex. Even many workflows within a process can be long and complex. When anything changes, the change will impact the way work is done – that is why the change is being made. You want a positive impact. But aside from delivering the list of requirements and declaring success, what impact has the change really had? That is usually difficult to answer. It is also a question that is seldom asked.
Unfortunately, many business processes and workflows have little, poor, or no documentation. So accuracy in identifying everything that should be impacted by a change is often based on a guess. I believe this fact makes the type of change control that I am advocating challenging and in some cases, costly.
That is why any consideration of increasing project scope to include an impact consideration is not a trivial matter.
Controlling change
As noted above, unless the ripple impact of changes is controlled, sooner or later the result is that the business operation will reach a point where it must undergo serious redesign. This was recognized in the Business Process Reengineering move of the 1990s.
It was broadly recognized that work was inefficient and often ineffective. Much of it was manual and the reason for many of the activities that were being performed had been lost. The result was the call for “radical transformation”. Some even said you needed to start with a blank slate and redesign the business from scratch.
Of course that didn’t work well for a lot of reasons, but it did recognize that change must eventually be looked at from a broad and holistic perspective.
From recent history, we know that many who “reengineered” found that inefficiency was creeping back into the operation or had already crept back into the operation. That was one of the real reasons behind the recognition that companies needed to adopt continuous improvement – trying to avoid this creeping degradation.
That was a great move and brought in a lot of advances – like Lean and Six Sigma. But we are still seeing ineffectiveness and inefficiency creeping back in and we have to ask why it is happening. Looking at that question is what this column is really all about.
So while we have come a long way down the path to continuous improvement, I think we have a long way yet to go. We need to find a way to get rid of the “mediocrity cycle”.
One of the first steps may be to include ripple evaluation in all projects. (But that may be hard to justify due to the time and resource cost.) A second step may be to reevaluate the efficiency and effectiveness of processes and workflows on a given cycle to “adjust” them and better integrate all the business, legal, financial, and IT related changes that have been made over the time of the cycle. This cycle, should not, however, be in years. It should be done at least annually and every six months would be better.
But to do that will require a cultural change as the business areas would need to be tasked with this workflow model update. That is possible, and what should really happen, but it is not going to be an easy sell to overstretched business managers.
Culture is key
Continuous Improvement is not simply an IT or process issue. All activity eventually comes down to people. Any move to consider continuous improvement and the cultural changes noted above requires that people from all areas and from senior officers to line managers to factory workers, need to be engaged. It also requires that people be dedicated in different aspects of a comprehensive program that evaluates ongoing change for its impact on other parts of the business or IT operation.
This is the hardest part – just as dealing with culture is the hardest part of any program. Why? Some people will accept, some will reject, some will fight, some will sabotage, and some will just ignore.
As a general rule, most people resist change in some way. This is especially true when it affects something they are evaluated on – everyone hates being evaluated. When people have been successful with the way things are done, they will naturally be afraid of moving to a different way – after all, they may not be successful in the new way.
For this reason, any move to include ripple impact evaluation in a project’s scope relies on the participation of the people who will be involved. Control over the perception of this evaluation is critical and will make or break this type of review. Formal human resource change management is thus important and should be a long term consideration in most companies.
The fact is that if people perceive that they are being judged, they will be much less cooperative. Culture thus plays a critical role in both continuous improvement and in any type of operational ripple evaluation.
What can be done?
It seems that there are different responses that can help, but the foundation is the first step. That is to accept that ongoing change, regardless of what it is called, is immediately good, but that unless controlled, can have a negative cumulative impact both upstream work (making it no longer needed or the products no longer optimal) and downstream work (changing what is provided).
Once this concept is accepted it can be dealt with. I have offered a couple of suggestions – scope inclusion, cyclic operational review, but there are other approaches that will work. The key is that attention be paid to the cumulative impact of small changes on the broader workflow or process and the solutions adjusted as needed to eliminate the potential of causing upstream and downstream problems.
However, in any approach that is taken to deal with this issue, manager/staff perception and corporate culture must be honestly considered. If the approach to dealing with this is not accepted or if people feel threatened, the approach will fail. For this reason, people are the key to implementation and should be included in the design of any actions that are built to help eliminate this cumulative impact from the ripple effect of small changes.
Next month I will introduce you to a new concept first reported by Jim Sinur of Flueresque (formerly of Gartner Research) called Wagile pronounced “Wag-l“. It recognizes that neither the traditional Waterfall approach to change nor the Agile approach really fit well with BPM/BPMS driven improvement. Wagile, is the result of putting the best parts of both approaches (from a BPM/BPMS perspective) together. Please look for this discussion and see Jim’s blog at (http://jimsinur.blogspot.com/2013/09/new-book-on-next-wave-of-business.html).
But what do you think? Do you agree that continuous improvement is not always beneficial?
0 comments:
Post a Comment