Author: Alan Ramias

In most of the process maps I have seen produced by others, the process activities (or steps) are depicted like this:

Version 1

That is, the activities are described with a verb-noun format.  Whenever I have worked with a group of people for the first time and they begin to create process maps (without first being trained by PDL), this is the format they naturally, for some reason, apply.  (I suspect this is “natural” because it follows from the question, “What happens in this process?”  “Well, first we design the engine, then we manufacture the parts…”  It’s a grammatical construct that makes sense and is the way we describe how things happen.)

But those of you who have worked with PDL, or taken one of our process courses—such as the Rummler Process Methodology (RPM) or Process Modeling and Improvement—know that we promote a different approach to the naming of activities.  We say that instead of dwelling on activities, the steps in a process map should identify the accomplishments that are achieved as a result of what are often multiple activities.  That is, we see an accomplishment as generally being at a higher level than a single activity.  It is something more important than an activity, and is also measurable against organizational goals or milestones.

To indicate accomplishments inside the boxes on a process map, we use a noun-verb construct, as follows:

Version 2

You’re likely thinking, “What’s the difference between this map and the first one?”  And of course, there isn’t any in this particular example.  The activities in Version 1 are huge.  Designing an engine is composed of numerous sub-steps or activities that when all completed, constitute the achievement of a major accomplishment.  So reversing the noun and verb doesn’t make any difference.

This is why very often when working with client groups, I tend not to push the accomplishment notion.  I’ll explain it, demonstrate it, and if I’m leading the group in creating a map, I’ll apply it.  But often I can tell that I am the only one who really cares about the notion.  And I’ve learned that if I push it too hard, it tends to be viewed as an academic nicety rather than all that helpful.

So in actual practice, I’ve backed off from a militant application of the accomplishment notion and believe my colleagues at PDL have as well.  But still, there is something of real value here that is being overlooked and perhaps worth reviving.

The Origins of the Accomplishment Model

Geary Rummler was a partner with Tom Gilbert at Praxis Corporation from 1969-1979, where they promoted and applied their pioneering notions about performance technology.   The word “accomplishment” pops up in much of their writing, particularly in Gilbert’s book Human Competence:  Engineering Worthy Performance, in which he argued that results can only be produced by accomplishments. 

During his Rummler Group days, Geary often used a tool he called an Accomplishment Model, which could identify and link all the accomplishments an organization has to achieve, from the highest level down to individual jobs.  (A partial example is shown in Figure 1.)  This device could be used for a variety of diagnostic purposes, such as identifying potential breakdowns in accountability, or overlaps between parts of an organization.

And in process modeling, the concept of an accomplishment was intended to keep a group of process mappers from dropping down into the weeds, into small, insignificant activities.  The use of accomplishments also provides a managerial view of a process, which is important in distinguishing between all the details and the worthiness of the result.  To illustrate, here is a mythical cornball interchange between a visiting executive and a worker operating a drill press at a furniture factory.

Manager:    So what is it you do?

Operator:  Well, first off, I brush off the platen, to make sure there is no sawdust in the way.  Then I choose the next chair leg.  I always choose the right front corner leg if it is the first leg of a chair I am doing because then I work my way around the chair a leg at a time.  Then I align the leg on the platen, bottom toward me, like so.  Then I look to see if I must adjust the drill bit.  This is often the case.  And then…

Manager:   Good God, man, I asked you what you do!

Operator:   I’m telling you what I do.  Then I bring the drill bit down…

Manager:   OK, OK, what is it you accomplish with all this work?

Operator:   Oh.  Well, when I’m finished, the legs are ready to be assembled onto the chair.

The key question always is, “So what got accomplished?  What’s the result?” 

So long live accomplishments.  We shouldn’t lose the concept completely, even though we’ve come to recognize that it may strike some people as largely an academic distinction.

It’s the morning after and your head hurts. It all seemed like such a good idea yesterday, the answer to all your problems. Now, instead of smooth sailing, things seem more like chaos and panic… and lots of questions. No, this isn’t waking up in Vegas. This is the post reorganization reality.

We have seen this time, and time again, in companies who use reorgs as their weapon of choice to address poor performance or make improvements. They believe that “boxology” (the art of rearranging the boxes on the organization chart) can provide the solution to any number of performance issues; centralize to reduce cost; co-locate to provide more focus; consolidate under the “strongest” manager; increase span of control to get things under control.

The problem with this approach is that it is “one-dimensional” thinking. It is focused on only one dimension of the organizations performance equation; the resource dimension. It ignores completely the work system or value dimension. When you simply rearrange the resources, you are not addressing how the work gets done. In fact, you have probably temporarily (or permanently) disrupted how the work gets done. It takes time for the resources to figure out the new pathways and processes to do the work they did before.  For example, in one organization, a department who had been paying all of their invoices on time, was moved from HR over to Finance. Suddenly they were 30 days late in paying their invoices because nobody could figure out the new approval paths for the payables. In most reorganizations the value dimensions (work systems and processes) are not thoughtfully redesigned as a part of the change. For every process that these resources participate in, what are the changes in roles and responsibilities? What steps do they perform differently? What support and resources have changed? Are the escalation paths changed? Are the approval paths changed? Are there changes in policy? Are there changes in standards?

Boxology usually ignores the other dimension in the performance equation; the management dimension. Although most reorgs are about moving resources from one manager’s domain to another’s, there is rarely a thoughtful redesign of the management system that goes with those resources. What needs to be planned differently? What new performance support needs to be in place? What different metrics should be monitored? What new corrective actions should we be taking to keep on course?

By thoughtfully addressing all 3 dimensions of performance, resource, value and management, organizations can avoid waking up in Vegas after reorganizing. A 3-D approach to change can ensure that the performance issues are really addressed and the results are sustainable.

For more on the 3-D approach to improvement read Rediscovering Value or White Space Revisited.

http://www.performancedesignlab.com/seeing-a-process-the-power-of-visual-analysis

BPTrends, March 2013

Author: Chris Ramias

This month Alan Ramias and Cherie Wilkins have invited Chris Ramias, a colleague at Performance Design Labs to describe a technique he calls “visual analysis.” This technique goes beyond simply identifying the problem in a process to actually determining its root cause. Chris identifies a list of issues you may encounter when reviewing a process model and provides visual diagrams to analyze each one.

Download PDF

Geary Rummler on Needs Analysis – 1986

Geary Rummler on Performance Engineering – 1986

For more of Geary’s work, please visit the Geary Rummler Publication Library.

BPTrends, December 2012

Authors: Alan Ramias, Cherie Wilkins

Role/Responsibility Charting in Improvement Efforts

One of the most versatile items in the performance improvement specialist’s toolkit is the role- responsibility matrix (or RRM). We have been using this handy, easy-to-apply tool for decades in all kinds of project efforts, including:

• Process improvement projects
• Job/role redesign projects
• Organization redesign projects
• Project management

Over the years we’ve come up with a number of refinements to the standard tool and its usage, which we describe in this article.

The Basic Model

The standard format for an RRM is shown in Figure 1 (Note: Figures can be seen via downloading the PDF, linked above). It consists of a chart with steps or tasks listed on the vertical axis and the responsible parties along the horizontal axis. Typically the tasks are derived from another model such as a cross-functional process map, or “swimlane” chart.

The cells within the chart may be simply filled out with X’s, as shown in Figure 1, indicating who performs or is accountable for each task. But we have found it helpful to go further, and in each cell, we describe in greater detail exactly what is being accomplished. Figure 2 shows an example of an RRM employed this way. The RRM in this example links a business process to the jobs and performers who participate in the process. The RRM is based on a cross-functional process map but describes in more detail what is happening at each step in the process. This RRM was created by simply turning the cross-functional map on its side, so that the process steps run along the vertical axis and the participants run across the columns at the top. Note that we have allocated one column to the “System”, thus recognizing that some of the process steps may be enabled or performed by some software system.

Why create an RRM? Well, as you can see in Figure 2, we have teased out more information about each step in the process than what appeared on the process map. It turns out that both steps 1 and 2 are fairly complex and that may be important to know. For example, we might be analyzing an as-is process, and this detailed information could be helpful in better understanding the steps, and in figuring out why some steps are performed poorly. If we are creating a to-be process, this RRM might be valuable in identifying the steps that will take more time, effort or skill.

In either case, the RRM supplements the process map but doesn’t replace it. Whether we go back to the process map and add these newly discovered sub steps is a decision that has to be made, but one key value of the RRM is that it enriches the details about how a process works (or will work in the future) but without adding so many steps and sub-processes to the process map that the main flow is hard to identify. PARIS Coding To further enrich the RRM, we often using a coding system of our own invention, called PARIS. (Figure 3 shows our RRM with PARIS codes.) PARIS is similar to RACI, which is very commonly used by people who create RRM’s. We prefer PARIS because in our view it provides a more thorough understanding of the process steps. Here is a comparison of the two codes:

(Note: Please download the PDF linked at the top of this page to view figures and tables in this article)

One of the key differences between RACI and PARIS is the “Accountable” designation. Our belief is that accountability belongs to both the performer and the approver and thus is satisfactorily addressed in PARIS. The other main difference is “Informed” but we have seldom seen this designation used.

Regardless which coding system you use, the purpose is to further elucidate what is going on in the process. Very often, unless we complete an RRM, details like inputs or support are either ignored or simply not recognized as necessary parts of the process, but successful performance may very well depend on them. For example, if the RRM in Figure 3 is for a process being redesigned, we might not recognize that the driver is providing his location via the company’s GPS tracking system and thus we fail to identify that system requirement.

Coding Challenges

Sometimes complexities can arise in correctly coding an RRM:

1. Multiple performers: Normally only one function should be identified as the performer (P), which establishes clear accountability. Sometimes, however, more than one function shares a responsibility and each considers itself in charge and/or accountable.  In such a case, try to get one of the functions to treat its role as support (S) and code it accordingly. lf that is not acceptable, use a P for each function participating in the task.
2. Review and Approve: Sometimes it will be argued that giving approval (A) must include reviewing (R), so such a task should be coded as R/A. Fine, this is a point not worth arguing about.
3. Review, Approve and Input: Sometimes it is also argued that giving an approval is also an input, so now you have R/A/I. That seems like hairsplitting, though, and the better option would be to simply code the activity for its primary intention, which is an approval (A).
4. Consult: The designation of R is meant to include activities commonly thought of as providing expert advice, but some people used to RACI may insist on the word “consult” instead of “review”. Fine, go ahead and substitute a C for any R where the activity is to provide advice during the performance rather than review after the performance has been executed.
5. Review and Input: Usually when an individual or function reviews a product, they provide feedback or advice. For example, the Legal Department may review a proposal and offer a legal opinion on the soundness of the proposal. Like point #3 above, some would interpret this as both a review (reading and evaluating the proposal) and then providing an input (the legal opinion itself). Fine, go ahead and code the activity as R/l, but again it seems like hairsplitting.

Application of the RRM Tool for Job/Organization Design

In the examples we described above, the RRM is being used in support of process analysis and improvement. But it can also be employed as a device for job, department or organization analysis and design, although some changes are required. A process-based RRM like Figures 2 and 3 does not necessarily represent all the work performed by the involved functional areas of Order Entry, Dispatch and Driver Pool.

But the basic RRM format is easily modified so that the vertical axis contains all the tasks that a department does, and thus all the work performed by its employees. We could also create a higher-level RRM that lists all of an organizations major work processes on the vertical axis and all of its departments across the top. We could even do this across several organizations, each containing multiple departments.

Not only does an RRM tease out details about how work is performed, it can help to identify a number of common organizational problems such as:

• Ambiguity about who is responsible for work
• Redundancies in responsibilities
• Lack of clear ownership or accountability for tasks
• Lack of clarity for collaboration or support of performers
• “White space” between parties in a process, especially where work is supposed to get handed off
• Lack of understanding about what it actually takes to get a task or process accomplished

Summary

One of the tools that should be in the utility belt of every improvement practitioner is the Role- Responsibility Matrix, or RRM. This simple chart is useful for both analysis and design work, and can be applied at virtually any level, from a single process to multiple ones, from a single department to many, from one organization to several. in each of these applications, the value of the tool is what it visually captures and reveals to make the work of improvement more thorough and effective.

http://www.performancedesignlab.com/rummler-library

This webpage provides a comprehensive list of Geary’s published writing.  As much as possible, we’ve attempted to provide the actual articles for you to read.  As those who knew Geary are aware, this library is a treasure trove of learning.

The library was updated today with around two dozen new and updated articles.  Check it out!

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

Password:

But selecting, designing, implementing, and using metrics is a complex set of activities and loaded with pitfalls, and enabling software can either help or make it worse, depending on the human intelligence being applied to such questions as what to measure, when to measure, who should be watching performance, what to do with data, and how to diagnose and react to performance issues.

Performance Design Lab has a proven track record at understanding and addressing the issues surrounding process metrics, and implementing working solutions to managing process performance.  Our approach to business process management has been adopted by Fortune 100 companies and multinational corporations for the past 25 years.  We are known for both teaching of a set of proven management principles and partnering in their application.

Resources

Performance Design Lab’s approach to process measurement and management and associated tools and models are described in detail in our book ReDiscovering Value: Leading the 3-D Enterprise to Sustainable Success.  The links on this page will provide you with further information on our approach. Hopefully, we can help you avoid some  of the difficulties we have experienced and to speed you forward to effective design, implementation, and use of process metrics.

Online Resources

We wrote a series of articles for Business Process Trends on the subject of metrics and process management.  To view the articles, click on the links for Part 1, Part 2, Part 3.

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.

If you are a practitioner working on implementing process metrics or process management, and are interested in coaching from a PDL partner to ensure you take the right approach, please contact us for further information.

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

Password:

BPTrends, September 2012

Authors: Alan Ramias, Cherie Wilkins

Uses of the 3-Dimensional Enterprise Model

In our book Rediscovering Value, we provided a model for describing the major components of any organization. The 3-dimensional model (shown in Figure 1) applies to any enterprise. When introducing this model to clients, we make the following points:

• Every organization exists to produce goods or services that are meant to be of value to some receiving entity, such as a marketplace.
• Every organization also has to satisfy the expectations and requirements of some external stakeholders, whether owners, shareholders or others.
• To satisfy both demands, the organization must have in place three dimensions: a value dimension consisting of a work system to produce the goods and services; a resource dimension containing all of the resources required to perform the work; and a management dimension with a system to design the other two dimensions and to keep them in balance.

The purpose of this deliberately simple model was originally to help us in positioning processes (i.e., the work system) in their larger organizational context in order to explain why there often seems to be such ambiguity in the minds of people unfamiliar with processes about what those things are. With the 3-D model we could point out that managers often focus most of their attention on the resource dimension, which is tangible, visible, and frankly where the money is.

By contrast, many managers are far less clear about the work system. There is often confusion when organizations aim the majority of their so-called process improvement efforts at the resource dimension.
We didn’t expect to do much more with the 3-D model than to use it to explain this imbalance in managerial attention. But we are finding some of our clients applying the model to analysis and design. The model provides a great way to talk to senior people about performance — it is at the right level and seems to resonate with executives who typically have little patience with more complex depictions of process architectures and work systems. The underlying theme is the need for balance of the three dimensions. Here is an example of how we have seen the 3-D model being applied as a tool:

As a Design Tool

A fledgling performance department in a large utility company was built around the model. The organization, its processes and the management system were all designed simultaneously. Once up and running they were able to bring the model to their client organizations.

When introduced to the 3-D model, the managers of this department recognized that they were indeed spending most of their time planning and adjusting the resource dimension. One manager who had just decreed a major reorganization commented to us that he realized that he was trying to solve his division’s issues through a reshuffling of the resources and asked that we help him to also work on the other two dimensions-management and process-in order that he might successfully address the issues. We helped them redefine the processes as they would work in the new organization and identify metrics and management roles and responsibilities.

As an Analysis Tool

Gradually the 3-D model caught on as an analysis tool. The Performance Department mapped all of their requests for support (their portfolio) onto a version of the 3-D model that showed all of the client organizations~ processes as well as their resources and management systems. They were able to see synergies and overlaps between requests and the review became a method of prioritizing their work. If a cluster of requests from several sources (regions or departments) were in fact all related to a common process, it was given a higher priority. It also told them that there was a lack of focus on the management system, which they knew to be problematic.

As a Support Tool

One of the most valuable concepts the Performance Department was able to bring to their clients was a “Manager’s Playbook.” The playbook was organized around the 3-D model. These devices were intended to address the inattention to the value and management dimensions prevailing in many areas. The playbook gave the managers and supervisors of a given department:

• Visual Maps of 12 types of work orders showing the handoffs between work groups. Also included were concise written explanations of the work. (Value dimension)
• A troubleshooting guide providing information to assist with evaluating and responding to undesirable performance results. (Management dimension)
• Event calendars to ensure performance results are included in the day-to-day operations of the organization. (Management dimension – ensuring that the value dimension is managed in an integrated way with the resource dimension)

The 3-D model is simple, yes, but a powerful concept and also a potentially useful tool. Particularly with executive teams, the 3-D model can be used to show the missing pieces in a proposed organizational change, or the tendency to try to fix every problem by tinkering with resources (including all forms of downsizing, rightsizing, outsourcing, insourcing and restructuring), or the need to have the work system clearly defined, or the insufficient attention paid to the management system. Where more complex models and diagrams might fail to communicate effectively, the 3-D model is an alternative to consider.

Workshop Length:

2 Days

Who Should Attend:

Process Improvement Practitioners, Performance Consultants and individuals who have been assigned to perform process improvement work in their organizations. Secondarily, the training can be useful for sponsors of process improvement initiatives.

The Business Process Architecture (which we also refer to as a “Business Process Framework”) is a high-level roll-up of the data that is frequently captured in lower-level process documentation, such as cross-functional process maps, role-responsibility matrices, and so on.  the BPA shows all of the significant processes – that is, value creation processes, management processes, and contributing processes – of a given organization, and the systemic interrelationships between those processes.  This tool provides executives and employees with a common definition of all the major processes of the business, on one page.  The document is a concise summary of the value-adding work that must be performed and managed to provide products/services to customers.  The picture is a work-centric picture and does not reflect who does the work.  Therefore, the primary focus of dialogue, troubleshooting, and decision making stays on the work and on the creation and delivery of value.

Example of a Business Process Architecture:

Resources

The Business Process Architecture is one component of the Value Creation Architecture documentation set, described in detail in our book White Space Revisited: Creating Value through Process. This means that for each process depicted at a high level on the BPA, there is additional detailed documentation available such as the more typical cross-functional process map.  The BPA serves as a useful tool for executives and managers who need to understand processes in their area for business purposes (such as setting strategy or targeting improvements), without the need to get bogged down in detailed documentation.  For the practitioner, the BPA serves as an organizing tool for process documentation, and to facilitate communication with others in the organization to ensure that everyone from executives to employees to practitioners are using a common vocabulary when describing processes.

Online Resources

To read an article that describes a number of organizations’ experiences with using a Business Process Architecture, click here.

To read a case study on a company that we engaged in helping define and use their Business Process Framework (aka (Business Process Architecture), click here.

For a presentation on the topic of the Business Process Architecture, click here.

For information about PDL’s consulting service, where we assist organizations in defining their Business Process Architecture, click here.

For information about our workshops, click here.  The BPF is a key tool in Performance Design Lab methodology, so it is taught in a number of different workshops.  The  Business Process Architecture workshop, specifically, teaches the core models and concepts of the PDL approach to architecture.

If you are a practitioner working on developing a Business Process Framework, and are interested in coaching from a PDL Partner on the right approach, please contact us for information.

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!