Lecture 5
Measuring process performance & reducing cycle time
“People do what you inspect, not what you expect.” [Anon.]
Developing capable processes
When we work with clients to help them implement Process Management we often introduce a simple “Process Capability and Maturity Model”. This framework can be used to help plan what needs to be done at an organizational level, but can also be applied at the level of individual processes. It’s something that can be used by Process Owners and Managers to guide them in building capable processes.
Balanced Measurement
Every process should have a balanced set of measurements (Key Performance Indicators - KPIs) against which its Performance can be tracked, communicated and improved.
There are three types of measurement required:
Internal measures
Output (or quality) measures
Satisfaction measures
Internal measures enable you to assess the basic Performance of the process itself.
Output measures enable you to assess the quality of the intermediate or final outputs. Both (Internal and Output) can be measured without involving the customer(s) of the process.
Satisfaction measures are direct assessments of the customer’s view of the process and can only be gathered by asking the customer.
The measurements you select should be based on the purpose of the process and what you are trying to achieve. For example, a process to recruit new staff exists to ensure you can employ the right people, in the right place, with the right skills at the right time. So, you will almost always need to know how many people
(Volume) are being recruited. The time it takes to recruit someone (cycle- time) is probably irrelevant; what’s important is Timeliness – is the person available, when needed? Quality of recruit is also important – do they meet agreed criteria? Finally, you will want to measure the customer’s views – Line Manager perception of the process and of the employees it supplied.
As a process Owner, you will probably only need 4-7 KPIs in order to manage and continuously improve any process. If you have too many, it probably means you don’t understand what is really important about your process’ Performance.
For each measurement you select, you need to define:
what it is (a precise definition)
how you will gather the data (including sample sizes)
how often you will gather the data
how often you will report and review the data (including the format in
which the data will be presented)
any targeted levels of Performance (if known)
who is responsible for measurement
Data collection tools include:
Check sheets (Tally sheets)
Concentration Diagrams (pictorial Check sheets)
Traveller Time-logs
Surveys/Questionnaires
Interviews/Focus Groups
In many cases, we obtain data through sampling; often because it is simply not possible to measure every single item, or to log every activity, transaction or incident. The purpose of sampling is to collect an unbiased subset which will give you a manageable amount of data. When you take samples, they should be representative (statistically correct and reliable) and economic to collect(quick and cost-effective). Moving beyond “Defined”
Three activities need to be carried out to achieve the “Quantitatively Managed” level of Performance
1. Measure Performance (gather data and analyze it)
2. Implement Corrective Actions (address any immediate Performance gaps)
3. Review Performance (regularly check that the process is “fit for purpose”)
Three activities need to be carried out to achieve the “Optimizing” level:
1. Establish DMAIC Improvement Projects (teams to make bigger changes than from Corrective Action)
2. Establish Statistical process Control (SPC)
3. Benchmark Externally (compare with known Performance leaders).
Measuring Process Improvements - Cycle Time?
One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?
Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.
Cycle Time
Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
The following are the high-level steps:
Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
Development begins. (Note: many people mistakenly start measuring cycle time here.)
Developers and testers work to validate the results of development and fix any problems discovered.
Final acceptance testing is done.
The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.
Measuring process performance & reducing cycle time
“People do what you inspect, not what you expect.” [Anon.]
Developing capable processes
When we work with clients to help them implement Process Management we often introduce a simple “Process Capability and Maturity Model”. This framework can be used to help plan what needs to be done at an organizational level, but can also be applied at the level of individual processes. It’s something that can be used by Process Owners and Managers to guide them in building capable processes.
Balanced Measurement
Every process should have a balanced set of measurements (Key Performance Indicators - KPIs) against which its Performance can be tracked, communicated and improved.
There are three types of measurement required:
Internal measures
Output (or quality) measures
Satisfaction measures
Internal measures enable you to assess the basic Performance of the process itself.
Output measures enable you to assess the quality of the intermediate or final outputs. Both (Internal and Output) can be measured without involving the customer(s) of the process.
Satisfaction measures are direct assessments of the customer’s view of the process and can only be gathered by asking the customer.
The measurements you select should be based on the purpose of the process and what you are trying to achieve. For example, a process to recruit new staff exists to ensure you can employ the right people, in the right place, with the right skills at the right time. So, you will almost always need to know how many people
(Volume) are being recruited. The time it takes to recruit someone (cycle- time) is probably irrelevant; what’s important is Timeliness – is the person available, when needed? Quality of recruit is also important – do they meet agreed criteria? Finally, you will want to measure the customer’s views – Line Manager perception of the process and of the employees it supplied.
As a process Owner, you will probably only need 4-7 KPIs in order to manage and continuously improve any process. If you have too many, it probably means you don’t understand what is really important about your process’ Performance.
For each measurement you select, you need to define:
what it is (a precise definition)
how you will gather the data (including sample sizes)
how often you will gather the data
how often you will report and review the data (including the format in
which the data will be presented)
any targeted levels of Performance (if known)
who is responsible for measurement
Data collection tools include:
Check sheets (Tally sheets)
Concentration Diagrams (pictorial Check sheets)
Traveller Time-logs
Surveys/Questionnaires
Interviews/Focus Groups
In many cases, we obtain data through sampling; often because it is simply not possible to measure every single item, or to log every activity, transaction or incident. The purpose of sampling is to collect an unbiased subset which will give you a manageable amount of data. When you take samples, they should be representative (statistically correct and reliable) and economic to collect(quick and cost-effective). Moving beyond “Defined”
Three activities need to be carried out to achieve the “Quantitatively Managed” level of Performance
1. Measure Performance (gather data and analyze it)
2. Implement Corrective Actions (address any immediate Performance gaps)
3. Review Performance (regularly check that the process is “fit for purpose”)
Three activities need to be carried out to achieve the “Optimizing” level:
1. Establish DMAIC Improvement Projects (teams to make bigger changes than from Corrective Action)
2. Establish Statistical process Control (SPC)
3. Benchmark Externally (compare with known Performance leaders).
Measuring Process Improvements - Cycle Time?
One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?
Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.
Cycle Time
Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
The following are the high-level steps:
Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
Development begins. (Note: many people mistakenly start measuring cycle time here.)
Developers and testers work to validate the results of development and fix any problems discovered.
Final acceptance testing is done.
The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.
No comments:
Post a Comment