(Part One in a Series)
We live in a world of instant gratification and quick fixes. In business, competitive pressure escalates relentlessly. Money’s tight, time’s limited, and everyone’s impatient. Regardless of the country or culture, business leaders’ prevailing attitude is to hurry up and get working on the fix. Any action is better than no action. We can afford any waste that results from our haste. The end is certain to justify the means. We’re too big to fail. This time it’s different.
That’s why, when it comes to defining software requirements, or embarking on any type of process improvement initiative, focusing on today’s situation isn’t considered a good use of time or resources. On nearly every project I’ve worked on, I encounter some resistance toward the work of defining the “as-is” or “current state” of processes. Sometimes resistance comes from the project sponsors. Sometimes it comes from process owners, process managers, and other subject matter experts (SMEs). And sometimes it even comes from project managers and business analysts within the project team.
Too many process stakeholders think they know the full breadth and depth of current state issues and problems. They think know how and why those problems started and why they persist. Too many meetings, discussions, and E-mails have beaten the horse to death. Many times, organizations are so sure of the problems – and the likely resolutions – that money has already been spent and resources have been deployed to start working on the resolution. All resources and activities are focused on the future, on the great vision of the fully-optimized future state. Devoting any more time and effort to the current state is analysis paralysis. “We’ve survived this long, we can survive a little while longer,” is the tragic belief.
However, the current state is always in a lot worse shape than anyone realizes – or might be brave enough to admit. And it’s not likely to change any time soon, regardless of how aggressive the transition plan is. Unless the entire organization (not just a few change management “gurus”) has a lot of experience in successfully implementing large-scale business model or process changes, the odds are stacked against this project finishing on-time, within budget, and with results closely meeting or exceeding expectations. Realistically, few organizations can claim organizational change as a core competency. Sadly, for most organizations, it’s a core incompetency.
From this perspective, it means that anytime is a good time to model the current state. That’s because current state processes have problems currently causing customer dissatisfaction, waste and lost profitability. Until the future state is reached, these problems will persist. In reality, there are plenty of reasons to model current state. In addition to simply being a means for identifying improvement opportunities in general, the following lists more reasons to justify defining, modeling, and documenting current state:
A. You Know a Lot Less About the Current State than You Think You Do
B. Your Process Stakeholders Know a Lot Less than You Give Them Credit For
C. You Need to Stop the Bleeding Today
D. You May Not Live to See the Future State
E. You Need a Baseline for Measuring Progress and Return on Investment
F. Process Stakeholders Need and Want a Change Roadmap
G. Your Current State is the Future State
H. Some Things Can’t be Changed – What Might They Be?
In subsequent posts, I’ll take an in-depth look at each of these reasons.
Pingback: Your Process Stakeholders Know a Lot Less than You Think | The Business Process Improvement Journal
Unfortunately I see the same thing.I usually use an analogy to coaching. We can’t improve someone’s performance without analyzing that performance. I then ask why you would risk your business by not applying the due diligence we would in coaching an 8 year old child? Doesn’t always work, but “due diligence” is a wonderful phrase.
John,
Coaching is a great analogy! I’ve seen a good example of it this week at the gym where I work out. I’ve been watching a personal trainer work with a new client of his. The very first thing he did was take his client around to all the weight machines and have his client try 10 reps at each station – using the heaviest weight the client thought he could complete 10 reps with. The trainer actually used the word ‘baseline’ when describing the purpose of that exercise.
There are so many reasons to document the as-is, and you’ve laid great reasons in your post. Of all the questions I’ve asked on LinkedIn and other forums, none has garned more passionate responses than, “How much time should be spent documenting the as-is”. The replies ranged from “NONE!” to “Why would you want to capture what you’re doing if what you’re doing isn’t good enough?” I agree with what you say that there’s no way to adequately know what you really have (and it probably is quite bad) and to know what to keep and what to throw away without a real inventory. It doesn’t have to be analysis paralysis, but there needs to be an inventory of processes, actors and contextual information. Without it, the risk of significant disruption for a host of reasons is high.
I touched on this topic in my own post: “Leather boots and other acquisitions. http://bpmforreal.com/2011/04/18/leather-boots-and-other-acquisitions/
Thanks for your comments Chris. In your “Leather Boots and Other Acquisitions” post on your Blog, your perspective on acquisition ROI is particularly interesting. I’ve always suspected that most acquisitions happen without in-depth process analysis. It’s refreshing to hear about those who deliberately do take a process-centric approach to integrating organizations.
Pingback: What’s Your Process Intelligence Level? | The Business Process Improvement Journal