How to develop a statement of accountability for a process construct

Humans bring a process construct™ to life through a role structure. A role structure has dynamics that a construct does not have. In a structure there is inequality between people, which we create through authority levels, power dynamics, job grading, wage differences, etc. This creates a myriad of dynamics that has little to do with work. I explain the difference between a role structure and a construct in my post: "What is a process construct". Also, I discuss more on structures in my blog posts about organisational design and structure. In our consulting projects, I always try to get the structure as closely aligned to the construct as possible, but due to power and authority dynamics, full alignment is mostly not possible. Even in cases where we do have a close fit, the construct mostly takes on a new shape within 12-months. It is human nature to bend things towards their own desires and needs. Mostly this happens beyond consciousness.

To align the targets and content within a construct to a role structure, we ask the units within the structure to each complete an Orgamatics™ Statement of Accountability (OSA). The greater the disconnect between a structure and a construct, the more complicated it is to complete the OSA. The OSA has two parts, which are the OSA statement and the OSA target scorecard. I discuss each one below.

The OSA Statement

The aim of the OSA statement is to take accountability for various aspects of the process construct. We exclude targets here since we have a separate spreadsheet that does that.

Following is a list of items that must be in the statement of accountability:

• Basic identification such as: name of the unit; classification (do we call it a department or division, etc.?); name of the unit's leader; and names of the team who work in this unit.
• Purpose of the unit.
• The processes and systems of the construct from which the unit draws their targets.
• The processes and systems of the construct that has an impact on the unit, but that does not hold the unit responsible for its targets.
• The policies and procedures that binds the work of the unit.
• The tacit intellect that the unit needs to do its work. This is the human knowledge and skill that a process needs.
• The customers of the unit. These are the entities that uses the outputs of a process.
• The stakeholders of the unit. These entities are not customers, but they have a stake in the unit. In other words, it is important to them that the unit exists.

I explain how to write a purpose and many other aspects of the OSA in my post: "How to develop system and process briefs". Below is a sample of a completed OSA statement:

The ODA Scorecard 

The scorecard is that part of the OSA that works with targets only. The purpose of this scorecard is to give a frame for the effective management and measurement of what the unit must do to stay relevant to its sponsoring environment and what they must do to perform optimally. With this intent, the scorecard directs the following two aspects:

1. A project scorecard that shows completion, target date efficiency, and budget efficiency.
2. A process output scorecard that shows us whether we achieved our targets and what our target achievement score is.

I will explain the project part of this scorecard in my posts on the project construct™. In this post I focus on the process output targets for which the unit takes responsibility. Below is a sample of a completed OSA scorecard:

I explain how to define and write a target in my post: "Creating targets for a process construct". In this post I only explain the items that I did not explain in the mentioned post.

Target Level:

The target level is the same as the process level. This is important since you cannot have targets that comes from various levels within the same process family. E.g.: on level 2, we might measure a process target through the collective average of all the targets of its child processes. In so, if you add a level 3 target from the same process family as the level 2 target that you have added, then you are adding an item that you already accounted for. We recommend that units take their targets from front-line processes, except where not possible.

Point of Measure: 

Although we measure process output targets quarterly, we have a last point of measure. This is a date on or before which we record the final output target achievement of the year. All quarterly targets add up to this point.

Adjusted Weight: 

In my post "Creating targets for a process construct" I explain how we work with priority weightings. The problem that we face when we create an OSA scorecard, is that a unit will take its targets from various processes. Also, they will mostly not take all the targets of a process. Therefore, if they transfer the priority weights, it might often add to a sum that is less or more than 100 points. A basic rule of weight is that we always work with 100 points. In so, the "adjusted weight" is where we divide a transferred weight of a target into the sum of all transferred target weights to get a new adjusted weight. E.g., if "Target 1" weighs 30 points, and the sum of all transferred targets are 155 points, then we will divide the 30 points of Target 1 through the cumulative 155 points of the other targets. In that case we will get a new adjusted weight of 19 points. In other words, we have now adjusted the 30 points of Target 1 to 19 points. All weightings must always add to 100 points – that is a base rule.

Quarterly Measures: 

The quarterly measures will help the unit to know whether they are still on track and will warn them early where things go wrong. It is up to the unit when they do so. We show the four quarters on the scorecard as: "Q1, Q2, Q3, and Q4".

Total: 

The total on the scorecard shows the cumulative sum of targets achieved through the four quarters or the average of the four quarters. Whether the total is a cumulative sum, or an average depends on how we defined the target quantity and measure.

Completed: 

The "completed" column in the scorecard shows us how much of a target we have completed. This is a simple calculation where we divide the actual output with the pre-set output. E.g., if Target 1 was set at 3 units, and we achieve 2 units, then we will divide 2 by 3 to get a "completed" score of 66%. That means that we have done 66% of what we have set out to do. There are times, when we must reduce something, e.g., "Reduce the reported cases of misconduct with 10%". In this case we must calculate an inverse quantity. I explain this in my post: "How to audit a process construct".

Score: 

This is the final assessment of how well we have done in achieving an output. To get our "score" we simply multiply the target completed score with the targets weight. In other words, we take what we achieved with the target and we reduce it to its importance. If we have completed a target at 66.67% and its priority weight is 27%, then the score is 18% (67% x 27%).

Target Achieved: 

This is the sum of all the target achieved scores divided by the number of targets we have. E.g., if the sum of all target achievement is 275% and there are six targets, then the target achieved score is 46% (275/6). This score shows us an average of how much of all our set targets we have achieved to date.

Target Score: 

This is our final score and shows how well we have done in our targets. The difference between this score and the "target achieved" score, is that here we reduce our achievement to its priority weight. This means that importance hugely influences the score of a target. Completing something important and neglecting something that is not, might still give you a high score, while the inverse of this might radically drop your score.

*** 

It is important that units get all their targets, risks, policies, and procedures from the process construct and that they do not guess these by themselves. It is only processes that have output targets. The task of units and teams is to ensure that we meet those performance standards.

#orgtology #orgamatics #process_construct #derekhendrikz #statement_of_accountability #business_process_engineering