BPTrends – October 2009
Written By: Alan Ramias, Cherie Wilkins
In our last column, we described various approaches to process ownership that we have seen established, with varying degrees of success, in different companies. Our focus was primarily on the organizational position of the role (a senior executive, a staff, a line manager, and so on) and the amount of authority accorded the position (control of process design, process performance, or both, or neither).
This time we would like to describe what we have seen process owners actually doing in the performance of their roles. To some extent, of course, what they do is dictated by their position and authority, but not entirely, so we are presenting a different angle on the subject of process ownership. We will first describe how we have seen people carry out the role, and then offer some advice as to what we think they should be doing. We have organized these variations of the job somewhat by frequency – that is, we start with the tasks we have most often seen process owners doing and then go from there.
For the sake of simplicity, we are also restricting our descriptions of process ownership to a single owner of a single process. In reality, there could be multiple process owners in an organization who collectively view themselves as managing a network or architecture of processes, or we could have an owner who owns several related processes. All those possibilities are understood but left out of the following descriptions.
The Minister of Process Documentation
The most common preoccupation of process owners that we’ve seen in actual practice has been the creation and/or maintenance of process documentation. The purpose for having the documentation has usually been for certification – for ISO, CMMI, Baldrige, and so on. Sometimes, the documentation activity is a one-time event (we got certified and that’s it), but most of the time, verification or recertification is required, so the task becomes maintaining the documentation or refreshing it in order to survive the next audit. But, of course, depending on the resources available to do all this documenting and depending on their position in the organization vis. a vis. the “line” where the processes are actually performed, there can be an ever widening gap between the details of the process documentation and actual work practices.
The IT version of this role is creating and keeping documentation for systems. It is all about having a reusable set of documents that can speed the next project. Sometimes this is a way of avoiding going back to the SMEs actually performing the process, and, once again, the documentation may lose its authenticity. In addition, IT documentation of processes can be too focused on technology and user interfaces while missing other significant (but manual) parts of the process, so it is not always the best source of information for improvement efforts.
The Chief Watcher
Someone in this role collects and reports process performance to whomever is supposed to be managing the work. If there is a company “scoreboard” or “dashboard,” this is the person who is posting the scores and perhaps maintaining the website or another place where the scoreboard is kept.
This is an important role, and somebody certainly has to do it. If the role includes figuring out what performance data should be monitored and how to collect it, the work can be complex and challenging, requiring someone with sophisticated skills in measurement and systems design. If the person performing this role is also involved in management of performance, it can be a powerful position from which to influence the design and improvement of the process. But, if relegated to merely collecting and reporting, the role may be little more than clerical. If the person in this role is reporting to functional managers who have the real authority, it is easy for them to treat that person as the “process nag,” while they continue to manage as they always have.
Continuous Improvement Initiator
The focus here is on finding small areas of improvement and running projects to close the gaps. This is often the role that you see internal Black Belt specialists doing. On the plus side, improvement (like data collection) is a legitimate role that supports process management. If this person has real authority to authorize, fund, and manage the projects, it is potentially a very effective role. And having someone in charge of all those projects in some organized, centralized fashion is far better than the chaos you can see inside organizations where everybody and anybody can start up an improvement effort. On the minus side, it may have little to do with management, but can instead be more of an order-taking function.
A process owner in this role is the enforcer of process standards (perhaps also the creator of those standards). More and more, we have seen this role attempted when a company wants global standards – for example, in how customer relations are performed, or to meet some strict environmental or other regulatory requirements that are imbedded in particular processes. When this role is in IT, it is usually driven by the desire to have standardized systems – a single instance of the ERP system, for example, across a set of diverse regions or businesses. This can be a powerful role if given real authority to enforce compliance – and is absolutely suicidal if that authority is missing.
Process Engineering Manager
A person in this role conducts health scans of the process in question in order to identify improvements, does analysis of the current process when there is some reason to evaluate performance, and does redesigns of the process to meet new or future requirements (a changing market, or new technology, for example). The person is responsible for design of the process but not for the people who perform it. We described this configuration in our last column as “staffers being process owners.” While theoretically possible, we have seen it always leads to problems – such as arguments over who is really in charge of the process and the performers; the implementation of process changes (since they are coming from the staffers) are treated as optional – process redesigns that make sense at the corporate level but not in the field where the process is actually performed.
We have described these various roles and tasks of a process owner as if they existed separately, and in some organizations they do, while in others you can find them in various combinations. But our view is some, but not all of these activities, should all be part of the role, as we describe below…
What Should a Process Owner Be Doing?
First and foremost, a process owner should be performing management duties, not clerical duties. At the highest level, management includes the planning, managing, and supporting of performance. A process owner should be doing all those activities for a given process.
Planning includes setting annual performance goals for the process that are derived from organizational goals. The goals and support plans of the functional areas that participate in the process should cascade from those process goals. The process owner should be actively engaged with functional leaders to determine what kinds of resources are needed to enable and support the process and then to get commitments from the functions to provide those needed resources. This planning and resource allocation activity includes determining if the process is capable of meeting organizational goals, which means regularly assessing the condition of the process in question, and then initiating, sponsoring, and steering the improvement efforts that will make the process capable. But the role does not include doing the improvements – process ownership is not a role for the Black Belt specialist.
As for ongoing management, the process owner role should include regular reviews of process performance and capability, and re-planning or adjusting as necessary. This monitoring of process performance should be driven by both process and function metrics that help the process owner and functional managers understand where performance deviations are occurring and agree on what the corrective actions should be.
In short, a process owner should be performing process management – not clerical duties or improvement projects.
So what about the tasks we left out, such as documenting of processes and the mere collecting and reporting of process data (as opposed to managerial review and decision-making)? We said those are actually some of the most common activities of existing process owners, and somebody should be doing those activities.
In our view, the process owner should not be doing these tasks, but should be supported by someone else – what we call the performance architect – who does these things and other tasks while the process owner concentrates on the governance aspect of process management. We will describe the role of performance architect in our next column.
For more detailed information on the management system, consult our book Rediscovering Value.
For an article on the role of management in performance support, click here.
For information on our workshop about Metrics and Process Management, click here.
For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.
For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.