Welcome to the Geary A Rummler Publication Library.  On this page, you will find an archive of Geary’s publications.  A list of all of Geary’s publications – articles, chapters, and books – can be found below.  Our intention is to make as many of Geary’s published work available via this web page as possible. To read a specific article or find the Amazon page for a specific book, simply click on the title of the book or article.

This page is a work in progress.  Not all publications that are listed may be available.  Additional articles will be added as they are located.  If you have a copy of an article that is listed, but not downloadable, on this page, please send an email to pdl@thepdlab.com.  Thank you.

DR. GEARY A. RUMMLER PUBLICATIONS

BOOKS

Programmed Learning: A Practicum (with Brethower, et al.), Ann Arbor Publishers, 1965

Managing the Instructional Programming Effort (with J. P. Yaney and A. W. Schrader, eds.), Bureau of Industrial Relations, The University of Michigan, 1967. Link

Labor Relations for the Supervisor (with J. P. Yaney), Addison-Wesley, 1968

Retail Salesmanship (with Staff), Addison-Wesley, 1968

Training and Development: A Guide for Professionals (with G. S. Odiorne), Commerce Clearing House, Inc., 1988

Developing Organization Maps: A Handbook for Understanding a Business (with A.P.Brache), Rummler-Brache Group, 1990, 1995.

Improving Performance: Managing the White Space on the Organization Chart (With A. P. Brache), Jossey-Bass, 1990, 1995

Serious Performance Consulting – According to Rummler, International Society for Performance Improvement, 2004.

White Space Revisited: Creating Value through Process (with A. J. Ramias and R. A. Rummler), Wiley Jossey-Bass, 2010

Rediscovering Value: Leading the 3-D Enterprise to Sustainable Success (with A. J. Ramias and C. L. Wilkins), Wiley Jossey-Bass, 2011

ARTICLES AND CONTRIBUTIONS TO BOOKS

1. “Programmed Learning for Business”, Michigan Business Review, March, 1963.
2. “Programmed Learning: The Whole Picture”, Training Directors Journal, April, 1963, Vol. 17, No. 4.
3. “Programmed Learning-A Progress Report”, Management of Personnel Quarterly, Vol. II, No. 3.
4. “Training Industrial Programmers” (with P. G. Herrick), Programmed Instruction, Vol. V., No. 1, October, 1965.
5. “The Economics of Lean Programming”, Journal of Programmed Instruction, National Society of Programmed Instruction, October, 1965.
6. “A Review of Programmed Instruction: A Guide for Management”, Journal of Programmed Instruction, National Society of Programmed Instruction, April, 1966.
7. “For Improved Work Performance, Accentuate the Positive”, (with D. M. Brethower), Personnel, Sept.-Oct., 1966.
8. “Programmed Instruction: A Learning Technology for Management”, Ideas for Management, Systems and Procedures Association, 1967.
9. “Programmed Instruction: A Fact of Educational Life”, Michigan School Board Journal, Volume XV, Number 4, pp. 8-14, 1968.
10. “Introduction” to Training for Results (A Systems Approach to the Development of Human Resources in Industry) by M. W. Warren, Addison-Wesley, 1969.
11. “P.I.-Where the Action Is”, Educational Technology, July, 1970.
12. “The Emperor’s Clothes: The Behavioralist’s Strategy for Management Development” (with Training Research Forum) Training and Development Journal, 1970.
13. “Training: Sharp or Dull Management Tool?” (with T. F. Gilbert) Modern Government and National Development, Jan.-Feb., 1971.
14. “How to Conduct Your Own Training Audit” (with T. F. Gilbert), Plant Operating Management, March, 1971.
15. “Guidance: The Short Way Home” (with T. F. Gilbert) Continuing Education, April, 1971.
16. “Instructional Techniques for Trainers”, a chapter in The Handbook for Modern Personnel Administration, McGraw-Hill, 1972.
17. “The Performance Audit”, Changing Employee Behavior, (Conference Proceedings) University of Pittsburgh, 1972.
18. “Human Performance Problems and Their Solutions”, Human Resource Management, University of Michigan.
19. “The Management of Change: Preparing for Automation”, (with S. Cowen) Training and Development Journal, May, 1974.
20. “Troubleshooting Performance Problems”, The Bureaucrat, Vol. 3, No. 2, July, 1974.
21. “Leverage: How to Get It…What to do when you get it” (with K. Brethower) Training, October, 1975
22. “Conducting the Performance Audit”, A chapter in The Training and Development Handbook, McGraw-Hill, 1976.
23. “How to Determine what Problems can-and can’t- be Resolved by Training”, Training HRD, August, 1976.
24. “A Model for Evaluating Training” (with K. Brethower), Improving Human Performance Quarterly, April, 1977.
25. “You Need Performance, Not Just Training”, Training HRD, October, 1977.
26. “Evaluating Training”, (with K. Brethower), Training and Development Journal, May, 1979
27. “Job Performance Standards and Measures”, A Series of Research Presentations and Discussions from the ASTD Second Annual Invitational Research Seminar, Savannah, Georgia. November 5-8, 1979.
28. “Educational Technology and Organization Performance: An Historical Perspective”, International Yearbook of Educational and Instructional Technology 1980/81, Kogan Page, London/Nichols Publishing Company, New York.
29. “Strategic Thinking for HRD”, (with B. Tregoe), Training, April, 1981.
30. “Performance Analysis: Quality, Productivity, and the Real Targets”, (with A. P. Brache), Government Executive, Vol. 14, No. 1, January, 1982
31. “Instructional Technology and Organization Performance: An Historical Perspective”, NSPI Journal,  April, 1982
32. “How to Close the Gap in Human Performance”, (with J. F. Bolt), May, 1982, Management Review, American Management Association
33. “The Oldcomer’s Track (or whatever happened to the ‘P’ n NSPI)”, NSPI Journal, July/August, 1982.
34. “Technology Domains and NSPI: A Proposed Framework for Organizing the Professional Content of NSPI”, Performance and Instruction Journal, October, 1983.
35. “Japanese Productivity: Observations of a Human Performance Technologist”, Performance and Instruction Journal, May, 1984.
36. “Organization Redesign”, A chapter in Introduction to Performance Technology, The National Society for Performance and Instruction, 1986.
37. “Determining Needs”, A chapter in the Training and Development Handbook, A Guide to Human Resource Development (Third Edition), McGraw-Hill, 1987
38. “Six Myths of Quality” (with A. P. Brache), Business Age, Vol. 1, No. 12, November, 1987.
39. “Make Your Organization Your Competitive Edge” (with J. R. Murphy), Advanced Management Report, Vol., No. 9, 10, 11. 1988.
40. “The Systems View of Human Performance” (with A. P. Brache), Training, September, 1988.
41. “The Ten Most Important Lessons I’ve Learned about Human Performance Systems”, contribution to What Works at Work: Lessons from the Masters, Lakewood Publications, 1988.
42. “The Three Levels of Quality” (with A. P. Brache), Quality Progress, October, 1988.
43. “Managing the White Space” (with A. P. Brache) Training, January, 1991.
44. “Transforming Organizations through Human Performance Technology”, (with A. P. Brache), chapter in the Handbook of Human Performance Technology, Jossey-Bass, 1992, 1999.
45. “Process Improvement and Management in Service Organizations: Managing the White Space on the Organization Chart” (with A. P. Brache), A chapter in the Handbook for Productivity Measurement and Improvement, Productivity Press, 1993.
46. “Invited Reaction: Performance Improvement: A Methodology for Practitioners”, (with A. P. Brache) Human Resource Development Quarterly, Vol. 6, No. 1, Spring, 1995
47. “Change Management Strategies for Performance Improvement” (with A. P. Brache), The Quality Observer, April, 1996.
48. “In Search of the Holy Performance Grail”, Training and Development, April, 1996.
49. “Redesigning the Organization and Making it Work”, CMA Magazine, (Certified Management Accountant), June, 1996. The Society of Management Accountants of Canada.
50. “Managing the Organization as a System”, (with A. P. Brache) Training, February, 1997.
51. “Integrating People, Processes, and Technology”, (with R. P. Peebles), A Landmark White Paper, February, 1998
52. “The Three Levels of Alignment”, A chapter in Moving from Training to Performance, Robinson and Robinson, editors, ASTD, 1998.
53. “Performance Logic: The Organization DNA”, Organization Change Conference Proceedings, University of Nevada, Reno. 1999.
54. Foreword to Business Process Change, Paul Harmon, Morgan-Kaufmann, 2003.
55. “Know Your Client’s Business” (With K. Morrill, Performance Improvement, March, 2004.
56. “The Results Chain – A Tool for Serious Performance Consultants”, T + D, (Training and Development), February, 2005
57. “Potential Pitfalls on the Road to a Process-Managed Organization (PMO), Part 1: The Organization as System Lens”, (with A. J. Ramias and R. A. Rummler), Performance Improvement, April, 2009
58. “Potential Pitfalls on the Road to a Process-Managed Organization (PMO), Part 2: A Road too Much Traveled”, (with A. J. Ramias and R. A. Rummler), Performance Improvement, May, 2009

This post is password protected. To view it please enter your password below:

Password:

You have reached the registration page for the Immersion HICD Training Program.

Date: Monday through Wednesday, April 30 –May 02, 2012

Time: 08:30 am to 12:30 pm and 1:30 pm to 05:30 pm every day

Reception of participants will be on Monday, April 30, from 8:00 to 8:30 am

Fee: 3,000$ per participant including all materials, lunch on all days, with coffee and soft drinks.

Payment is due in full before the event. Payment details will be sent via email once you register.

Location: Washington DC

Presenter: Dr. Patrick Coughlin

The training program will take place at:

Residence Inn Vermont Avenue, Washington DC

1199 Vermont Avenue NW

Washington, DC 20005-3519

Phone: 202-898-1100

Hotel Website

Questions: Please contact Dr. Patrick Coughlin at Patrick.Coughlin@pd-international.de . He will respond to you within 24 hours – via his Gmail address alternatively.

Registration for this event has been closed. Thank you for your interest.

BPTrends, March 2012

Authors: Alan Ramias, Cherie Wilkins

Business process reference models are one of the most popular tools in the arsenals of those doing process definition. Deriving from tools for defining and_ designing information systems, some 30 reference models for business processes now exist*, including such well-known ones as SCOR, V-COR, ITIL, TOGAF, and e-TOM. The notion of a reference model appears to make practical sense: Instead of starting from a blank sheet of paper, why not get a head start by borrowing from a generic model instead? It is a complicated task to identify, sort, categorize and organize a business process architecture, especially for people who have not done it before, and having a framework to assist with the task is most welcome.

There seem to be three types of reference models. One type describes “best practices” for a specific domain or area of expertise—ITIL is an example of this type. A second type describes the structure of a business process architecture—SCOR is an example of this. The third type aims at defining the design of a software system. The first two types are used for business processes; the third is not necessarily applied directly to business processes but sometimes is.

We have no objection to the concept of a reference model as long as it proves useful, and for many practitioners, reviewing a reference model while defining their processes is a helpful aid to their thinking. In fact, when we define a business process architecture for a client, we use our own framework, which could be viewed as a reference model of sorts. We always start by identifying and categorizing the core business processes as belonging in three buckets: processes that create and launch products or services; processes that market and sell products or services; and processes that deliver and support products or services. This simple structure applies at least roughly to most any organization, even those in non-profit and government arenas, and it does give us a head start in identifying, categorizing and naming the processes of an enterprise.

But as we have watched a good number of clients attempt to use reference models, we have noticed the same difficulties arising again and again—often enough to make us question whether this shortcut is always as helpful as it ought to be. So in this article we will share the problems we have seen in adopting and using reference models and offer some advice for avoiding these pitfalls. We will sort the problems into two types:

Some of the problems described below have to do with the design and content of various reference models that are most popular with process practitioners, enterprise architects and system developers. (We will not name names—this is not meant as an attack on any particular reference models or any sources that provide reference models. If you already use the ones we describe, you will likely recognize the ones we talk about; and if you encounter any of these models in the future, you will probably be able to recognize them from our descriptions.) Other problems stem from the practices of those who attempt to apply reference models and not necessarily with anything deficient in the models themselves.

The Functional Trap

A division of a large utility company had been working at some process improvements as a result of a major, multi-year transformation initiative. The process changes were still being implemented when it was recognized that process management would be needed to sustain the improvements. Several management teams were already doing some process architecture definition work as a way of clarifying roles and responsibilities after several reorganization efforts. To support and coordinate all these initiatives, a process center of excellence was established. The new manager of the center did not want more than one approach for process definition in the company, so she reached out to EA and other process groups in the company, and together they decided to adopt a utility industry architecture.

But once the manager got her hands on the actual utility reference model, she realized that the “processes” were actually all functionally bounded. None were cross-functional, which contradicted her experience that the important processes of an organization are cross-functional. She and her cohorts also realized that one of their main objectives in defining a process architecture for the company—to help managers manage processes across functional boundaries—would not be helped by an architecture designed like this one.

You might think that perhaps this is an isolated case, but examine for yourself some of the reference models commercially available and you will find this flaw in several of them.

The Irrelevance Trap

As another company embarked on a process management journey, EA identified several process models that were respected as “best practice” and—with the goal of engaging and pleasing several constituencies—they put together a composite reference model. The model was promoted within the company as the key tool for assigning process owners and initiating process improvement and management.

One of two business lines did make an effort to adopt and upgrade the model. The other business line had no interest. And at corporate level, the model was dismissed because it was viewed as unrepresentative of the entire organization. As a result, the model has never been institutionalized and is utilized only inside EA.

The Semantics Trap

Inside an IT shop, a major effort was started to adopt a “best practices” reference model that would help guide both IT and the client organizations it serviced. The effort was begun with great enthusiasm but began to stall when problems with terminology surfaced. Such innocuous terms as “services,” processes,” “outputs”, even “features” were sometimes used interchangeably and debated endlessly, causing widespread confusion and growing frustration. What became increasingly obscure was the actual purpose of the effort—was it to determine the “right” or “correct” way to define a service or to establish something useful to support real work?

Also arising during this effort was a conflict between IT and its business partners. Because the contents of this reference model were labeled as “best practices,” to some team members this meant the model had to be adopted wholesale, while others from the business side kept inquiring about how the model connected to customer needs. What the team was trying to do with the model became itself a cause for debilitating debate, until the effort fell apart.

The Absolutism Trap

A similar burnout happened in another organization where we were involved in defining a new line of business for a company. One of the steps was to create a business process architecture, so a decision was made to adopt an existing reference model from an industry similar to this new business line. All fine and good if the model had been employed for its intended purpose—as a reference tool—but instead, a number of the team members (not surprisingly, those who had suggested this particular reference model in the first place) insisted that it be adopted exactly as is—with no changes in structure or terminology. Why? We suspect they hoped that the reference model would be a shortcut. They did not have the stomach for debating and deciding exactly what to use from the model and what to discard or replace with better terms from the company’s own lingo. Easier to be fanatical about it. Of course this did not go well with the more practical members of the team and the effort collapsed as a result.

The Generic Trap

If a company adopts an industry-specific reference model, you would hope that the model is in fact specific to that industry. But don’t count on it. The utility industry model described earlier not only was functionally oriented, it was largely generic. Some 90 percent of the processes identified in the reference model could apply to virtually any industry. That would be okay if you knew you were buying a generic model but not if you paid for one that is tailored to an industry— or why bother? Yet a number of the so-called industry-specific reference models are anything but specific. Check some of them out for yourself.

A Few Principles to Consider

If these tales of woe have not utterly dissuaded you from reference models, there are a few notions for making them useful. We describe these principles below, followed by an example of a company where reference models were effectively used as a result of following these principles.

1. Uniqueness is more important than sameness

Reference models are based on the supposition that organizations share things in common. They all have some structural similarities, they all have some general categories of things (for example, you can find management processes, core value-creating processes, and supporting processes in any organization). Of course, this is true, which does make it possible to create generic models that can be of some use in any company, and industry-oriented models that can be generally accurate for any company in a given industry.

But that’s as far as it goes. What is more important about a given company is not what makes it like any other company but what makes it different. Competitive advantage lies in how a company might design and execute its marketing and sales processes, or how it manufactures its products more efficiently than anyone else, or how much better it is at pleasing and keeping key customers. So a major reason for creating a business process architecture is to identify an organization’s unique, value-adding, competitive differences and using process management to institutionalize those advantages.

What we have found is that the highest levels of a reference model are reasonably accurate for describing a given company’s business process architecture, but as you go down into the details of specific sub-systems and processes, things are quite different from one company to another. A generic reference model applied literally to a company could cause you to miss this insight.

2. Adaptation, not adoption, is the goal

Reference models are supposed to be useful tools—adjuncts to the task of defining an organization’s architecture—not the Holy of Holies. The structure and contents of a reference model should be borrowed, twisted, reshaped, replaced, rethought, not adopted as some talisman to discourage thinking. The creators of most reference models will all tell you as much. They don’t regard their own work as perfect, so why should their users?

3. Don’t forget your purpose

In the inevitable debate and confusion over terminology and whether some part of a reference model should be used, changed or discarded, what is most helpful in guiding the decisions is a point of reference that everyone can agree on. In our experience this has always been to consider the views of the customer. If the organization creating a process architecture is a staff group like EA, its customers are the business, and if the architecture is for the entire company, the external customers are the focus. Once we can agree that we are doing this ultimately to better serve customers, we can ask whenever disagreement arises what it would matter to the customer, what terminology would make sense to the customer, what level of detail would the customer want to see. And of course answering these questions happens most readily when you make your customers part of the team that is doing this definition work.

A Positive Example

This is a company that embarked on a series of process management efforts over some five years. Along the way they paid for development of several customer process architecture models and attempted to use proprietary industry models, but in every case there were fundamentals about the business that were missed. The most recent effort was an attempt by Corporate EA to create a high-level business process architecture in the form of “capability maps” but this too ignored much of the structure of the business. What then ensued was an agreement across several departments, including EA and a BPM groups inside R&D, to develop a multi-level custom business process architecture that would identify and be organized around well-established business milestones. Key to the effort was including two executives along with several BPM business SME”s and senior project managers. We began with the process best understood and already somewhat defined: the product development process. With that as a base, we had the team identify the milestone achieved at each stage gate, and then we identified and named upstream and downstream milestones Guiding the choice of what to include in the architecture was the significance of a process to the business strategy. Over two months, the team met regularly to hammer out a process architecture that when finished triggered the following reactions:

• “You have captured the business on three sheets of paper.” (comment from the executives)
• “This satisfies our modeling needs.” (Corporate EA)
• “This is much better [than previous models] because it’s based on our business, not just our industry, and how our leaders think of it.” (R&D BPM)

So reference models can be useful, can be adapted to your organization, can provide content and structure for your business process architecture, and can be valuable to the many different departments that need an architecture to guide them—but don’t hold out hope for a shortcut. It takes hard work, participation from business leaders, a practical attitude, and a clear focus on purpose. Fanatics not welcome.

Gartner BPM Summit, Lisbon, 2011

Guest Keynote

The differences in definition of “process” range widely within the BPM community and among our clients.  These differences have a huge impact on our work and our effectiveness.  We will offer proven criteria for good process definition and models for clarifying and communicating the scope of processes we’ve found to be effective.

Download PDF

BPTrends, January 2012

Authors: Alan Ramias, Cherie Wilkins

In the previous three installments of this series, we presented three examples of PCO journeys that started in the “core of the business” and were sponsored and driven by line business executives. In this last installment we want to share with you our experience with one client who drove the journey from the IT department.

Let’s look first at how they got to this point. This particular client was a global building products company with operations in about 40 countries. The industry has been consolidating over several years and so their growth had been achieved by a series of successful acquisitions around the world. As the companies they acquired got larger and larger, the integration of those operations took longer and was more expensive and complex. But the economics of their acquisition strategy would only be achieved through cost savings from implementing best practices and leveraging global processes and systems.

The CIO recognized that it was a combination of process and systems that were needed to deliver the results and so he took on the process mantle -in fact, renaming his position as CPIO (Chief Process and Information Officer).

This made sense. There are a growing number of companies that have placed their process center of excellence in IT. Virtually all processes in today’s organizations require data and technology to support them. In fact, for many process steps, technology systems are the performers. Human performers and technology performers are two sides of the same coin – they execute the process, either separately or together.  (Incidentally, some readers might define the confluence of people, process and technology as a “capability”.  For purposes of this discussion we will use “process” to represent all three since it is the window through which their interrelationships are most clearly seen and understood, but we believe the point is relevant regardless of preference in terminology. This move to view technology and process together also makes sense for many process practitioners, in that most of the effort and cost of process change usually falls to IT.)

The Organization Design

So having taken on the mantel of process, it was time for the CPIO to put in place the supporting infrastructure. This is the point at which we were asked to help.  The original request was to develop a standard for process documentation. The company rightly recognized that it needed the language of process to be consistent across the organization. We advised them they also needed a business process architecture (BPA) to establish a common definition of process, a single methodology for making process and IT changes, and a portfolio management system to manage all of the change. These were the four components that were put in place.

They also organized four design groups inside IT roughly based on domains of Operations, Supply Chain, Commercial, and Back Office. These design teams acted as global process owners for the enterprise. They were supported by a group of IT account reps attached to the business that represented the regions and countries. The design groups were accountable for the process design and global process performance. The region and country managers were accountable for process performance in their geography.

The Intake Process

All requests for IT or process change came into the design teams where the portfolio was managed. The design teams used the BPA as the screen and organizer for the portfolio. As you might imagine, most requests arrive in IT as a request for a particular solution (“Build me a database for this.”). The design teams worked with the account reps to reframe the request as a business issue (“I need to solve x or I need to be capable of y”). They then were able to locate which process or which type of work was associated with that issue. They were better able to see patterns in the requests as well as keep track of all other process change related to that same process in this way.

In one particular case, the Operations Design Team was screening the global set of requests and identified more than 30 different solution requests all aimed at the exact same process issue. So instead of 30 initiatives, they had one. They could also look at their total IT expenditures against the BPA and make a judgment as to how aligned to strategy the investments were. As you see in the example below they were surprised to see how much they were investing in contributing processes rather than value creation processes.

Pitfalls of this Approach

We integrated our process improvement methodology with their system development methodology so they were sure to address the process – both sides of the coin (human and technology)—equally and simultaneously. A potential pitfall of placing process in IT is for designers to always opt for a technology solution to process issues when in fact there is often a human solution or combination that may serve the business need, urgency and budget better.

So what are the other potential downsides of this model? We have already mentioned the legacy of making requests for solutions as opposed to coming with a business issue. In addition, when process ownership rests with a support function outside of the core business, connectedness can be problematic.

On the one hand, IT can function as a “neutral party” that can arbitrate all of the varying regional requests and choose those things that are best from an enterprise perspective. On the other hand, because IT does not have a stake in the business, IT may be biased toward technology optimization or merely cutting costs versus value creating solutions. And even if IT can temper its tendencies toward technology solutions, they are often regarded with suspicion as being biased toward their own interests.

There is also a risk that IT may not be as connected to business strategy as IT needs to be to make tradeoffs in cost and internal objectives versus quality and impact on customers. In our example, the design team members had all come from the business, but as time went on, they could have lost their close connection to the business. This has always been the dilemma with the business analyst role in IT. In many organizations, BA’s have been moved back and forth from business to IT in an attempt to find the appropriate balance of business knowledge and IT knowledge. The connection is important because it’s critical for IT to be both solution-neutral and yet informed enough to understand the nature and impact of the business problem or opportunity.
The story would be similar for any organization that is driving the PCO effort from any one of their support functions – HR, Finance, etc. Many of the pitfalls would hold true for those organizations as well. Given the choice, we think that a business-driven effort has a better chance of achieving and sustaining success. The challenge for our client will be getting the business to remain engaged with them on their process journey.
 

 Conclusion

So now we have reviewed four different approaches an organization could take in becoming process-centered, and have tried to outline both the advantages and the shortcoming of each approach. The first approach was the ideal one, in which the top leadership team transformed its entire business by designing, installing, managing and maintaining its value creation system of core processes and contributing functions and processes.  The advantages were great; the downside is finding an organization with the leaders to have the vision and patience to make something this comprehensive actually happen.

The second approach was the slow but steady change by an organization that knew where it wanted to go but had to overcome obstacles one by one.  The advantages include a leadership team and workforce that gradually understand and thoroughly buy into the vision over time, but with the risk of derailments over the long term.

The third approach was the classic example of a company driven by extreme external threats to invent itself.  The business payoffs can be enormous, as they were at Motorola which was our example, but sustaining the changes can end up being problematic.

And the final example we’ve outlined in this Column is the transformation driven by a support organization—an approach becoming more and more common but difficult to achieve because of credibility issues.

We hope you have found these four journeys helpful as you plot your own organization’s PCO
path.  And keep in touch—maybe there is yet another way to go.

In addition, here is a video of Geary Rummler presenting at MTEC in 1981.

And one final video from 2008, with Geary speaking for the HPT Practitioner Podcast.

Many thanks to Guy Wallace for the videos!

This post is password protected. To view it please enter your password below:

Password:

BPTrends, September 2011

Authors: Alan Ramias, Cherie Wilkins

In our last Column we discussed process-centered organizations (PCO) that take a slow, gradual  route, describing the risks of such an evolutionary approach and its long-term potential benefits.   This time we will focus on organizations that become process-centered because they are in deep trouble.

Organizations in crisis are sometimes ideal for introducing a transformative change at the scale that a PCO requires.  When the need for change is real, when many if not all of the company’s key leaders recognize the crisis, when the pathway to restoration can be seen…good things can happen rapidly.  Unfortunately, even when a company is suffering a crisis, all the variables are not necessarily lined up in favor of rapid change.  We will explore what critical elements need to be in place in order for a stricken organization to move ahead to recovery, and describe two different organizations that have gone down the PCO path because of an initial crisis.  The first example is from the distant past but still offers some valuable lessons; the second example is from today’s headlines.

The Classic Case

Motorola in the 1980’s is still the classic example of a company that transformed itself because of a crisis.  (Never mind its current travails—it still stands as one of the best examples of an organization that became process-centered on a grand scale and was the inspiration for countless other companies.)  Poor product quality and Japanese competition in the late 1970’s were the twin drivers for change, causing CEO Bob Galvin to announce the goal of ten-fold quality improvement, spurring a decade-long effort to improve that completely reconfigured the company, earned it the first Malcolm Baldrige Award and made it an American icon.  We have written before about how the change was accomplished at Motorola (Ramias, 2005), so here we will merely summarize its major stages:

1. Initial efforts were focused in manufacturing, where quality circles were created and training in what we today would call lean techniques were employed.  Improvements were achieved but were scattered and way down at the task level, not addressing end-to-end processes.  To provide the training, Galvin authorized the establishment of a corporate training organization, which became the famed Motorola University.

2. In the second stage, engineers were trained in Statistical Process Control tools and techniques and began to apply them to whole processes, initially confined to manufacturing but then gradually spreading to product design, supply chain and other areas.  At the same time, Geary Rummler entered the scene and co-developed a process improvement methodology that did address end-to-end business processes.  With these developments, large gains in quality, cost reduction, cycle time and reputation began to take place, largely inside the product divisions where manufacturing and engineering resided.

3. In the third stage, the improvement efforts became widespread in Motorola, with virtually every department having some training in improvement techniques and formal goals and programs.  The umbrella label of “Six Sigma” was invented to encompass all of the efforts, and Motorola went public, hosting endless benchmarking visits by other companies.

In the first stage, recognition of the crisis was paramount.  CEO Galvin saw it but not all of his executives did, and the result was a swift trimming of naysayers.  Galvin had the courage the top leader must possess, and it is the variable that matters most in stage one.

The other necessary variable is having in place the means to make the change.  Galvin did this by bringing in Bill Wiggenhorn to create the corporate training organization.  Motorola University became Galvin’s change agent.  He provided funding and political cover as MU spread the quality gospel throughout the company.  All of the major tools and ideas came from outsiders like Rummler, Joseph Juran and Dorian Shainin, and they were brought in via MU curriculum. Training does not necessarily have to be the change agent, but something is usually needed to give a company both the push towards change and the tools, ideas and mechanics.  Companies in crisis often get there because they lack critical skills or ideas, so improvement from inside is not going to happen.

In other cases, the chief limiting factors are the panic and hesitation triggered by the crisis itself—people may have the potential to change their circumstances but they are paralyzed by fear and self-doubts.

Once the improvement efforts began in the product divisions, the driving factor came from the division heads.  Not all of them, of course, at first had the foresight or  courage, but there were a few capable of operating like Galvin on a smaller scale—pushing for change, describing a different future, supplying the means, and providing political safety.  They led the change and others lagged but eventually imitated the leaders.

There is a key lesson in how this happened:  it is wise not to try to make the change everywhere at once, but instead to concentrate on a few places where the need is clear, the leadership is ready, and the results can demonstrate the value of the effort required.  Motorola didn’t think this through, of course—it just kind of happened, but the lesson is clear.

The Current Case

Our second example is a bank that has suffered through the catastrophic economic downturn of 2008 and its aftermath, and is now attempting to right itself by becoming process-centered.  For reasons that will be obvious, we cannot name this institution but will describe its PCO journey to date.

Like its many brethren in the financial industry in middle of the last decade, this bank overextended itself, in particular making commercial loans that went bad when the economy tanked in 2008-9. The situation was so dire that after conducting a review, the FDIC almost closed the bank’s doors.  Instead it was given a brief period to recover, some new leaders were brought in, and we were invited to conduct a review of processes and operations.

Ironically, because of this bank’s location and clientele, one of its more promising areas of business was mortgage lending.  So we then conducted a classic process improvement project, using the well-known Rummler Process Methodology.  This effort was deliberately formulated to be “a tip of the spear”—that is, instead of attempting to transform the whole bank, we concentrated on one of the few areas where there was some promise of measurable results if the improvement happened.  And just as important, the goal was not just to address the mortgage lending process but to raise employee esprit de corps by engaging them in something they could change, by demonstrating how to work across functional boundaries, by producing a design that could, if implemented, have a positive impact on both the workplace and on the customer.

The implementation of this design is now underway, and, as expected, it has revealed the need for a comprehensive makeover of all lines of business, all key processes, all jobs and functions and the governing management system.  The effort on this systematic transformation is currently happening.  Once it has been put in place, it will be a model for the other banks in the larger constellation of banks owned by the parent company to undergo their own transformations.

So another organization in crisis, triggering an improvement effort with the longer-term outcome of being a PCO.  The success variables are much the same as at Motorola:  a clear need for change, in this case coming from outside (i.e., the regulators and the parent company); a set of key leaders in this case deciding that a transformation is required and providing the necessary means; assistance from outside to both understand the problem and propose solutions; a careful
effort to demonstrate the value of this way of designing and running an organization before trying it widely.  A crisis can  be a great trigger for change, but it doesn’t automatically happen—other variables must be in place or the opportunity can be squandered and the organization could join the long list of companies that have gone under because of inertia.

Lessons Learned

So what can these two cases, separated by decades, teach us about successfully implementing BPM and becoming a process-centered organization?

Both cases demonstrate that a crisis can indeed be a golden opportunity to make changes that otherwise an organization may be too complacent to undertake.  Both scenarios required a burning-platform issue, a strong leader willing to assume a “benevolent dictatorship” managerial style for at least a while, both required assistance from outsiders, and both needed a methodology for change.

But there are differences between the two cases. At Motorola, the entire effort took nearly ten years; despite there being a major driving force for change, Motorola’s progress was not actually that different from the slow companies we described in our last Column after all.  In large part, that is because much of what was attempted was experimental.  Galvin did not tell his subordinates how to change the company; his approach was to “let a hundred flowers bloom”.
Some ideas really did create great improvements while others failed or worked only for a time.  A case in point was the use of quality circles, which at Motorola was called the participative management program (PMP).  Its centerpiece was an incentive system that gave everyone a bonus when businesses made a profit. Much propaganda was used to try to link the PMP program to the improvements that the quality circles made, but there was little valid linkage. Some divisions did well and got bonuses without doing any improvements; others were pioneers in reinventing themselves but results were slow in being realized. This all came to an end when the company became unprofitable for a time during the mid-1980’s; and as the bonuses went away, so too did the interest in improvement.  In fact, the “six sigma” program was in part a rather desperate attempt at reviving the mentality for improvement because PMP had effectively died.

At the bank, the timeframe for change is already much briefer, and will be even when the improvement methodology is spread to other banks in the system.  The methodology being deployed had its origins at Motorola but has been vastly expanded and refined over the decades, so it is no longer experimental.

The leadership at the bank has a better sense of how to create and manage organization change.  Its “tip of the spear” tactic is quite deliberate, as opposed to the accidentally learn-while-doing approach that happened at Motorola.  And the leaders recognize that every element of the organization has to be altered to create a fully functioning, integrated high-performance system.

So, after thirty-some years of learning about how to harness BPM to an existential crisis, some variables remain the same: strong, courageous leadership; assistance from outside for many, if not all, companies; a methodology and means to create and support the required changes; and a demonstration of value before attempting a broad scale of change. Those are the variable that can turn a crisis into a transformation.

The new lessons are that BPM can indeed be the means for effecting broad organizational transformation, and now, with enough organizations having undergone the journey, the pathway can be planned at least in its broad stages.

In our final Column of this series on PCO’s, we will explore the unique challenges and benefits of a PCO effort driven by a support function—our example being an IT department in the driver’s seat.

BPTrends, May 2011

Authors: Alan Ramias, Cherie Wilkins

In our last article we described the characteristics of a process-centered organization (PCO) and gave an example of one company that reached the destination in a relatively short period of time.  But that kind of rocket-propelled journey is not the norm. In this and the next two installments of this series we will share with you the more common approaches we have seen.

The example in this article is an organization that illustrates what may seem like the tortoise version of the race to becoming a PCO – slow and steady. We will assess the effectiveness and pitfalls of this approach.

The Starting Line

The journey for this company began seven years ago. The driver was a major customer who was demanding improved performance—higher quality and more predictable cycle times. That customer wanted the company to stabilize its “service delivery” processes and put in a quality control system. In parallel, key members of the management team recognized the importance of process. Because of this, there was a decision to take a process approach to addressing this critical business issue (CBI).

The First Leg of the Race

The company started its journey by establishing a Process Center of Excellence.  The cadre of approximately 20 specialists was largely composed of Six Sigma-oriented process consultants who came from the various businesses augmented by few external hires.  Once in place, the consultants guided management in choosing and defining a business process architecture.  The architecture framework they chose was one of the most widely known in the BPM field, but they did make some adaptations to suit their company’s particular situation.

The company then assigned process owners to each process in the architecture and moved forward with the intent to create management teams, establish metrics, and document processes, all conforming to a standard process maturity model. A process consultant was assigned to help each process owner.

Although the goal was to address all of the processes on the framework, the reality was that the bulk of the effort and attention centered on the delivery processes and on addressing the CBI.

What was Achieved

The company did achieve real results in addressing the CBI.  In fact the results were so compelling that the CEO openly endorsed the goal of becoming a process managed company. He wanted this to be his legacy.

The process architecture was institutionalized, and to this day is the best example we have seen of full adoption.  Just about everyone in the org recognizes the architecture and can name from memory the top-level processes.

There was also some initial success in establishing process management. The Process Owner Council meets regularly to review process metrics.

With the endorsement of the CEO, the company began to slowly and steadily spread their success to the other parts of the organization. This slow and steady approach is a choice many organizations have made.

The Next Lap

CBI ‘s don’t last forever. The CBI was leveraged to drive the first part of the journey and it worked.  What was desired next was steady progress on the rest of the journey. But because the CBI had been addressed—all of the service delivery issues had been eliminated and the processes were yielding steady, predictable results—the urgency went out of the effort. The company settled into very slow progress and all of that driven by push from the Center of Excellence process experts, not pull from the business.

Eventually—five years into the journey—they hit a plateau. As process owners disengaged, there was lots of turnover on the Process Owner Council. The process owners were tired of metrics reviews and were asking to shorten the council meetings. It was tough for the Center of Excellence to continually push.

It was time to up the ante. What they had forgotten was how the CBI had fueled the early efforts. It is not enough to sustain the gains. Success in one area did not inspire effort in other areas as they thought it would. They need to find a new driving force.

Toward the Finish Line – What They are Doing Now to Address their Midlife Crisis

The company recognizes the need to tie back to real business issues to fuel the rest of the journey.  They are making a connection to strategy.  The Center of Excellence specialists have begun working with the strategy organization to use process management and improvement as a way to close gaps between current and future capabilities. In a pilot, they correlated long range business plans to processes, highlighting where the strategy calls for changes in process capability or capacity. These gaps will then have to be addressed in the company’s business plans.

Key managers, aided by Center of Excellence advisors—are actively looking for CBI’s in the other process areas and are gathering real data – including customer feedback -  to drive the desire to address those CBI’s.

The company has also made an adjustment to part of the process architecture – a bold move, given the level of institutionalization. They recognized that some of the complacency about the processes upstream from Service Delivery was due to the overly generic definition of those processes. Remember that they began with a best practice framework that they adopted from outside and then tweaked.  The upstream part of the framework did not really represent their business model – how they now do business. The process performers and managers didn’t resonate with that definition of their work. So they are now redefining that part of the process architecture and have a new framework that better reflects the business. They are hopeful that this will facilitate a higher level of process engagement in these upstream areas.

So the company now has all the right pieces in place and is making some smart moves to keep the journey on track. We are hopeful that, as in the fable, slow and steady wins the race.

Lessons for All of Us

In the beginning this company did not really make a conscious decision to go slow.  In fact it started on the PCO journey the way most companies do—by harnessing its self-education to an urgent business problem.  But after the initial surge in effort—the staffing up of resources, the training, the redesign effort, the establishment of a process management system—it didn’t know where or how to go next.  And that happens to many companies that burst into the BPM arena with great ambitions and enthusiasm but little in the way of long-term plans. And so without necessarily meaning to, the company found itself on the slow road to PCO nirvana. What can we learn from their experience?

One lesson is that this often happens.  A company could plan to go fast but only knows how to begin, not how to continue or how to end.  Asking questions about the destination at the outset might do everyone a lot of good.

Another lesson is the dangers of establishing an internal team of experts.  While staffing up a Process Center of Excellence is a common practice and is usually needed to guide a large organization to becoming a PCO, all too often the accountability for getting there ends up in the laps of the process specialists instead of staying where it belongs, with the business leaders.

The biggest challenge of a go-slow approach is, of course, sustainability. An organizational transformation taking years to achieve will take considerable effort to keep it alive, and it may not be revivable at some point if it is perceived as having “failed”.

And perhaps there is a bit of confusion about journeys versus destinations. Perhaps there is no destination.  If a company institutionalizes process management and links it meaningfully to the business, it has the means to adapt its internal processes and other capabilities as the external world changes.  But that means things are always changing.  So an effective PCO is not a stable, comfortable, predictable organization:  it is wide open to possibilities and able to pounce on them quickly, keenly aware of its vulnerabilities and quick to adjust whenever threatened.

A hideous little cliché making the rounds these days is “It’s a journey but not a destination.”  Some truth in that.

In our next article we will look at the journey undertaken by a company in real crisis – do or die….

Related Links

This article is part two of a multi-part series on the process-centered organization.  For Part 1, click here.

For an article on the pitfalls on the path to becoming a process-managed organization, click here.

For a presentation on the topic of the process-centered organization, click here.

For information on our consulting service to help organizations along the path to becoming a PMO, click here.

March 2011

Gartner BPM Summit, Guest Keynote

London, UK

For an enterprise to be successful it must excel in three dimensions of performance: value, resources and management. BPM can and should play a prominent role in all three dimensions, but that has not been the case in most organizations taking the BPM journey. We’ll tell you the implications for your BPM program, including change management, and give you examples of the successes and failures we’ve seen in leveraging BPM for transformation at an enterprise level.

Download PDF

BPTrends – February 2011

Authors: Alan Ramias, Cherie Wilkins

The concept of a “process-centered organization” originated with Michael Hammer in his 1996 book, Beyond Reengineering. “To become a PCO” still seems to be the most popular description of the destination that organizations claim to be trying to reach when they embark on BPM.  Because the PCO concept still resonates with so many organizations and practitioners, our column for 2011 will be devoted to that subject.  We will offer you a four-part series on the subject of a PCO, with different examples on the topic:

• In this article we describe the characteristics of a PCO and give you a real-life example of a company that successfully reached the goal.
• In Part 2 we will give you examples of the “tortoise” approach – that is, the slow, incremental path that we have seen a number of organizations take.
• In Part 3 we will give you examples of the “hare” approach – how an organization confronts a crisis by using BPM to achieve organizational change quickly.
• In Part 4 we will give a “from-left-field” example of a company that took an approach to BPM that was significantly different from the typical path.

Characteristics of a PCO

Here are the characteristics (or components) we believe have to be in place in order for an organization to be “process-centered.”  This is, of course, our own list, derived from our experiences with organizations that have asked for our help in going down the BPM path. There may be other characteristics you would add, but we think this is the minimum list of required components.

1. A well-articulated business process architecture

An organization can’t manage what it can’t see.  That is, an organization cannot manage its processes – much less be “process-centered” – if it doesn’t understand its own processes.  That means it must have a set of clear pictures of its core processes – those processes that enable it to create, sell, and deliver valued products and services as well as the key processes that enable and support the core processes.  Thought leaders and consultants in the BPM business have various names for these pictures – an “architecture” being the most common label.  Some would boil it down to a single high-level diagram, and others would argue that it must also include a collection of depictions of the most important processes.  Our preference is the latter, because such a collection of pictures provides a comprehensive view of what we call the organization’s “value dimension.”  But whatever you elect to call it, a prerequisite to becoming process-centered is a clear, complete, logical, and accurate view of how a given organization does its vital work.

2. The business process architecture is institutionalized.

The first requirement, above, may not be that much of a differentiator, as quite a few companies have defined their process architecture.  And some have gone totally overboard, endlessly mapping all the processes of the organization (a trap that numerous “process excellence” groups have slipped into) with little clear purpose.

But it’s a much greater achievement to have institutionalized the architecture – that is, when it is being used as a key tool for understanding the business, making decisions, and managing the daily work.  The process documents are not just sitting in some archive, rarely referenced except perhaps for an audit and generally accessible only by those who created the maps.

Further, the architecture is meaningful to employees:  The notion of process has spread throughout the organization, and any employee can tell you about the work they do in “process” terms.  They know where they fit in the architecture, and they understand the connection of their daily contributions to the business.

3. The management system is process-centered.

It is certainly well known that if an organization is to be process-centered, it must have process management. But the attempts to put process management in place have been problematic in most organizations we’ve seen.  Often a single manager (or a group of managers) is simply designated as process owner, with little clarity about what the role entails. In other cases, process management is a disconnected set of management roles, policies, metrics, and practices that are disconnected from the existing, actual management system.

What is required is for process management to be entirely integrated into the existing management system – integrated from enterprise level down through all levels of process in the organization’s process architecture, down to functions, jobs, and tasks.  In an organization with this process-centric management system, management first turns to the value-creating process view to do long and short-term planning, to identify new capability requirements, to assess the fit of new opportunities, and to make decisions about acquisitions, outsourcing, and other strategic actions.  The process view is applied to all the key activities of managers, including planning, budgeting, resource allocation, monitoring, troubleshooting, and performance management.  Planning and management activities form a closed-loop system linking strategy and objectives to daily work.

4. Capabilities to transform and evolve are in place

A major reason for an organization to become process-centered is to increase its agility.  When new threats or opportunities arise, traditional organizations tend to respond slowly, painfully, or not at all, because it is so difficult to change internal structures and behaviors.  By contrast, the process-centered organization is much better positioned to capitalize on the changing external environment because it understands its internal mechanics, and so it can pinpoint where changes have to be made and can do so quickly.  And, through conducting process improvement projects, process-centered organizations have developed a capability for change.  The tools and knowledge are in place to do continuous improvement or radical redesign.

Some organizations that want to be process-centered never do process improvement.  They aim for process management or spend much of their time in process documentation.  But they are missing much of the reason why processes became prominent in business to begin with.  The process view is an effective, efficient way to make the necessary improvements to an organization’s work systems that make the organization lean, competitive, and adaptive.

Yes, It’s Possible

What we have described may sound like some kind of business nirvana, and you may be asking yourself if any organization has ever even gotten close. The answer is yes. As proof, we offer one client’s 18-month journey and also tell you the circumstances that made this rocket-propelled journey possible.

The journey began with the CEO of a wealth management bank. He read Improving Performance and got excited by the concepts, especially by the section on management. He contacted us with the following plea, “Come make us into that type of organization.” Over the next several months, we worked with his company to put into place the components and practices that we described earlier.

We began with the analysis and redesign of their Client Services Sales and Delivery processes. Our design team consisted of all of their executive team, augmented by a few other subject matter experts. In essence, we redesigned 80% of their value creation processes (those that deliver value to customers). But, in addition to achieving the improvement gains, we also gained deep understanding of the power of the process view of an organization. We tore down most of the organizational silos in one fell swoop. The other thing that these executives experienced in a very real way was the connection between process and strategy. They were making their decisions on the design of the new process, based not just on resolving current issues, but on what the processes need to be capable of, in order to achieve their strategy. After this part of the project, it became pull instead of push. The managers wanted to map and get insight to all of the other processes, including all of the enabling processes like the Technology and Human Resources enablers. Several other improvement projects were launched.

At the same time we were defining and redesigning processes, we got to work defining and redesigning the management system (aka the management processes). For each of the processes we developed a set of process metrics that measured process performance across the functional boundaries. We linked those metrics to enterprise metrics through a performance logic tree. Process owners and process management teams were assigned. Then we were able to redesign the planning and review processes, including meetings to accommodate process plans, both operational and improvement, being developed and used as the drivers for functional plans. This sequence of planning was piloted during the next annual planning round.

Although this work was led by us as consultants, all along the way we were also building the organization’s own internal capabilities in process modeling, improvement, and management system design. In the course of this transformation, virtually everyone in the organization was involved in some way – as a member of a design team or an implementation team, as a process owner, or as a manager participating in the new planning activities.  Everyone in the organization was exposed to some training on the process approach to improvement and management. Every manager used the new management system. In short, it was a profound and successful transformation to a PCO.

However, there was an extraordinary set of circumstances that came into play here to make this journey possible. First and foremost, the CEO was an extraordinary leader. He had a vision and never wavered from it in the years that we worked with him. He made it the priority and understood that achieving the PCO end goal was the way to achieve his strategy. He was also very engaged. He was directly involved in many of the design sessions.

Second, this was a small organization – fewer than 200 employees – so we could get it all done in 1.5 years. They still had all the same processes as a big organization, just fewer resources and less complexity.

End of story? Well, they were a very successful organization. Their PCO journey allowed them to continue their growth and success. They were subsequently bought by a larger wealth management bank that was then acquired by an investment firm that was larger yet. These larger players imposed their systems and procedures on the small company wherever they could. The parts of the operation that we had worked with were sustained as much as they could be for as long as they could. To this day they still have some of it in place.

Related Links

This article is Part 1 of a multi-part series on the process-centered organization.  For part 2, click here.

For an article on the pitfalls on the path to becoming a process-managed organization, click here.

For a presentation on the topic of the process-centered organization, click here.

For information on our consulting service to help organizations along the path to becoming a PMO, click here.

Presented by the Austin chapter of ISPI (The International Society for Performance Improvement), in Austin, TX.

April 1, 2011, 8:30 am to 4:30 pm

Click here for flyer with registration information.

Guest Keynote: Repositioning BPM for Sustainable Success

Monday, 07 March 2011
10:45-11:30

For an enterprise to be successful it must excel in three dimensions of performance: value, resources and management. BPM can and should play a prominent role in all three dimensions, but that has not been the case in most organizations taking the BPM journey. We’ll tell you the implications for your BPM program, including change management, and give you examples of the successes and failures we’ve seen in leveraging BPM for transformation at an enterprise level.

From Process Analysis to Process Design: A Proven Approach

Monday, 07 March 2011
16:45-17:45

There are a wealth of tools and techniques for process analysis and process design but there are few that assist in making the transition from analysis to design. This session will demonstrate a proven approach for making the transition from analysis to design and avoiding common process improvement pitfalls:

• Lack of agreement on where and how the process is “broken” and the significance
• Fixing only what’s broken (and missing other improvement opportunities)
• Not knowing the availability, impact and limitations of potential breakthrough ideas

Turning Client Preconceptions into Performance Gold

Tuesday, 08 March 2011
08:00-09:00

So often, clients come with a predetermined solution. It may be new technology, process improvement, or organizational change, but it’s hard to say ‘no’ when a decision has been made for you. This workshop provides a time-tested model for:

• Reframing the request into performance terms
• Scoping the affected dimensions: value, resources, management
• Helping clients see their solution in terms of likelihood of success

• The evolution of organization complexity and the impact on performance
• The importance of and approaches to making the creation of value visible and understandable
• The benefits of ensuring balance between your resource and value dimensions
• An agenda for moving to the 3-D Enterprise

For those who want application and practice using the PDL tool kit, please see the workshop page for Creating the 3-D Enterprise: The Workshop

Seminar Length:

2 and 4 hour versions available

Who Should Attend:

Executives, Managers at all levels, BPM Practitioners, Business Analysts, Performance Consultants

The first half-day of this workshop presents the content of our introduction seminar. The workshop then goes on to explore the acts of process management, and provides practice in applying PDL’s proven tools and principles to your unique business situation. Workshop topics include:

• Introduction Seminar 
  • The evolution of organization complexity and the impact on performance
  • The importance of and approaches to making the creation of value visible and understandable
  • The benefits of ensuring balance between your resource and value dimensions
• The Acts of Process Management 
  • Definition
  • Design/Improvement
  • Management
  • Performance Support
• An agenda for moving to the 3-D Enterprise

Workshop Length:

1 and 2 day versions available

Who Should Attend:

Managers at all levels, BPM Practitioners, Business Analysts, Performance Consultants

• The History of the BPM movement, including the current state of the field and lessons learned
• The evolution of organization complexity and the impact on performance
• The importance of and approaches to making the creation of value visible and understandable
• The benefits of ensuring balance between your resource and value dimensions
• The Acts of Process Management
  • Definition
  • Design/Improvement
  • Management
  • Performance Support
• An agenda for moving to the 3-D Enterprise

Workshop Length:

1.5 day and 2 day version available

Who Should Attend:

BPM Practitioners and Managers

BP Trends – December 2010

Authors: Alan Ramias, Cherie Wilkins

This is the third and final Column in our series on process performance measurement. In the first Column we described some of the complications we have encountered in helping organizations install effective process performance measurement systems and then offered some principles for accomplishing this important work successfully. In the second Column we provided a tool – the measures chain – for identifying appropriate process metrics linked to both customer and business requirements.

But once you have the metrics identified, what do you do with them? Who uses these metrics to monitor performance? How often is data collected and reviewed? Who makes decisions about corrective actions, and who takes those actions? Metrics not being used to guide and improve performance are worse than useless -they can get in the way of understanding the performance taking place, they can clutter the landscape with irrelevant data; they can create the appearance of control where it doesn’t exist. It may be hard to believe but we’ve seen a good number of organizations in just this situation – where they have created a “chaos of metrics” but have not put it into use for a variety of reasons. So this final article in our series is about the most important step in creating process metrics…and that is figuring out the “who, when, why, and how.”

A Management Model

Our approach to determining who’s watching performance and taking corrective action is based on the management model shown in Figure 1. This model separates the major activities of performance management into “Performance Planned” and “Performance Managed.” (“Performance Executed” is shown in Figure 1 but is actually the actions of performers inside the organization who are doing work and achieving results.) ln “Performance Planned,” the organization’s leaders are setting goals, establishing budgets and action plans, gathering and assigning resources, and setting the plans into motion. In “Performance Managed,” the leaders are monitoring performance as it takes place, identifying deviations in actual performance versus the established goals, determining what corrective actions are required, and taking those actions to get performance back on track. Metrics are, of course, the key component in use during performance monitoring and variation identification and analysis.

This is a simple enough model in concept, yet it’s applicable to even the most complex of organizations in determining who is responsible for performance at any level. Our use of the model for creating process metrics is to figure out who should be responsible for that particular set of performance indicators.

The Management Domain Matrix

To put the management model into use, we apply a tool called the management domain matrix.  Shown in Figure 2, it shows management responsibilities for planning and managing performance. (lt could be called a “role/responsibility chart,” but that term is used commonly for job responsibilities, and our chart is going to contain something a bit different- not just single job responsibilities but collective responsibilities of management teams.) In this particular case, we will demonstrate the application of the domain matrix to a process measurement and management system. We will use it to determine the role (if any) for each level of management regarding a given process. A completed example of this application is shown in Figure 4. But the tool is scalable up to an entire enterprise management system.

Using the measures chain described in our last article (Figure 3), process metrics have been identified for an order fulfillment process. Some metrics are for the entire process (e.g., total cycle time, percent shipped on time), and others are applicable to specific steps inside the process (e.g., number of order entry errors). Now comes the question of who should be responsible for these metrics? What is the logic for assignments of responsibility?

The management domain matrix is organized by level of management. For the sake of illustration, let’s have four layers of management, each of which is a “domain” on the chart. There is Business Management (or management of the entire line of business), Region Management, Process Management (or management of this given process), and Function Management (which consists of the managers of all the functional departments that participate in this process).

To fill out the management domain matrix, we take each domain and fill out the cells by answering these questions:

1. Mission/Value Add: What is the value of managing at this level in regards to this particular process? What can this level of management do that the others can’t? For example, the executive team may be the only level that can look at global process performance. The Region Managers can only look at regional process performance. And an individual plant manager can only look at the process performance in his/her plant.
2. Planning: What planning are they responsible for regarding this process? Which goals should they set? What resources do they specify or approve?
3. Performance Monitored: Which of the measures should management at this level be monitoring? What indicators of performance do they need to fulfill the mission? It is useful to also add the frequency of monitoring (weekly, quarterly etc.) What would be leading indicators to predict performance?
4. Looking for…: What deviations are they watching for? Are they looking for trends? What variables are they tracking?
5. Corrective Actions: What corrective actions should they take based on what they are looking for? Should they initiate a resource change? A process improvement?

In our experience, this tool has been extremely helpful in clearing up much of the reigning confusion about process management:

• To start with, it aligns performance planning with ongoing management. Goals are set and resources are allocated in Performance Planned, but as things happen unexpectedly during the performance period, rational adjustments in expectations, resources, or actions can be made, and it is clear who should be making the decisions.
• Identifying responsibilities for planning, measuring, and taking corrective action by management level has been very helpful in getting away from some of the very disruptive management practices that we have seen, with managers from all levels jumping in to put out fires and with nobody practicing fire prevention.
• This tool also helps managers distinguish between managing process performance and managing individual performance. Process management has failed in some companies because there seemed to be little difference between it and what had always gone on, which was generic performance management of individuals. But process management is a different entity, involving the collaborative achievement of people in teams across departments, regions, and whole businesses. The domain matrix makes this kind of responsibility concrete, because a domain may need to be managed by a team whose members are being held jointly accountable for process performance.

With the use of the measures chain and the management domain matrix, we have been able to overcome many of the pitfalls of process management systems that we described in the first article of this series. These two essential tools help create a balanced and logical set of metrics that enable managers at all levels to get insight in critical performance and take action to keep on track. It is process management in the proper context of organization management.

To view figures 1 and 2, download PDF

Related Links

This article is Part 3 of a 3-part series on the topic of metrics and measurement.  For other articles in the series: Part 1, Part 2.

For more detailed information on the management system, consult our book Rediscovering Value.

For a 3-part series of articles on the topic of process ownership, click here: Part 1, Part 2, Part 3.

For an article on the role of management in performance support, click here.

For information on our workshop about Metrics and Process Management, click here.

For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.

For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.

Rummler/Ramias/Wilkins

available early February, 2011

When Improving Performance was published in 1990, it was acclaimed as the book that launched the process improvement revolution -establishing a practical foundation for process improvement and management. In Rediscovering Value, Geary Rummler, Alan Ramias, and Cherie Wilkins establish a foundation for identifying and managing the oft obscured value in organizations. The predominant focus in  most organizations is on resources –the resource dimension. What often suffers or is virtually invisible is the complex system of work that delivers value to customers and thereby shareholders. The key to sustainable success is keeping these two dimension in balance – being able make effective tradeoffs between efficient use of resources and sufficient delivery of value.

Most managers equate the management of resources to effective management – believing value will result by default. It turns out that keeping the resource and value dimensions in balance and making the associated tradeoffs requires more than a subtle enhancement to the role of management in organizations – it requires a  fundamental rethink of the act of management. Thus management itself becomes the third dimension of a sustainably successful enterprise – the 3-D enterprise.

Rediscovering Value presents the executive agenda for making the transition from a typical unbalanced approach to managing organization performance to a true 3-D Enterprise. Readers will appreciate the wealth of practical advice and useful tools found in this book. In addition, the concepts and approach in this book are further supported by a companion book for performance improvement practitioners, White Space Revisited: Creating Value through Process.

The imbalance in the dimensions of organization performance as illuminated in Rediscovering Value, is at the core of many of the “hot button” issues for executive and managers today including failed strategy execution; costly white space between functions, processes, continents, and partner companies; and the inability to improve top line performance. Organizations who can rediscover their value have an effective weapon with which to fight back.

This post is password protected. To view it please enter your password below:

Password:

This post is password protected. To view it please enter your password below:

Password:

BP Trends – September 2010

Authors: Alan Ramias, Cherie Wilkins

Our last column kicked off a series on process metrics.  We started off by citing some of the problems and pitfalls we have encountered in our work with clients, such as creating metrics (and process management roles) that were unlinked to management of the business; creating disorganized piles of metrics instead of a logical set; measuring too much, too little, or the wrong things.

In this column we provide some principles and a tool to remedy the most significant problems.  We will describe the guidelines we follow in creating process metrics for clients and will apply those guidelines using a tool for identifying the right process metrics.  This tool is part of a larger toolkit that we employ when helping an organization build a comprehensive process-focused management system; this particular tool is central to the task of producing good, useful process metrics.

To apply the following principles and tools, some assumptions are necessary:  You have singled out a business process, you have mapped it in enough detail to identify its major subprocesses or phases, and you understand the existing management system into which these process metrics will be inserted.

Principles for Process Metrics Design

• Every process is designed to reliably produce one or more outputs, so, in deciding what metrics to develop, we always focus at first on process outputs, not activities,. The metrics should measure whether the process not only produces the outputs but also that all appropriate expectations are met every time the process is executed.
• Metrics should be applied to all the significant outputs of the process.  If the process is order fulfillment, for example, the output is not just the product but also the invoice, the order documentation, and customer information that will be used again for future orders.
• We always start outside the process itself and try to understand the expectations of the receivers of the outputs.  The receiver may be an actual customer, or it may be an internal party who is also a “customer” for a given output.  Regardless whether the process has an external or internal customer, the starting point is to understand what is important to that customer – what  are the expectations that we can then translate into what we call the “critical dimensions of performance.”  Once we know the expectations for the process, we then create and distribute metrics along the process that measure all of the relevant critical dimensions of performance, such as timeliness, quality, economics, volume, compliance, and so on.
• In first developing metrics, we focus on what to measure, not how measurement is going to happen.  There are several reasons for this:  First, the decision about whether to create a given metric is more important at first than determining exactly how the data might be tracked, reported, archived, and so on.  While measurement can be costly and sometimes not worth the effort, we have watched some teams talk themselves out of a potentially valuable metric just because they weren’t exactly sure at first how to collect the data.  Usually, you have choices as to what to collect and report – for example, maybe you focus only on exceptions, or only reporting quarterly – that can reduce the cost.  And metrics don’t have to be perfect.  Collecting data on secondary indicators of performance may be quite adequate for triggering a closer look, rather than collecting volumes of data that sometimes obscure what is actually going on.  There is also a tendency these days to fixate only on data from systems, but visual data (go and look) and interview data (go and ask) are also viable ways to collect data.
• The most useful performance data helps one see trends in performance.  So, metrics that can be constructed to yield a trend are the most useful, and most metrics can be formulated this way.  For example, “number of defects” for a given output is not that useful except for fixing a single product, but number of defects by product type by day, week, and month could provide a lot of insight into where performance problems are originating.  So in the table below, once we have identified all of the metrics we want, we turn them into trend data by adding an element that enables trend tracking (such as per lot, per day/week/month, per location per week, and the like).
• We seek to identify metrics that will be both leading and lagging indicators of performance.  Lagging indicators are the common ones:  they provide data on events in the past.  But leading indicators provide insight into the future; they center on data that act as an early warning on emerging problems or declining performance.  When chosen well, a leading indicator can signal the need for a course correction before the problem gets out of control.  The tool we describe below is a great way to identify possible leading indicators.

The Measures Chain

The Measures Chain is used to develop metrics for a given process.  The concept is shown in Figure 1.  The essence of this tool is to identify and link external requirements to an internal process. The technique is to start with customer requirements and work backwards and downwards into more detail that would be used for each dimension of performance.

The starting point is outside the process, where the process output is received.  In Figure 1, the process is order fulfillment, the output is a product, an invoice, and order documentation, and the receivers are customers in a given market.   (However, this tool and its principles can be applied to processes that deliver outputs to internal “customers” too.)

Once we know what the customer of the process wants, we can identify where to place appropriate metrics inside the process to see if we are meeting the customer’s expectations.  We end up creating a “chain” of metrics (hence the name) related to some performance requirement, such as timeliness across the process.

To build a Measures Chain for a given process, we usually create a table like the one in Figure 2.  We already know the process inputs and outputs as well as the outputs of each subprocess.  We start by asking what the customer requirements or expectations are.  These become the highest set of metrics – what we call M-1-External.  In Figure 2, the M-1-E metrics for the product are in three dimensions (economics, timeliness, and quality) because the customer has requirements in those three categories. Specifically, the customer cares about percent of deliveries made on time and about price, so those are metrics we place in the table.  We also decide to track customer complaints and returns because those are direct forms of feedback from the customer about product quality.

We then ask if there are additional business requirements for this output.  Business requirements are those things a customer may not necessarily know or care about (our costs, our internal standards, our compliance requirements, etc.), but we want to measure this output against any of those requirements that might exist.  So in Figure 2 you can see business metrics (called M-1-Internal metrics) in the same dimensions of quality, economics, and timeliness, but price is now reclassified as profit, because the business wants to measure how profitable this product is, and timeliness is measured in process cycle time.

Then we go inside the process and place metrics on the outputs of the subprocesses (M-2 level) in the same dimensions of quality, timeliness, and economics.  We can go even lower in the process, down to the activity level, and place M-3 metrics if we think this will provide insight about performance.  For example, the output of the process for writing a book is a manuscript; one of the activities for producing the output is editing.  One M-2 metric is the cycle time to edit the manuscript, but we may want an M-3 metric on the hours spent editing is that is a particularly problematic part of the process.

Possible Pitfalls

The Measures Chain is a great tool for identifying and classifying possible metrics for a given process, but there are some misconceptions to avoid:

It might seem as though the goal is to identify as many metrics in the Measures Chain as possible, but that should not be your aim.  You don’t need a metric for every dimension on every subprocess output.  You will notice in the table in Figure 2 that there are blank cells.  The goal is to identify metrics that provide insight into performance – especially ones that are leading – that give us early warning about possible performance issues.  Nevertheless, it is tempting to fill in all the blanks on a Measures Chain Table.  We have found that the best way to go about this is to fill out the table twice.  The first time, just fill in all the cells with all the metrics that are logically implied.  The second time, go through and choose only those metrics that will provide the greatest insight.

As we said earlier, in creating the Measures Chain, you have not necessarily formulated the metrics in a way that you will want to collect and track data.  For example, how are we going to measure whether every order meets throughput standards?  Will we be able to count every one going through?  Can we date-stamp every order?  Does a computer log show throughput time?  All these are questions to be figured out once there is agreement that we need to track and understand certain kind of process performance, but we haven’t figured out when, where, and how the tracking and reporting will happen, and we don’t know yet who is responsible for keeping watch on the metrics.

In our next article, we will take on some of these questions, and provide some guidance and a tool for determining who should watch what performance data and what they should be looking for.  Till next time.

To View Figures 1 and 2, download PDF

Related Links

Related Links

This article is Part 2 of a 3-part series on the topic of metrics and measurement.  For other articles in the series: Part 1,  Part 3.

For more detailed information on the management system, consult our book Rediscovering Value.

For a 3-part series of articles on the topic of process ownership, click here: Part 1, Part 2, Part 3.

For an article on the role of management in performance support, click here.

For information on our workshop about Metrics and Process Management, click here.

For information on our consulting service where we assist organizations in designing a measurement and management system (or “Organization IQ”), click here.

For information on our consulting service where we assist organizations in designing a process measurement and management system, click here.