The Work of a Process Team

All my other blog posts on the process construct is about the construct itself. This post is about the people who must manage it.

One problem that I often work with, is that many people struggle with the difference between a project team, a process development team, a process implementation team, and a process management team. They are all vastly different. A project team is a temporary team who must see through a non-repetitive outcome. A process development team is the group of people who create the process construct. We often call them the process construct engineering team. The process implementation team is the group of people who makes sure that processes are internalized and that they can run by themselves. Lastly, a process management team is the group of people who checks, evaluates, and adjusts the processes so that they function at the highest possible efficiency. Now, it is rare, and mostly not advisable, that any of the above teams are ever the same people.

This brings up two other questions that I must often answer. They are: "Should the same team who create the process also manage the process?", and "Should the same people who implement the process also manage the process?"

A short answer to both the above questions is "NO". The people who create the process construct are always experts at process construct engineering, and often Org™ outsources this work to them. Yet, even if they are employees, it is unlikely that they can be experts at all the areas which the process covers. E.g., A process that enables "resource management", will create flow for: recruitment; procurement; costing; asset disposal; and many other items that will need experts in multiple disciplines. The aim of a process management team is to use their knowledge and experience to work with the weaknesses and opportunities that can enhance or threaten the efficiency of a process. This includes adjusting its targets, adjusting its flow, etc. They are always an experienced team of experts form mixed disciplines.

Also, the people who implement the process construct, are not the same ones who executes its targets. To implement a process will need people who are experts in the implementation of a process construct. This entails internalising the structure into a construct. I give more detail on that in my posts on organisational design and structure. The process management team does not do this. They are there to test process efficiency against its outputs and against the outcomes of Org. Below I show the seven areas of focus for a process management team.

The SEVEN tasks of a process team...

1. Assess relevance.

The question here is: "Are we still doing the most relevant thing?" This step is so important that I openly guide my clients to give handsome rewards to those who can prove the irrelevance of any process within Org. What is key to remember is that the only aim of any process is to empower its own system. In turn, the only goal of a system is to empower its own construct. And so, the last aim is that the construct empowers its own purpose. Think about your own body and then you will find that it is not about your respiratory system - it is about you. Performance of the construct is the final test. Why would Org want to sponsor a process that does not enhance its performance?

2. Assess purpose.

Step one should tell us whether the purpose of a process is still relevant. So, in this step we ask whether the definition of the purpose is still correct. In other words, we ask: "Is the purpose of this process still helping us to do things in the right way?" Purpose gives authority to activity. I explain how to define a purpose in my post: "How to develop system and process briefs."

3. Assess flow.

Now that we know that our purpose is still both meaningful and relevant, we must assess the action that it ignites. The first step is to study every action within the process. We must ask: "What is not needed?" and "What is missing?" From here we probe the conditions that some of these tasks have. We ask: "Are they necessary?" and are some conditions missing?" Lastly, we must scrutinize the flow. We ask: "Is this sequence of activity the shortest and cheapest way to get the output that we want?" I explain process flow in my post: "Six steps to creating process flow for a process construct".

4. Asses outputs.

The questions we ask here are: "Do our targets accurately show what this process can do?" and "Are our targets accurately putting pressure on our outputs to produce at maximum capacity?" From these questions it might seem that I support a slave driving system. But, please bear in mind that there are also outcomes and dynamics, which together with outputs create the results of Org. I discuss more of this in my post: "The difference between a target, an output, and an outcome". Outputs drive processes, of which people are a resource. "Theory 2E of Results" tell us that outputs become efficient if what we get out, outweighs what we have put in.

5. Assess orgtelligence.

In "Theory 2I of Orgtelligence" I explain the implied and tacit intelligence that Org must have to perform and stay relevant. To ensure that we have mapped a relevant process in the right way is only part of process management. Another important part is to know the nature of the environment within which a process must be relevant, and more importantly, to know what a process needs on its inside to perform. So, the questions here are: "What is on the inside, and what is outside?" I discuss the detailing of this information in my post: "How to develop system and process briefs". The two sketches below guides what we must probe to assess the orgtelligence of a process.

6. Assess causality.

I give these seven steps to help process teams to know what they must do. However, these steps mostly overlap each other. To assess causality is a continuation of assessing orgtelligence. A process creates sequential behaviour of resources, cost, outputs, and risks. In this step, we ask whether the "cause and effect" relationships of this process are meaningful ones. For instance, some questions we can ask are: "Will the current process flow achieve the output targets that we have set?", "Does the cost of this process justify its outputs?", "Do the policies and procedures that are linked to this process, empower the process? , and "Are the risks that this process brings about, worth the taking?" If any of the above answers are "no", then we must find out whether there is a strategy in place that will create "yes" answers. If this is still not the case, then we must either create strategy or abandon the process.

7. Test relevance. 

We measure performance against outputs and relevance against outcomes. I explain the difference between outputs and outcomes in my post: "The difference between a target, an output, and an outcome". Since a strategy delivers outcomes, we must test our process against our strategy. The question we ask here is "Does this process make strategic sense?"

How to compile a process team?

I have already touched on this. The key to a good process team is that the people who are part of it, are experts in their fields. Mostly these teams are multidisciplinary – the process flow should guide this choice. The amount of process teams will depend on the size of your organisation. Most organisations have between 30 and 60 processes in their construct. I am excluding operating procedures here, a difference that I discuss in another post. In large organisations there are both system and process teams. An executive member will lead a system team, so that ze can give performance feedback on the system during executive meetings. Below this, there are usually a few process teams that work with front-line processes. In smaller organisations there are just system teams, who assesses all the process families within the system. We must take note that a process team is not a unit or a department. In other words, this is extra work. I discuss how we distribute targets to the units of Org in my posts on organisational design and structure.

A process construct takes time to mature, if we have engineered it well, and if we assess it regularly, it should take an average of three years to mature. Therefore, I suggest that process teams meet quarterly within the first three years, two times per year for the next three years, and annually after that. If a problem or threat arises, or if there is change in strategy, we increase the number of meetings, and so on.

Process teams are vital if you want to ensure the performance and secure the relevance or Org. Without them Org is likely to experience something that we know as "silo functioning".