Regardless of what process framework you use, and especially if you’ve done some ‘adaptation’ of processes, building process capability over the long haul goes hand-in-hand with building the organization’s process maturity.
Having thought about my comment, ‘so go ahead, adopt and adapt’, in one of my previous posts I thought further discussion might be in order.
Measuring Organizational Process Maturity
Based on the ISO standard[i], an organization’s process maturity is measured by establishing base and extended process sets at each stage of maturity. These base and extended process sets are tailored based on the domain and scope of the assessment and/or client-specific requirements.
For example, if a company decided that process A, B and C are critical to achieving organizational objectives they may determine that these represent the base process set. They could not achieve a process maturity of Level 1 (Basic) unless process A, B and C all met a Level 1 process maturity.
At Level 2, the organization may determine that there are additional processes that must be established. These would represent the ‘extended process set’ at a Level 2. To reach an organizational maturity of Level 2 (Managed), both the base and extended process sets would need to achieve Level 2 process maturity. Additional extended process sets might be added at higher levels of maturity as shown in the figure below.
Process Capability versus Maturity
Process capability is focused on the ability of the process to achieve its desired outcomes based on business objectives. The process ‘base’ practices are directly related to the process objectives; which means the base practice attributes of a process are different for each process. So rating the degree to which each process expected outcome is met (or not) is a quick way to provide insight to its capability, which may (or may not) be adequate for a given organization’s business objectives. An example for Incident Management is given below. (Note: A formal process assessment will also review the process inputs/outputs, supporting people/technology and other evidence
|Process Capability Attribute – Incident Management
(i.e., objectives/process desired outcomes)
|An incident and service request management strategy is defined and implemented|
|Incidents are reported, prioritized, analyzed for business impact, classified, resolved and closed|
|Customers are kept informed of the status and progress of their incidents or service requests|
|Management of potential service level breaches are communicated to and agreed with the customer|
|Incidents which are not progressed according to agreed service levels are escalated by customers|
If all the objectives of the process are either Largely or Fully achieved, the process will meet Level 1 (performed) requirements.
Process maturity attributes apply to all processes, and are considered ‘generic’ attributes. These ratings are usually taken across a group of processes (such as the base and extended process set). Each level of process maturity builds on the next:
- Level 1 – Performed (Process Performance)
- Level 2 – Managed (Process Performance Management, Work Product management)
- Level 3 – Established (Process Definition, Process Deployment)
- Level 4 – Predictable (Process Measurement, Process Control)
- Level 5 – Optimizing (Process Innovation, Process Optimization)
How mature are your processes?
Download this simple exercise using the ISO standard generic process attributes. Identify what you feel would be your ‘base process set’, and if you want a ‘extended process set’ as well. Then answer these questions for each process.
Organizational Process Maturity and ITaaS Transformation
Each organization has different starting points, different goals and objectives, and different levels of capability/maturity. So while we can effectively leverage our extensive experience with ITaaS transformations, each transformation path will be unique.
As processes are adapted along an ITaaS transformation path, changes in process boundaries, roles, controls and supporting technology can dilute organizational process maturity. This is another reason why ‘slow and steady’ may win the IT transformation race; frantic attempts to speed up the hill (again and again) increase the costs associated with the transformation effort an ultimately exhaust IT staff.
So go ahead, ‘adopt and adapt’, but be careful to maintain your hard-earned gains in organizational process maturity.