(Part 2 in a series.)
In part one of this series, I listed eight reasons to justify modeling current state processes. I addressed an argument that often comes up when working on software development or process improvement projects.
A lot of times, organizations are in a big hurry to get moving with a solution. They’re convinced that spending time on defining current state is a waste of time. They believe they’ve already identified the root cause of their problems and want to hurry up and get started on what is usually a hastily decided solution. And that, unfortunately, usually involves premature capital spending on technology.
In this rush to nirvana, it’s often a rush to fix the wrong thing. Thus, time and money is wasted, the real problem never gets solved, and often, the real problem is intensified. In other words, they pay too much for something they should not have bought in the first place.
In situations where I’ve either been given the opportunity to focus on understanding the current state, or have been able to carve out time without impacting the project schedule, I’ve never worked with a manager who had a comprehensive, in-depth, and completely accurate understanding of all the processes they were responsible for. At the very least, an in-depth understanding involves knowing:
• Every discrete process within their management domain
• The qualifiedly and quantifiable goals and objectives of each process
• The qualifiedly and quantifiable inputs to, and outputs from, each process
• The exact sequence of steps taken during the execution of each process
• The specific resources (human and/or machine/computer) responsible for executing each step
• The precise data that must flow within each step
• The acceptable speed or rate of effort expended in the performance of each step
In some cases, I’ve worked with managers who knew a lot of the above information, but never have I worked with one who knew it all at the levels described above – at least at first. In every case, it didn’t take long for the manager to realize that the first step in process improvement was to improve his understanding of the processes within his scope of responsibilities. Many times, I’ve been initially engaged on a project to help a manager train his employees to improve their process execution competency. In order to train the people, I needed to know the level of detail listed above. When I’d begin to ask the manager for this information, that’s when we would both begin to realize how little the manager actually knew. But to the credit of nearly every manager I’ve worked with, they were quick to admit and accept this knowledge gap, and equally as quick and enthusiastic about accepting personal responsibility for closing the gap.
If you’re a process manager and want a method for testing your own level of Process Intelligence, follow the instructions below. While this quick self-test can’t compare to a full-blown, formal process management maturity assessment, it can give you an initial idea of the gap you’re facing. If you do want to take it step further, simply use your favorite Internet search engine to search for the phrase, “process management maturity assessment” and you’ll find links to some assessments. Or, you can follow this link to download a preliminary draft copy of my extensive process management assessment spreadsheet.
PROCESS INTELLIGENCE QUICK SELF-TEST:
a. Time yourself on this one. Take out a piece of paper, and as fast as you can, make a list of every process you’re responsible for. If you can’t do it within about 15 second or less, that’s not good.
b. Compare your list to the Process Classification Framework. See how many you forget or should have more granularly identified.
c. For each process you manage, list at least three specific, quantifiable measurements. Allow yourself no more than 5-10 seconds for each process.
d. For each of those measurements, define the specific situations, times and places where you deliberately and consistently measure them.
e. Think back to your first day on the job as the process manager. Did you begin measuring on Day One? If not, when did you start? How does today’s performance compare to your Day One measurements?
f. Within ten seconds, can you access all the current, accurate documentation that exists for all the processes you manage? Do you think everyone else on the team can? What makes you so sure?
g. For each process, make a list of every single “data object” that participates in the process.
h. Then, for each of these objects, list their individual elements. (For example, an Invoice is a data object. Elements of an Invoice are things like the Invoice number, the date, customer name, line item, price, discount terms, etc.). Remember, most business processes involve data processing, which includes creating or inputting new data, recalling or reading stored (existing) data, changing or updating existing data, and sometimes, deleting data.
If you can breeze through the above list with ease and accuracy, you might just know enough about your processes to effectively start looking at the future state instead. But that would only be if you don’t expose an existing process problem that requires an immediate, temporary (or permanent) resolution. In any case, if you can’t breeze through the above list, there’s a strong probability that your “solution” will take a lot longer to realize, will cost much more than it should, and won’t likely fix the problem to the degree that you’d hoped for.
Pingback: Your Process Stakeholders Know a Lot Less than You Think | The Business Process Improvement Journal