Who's in Charge?
Who's in charge? That's a vital process governance question.
Also, what does "in charge" even mean?
Now that we are managing across as well as up and down the organization chart, who's the boss? Who decides about how the process is executed and what needs to change?
If we now have a Process Owner who is accountable for the cross-functional process, what does that mean for the Functional Managers in charge of executing parts of the process?
When we add horizontal (process) management to vertical (functional) management, that could get very confusing very quickly. Might the addition of process governance result in more continuous argument than continuous improvement?
There is a way to make it work very well. We need a clear operating model if we are to manage our processes in the same way that we want them to execute, that is, collaboratively.
A tripartite model
I introduced my tripartite model of process governance in a previous column so I won't revisit all the details here. First, a quick refresher and then on to discuss the important practicalities about how it works in practice — and how we know who's in charge.
As shown in Figure 1, there are three themes in the model, three elements that are necessary for effective process governance: authority, ownership, and support.
Figure 1. Tripartite process governance model
There must be a source of overall organizational authority (Process Council) through which to resolve contentions and questions of strategy. A new organizational role (Process Owner) is needed to provide ownership of cross-functional performance oversight. Since there are new moving parts, an additional support and coaching service (Office of BPM) is needed.
A question of authority
There are, broadly, two main approaches to defining the authority of a Process Owner (PO).
The role may be defined as the design authority for the process with every process change requiring PO prior approval. In the extreme, the aggregated budget and resources for the cross-functional process may be moved to the control of the PO.
This authority model is not my preference as it can create unproductive conflicts between POs and Functional Managers — "who's in charge?" becomes a valid question with real operational consequences.
Alternatively, the PO can have no authority at all, making it a position of influence rather than direct authority. In this scenario the PO's role is to monitor process performance and ideas for change and bring problems and opportunities to the attention of the group of functional managers executing the process.
It's a collaborative model of management (just as the cross-functional process is executed collaboratively). If the right people are not listening, the PO can escalate to the Process Council. More details about escalation below.
The second scenario where the PO has no authority, but can exercise considerable influence, is my recommendation. It has the following advantages:
- There are no changes to existing, and probably long standing, authority structures reducing the likelihood that Functional Managers will feel challenged or uncertain.
- The lines of authority are crystal clear, minimizing the opportunities for distracting confusion and argument.
- Disruption of finance, HR, IT, and other supporting systems is minimized with no need to reorganize, for example, charts of account, reporting structures, and work groups.
- There is an effective escalation path for when executive input or arbitration is needed, thus providing a safety net for all concerned.
Process Owner in action
The activities of a successful PO are driven by the following questions that define a continuous improvement mindset.
Are there any process performance gaps and, more importantly, what are the impacts of those gaps? What would be the impact of capitalizing on some new idea, even if current performance seems OK? It's not just about problems and their causes and opportunities and their constraints, we need to know the business impact of not fixing the problem or not realizing the opportunity. What is the business case for change? What is the business case for doing nothing?
The PO works with the process stakeholders to determine the critical few KPIs, i.e., the minimum set of KPIs that will safely indicate if the process is working as well as stakeholders need it to. Then they agree the targets, measurement methods, and performance impacts related to those KPIs.
Then the real work starts, i.e., coordinating review and analysis, and intervening to sustain and improve process performance where possible and appropriate. If this last phase isn't happening, everything else is a waste of time.
Specifically, the main PO activities, conducted in concert with Functional Managers, the OBPM, and other stakeholders, are these:
- Discuss the process to build a shared understanding in the stakeholder group.
- Ensure that key stakeholders are satisfied with the processes as described.
- Discover any gaps in important knowledge about the process.
- Confirm that the documentation for the process is sufficient, accurate, and useful.
- Ensure process KPIs are correct and complete and proper targets have been set.
- Design the process performance data collection and reporting processes.
- If possible, use historic data to test the measurement method and reporting.
- Collect and analyze the performance data, produce reports, discuss the results.
- Initiate a Process Improvement Project (PIP) as required.
Once the mechanisms are established, these activities do not give the PO a heavy workload.
Escalation pathways are needed for any situation where a difference of opinion is unable to be resolved or an agreed action is consistently not taken. There may also be circumstances where conflicting functional objectives or mandates are stopping the improvement of cross-functional processes.
Escalation should be the exception. Most issues will be resolved collaboratively between the POs, Office of BPM, Functional Managers, and internal service groups, as necessary.
As shown in Figure 2, the ultimate escalation is to the Process Council. Any PO, Functional Manager, or the Office of BPM (OBPM) can escalate an issue to the Council.
Figure 2. Escalation pathways
Before escalating any issue to the Council, a PO seeks the support of the OBPM to resolve the issue. This may involve discussions with Functional Managers, collection of more data, further analysis, or any other relevant activity that will help to better understand and resolve the issue.
There is a simple and clear escalation pathway. The clear preference, however, is that the inevitable difficulties be resolved cooperatively by those who are directly involved in the management and execution of the process.
While it is not possible to predict every possible escalation circumstance, it is useful to illustrate some general escalation trigger scenarios such as the following:
- Actions not taken
- Misalignment of objectives
- Process prioritization conflict
- Process change disagreement
- Process performance dispute
- Authority/responsibility contention
- Funding implications
Formal processes can be defined and tracked to monitor the use and effectiveness of these process problem escalation pathways.
Who's in charge?
In the model I have detailed there are three parts to the answer:
- The same people who were previously in charge — nothing has changed.
- POs have no authority but they have access to executive-level escalation if they believe authority should be exercised differently.
- Functional Managers have the authority they have always had, plus they have access to the same escalation pathways.
There is nothing to be gained by replacing functional silos with process tunnels, which is a likely outcome of giving the PO ultimate authority over the cross-functional process.
The change we seek to make in process-based management is to incorporate an additional element of cross-functional process management. This is inherently collaborative management and will be new for many and challenging for some.
The key enabler for successful and sustained implementation of this new management paradigm is to have a clear and widely-shared answer to the question "Who's in charge?"
# # #