My last Column closed with a theme that, without really planning it, has been central to my recent workshops and conference sessions:
“Simple (not simplistic!) techniques,
rigorously (not rigidly!) applied,
help you accomplish a lot in a (relatively) short time.”
That phrase “accomplish a lot in a short time” is at the heart of this. As I've noted before, the greatest single change I've seen in my 30+ years of consulting isn't technology, strategy, or even methods. It's the incredible pressure on time. Getting much more done in much less time is now a baseline assumption – “90 minutes is the new day” has become my mantra. Using the scoping models that have been a feature of recent Columns as a jumping-off point, this Column will describe some time-effective ways to assess a business process.
Background and Overview
I love what I do. I get to work with smart people, learn about new kinds of businesses, all in nice destinations around the world. Learning new techniques from consulting clients and workshop participants is a highlight. Sometimes it's a method that's completely new to me, other times it's an interesting adaptation of techniques I've shared with a client. This Column is a result of the latter.
Earlier this year, a client in higher education combined techniques I'd showed them in a new way – they used the subprocesses of a process scoping model to organize the issues and goals of a process assessment. It was so well received and time-efficient, and seemed so obvious in hindsight, I had to ask myself why I'd never done it that way. No problem – I will in future! In fact, I already have – I'm describing the Continuing Education example that closed the May 2014 Column (a link is coming up,) and prompted this Column on using simple frameworks to conduct a holistic assessment of a business process.
A reading assignment
Two previous Columns on the use of process scoping models laid the groundwork for the ideas in this one, so you might want to check them out:
- “What's In, What's Out? Thoughts on Scoping Models”
April 2013 http://bit.ly/11qjuhJ
This looked at TRAC (Trigger, Results, Activities, Cases,) a framework for a Scoping Model that works exceedingly well for clarifying the essential (what, not who or how) scope of a business process;
- “Using Scoping Models for Process Analysis –
Fast Results for a Hurry-up World”
May 2014 http://bit.ly/1ht0cy2
This looked at using a Scoping Model as the framework for detailed but time-effective analysis, especially when there just isn't time for process mapping/modeling.
Assessment within an overall methodology.
Moving on to assessment, the subject of this Column, let's look at where it fits within an overall methodology. I divide business process analysis and design into three phases:
- Establish process scope, issues, and objectives, which I also refer to as “framing the process” because it establishes the framework for all subsequent activities;
- Understand the as-is process (assuming there is one) which typically includes mapping the process (building a swimlane diagram or something like that);
- Characterize and design the to-be process.
Before those three phases is selection of a process for attention, and after is implementation, so you could look at these as the middle three of a five-phase methodology for a business process change initiative.
A methodical or structured assessment happens twice during those three phases, as illustrated by Figure 1.
We perform an initial assessment by stakeholder during phase 1, after process scope is established but before we get into modeling, mapping, or other forms of analysis in phase 2.
The second, a final assessment by enabler, spans phases 2 and 3. It is the last part of understanding the as-is, and the beginning of designing the to-be, so it's a transition activity that doesn't fit entirely in one phase or the other.
I refer to these assessments as methodical or structured because they happen at specific points in a methodology, and are structured around a framework – stakeholders in the initial assessment, and enablers in the final assessment.
To be sure, these aren't the only two points at which some sort of assessment is done.
- During the mysterious selection phase there is presumably some sort of assessment and prioritization of candidate processes to determine which one(s) to focus on next. In my unfortunate numbering scheme, that ends up as phase 0. Not very inspiring, but unintentionally accurate, because it often doesn't actually happen. That will be the subject of my next Column.
- During phase 2, understand the as-is, there is ongoing assessment. While modeling/mapping the as-is process, we constantly capture observations about what is right or wrong with it. Many of these observations are due to keeping an eye out for issues highlighted during the initial assessment.
- During phase 3, design the to-be, we assess individual improvement ideas and process characteristics, which I'll cover in a future Column (or series) on the mechanics of process design.
The real benefit of these assessments
Both these structured assessments are important in ways that might not be immediately evident.
- The most important outcome of the initial assessment isn't just a problem statement – it's broad-based support for the change initiative, and stakeholder-specific goals for the new process.
- The final assessment doesn't just identify root causes of process issues – it generates ideas for the features and characteristics of a better process.
In both cases, following a clearly defined framework enables participants to recognize problems, often significant problems, they would have missed without a framework forcing the examination of specific factors.
In this Column I'll focus on the Initial Assessment, with just a quick reference to the Final Assessment. Not that the Final Assessment isn't crucial – it is! – but I covered it in detail in an earlier Column – “Disabled by Enablers, Punished by Rewards” May 2012 http://bit.ly/1dtrecb
The Initial Assessment
If you're a Business Analyst, ” Whaddaya want?” is okay as a starting point, but eventually you have to take a more organized look at the current and desired situation. It's the same for a Business Process Analyst – “What's wrong with this process?” can get the conversation started, but a more organized approach will yield a richer understanding of the situation. It will also, perhaps surprisingly, save time, if only because you won't go around in circles or keep revisiting issues.
Origins of this format
The initial assessment is also called a “Case for Action,” a framework I first learned over twenty years ago in Hammer and Champy's classic “Reengineering the Corporation.” “Case for Action” is an apt name, because what we're really doing here is making a compelling case for change for taking action on a specific business process. On first reading it, I was struck by how the five questions in the Case for Action provided a richer and more nuanced basis for getting an initiative underway than the typical problem statements that were (and remain) common practice. Rather than getting everyone's back up with a litany of problems that could be construed as criticism, the Case for Action was designed to put problems in a wider context and thereby take the sting out of what could otherwise be seen as criticism. It seemed more likely to build support for change, which was, after all, Hammer and Champy's intent.
The framework for their original Case for Action covered five points:
- Business context:
What is happening, what is changing, and what is newly important in the environment in which the company operates?
- Business problem:
What is the major concern of the company? (Substitute organization or enterprise for company, if it's more appropriate.)
- Marketplace demands:
What new performance requirements can't be met by the company?
Why can't the company meet the new performance requirements? Why is incremental improvement not enough?
- Cost of inaction:
What are the consequences of not reengineering?
As we'll see, I simplified and reordered the points, but I give full credit to the original Case for Action for the excellent results I've had over the years – it's become one of the five cornerstones of my business process change practice. (Hmmm… Five Cornerstones – sounds like a potential Column.)
Years after learning and adapting Hammer and Champy's framework, I noticed some parallels with the work of John Kotter, who wrote the definitive 1995 guide to “Leading Change.” The initial assessment is all about encouraging support for a change effort, so a quick look at the guru's work seems appropriate.
Kotter's approach is described in eight steps – here's a simplified explanation of what each means:
- Create Urgency:
Help others see the need for change;
- Form a powerful coalition:
Assemble a group with enough power to lead the change effort;
- Create a vision for change:
Create a vision and strategies to help direct the change effort;
- Communicate the vision:
Make sure as many as possible understand the vision;
- Remove obstacles:
Change systems or structures that seriously undermine the vision;
- Create short-term wins:
Achieve successes that can easily be made visible and reward those involved;
- Build on the change:
Use credibility to change systems, structures, and policies that don't fit the vision;
- Anchor the changes in corporate culture:
Articulate connections between new behaviors and organizational success.
A simplified form
Kotter's framework has eight parts, Hammer and Champy's has five, and my simplified form has three questions. Here it is:
- What problems in the process are felt by each stakeholder group?:
A factual, unexaggerated, focused look at each stakeholder group's issues – makes it real;
- What changes in the environment caused these problems to surface?:
An identification of factors beyond our control that led to the problems – makes it blame-free;
- What are the consequences of inaction?:
An assessment of the likely outcome of taking no action on the process – makes it compelling.
Both the original Case for Action and my adaptation end by asking “what will happen if we maintain the status quo?,” which is intended to make change highly desirable – even urgent – compared to the alternative. Kotter's Eight Steps begin from this point – creating a sense of urgency – because it is more focused on implementation of the change than making the case for it.
The sequence of questions is just as important as the questions themselves. The intent is that they build up to the point where stakeholders, principally the people who work in and manage the process, realize “there are real problems with this process (question 1,) and they aren't really my or anyone else's fault (question 2,) but I'd better get on board with process change because the consequences are very unappealing (question 3.)” Change the order, and it just doesn't work as well. Relative to the original Case for Action, I combined points 2 and 3 into “what problems…?” and eliminated point 4 (diagnostics) for two reasons:
- Experience kept showing we can't accurately diagnose problems until more is known about how the process really works. Those early diagnoses often turned out to miss the mark widely, but people still felt attached to them. That's the same problem I see with the traditional problem statement – until a holistic, cross-functional look is taken, it's premature to diagnose the problems;
- On several occasions, stakeholders would see the diagnosis and ask, quite rightly, “If you've already figured out the problem, what do you need my time for?” In some cases, especially where we needed the participation bargaining unit members, the reaction was very negative – “So, it looks like the fix is in – management's already figured out the problem and they just want us to go along for the ride.”
Let's take a look at each of the three questions, and why they are important.
1 – What problems in the process are felt by each stakeholder group?
This is analogous to the traditional problem statement, except that it is made much more effective by explicitly considering each stakeholder or stakeholder group independently. This is a simple example of the power of a framework – by focusing on one specific “cell” or aspect of the domain at a time, people inevitably surface points that would have been missed otherwise.
Virtually every process has customers, performers, and owners/managers as stakeholders. The customer is the person or organization that receives the primary result (output) the process is intended to deliver, the performers are the people and organizations that do the work of the process, and the owner/manager is, essentially, the enterprise itself – the “operator” of the process. Other potential stakeholders include the regulator, industry or trade associations, the community, suppliers, and so on.
Whether you're doing this in one-on-one interviews, or in a facilitated session, here are some ideas for the questions you might ask:
- Does the process actually deliver what you want?
- Are there too many interactions?
- Are rules and requirements reasonable?
- Can your work be located within the process?
- Are you the “human glue” that holds the process together?
- What are your major sources of frustration?
- Do you have the necessary tools and support?
- Are there steps that serve no purpose?
- Are problems caused upstream? Are you constantly correcting or redoing earlier work?
- Does the workload vary wildly?
- What would you change if you could?
- Is there a documented process?
- Does the process use resources that would be better allocated elsewhere?
- Is it a net contributor or a source of problems?
- Does the process constrain innovation, growth, or market opportunities?
- Does the process provide information for managing it?
- Did the process earn your organization an unflattering segment on a consumer affairs TV show? This actually happened in not one, but two recent engagements. When we tied the very public eroding of brand image to very specific process failings, it had a marvelous focusing effect on the C-level mindset.
All of these perspectives are important, but we place special emphasis on the Performers. Why? Well, the organization itself (as represented by the owner/manager) tends to be pretty good at looking out for what it wants. And we hope they're also very concerned about the customer – who isn't? The performers, however, are often not explicitly taken into account, which can be a disaster for process change. Who, after all, is most impacted by change? The performers, of course – the people who do the work. So, we must honestly identify the pain felt by each performer, like the long-suffering Customer Service Rep who bears the brunt of the customer's dissatisfaction, if we are to enlist their support in making what could be major, job-altering changes. If they don't see “what's in it for me” there is a real chance that change efforts will be undercut.
I've learned to also look for the positives, and discover what it is (if anything) about the current process that each stakeholder group appreciates and would like to see preserved. For example, customers (advertisers) in a print advertising process had a litany of complaints, but we didn't want to lose sight of the fact that they really appreciated the cost-effectiveness of this particular channel, and the demographic groups it was able to reach.
This assessment gives us an idea what to look out for during process mapping or detailed analysis, although it shouldn't bias it. It also gives us an idea what goals each stakeholder might have for a redesigned process. Returning to the print advertising example, customers were frustrated by the number of in-person meetings that were typically required (three) to get an ad published, and by the long lead time between initial sales contact and ad publication. Two important customer goals for a process were therefore:
- A less “high-touch” method for placing ad orders, including a “no-touch” option;
- A shorter lead time between initial contact and ad publication.
These are subjective statements – we also try to establish objective measures where possible. For instance, the second goal might lead to the more objective “The lead time from initial sales contact to ad publication will be reduced from the current ten days to five days within three months of process implementation.” This is stated using the “Topic-Target-Timeframe” (TTT) format we find more useful than the oft-cited “SMART” format (Specific-Measurable-Achievable-Realistic-Time-bounded.) SMART is aspirational, but TTT forces the statement of specifics.
This assessment must be factual and unexaggerated – this is not the time for bombastic overstatement. No matter how factual, though, it can lead to some discomfort, a sense that “hey, we're not THAT bad.” The power of the next question is that it can defuse these feelings.
2 – What changes in the environment caused these problems to surface?
The idea here is to demonstrate that the problems in the process would not have arisen if it weren't for changes beyond anyone's control in the wider business context. People might be uncomfortable with the problems surfaced in question 1, but we take the sting out of it here in question 2 by establishing that the process was (probably) perfectly fine, and would have continued to be, if it weren't for changes in the environment. As an example, many processes I've worked with in the financial services sector were perfectly adequate until the regulatory environment changed after the global financial crisis of 2008. Compliance and Risk Mitigation moved to the fore in processes that simply weren't designed with those in mind.
Here's my “Top Ten” (actually, eleven) list of topics to consider when assessing changes in the environment:
- Changing customer expectations
- Regulatory change
- Competition, especially new or emerging
- Workforce changes (e.g., supply or retirement)
- Economic conditions
- Socio-political change
- Change in business model (e.g., customised or standarised offerings)
- Change in business ownership (public, private)
- Emergent or disruptive technology
- Changes in business volume (up or down)
- Changes in business operating locations
For a more detailed list of questions to consider, do a search on “PESTLE” (Political Economic Social Technological Legal Environmental,) a widely used framework for assessing the state of the environment.
At this point, a sensible reaction would be “Well, the process is definitely broken, but it isn't my fault, so why worry?” Next, we'll establish why “worry” would be an entirely sensible reaction.
3 – What are the consequences of inaction?
The question here is stark: what will happen if the process is left as-is, and the status quo is maintained? Specifically, what are the consequences to individuals, their organizations, and the enterprise as a whole? A cynical observer might think people would only care about personal consequences, which they certainly do, but experience shows people care, often deeply, about the well-being of the enterprise they work in.
Note that you absolutely have to do question 1 and question 2 first. Question 1 establishes there are real problems, and question 2 opens up people's thinking by reinforcing that no blame is involved. This sets the stage for an honest assessment.
The ideal situation, in terms of generating support for change, is to first demonstrate serious, negative consequences for all concerned. In our experience, the consequences of inaction range from “the demise of the organization and significant job” loss through to “no impact whatever.” If there really is no consequence to maintaining the status quo, it's time to look for a new project.
A quick example
There's nothing like a real-life example to illustrate a technique. Here's one, summarized, from one of the first times I used this framework.
A large manufacturing company (the world's largest in their decidedly low-tech sector) had hit the wall with attempting to redesign its core financial reporting processes prior to implementing new systems. No progress was being made, and the project had descended into “the blame game.” At the time, most of my consulting work was helping to get runaway projects and stalled projects back on track, and this one was no different. The CFO asked if I could come in for a few days and (a) figure out why progress was stalled and (b) get the thing moving again.
In situations like this, it's always useful to go back to scope and objectives, and the Initial Assessment provided the perfect framework for this.
1 – Stakeholder assessment
- Customer – The investment community, specifically financial analysts and fund managers, could not get the information they needed in a timely fashion for guiding investment advice and decisions;
- Performers – Finance staff spent all their time on mechanical aspects of assembling “the numbers” with no time for value-adding analysis;
- Owner/manager – The CFO was under constant pressure and criticism from other executives, notably the CEO, because of increasingly public criticism of the firm's inability to provide information to the market. This was jeopardizing the firm's plans to float a bond issue that would raise capital for a vital expansion.
2 – Context
It seemed incredible to me that the organization had survived and prospered for so long in the face of these problems. Of course, it hadn't faced these problems forever, which is the whole point of examining “context.” When I asked the group if there had been any significant changes in their environment, there was (as usual) some hemming and hawing and casting about. Eventually, though, someone ventured “Maybe the divestiture had an impact…?” Zeroing in on this quickly surfaced the three key factors:
- For close to 80 years, the firm had been part of a huge, multinational conglomerate. Its financial reporting processes were entirely designed to report results, at a leisurely pace, to Head Office.
- The firm had recently been divested, and was now an independent entity, publicly traded on the stock markets.
- The key point – financial reporting was now expected to serve the financial markets, which the processes were never designed to do.
3 – Consequences of inaction
This is the point at which everyone became somewhat wide-eyed at the likely outcome if the current situation wasn't addressed:
- The inability to provide timely information to the financial markets had led to a lack of support for the new bond issue, which in turn was impeding the planned (and much hoped-for) acquisition of a competitor. That acquisition was the centerpiece of the firm's expansion plans.
- If the acquisition attempt was unsuccessful, the reverse was almost inevitable – the firm would surely be acquired by the competitor. Uh-oh… The likely consequence, obvious to everyone in the room, was that not only would their company cease to exist, their jobs would ease to exist.
To say this focused everyone on the need for change would be an understatement. And that, after all, is the point of the Initial Assessment.
The Final assessment by enabler
After process mapping or other analysis methods, much is known about how the process currently operates. Now, it's time to consolidate what's been learned, and ensure completeness, by forcing the consideration of the process with respect to each of the six enablers of a business process. As noted earlier, the use of the “six enablers” framework is described extensively in a Column from May 2012, so I'll just provide a recap here.
Process enablers – an overview
An enabler is a factor which can be adjusted to impact – positively or negatively – the performance of a process. “Adjusted” might be a bit charitable in terms of the as-is process. More often than not, we find these factors weren't explicitly “adjusted,” or even consciously considered – they just happened, or evolved, or mutated over time. That's why I used to joke that “reengineering” was a misnomer because it implied the process was engineered in the first place.
The six enablers are summarized in Figure 2. I often label the first two, Business Process Design and Information Systems, as “the usual suspects” because they typically get the most attention. The next three are highlighted because they don't always get the attention they deserve, but are usually the most significant in terms of understanding why a process underperforms.
As I observed in that earlier Column, my six enablers are very similar to Roger Burlton's hexagon – we developed them independently, at around the same time in the mid-1990s, and were both a bit surprised when we saw how similar our approach was.
Why we really do process mapping
The reason for process mapping is often misunderstood, a predictable outcome of it often being misapplied. Too often, process maps descend into excruciating detail, documenting rules and logic that have no place on a business-oriented flow model. No wonder people conclude that “rules and logic” are what it's all about.
To me, the reason we develop a process workflow model or swimlane diagram it is to develop a fact-based view of the process we can use to organize an enabler-based assessment. Detailed rules and logic just get in the way of that. What's most useful is a graphically simple “boxes and lines” diagram that shows “who, does what, when.” It doesn't descend into the details of how they do it; that's better documented in other artifacts like procedures, use cases, service specifications, business rules, and so on. As a mechanism to keep the diagrams simple, I'll often develop multiple diagrams, each illustrating a particular case or scenario, rather then produce one “master diagram” showing every alternative and permutation.
With these process maps in hand, we can guide the stakeholders through an assessment of each enabler, considering the following:
Is each step adding value, placed at the right point in the process, sequential or parallel as appropriate, etc.?
Are the process, the steps within it, and the actors supported by the right technology?
Motivation & Measurement:
How is the performance of steps, actors, participating functions, and the process itself measured, and is that appropriate?
Human Resources & Organization:
Are the roles appropriately defined, staffed by people with the right skills, and deployed effectively within the process?
Policies & Rules:
What policies and rules constrain or are enforced by the process?
Facilities (or other):
Are the layout, furnishings, and equipment optimal or are they impeding the process?
Some typical questions to consider are summarized in Figure 3.
In an extreme case, I might assess each step independently according to all six enablers, but that typically isn't helpful. What's important is to “put the blinders on” and focus on just one enabler at a time. I'm always surprised at how much more complete an assessment is when this is done.
Another quick example
I was recently asked to review the work a process improvement team had done in mapping one of their organization's financial processes. The purpose was to approve (after the fact) an expenditure and ensure it was allocated to the correct account or accounts. They showed me the workflow model they'd developed, and I was extremely impressed they'd managed to get this done in a single 90 minute (there it is again!) facilitated session, especially considering some of the fractious personalities they had to deal with.
As for the process itself… well, it was unbelievable. It was excruciatingly sequential, included 19 actors, and in general looked to have come from a 19th century civil service in some remote outpost of the Empire. I asked the group, which included some of the performers, what they thought of the process now that they'd mapped it. Without dropping a beat, the reply came “Oh, it's actually pretty good. I mean, it must be, because it's worked this way for over 30 years.” I was stunned, and came close to using some inappropriate language, but that wouldn't accomplish anything. Instead, I asked the group if we could take a closer look at the process, considering it from the perspective of just one enabler at a time. Here's the gist of what they told me for each enabler:
- Workflow: “Well, when look at just that, you can see it's terrible. Each approval step is done strictly sequentially when that isn't necessary at all, and the process ‘yo-yos' back and forth all over the place.”
- Information Technology: “What technology? Our workflow is supported by color-coded Rubbermaid bins.”
- Motivation and Measurement: No thoughts just yet.
- Human Resources: “Our use of people is a disaster – just look at the number of senior people who have to get involved in trivial approvals.”
- Policies and Rules: “Also a disaster. The sequential, escalating approvals are dictated by policies that don't make any sense. In fact, many are “anecdotal policies” that don't really exist.”
- Facilities: “Are you kidding? We can't hire tall people because some of those bins hang from the ceiling.”
At this point, one of the participants said they had been thinking about Motivation and Measurement, and realized the motivation driving the process was all wrong – it was all about avoiding “audit points” rather than delivering timely service.
The point – a blanket “What do you think of this process?” let to some fairly uncritical thinking, but having the group focus on one enabler at a time – that is, use a framework – led to entirely different conclusions.
Just like the last Column, the recap is that we've demonstrated, I hope, that simple (not simplistic!) techniques, rigorously (not rigidly) applied, will help you accomplish a lot in a (relatively) short time. We've also seen that focusing on one aspect of the problem space at a time, specifically the stakeholders of a process and the enablers of a process, eliminates blind spots and ensures a more complete and accurate assessment.
It would be terrific if you shared your thoughts on this, and maybe some of the frameworks you've found valuable. Please take advantage of our new comments feature.
I presented twice at IRMUK's June Enterprise Architecture and Business Process Management Conference in London:
- A half-day workshop on running a process scoping and mapping session (a repeat of a “standing room only” session from the previous year) and
- A 50 minute session on how you actually design a new process (I must have been crazy to try to cover that in under an hour)
These will be the subjects of future Columns, but next we'll look at how processes actually get selected for attention. We'll see that practice diverges substantially from theory. After that, I'm going to get a little more organized. Over the past few years, I've shared a variety of techniques, but in a semi-random order. Reorganizing the Columns under the phases and activities of a typical assignment will make it clear what still needs to be covered.
In addition to a full load of in-house work, I have several public workshops and speaking gigs on the calendar:
- Nov 02-06 – Ft. Lauderdale. The Building Business Capability conference returns to Florida. I'll do a one-hour session on “How Do You Actually Design a New Process?” and a half-day tutorial on “Running a Successful Process Discovery, Scoping, and Mapping Session.” http://bit.ly/1r8mX3b
- Nov 10-13 – Indianapolis. I'll do a half-day seminar “Process Modeling and Analysis for Higher Education” plus two one-hour sessions on model-driven techniques at Kuali Days 2014 http://bit.ly/1oMUYAV
- Mar 02-20 2015 – I'm back to New Zealand and Australia for our “Advanced Business Process Management” class. Auckland – Mar 02-03 2015 and Wellington Mar 05-06. Stay tuned for Australia dates. http://bit.ly/1oMUYAV
I hope our paths cross somewhere. Probably, in an airport…
From the Trenches,