I am currently working on measuring processes and have found a few questions crossing my mind
The main one being, If this company does not do any real process measurement (coz they mainly do reporting on sales, exceptions etc) where do I start in getting them to measure processes and what sorts of things should they be considering?
I have currently provisioned for Average handling/processing time and cycle times. I have not come up with many and could do with some assistance. The environment is telco and the processes are for a new product that touches sales, logistics, customer service and billing.
I know this sounds like a broad question but I can narrow it down if required.
Thanks in advance.
Saving Changes...
Sort By:
Stephen MayeSenior Vice PresidentVa, United States
My comments may be too vague to be useful, but a couple of thoughts came to mind when I read your post...
Establishing the purpose (business objective) of doing the process measurement is key to guiding what should be measured and to what level of granularity. If you are clear on what is the quality improvement or delivery goal, or savings that you are trying to acheive (i.e., better/faster/cheaper) then you are way ahead of the game. This sense of mission is important in terms of managing the scope of the measurement and demonstrating it's value. Otherwise, you risk finding yourself on an Easter-egg hunt without a clear definition of what you are to find or what success looks like.
More to your question--and I realize you've probably already done this--it is also extremely useful to understand what the benchmarks are in your industry or discipline. But again...depending on WHY you are measuring this will be more or less relevant to your goals. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Kendall, the measurement is in the gap between where the company is now and where their objectives will take them if achieved. So start by quantifying the business objectives in operational terms and which stakeholders will stand to benefit from their acheivement. Then correlate the core business processes that need to be improved to contribute to the acheivement of those objectives. Once that is done, quantify the changes that need to take place in the core processes using the current productivity and outcomes as a baseline to be improved upon. Hope this helps a little or a lot. Let me know how you are doing. Saving Changes...
(I'm not sure why my paragraphs are not delineated, but I'll post this now and correct on later posts.)
Michael touches on a good point- the gap - that could use some additional comments. The key point that I take away from your message is that there have been no "real" measurements of where the company is currently. This provides no baseline for measurement. The baseline measurement is CRITICAL.
Let me suggest that you start with quanitifying the project development "cost" associated with each project or project enhancement. Management understands "money" - dollars and cents - and it is a universally understood entity.
Unless, I misread (between the lines), currently, a formal business case for each project has not been accomplished or is limited in scope. The business case should/would have addressed the expected ROI on the capital spent for the project. The business case by default would have addressed the revenue or revenue uplift expected from the product or product enhancement, respectively. It would also have developed baseline costs for the implementation for each impacted area of the company.
Implementation costs should reflect project definition, project management, training, first year operational costs, and project/program role out costs, as well as the costs to actually develop (i.e. hardware and software)the project. In addition, you should be able to develop costs associated with the improvements to order entry and billing/audit processes to support the project. In telecom these steps are critical and often over looked in the original "high-level", translated "pie-in-the-shy" business case. ICBs and "one offs" are OK for twenty customers, but not for thousands, so plan for success. Improvements/enhancements to these core systems are generally expensive, time consuming, but absolutely required.
If success is in question, then prototype a limited offering in a key market prior to capital commitment for a company wide role out.
In addition, do not forget "risk". This is by far the hardest to quantify. There are always risks in going forward with the project - loss of capital with an unacceptable ROI; or in doing nothing - loss of competitive advantage or marketshare.
I'll stop rambling for now. If I am on the right track let me know. It appears that you are starting from scratch and I assume WITHOUT a Project Management Office (PMO) function in the company and limited Project Management functions.
There is a great article in CIO magazine May 1, 2003 that talks specifically about portfolio management - basically looking across the whole organization and evaluating where you are spending time and capital.
There are two kind of measures, performance and operational. Performance measures are primarily historical (and often calculated well after the fact) and only really good for hitting people over the head well after the horse is out of the barn (cost is an example of this). Operational measures are more about short- and medium-term predictions about the expected outcome of a currently operating process and have the objective of guiding people and sub-processes to do what is right for the future performance of the larger system/process.
An easy example related to the operation of an automobile. Fuel consumption -- miles per gallon -- is a performance measure. Miles per hour, oil temperature, tire pressure, and fuel level are operational measures. For that matter, engine noise can be an operational measure as well, as deviations from the usual noise (like pinging, rattling, exploding) indicate something about the future viability and performance of the car. You can obsess about MPG (a cost metric, by the way) to the point that other critical functions -- acceleration and safety -- could be hurt.
Since the past is under the bridge (I'm not saying you can't learn anything from it or use it -- fuel consumption plus fuel level can give you a rough idea of the current possible range of distance you can go before needing to fill up -- but it does often take too long to be immediately useful), operational measures are the ones that will do you the most good for impacting the future.
Note my example of variation in operating noise. An excellent book about measuring systems and processes comes from the statistical process control world is Understanding Variation, by Wheeler.
Ahh... but what to measure?
A few thoughts...
Keep in mind that every process has one or very few (less than 2?) active constraints that limit its performance at any point in time, and that performance is a matter of maximizing throughput -- the rate of attainment of "goal stuff" -- of the system/process. Therefore, while it is true that every link of the process chain is necessary to deliver more "goal stuff," if working at nominal performance -- if there are no out-of-the-ordinary issues in some part of the chain -- the performance of the entire chain is limited by very few key aspects. It's the good old "weakest link of the chain" analogy.
(In project terms, if the goal of the system/process that is the project is to deliver beneficial value, then the time until that valuable ring of the cash register is the constraint, limiting the ability to accrue project benefit. This is usually defined by the longest set of dependent tasks and their anticipated durations to get from today to the cash register, so it's no wonder that much of project management focuses on the critical path or critical chain of the project.)
The purpose of measures should be to encourage all the links to do what will help the constraint (or other near constraints) maximize it's (their) throughput and to discourage them from doing things that sub-optimize system performance by hindering the constraint. So measurements of non-constraint sub-processes need to be focused on their support of the constraint's ability to deliver what it delivers.
Measurements of constraints, on the other hand, need to focus on pure maximization of throughput (to the extent it is demanded by the processes customer/market), since the throughput of the system is directly related to the throughput of the constraint.
That said, since the initial question was about measuring processes, be careful to remember that processes generally live in the context of a larger system as well -- the business unit or company. One needs to be careful not to push for measures at the lower level -- the process -- that will get in the way of the ability of the parent system's constraint to do what it needs to do. Saving Changes...
I need to firstly understand what the comapny will do with their measurements before I can work out what they need. So define the measuring purpose.
Then break these into opeartaional and performance. Find out which stakeholders will benefit from the measurement and why will be next
Next, define the benchmarks either internally and or externally.
Then, highlight the constraints that are applied on the processes and highlight the need to include these in the measurements.
Finally, determine what level of granularity they want in the measures and allocate a person to develop reporting of these.
That is the plan I will use so let me know if you have any other items to throw into the mix....but if I am off track...let me know that quite soon.
Thanks again
Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Kendall,
I would add the following:
* Be sure the measures translate into operationally understandable metrics (eliminate averages, percentages, etc. from the measures). They must be stated in terms that the people who do the related work can manage, attach to and understand.
* Design the capture and feedback meachanisms into the business processes they relate to. People need feedback on a continuous basis to improve. Make the measures and feedback as real-time as possible.
* Communicate the rationales behind the metrics being tracked. Be sure these rationales are not essoteric in nature but rather very down to earth.
* Create a process by which the rank and file can contribute to how to achieve the metrics developed (moving from baseline towards desired states).
* Create a Performance or Value score card that is Stakeholder focused and process improvement driven.
