Discussion Post And Summary/Case study for (A-Plus Writer)

Discuss and describe the Role of Analyst. The Role of the Line Manager as Analyst is examined in chapter 2. What is the most significant take away from the content you evaluated? Why is this chapter important?  Provide a minimum of 250 words in your initial post. 

Next write a summary

choose 3 subjects of your own interest, from weekly chapter readings. They are to write an APA style 3 paragraph minimum synthesizing those subjects. Should have a cover page and references page, too. Summary should also include an applied reaction concept. As an example: How would you apply this information to the work place? Review the chapters to help focus areas of summary. Use this assignment to demonstrate your level of comprehension.

Human Performance Improvement (Improving Human Performance) Author: Pershing

2nd Edition: Rothwell, Hohne, King

2 The Role of Analyst Chapter 1 set the stage for human performance improvement by defining foundational terms and by emphasizing the importance of HPI. The HPI process model was presented as a systematic way to approach performance improvement efforts in organizations. The first chapter provided a broad overview of HPI. This chapter descends from that high-level perspective and zeroes in on the first role associated with HPI—that is, the analyst role. This role, as well as the six key competencies and associated outputs, is defined and described in this chapter. An important goal is to introduce readers to some key analytical tools and models used by HPI practitioners as they analyze human performance problems and improvement opportunities. The chapter details practical strategies for enacting the analyst role and opens with a case to dramatize the importance of analysis and the role of the analyst. A Case Study As your read the following case study, think about the role played by the people in the case. The Setting* The San Diego Unified School District, the nation’s eighth largest school district, provides an array of programs for which transportation services are provided. For these programs, the district’s transportation department buses nearly 16,000 students each school day. Smooth operations depend on a cooperative relationship between transportation staffers (particularly dispatchers and clerks) and school staff personnel. The principal at each school selects a transportation site liaison each school year. The liaison assignment is a duty in addition to regular responsibilities and assignments. The duties of the site liaisons include: Being an advocate on behalf of students and parents Promoting resident school programs, especially those supported by the transportation service Implementing, supporting, and explaining relevant district and transportation department policies and decisions The Problem/Opportunity Both the coordinator of one of the district’s major desegregation programs and the assistant director of Transportation Services were being deluged by complaints about poor transportation services, especially when those services were seen to impact the district’s desegregation programs. The district first sought to design a new manual to provide better guidelines for the site liaisons. The nature of the complaints suggested that the problems might require more than a simple training solution. Some of the complaints identified problems that were beyond the control of the site liaisons, no matter how well-trained they might be. Other complaints, however, suggested that some of the problems seemed to originate outside the scope of the site liaison’s responsibilities. The Performance Technology Solution An extensive performance analysis was conducted, including: An examination of relevant transportation and related records Interviews with program administrators, transportation staff members, school personnel, and parents Reviews of existing school bulletins and directives A review of the existing manual for site liaisons The findings of the performance analysis pointed to several situations and conditions. In addition to the need for formal training of site liaisons: Liaison duties varied from one school site to another, depending, in part, on the liaison’s paid position; Problem resolution was impacted by an outdated phone system; No one at the transportation department was assigned responsibility for resolving chronic service problems; Liaisons expressed frustration over defending transportation department decisions in which they had played no role. Results As a result of these findings, recommendations were made and implemented, such as: The transportation department now provides biannual formal training of site liaisons; A new Transportation Site Liaison Handbook has been developed; The transportation department’s vision and mission statements stress customer satisfaction as well as bus routes and schedules; Transportation staffers regularly visit school sites to advise and better understand the environments in which liaisons work; Liaisons can air concerns in a special column added to the transportation department newsletter; Principals have been given district-provided selection criteria; A new phone system has been installed to improve accessibility. The number of complaints regarding transportation service has dropped dramatically. The site liaisons have a clearer view of their responsibilities and authorities. The new phone system has greatly facilitated problem resolution, and transportation staffers and site liaisons report improved working and personal relationships. Thus, the first step in the performance technology process, analysis, proved instrumental in uncovering the real causes of the problems of the transportation department, thus assuring that the recommended solutions would achieve the desired results: better performance and fewer complaints. Defining Analysis Analysis serves a vital purpose in performance improvement efforts conducted in organizational settings. Various methods were employed in the case study to accurately identify and define the problem. As shall be seen, many have argued that analysis is the most important aspect in the entire HPI process. The purpose of analysis in performance improvement efforts is comparable to the diagnostic process undertaken by physicians. Before a physician prescribes a treatment for an ailing patient, the patient is systematically diagnosed. Through this careful analysis, in which various tools and mental models are utilized, the physician identifies the problem’s source, determines possible causes, isolates the most acute cause(s), and makes an accurate diagnosis that sets in motion therapeutic treatment. The treatment is akin to the focus of the next chapter, which will deal with intervention selection. The parallels with analysis in human performance improvement are close. HPI practitioners sometimes use the doctor-patient approach. Through the diagnostic phase of human performance analysis, the HPI practitioner can troubleshoot the cause(s) of the problem and then select appropriate human performance improvement intervention(s)—that is, the “cures” or the “solutions”—to address those causes. The purpose of analysis, then, is to accurately diagnose the problem or situation and set the stage so that the appropriate intervention(s) can be selected, implemented, and evaluated to achieve positive performance results and outcomes. It should be noted that many practitioners have assumed a less-directive stance and attempt to facilitate HPI efforts among others in the organization. This, however, in no way diminishes the emphasis placed on analysis. In fact, the partnership or collaborative approach to performance analysis is clearly an approach that can help to build not only the trust and confidence of the client but also the buy-in and commitment to the eventual solution that arises from the analysis efforts. Thomas Gilbert (1982), a pioneer of the performance improvement field, provided another excellent context for viewing analysis and its position and purpose in human performance improvement work. He wrote: To cope with the explosion of thoughts and answers, we need some framework—some sets of questions—to help us keep an eye on what we are trying to accomplish and to sort out, in some logical way, the useful means for accomplishing it. Performance analysis provides such a structure. It is an attempt at a method of disciplining ourselves as we seek to delineate our problems before we rush into a solution. The Importance of Analysis Many people who have written about HPI tout the importance of analysis. HPI practitioners must “diagnose situations before implementing solutions” (Rummler and Brache, 1995). To cite a few other examples of authors who have emphasized the importance of analysis, consider the following memorable quotes: “Because the analysis phase defines, frames, and directs the remaining steps, it is considered the most critical” (Swanson, 1994). “The foundation of the HPT model is the analysis of human performance” (Elliot, 1996). “Without analysis, there is no Human Performance Technology (HPT). Analysis provides the foundation for HPT, a profession and a perspective that demands study before recommendations, data before decisions, and involvement before actions” (Rossett, 1999a). “The most important human performance improvement role is that of analyst” (Kirrane, 1997). Many other practitioners and researchers have echoed the importance of analysis (see Spitzer, 1988; Hutchison, 1990; Robinson and Robinson, 1995; Marker, 1995; Harless, 1995; Rossett and Czech, 1995; and Medsker, Stepich, and Rowland, 1995). The number of quotations and references is ample testimony to the importance of analysis. We agree to the criticality of analysis, and our intent for the remainder of this chapter is to introduce readers to key definitions as well as to practical models and tools for carrying out analysis activities. Definitions of Analysis As a process, analysis wears many labels. Recall that the definition for the role of the analyst was presented earlier in this chapter. Analysis has a number of names, including all of the following: Front-end analysis (Harless, 1973) Performance analysis (Gilbert, 1978; Sleezer, 1992) Performance assessment (Robinson and Robinson, 1995) Performance audit (Rothwell, 1989) Performance diagnosis (Ruona and Lyford-Nojima, 1997) Training needs assessment (Rossett, 1987) Needs analysis (Kaufman, 1986) While there is some conceptual overlap among the meanings of these terms, there is also much inconsistency. Some authors, for instance, have expressed disdain over the term “training needs assessment” (Watkins and Kaufman, 1996). They argue that attaching the word training to needs assessment represents an erroneous assumption that training is the appropriate solution before knowing if a problem exists and (if it does) what causes it. While a wide variety of terms, definitions, and perspectives exists, it is critical to convey the definitions and assumptions that will be used in this context. Analysis, for the purpose of this book, is an assessment and analysis of human performance rather than of training or other prescriptive purposes. Anyone who undertakes analysis concentrates on identifying problems or opportunities in these areas and surfacing the cause(s) so that one or more appropriate interventions can be recommended that will lead to improvement. There are two steps in the HPI process model that are linked with the role of the analyst. These are performance analysis and cause analysis. Both are described below. Performance Analysis Performance analysis is “the process of identifying the organization’s performance requirements and comparing them to its objectives and capabilities” (Rothwell, 2000). It involves the identification of gaps, or discrepancies, in performance. A discrepancy can be thought of as the difference between current and desired performance levels. Allison Rossett (1999b) uses the terms “optimals” and “actuals.” For example, if a customer care center’s desired performance (optimals) is a 30-second wait time and the current performance level is a 55-second wait (actuals), then the discrepancy—the performance gap—is 25 seconds. Twenty-five seconds may not seem like a huge gap at first glance, but if translated into a dollar value, it could be worth millions. Through this simple example it probably becomes readily apparent how performance analysis begins to set the stage for evaluation—the last stage of the HPI process. The description of a discrepancy shown in Figure 2-1 is frequently cited as a simple formula: Desired Performance – Current Performance = Performance Gap or Discrepancy. In addition to defining the gap in performance, part of the performance analysis process involves assessing (or at least estimating) the impact, results, or consequences of the discrepancy. Another way of viewing the impact of the discrepancy is to ascertain how much “pain” is being felt by organizational stakeholders as a result of the gap. There are direct costs, such as poor quality resulting in products that cannot be sold, downtime, or other tangible costs to the organization. Then there are opportunity costs that are not quite as easy to measure but that have a direct impact on the bottom line, such as missed sales and less-than-optimum productivity. Finally, there are intangible costs, such as employees’ morale and customer confidence. While these are difficult to assign an actual cost to, they are critical factors in determining the true “pain” an organization is experiencing due to a performance problem. Figure 2-1 Performance gap or discrepancy. Why is determining the impact so important? One reason is to ensure that the cost of minimizing or eliminating the problem does not exceed the cost of the problem in the first place, thus resulting in a negative return on investment (ROI). In most cases, the true cost of a performance discrepancy is far greater than management realizes. Therefore, calculating this cost, and sharing it with management at the onset of a performance improvement effort, will help you generate management support for your work. In addition to assessing problems, performance analysis can involve assessing opportunities for new performance as well. For example, if new technology is to be introduced into an organization, then desired performance levels can be determined and analyzed void of any immediate problems. The notion of focusing on what could be in an ideal world has received much attention in recent years. Much of this popularity can be indirectly linked to the work of David Cooperider in the area of appreciative inquiry, which focuses not on fixing problems but on finding possibilities, often drawing upon people’s most positive experiences to envision success (Cooperrider et al, 2000; Cooperrider and Whitney, 2005). The outcome of performance analysis, according to ASTD Models for Human Performance Improvement, “should be a clear description of existing and desired conditions surrounding performance” (Rothwell, 2000). Cause Analysis The second part of analysis is cause analysis. Cause analysis is defined as “the process of determining the root cause(s) of past, present, or future performance gaps. It follows, but is integrally related to, performance analysis” (Rothwell, 2000). Cause analysis involves examining the discrepancies identified through performance analysis and determining their root cause(s). In other words, cause analysis attempts to determine the reason for the discrepancy. Returning to our customer care center example, the performance analyst, upon defining the gap of 25 seconds in wait time (current wait time of 55 seconds minus a desired wait time of 30 seconds), would now begin determining the reason(s) for this discrepancy. Perhaps the gap is due to understaffing, perhaps some call center reps are on a slower technology than others, perhaps there are spikes in call volumes during certain times of the day, perhaps no one has ever informed the reps of the goal of 30 seconds, perhaps reps have never received feedback on their current performance—perhaps, perhaps, perhaps. As you have gathered, the reasons for a gap in performance are limitless, and thus, the purpose of cause analysis is to figure out what factors are truly affecting performance. Many tools and models exist that can be applied to determining the cause(s) of performance problems. Some are described later in this chapter. The outcome of cause analysis “should be a clear description of the cause(s) of the performance gaps” (Rothwell, 2000). Levels of Analysis Performance can be viewed from several vantage points, including the organizational level, the work or process level, and the individual performer level (Rummler and Brache, 1990). Describing performance according to these levels helps those who conduct analysis to more clearly delineate the scope of what they are investigating, while also establishing an understanding of the interrelationships among the levels. Moving from highest to lowest, the organizational level of analysis focuses on the ability of the organization to meet customer needs, compete in the marketplace, carry out strategies, and achieve goals, such as sales, profitability, safety, and market share. Analysts will sometimes find themselves explaining performance issues at this higher, more strategic level. They may also begin analysis efforts at this level and “drill down” to isolate key variables at the other levels. The work or process level deals with the internal systems and processes that are in place to achieve the goals of the organization. Many organizations have been experimenting with process improvement strategies, such as continuous improvement programs, Six Sigma efforts, and other similar initiatives, and those are clearly focused on this level of analysis. Finally, the individual performer level of analysis relates to the people carrying out work activities in the organization. Taken collectively, these individual performers produce results through the organizational processes that contribute to the overall performance of the organization. Various models and tools, which are introduced later in this chapter, can be helpful in analyzing performance at each level. The Analyst’s Role According to ASTD Models for Human Performance Improvement (Rothwell, 2000), the analyst is the role that “conducts troubleshooting to isolate the cause(s) of human performance gaps or identifies areas in which human performance can be improved.” The role is linked directly to performance analysis and cause analysis in the HPI process model appearing in Models. Competencies Associated with the Role of Analyst ASTD Models for Human Performance Improvement identified six key competencies that are associated with the role of the analyst. They represent the important characteristics that contribute to exemplary performance and success in the role. Chapter 8 also discusses a self-assessment tool that can be used to calculate individual development needs. In addition, Appendix III provides a comprehensive list of resources, current at the time this book went to press, for building competence in each competency area. The six competencies linked to the analyst role are (Rothwell, 2000): Performance analysis skills (front-end analysis): Comparing actual and ideal performance in order to identify performance gaps or opportunities Needs analysis survey design and development skills (open-ended and structured): Preparing written (mail), oral (phone), or electronic (e-mail) surveys using open-ended (essay) and closed (scaled) questions in order to identify human performance needs Competency identification skills: Identifying the knowledge and skill requirements of teams, jobs, tasks, roles, and work Questioning skills: Gathering pertinent information to stimulate insight in individuals and groups through the use of interviews and other probing methods Analytical skills (synthesis): Breaking down the components of a larger whole and reassembling them to achieve improved human performance Work environment analytical skills: Examining work environments for issues or characteristics affecting human performance Outputs Linked to the Role Each competency of the analyst role is linked to a number of outputs that generally represent the tangible outcomes or results that are produced when someone enacts the competencies. Figure 2-2 lists the outputs related to each of the six analyst competencies. As you read through the list, you may wish to compare some of the outputs you currently produce—if you are employed and have an opportunity to apply HPI—with those shown in Figure 2-2. Are there outputs that you do not produce in your job? Are there outputs that you currently produce that are not shown? What It All Means Taken together, the role, competencies, and work outputs of the analyst are the foundation upon which the HPI model can stand. HPI is data driven; therefore, the role of analyst is the most critical factor in the entire process. The outputs of this role are the basis for all decisions forthcoming in the performance improvement efforts. If the mark is missed at this stage, tremendous amounts of time, effort, and financial resources may be squandered on activity that does not solve the problem or achieve the goal. Analysts may apply their competencies as illustrated by the following examples: With performance analysis skills (front-end analysis), analysts may:   Identify the best sources of data to identify existing gaps or expected gaps due to anticipated changes in the work processes or environment   Work with job holders, their managers, exemplary (star) performers, and possibly their customers to complete job and task analyses With needs analysis survey design and development skills (open-ended and structured), analysts may:   Develop surveys to gather information on what is currently happening in the organization   Work with management to help identify pertinent demographic information that should be gathered to report data in a meaningful way With competency identification skills, analysts may:   Utilize job and task analysis data to identify core and role-specific competencies for jobs and job families   Create job descriptions for use in selection and hiring, job evaluation, and employee development   Create 360-degree assessment tools With questioning skills, analysts may:   Interview key stakeholders who can provide essential input to determine the root cause(s) of a performance gap   Prepare hiring and selection interview protocols   Lead stakeholders through a process of discovery With analytical skills (synthesis), analysts may:   Utilize the data gathered from a survey or other data collection method and decipher the pertinent information that provides insight into the root cause(s) of a performance problem   Interpret qualitative data and identify themes that provide insight into the cause(s) of performance gaps With work environment analytical skills, analysts may:   Study the physical layout of the work area and identify features that are impacting, enhancing, or impeding performance Investigate the channels of communication to determine if any barriers to information exist   Determine an opportune way to achieve business results given the barriers and constraints in a given situation Analyst Role Terminal Output Conducts troubleshooting to isolate the cause(s) of human performance gaps or one who identifies areas in which human performance can be improved. Persuasive reports to stakeholders about past, present and future performance gaps and their cause(s) Analyst Competencies Enabling Outputs 1.  Performance Analysis Skills (Front-End Analysis): The process of comparing actual and ideal performance in order to identify performance gaps or opportunities. Models and plans to guide troubleshooting of human performance gaps Work plans to guide performance analysis Information on trends affecting existing or possible future performance gaps Task analysis Job analysis Observations* 2.  Needs Analysis Survey Design and Development Skills (Open-Ended and Structured): Preparing written (mail), oral (phone) or electronic (e-mail) surveys using open-ended (essay) and closed (scaled) questions to identify human performance improvement needs. Written (mail) surveys Oral (phone) surveys Electronic (e-mail) surveys Survey administration plans Research designs Data analysis and interpretation plans Reports of needs analysis surveys Statistical summaries of needs analysis results Content analysis summaries of needs analysis results 3.  Competency Identification Skill: Identifying the knowledge and skill requirements of teams, jobs, tasks, roles, and work (McLagen,1989). Work portfolios Job descriptions Behavioral events interview guides Written critical incident survey questionnaires Competency models by function, process, organization or work category 360-degree assessments 4.  Questioning Skill: Gathering information to stimulate insight in individuals and groups through use of interviews and other probing methods (McLagen, 1989). Interview guides Interview administration plans Content analyses of interview results Team meeting agendas and plans Focus groups* 5.  Analytical Skill (Synthesis): Breaking down the components of a larger whole and reassembling them to achieve improved human performance. Strategies for analyzing the root cause(s) of performance gaps Fishbone diagrams Storyboards of problem events 6.  Work Environment Analytical Skill: Examining work environments for issues or characteristics affecting human performance. Environmental scans Business/organization plans Team/group plans Process improvement strategies/plans * Additional outputs identified by King, S. B. (1998). Practitioner Verification of the Human Performance Improvement Analyst Competencies and Outputs. Doctoral Dissertation. University Park, PA. Figure 2-2 Analyst competencies and associated outputs. Source: Rothwell, W. (2000). ASTD Models for Human Performance Improvement: Roles, Competencies, and Outputs. 2nd ed. Alexandria, VA: The American Society for Training and Development. Used by permission of the American Society for Training and Development. Being able to identify the performance gap(s) that exist in an organization and then determine the root cause(s) of those gaps are the most critical skills of the analyst. Thus, perhaps performance analysis skills are the most critical to success in this role. Models and Tools Basic analytical tools must be mastered by all HPI practitioners for them to be successful (Carr and Totzke, 1995). The practice of HPI is replete with models and tools. A model is essentially a representation of some real-world phenomenon that is used for descriptive purposes. A city street map is an example of a common model because it represents an actual physical place. A map is useful for providing directions to someone who is seeking a destination, landmarks, and other points of interest. A model that may be used for HPI purposes serves a similar purpose in that it represents a way in which problems can be framed or activities can be described. Similar to models, tools help HPI practitioners conduct analysis. They give some degree of structure to an otherwise fluid process. While some distinguish between models and tools, they are discussed together here in order to introduce readers to practical approaches to conducting analysis. Models and tools provide an analyst with organized and systematic methods for examining human performance problems and performance improvement opportunities. Similar to a hammer or a saw for a carpenter, analytical models and processes are contained in the toolbox of HPI practitioners to help them conduct their work efficiently and effectively. They provide the methods by which to examine performance problems and opportunities, and they provide the foundation by which subsequent improvement and evaluation efforts are organized and implemented. The analytical models used by HPI practitioners can be categorized in a number of ways. Some models are comprehensive and thus assume a high-level, holistic focus, such as analysis at the organizational level. In contrast, other models are considered situational because they focus on a specific problem or situation. Another way to think of models is that some are most useful for describing current conditions, while others are most useful for exploring the root cause(s) of problems. This section reviews sources of data and then some of the more commonly used models and tools of HPI practitioners. Sources of Data Since HPI is data driven, the important topic of sources of data should be discussed. The focus is often on quantitative (numeric) performance measures concerning issues of quality, productivity, cost, timeliness, profitability, and so on. Equally important are qualitative (nonnumeric) data that exist. A number of potential sources of data can be drawn upon to gain insight and information to drive an analyst’s performance improvement efforts (see Figure 2-3). As can be seen in this chart, data can come from various human or nonhuman sources. During HPI efforts, an analyst may be working with existing data (referred to as extant data), such as production or quality reports, or may be involved with generating new data, such as gathering data by conducting a survey. Human Sources Nonhuman Sources Employees Work records Supervisors Exit interviews Executives Help desk logs Clients/customers Absentee reports Vendors/suppliers Performance appraisal data Star performers Financial reports Subject experts Sales logs Survey data Benchmarking results Quality reports Figure 2-3 Potential sources of data for analysts. The diverse nature of the data sources that can be used by HPI analysts, along with the various functions that they perform, indicate that it is often necessary to interact with many people throughout the organization. The finance and accounting department, for instance, may be the owner of financial performance measures. Other members of the organization, such as engineers, operations managers, quality specialists, information systems, or human resource professionals, can supply analysts with other relevant data—such as productivity or efficiency metrics, quality records, operating reports, or exit interview data, to name a few. Since the analyst must interact with so many people during data gathering, it comes as no surprise that communication and interaction skills are important nontechnical competencies for HPI work. One caveat should be mentioned concerning data sources, however: In many organizations, no tracking systems or data infrastructure is in place to gather, document, and monitor performance. In other cases, sources exist, but the data they provide are inadequate for analytical purposes. Still other problems exist when data are collected but are not used for performance monitoring and improvement efforts. For example, operating reports may be generated on a daily basis, but they may only be entered into a computer database for record-keeping purposes and then placed in a filing cabinet for storage. When such situations are encountered, HPI analysts can pursue one of several possible strategies. One is to create a data collection system and establish a baseline to make it easier to carry out analysis. (Remember it will take time to accumulate enough data for valid analysis.) At other times, establishing a measurement system may actually become part of the recommended performance improvement intervention, especially when lack of information, expectations, or feedback regarding performance is identified as a root cause of, or contributor to, poor performance. In cases where data are collected, but not for the purpose of improving performance, the analyst may need to roll up his or her sleeves and pore over reams of paper files to dig up the data, organize it, and analyze it in a way that makes it meaningful. This is certainly one of the less glamorous activities in which analysts engage, but for some it is energizing. Models and Tools for the Analyst’s Role The HPI process model, described in Chapter 1, is an example of a process model. The first two steps of this model—performance analysis and cause analysis—apply to the analyst’s role. Detailed descriptions of how to carry out those steps were not provided previously. For this reason, the models described in this section attempt to provide readers with useful methods to carry out analysis in organizational or workplace settings. The Rummler and Brache Model In their book Improving Performance (1995), Rummler and Brache present a framework for viewing organizational performance systems (see Figure 2-4). One axis of the model consists of three levels of performance—the organizational, process, and individual levels—that can be equated to the three organizational levels that were described earlier. The other axis is comprised of three performance needs—goals, design, and management. These three performance needs and three performance levels intersect to form a grid pattern with nine variables. This matrix provides the analyst with a structured way to examine human performance in dynamic organizational settings. A clear strength of the Rummler and Brache model is that it is based on a systems perspective of the organization and illustrates the relationships between the three performance levels and needs. Of key importance is the assumption that organizations should be aligned in these areas. For example, in the area of goals, it is important for an organization to have a clear strategy and accompanying goals for making the strategy operational. At the process level of performance, the goals of the process should be congruent with the goals and strategies articulated at the organizational level. At the job/performer level of analysis, the goals, objectives, and standards for individuals should be aligned to those at the process level. The Three Levels of Performance The Three Performance Needs Goals Design Management Organization Level Organization Goals Organization Design Organization Management Process Level Process Goals Process Design Process Management Job/Performer Level Job/Performer Goals Job Design Job/Performer Management Figure 2-4 Nine performance variables. Source: Rummler, G.A., and Brache, A.P. (1995). Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco: Jossey-Bass. Used by permission of the publisher. In this respect, there is consistency among the three levels such that performance at the job level contributes to process level outcomes, which (in turn) result in organizational accomplishments. Analysis may uncover a lack of congruence or alignment among these levels. When that is the case, a potential intervention to remedy this problem may include strategies to achieve goal alignment or cascading goals. Further, communication of these interrelationships can be a key vehicle for creating “line of sight” so that individuals can see how their efforts and accomplishments contribute to the results of the organization, which can be highly motivating in itself. The “balanced scorecard” (Kaplan and Norton, 1996, 2006) represents a common and powerful strategy used by organizations to create alignment around, and visibility into, a balanced set of metrics, including financial, customer, process, and learning. Analysis may also result in the identification of problems or inefficiencies within the matrix. Various interventions may be recommended to bridge performance gaps. Intervention selection will be discussed at length in Chapter 3. Regardless of the focus, with the Rummler and Brache model, the analyst can enter the organization and ask a series of probing questions to diagnose the current state of affairs. Figure 2-5 provides some general questions that analysts can pose to surface discrepancies or problem areas, as well as new performance opportunities. Gilbert’s Three Stages of Analysis Thomas Gilbert is considered by many to be a key founder of the human performance improvement field. In his landmark text Human Competence: Engineering Worthy Performance, first published in 1978, Gilbert introduced a number of concepts, models, and tools of performance improvement. Many have become commonly accepted methods still used by HPI practitioners today. Further, many variations on Gilbert’s themes and philosophies are evident in the tools and techniques of others. To understand the performance matrix analytical framework that follows, it is important to first recognize how Gilbert views the analytical process. His three-stage process model is shown in Figure 2-6. Stage One, labeled “models of accomplishment,” is the starting point for the performance analysis process. In this step, the analyst attempts to create a model of exemplary performance. A model of performance begins by attempting to identify the key accomplishments or performance results, goals, or outcomes to be achieved. The focus is on top performance as it occurs at the organization, group, or individual level. The source of exemplary performance is typically a select set of “star performers”—those who consistently outperform the average or typical performer in that particular role or job category. In the sales world, the star performers might be the top 5 percent of revenue generators. A model of accomplishment attempts to describe the desired performance—in other words, what should be happening. It entails uncovering the key factors that separate the results achieved by the stars from the other performers. What are the factors that most contribute to the success of the top 5 percent of the sales force? Figure 2-5 The nine performance variables with questions. Source: Rummler, G.A., and Brache, A.P. (1995). Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco: Jossey-Bass. Used by permission. Figure 2-6 Gilbert’s three stages of analysis. Source: Gilbert, T.F. (1996). Human Competence: Engineering Worthy Performance. Washington, DC: International Society for Performance Improvement (ISPI). Stage Two is labeled “measures of deficiency” because the focus is on determining the current level of individual, group, or organizational performance. Whereas the desired level of performance focused on what should be happening, the current level concentrates on what is happening. When information about the current performance level is gathered, it can then be compared with the desired performance level (from Stage One). The difference between current and desired performance forms the performance gap or performance discrepancy. In addition to defining the performance gap, the analyst must also determine why the gap exists—a process Gilbert called causal analysis. Finally, Stage Three, labeled “methods of improvement,” involves proposing solutions designed to close the gap between current and desired performance. It is equivalent to intervention selection, which will be the focus of Chapter 3. As Chapter 3 will demonstrate, literally hundreds of potential solutions can be applied to close performance gaps. Gilbert’s Performance Matrix Gilbert’s simplified performance matrix is displayed in Figure 2-7 and has as its foundation the three stages of analysis discussed earlier. STAGES Levels A Accomplishment Models B Measures of Opportunity C Methods of Improvement I Policy (Institutional Systems) Organization models Cultural goal of the organization Major missions Requirements and units Exemplary standards Stakes analysis Performance measures Potential for Improving Performance (PIPs) Stakes Critical roles Programs and policies Environmental programs (data/tools/incentives) People programs (knowledge/selection/recruiting) Management programs (organization/resources/standards) II Strategy (Job Systems) Job models Mission of job Major responsibilities Requirements and units Exemplary standards Job assessment Performance measures Potential for Improving Performance (PIPs) Critical responsibilities Job strategies Data systems Training designs Incentive schedules Human factors Selection systems Recruitment systems III Tactics (Task System) Task models Responsibilities of tasks Major duties Requirements and units Exemplary standards Task analysis Performance measures or observations Potential for Improving Performance (PIPs) specific deficiencies Cost of programs Tactical instruments Feedback Guidance Training Reinforcement Selection Figure 2-7 Gilbert’s simplified performance matrix. Source: Gilbert, T.F. (1996). Human Competence: Engineering Worthy Performance. Washington, DC: International Society for Performance Improvement (ISPI). Used by permission. This framework merges the three stages of analysis with the three levels of policy, strategy, and tactics. The result is a comprehensive way to analyze performance problems and pinpoint possible solutions. The performance matrix expands on the three stages of analysis by introducing three vantage points represented by the three levels. With each level, the matrix is meant to be worked from left to right. First, an accomplishment model is created that describes desired performance. Next, the actual performance is identified and compared with desired performance to articulate the gap or discrepancy. It is important to identify the causes of the gap through some means of root cause analysis. Some useful strategies for cause analysis will be described later in this chapter. Finally, the far right-hand column lists potential methods of improvement based on the identified root cause. Use of Gilbert’s performance matrix can guide an analyst’s diagnostic efforts. It can thus help to surface and isolate areas in which problems or opportunities exist. Another value is that it points toward potential solutions based on the level of analysis and the problem situation. Gilbert’s Behavior Engineering Model Another performance analysis model, developed by Thomas Gilbert (1978) and described in Human Competence, is the behavior engineering model (BEM). The BEM is shown in Figure 2-8. The behavior engineering model is comprehensive. It provides a wide perspective to diagnoses of performance problems. When examining a particular job, for instance, if all the aspects listed in the model were in place, then the likelihood of competence and successful performance would be high. When they are missing or inadequate, the result is decreased performance. The BEM consists of two levels or dimensions. The environmental supports represent those influences that exist in the work environment that affect performance. Performance standards is an example of an environmental support. The second dimension, the person’s repertory of behavior, indicates those factors possessed by the individual performer that affect performance. A person’s knowledge and skill in project management is an example. The items listed across the top of the BEM framework represent stimuli, response, and consequences. These make explicit the behavioral psychology roots upon which much of Gilbert’s work rest. These translate into the elements of information, instrumentation, and motivation. Information Instrumentation Motivation Environmental supports Data Relevant and frequent feedback about the adequacy of performance Descriptions of what is expected of performance Clear and relevant guide to adequate performance Instruments Tools and materials of work designed scientifically to match human factors Incentives Adequate financial incentives made contingent upon performance Nonmonetary incentives made available Career-development opportunities Person’s repertory of behavior Knowledge Scientifically designed training that matches the requirements of exemplary performance Placement Capacity Flexible scheduling of performance to match peak capacity Prosthesis Physical shaping Adaptation Selection Motives Assessment of people’s motives to work Recruitement of people to match the realities of the situation Figure 2-8 The behavior engineering model. Source: Gilbert, T. F. (1996). Human Competence: Engineering Worthy Performance. Washington, DC: International Society for Performance Improvement (ISPI). Used by permission. When examining performance, an analyst is advised to begin at the box in the upper left section of the model, where the focus is information at the environmental level. The troubleshooting process should proceed from left to right, beginning at the work environment level and then at the individual performer level, as shown in Figure 2-9. In workplace settings today, there seems to be a great propensity among managers and others to approach problems in a manner that is exactly opposite to this. Many point to the person and blame poor performance on a lack of knowledge, capacity, or motivation. Some managers jump to the conclusion that “these people just aren’t motivated” or “he’s just not smart enough.” This attitude underscores a tendency among some managers to blame people—or even specific individuals—for poor performance rather than to examine all elements related to their performance for contributory causes, including turning the mirror inward to look at their own role in the situation. Gilbert’s behavior engineering model assumes that most people want to do a good job and are generally capable. This assumption shifts the focus to aspects of the environment that can become obstacles to high performance. Sometimes managers resist this approach because they are often responsible for erecting these barriers. The focus, however, is not on placing blame or pointing fingers. Rather, the goal is to examine all variables influencing performance—both in the work environment and at the individual performer level—and structure them so that the desired performance is achieved. Figure 2-9 Direction of troubleshooting with the behavior engineering model. A large number of performance problems relate to lack of information. Some believe that up to 80 percent of performance problems can be traced to this cause. For example, looking at the first cell of the BEM, information in the work environment level can be broadly classified as data. Such data may be represented as expectations, role clarity, feedback, or performance standards. As mentioned earlier, these environmental elements generally should be provided by managers. Many analysts have discovered that the major causes of poor performance are that standards have never been established, expectations about desired performance have never been communicated, people are unclear about their roles, and they do not receive clear, specific, relevant, or timely feedback about how well they are performing. The value of the BEM is that, if aspects of the work environment are missing, they are often relatively easy to fix. It is much easier and less expensive, for instance, to establish standards (cell one), give people the tools they need (cell two), and recognize positive performance (cell three) than it is to increase their competence (cell four), their ability (cell five), or their motivations (cell six). One critique of the behavior engineering model is that it does not provide a comprehensive list of factors within each cell. Also, it does not explicitly direct the analyst toward specific solutions. Mager and Pipe’s Model Unlike a comprehensive analysis framework, some models are more situation specific. A classic model that falls within this category is the troubleshooting model formulated by Robert Mager and Peter Pipe (1984) and described in their book Analyzing Performance Problems, or You Really Oughta Wanna. The Mager and Pipe model, as it is commonly called, is displayed in Figure 2-10. As can be gathered by the manner in which the Mager and Pipe model is structured, it is designed as a flowchart with alternative branches, decision points, and, unlike Gilbert’s BEM, suggested action steps. The process begins with the identification of a specific problem, perhaps through the application of one of the comprehensive analysis models described earlier. Alternatively, a specific problem may be identified when a customer, manager, or worker complains about something or when they request action (such as training) to solve a problem. If possible, the problem should be described in measurable, observable, performance-based terms. It is thus worthwhile to describe the problem as a gap or discrepancy between current and desired performance. Figure 2-10 Mager and Pipe troubleshooting model. © 1997, “Analyzing Performance Problems”. The Center for Effective Performance, Inc., 1100 Johnson Ferry Road, Suite 150, Atlanta, GA 30342. www.cepworldwide.com. 800-558-4237. Reprinted with permission. All rights reserved. No portion of these materials may be reproduced in any manner without the express written consent from The Center for Effective Performance, Inc. Once the problem has been defined as precisely as possible, the analyst or others involved in the performance improvement process answer specific questions about the problem. For example, the first question after the performance discrepancy has been described is to decide whether the problem is important. This question requires the analyst, with the input of clients or other stakeholders, to place a value judgement on the discrepancy to determine the importance or the stakes associated with either solving the problem or ignoring it. One view of this issue is to gauge how much “pain” the discrepancy is causing the various stakeholders who are affected by it. If, on one hand, the problem is considered unimportant, then the model suggests that it should be ignored— and attention focused on other problems where the payoff for action is higher. On the other hand, if the problem is judged to be important, then the next step is to determine if it involves a deficiency in skill. The model progresses in various directions depending on the response provided to that question. One criticism of the Mager and Pipe troubleshooting model is that it tends to be too simplistic, especially considering the complex nature of most organizational problems. It is also difficult to answer questions about organizations with a simple “yes” or “no” response. Many problems encountered by analysts involve complex, ill-defined problems with multiple causes that call for multifaceted solutions. This is not to suggest that this HPI model is not powerful and useful to analysts. Indeed, the Mager and Pipe process provides a systematic means for addressing performance and has been used with great success by HPI practitioners and managers alike. When using any model, analysts should be keenly aware of the assumptions on which decisions were based and the weaknesses inherent in them. Cause Analysis: Determining Root Causes Analysts must be able to determine the root causes of performance problems they encounter. Too often, the symptoms or visible manifestations of problems are the focus of HPI, while the true cause remains unaddressed. These symptoms are called presenting problems. They are the consequences or results of another cause—not the cause itself. Managers and workers alike, however, may confuse the presenting problem with the cause. A brief example is in order here. If a patient goes to the doctor and complains of a pain in the side, the doctor is made aware of a presenting problem (the complaint about the pain). The complaint should prompt the physician to seek underlying causes. In other words, why is the patient’s side hurting? The same principle applies to cause analysis. Suppose an organization is experiencing what the managers believe to be higher-than-normal turnover. Managers complain to others about it and might say something like this: “Our turnover is too high, so let’s do something about it” or “We are spending too much time finding replacements.” Of course, these complaints are akin to the patient’s complaint to the doctor. High turnover—assuming that it is high, since that begs the question “compared to what?”—is only a presenting problem. The cause is not apparent. Similarly, the time spent on finding replacements is a consequence (side effect) of the problem rather than the problem itself. Surprisingly, a common response to such a situation is to try to reduce the time spent to secure replacements. A project team may even be formed to find ways to decrease the time to replace people. A great deal of time, money, and effort could be expended here rather than on the true cause. In reality, of course, there are many possible causes of turnover, and so a multipronged strategy may have to be discovered to uncover and attack those causes. The danger for analysts is confusing the presenting problem or the consequence of the problem with the problem’s root cause (the underlying reason for the problem). If that happens, analysts will tend to misdirect their attention rather than address underlying causes. This can be extremely costly in terms of time, money, and other resources. For this reason, analysts must be able to uncover root cause(s). The root cause is the underlying reason(s) for a problem. The onion, with its many layers, has become a common metaphor for how problems can be viewed (see Figure 2-11). The layers of the onion represent the symptoms of the problem. The onion’s core is the true root cause. Analysts must therefore invest the time, patience, and persistence required to peel the onion until root causes are discovered. (They must also resist the temptation to believe that problems have only one root cause.) Fortunately, a number of tools and techniques exist to help analysts uncover the root cause of the problem. Figure 2-11 Symptoms versus root causes of problems. Brainstorming Brainstorming is generally used in group problem solving to generate a large number of ideas or suggestions. This technique can also be used effectively by analysts when working with members of a human performance improvement team. It can be used to generate a list of potential causes of a problem or gap between current and desired states. Brainstorming is helpful because it can help to surface many creative ideas in a relatively short time period. It also encourages the involvement and active participation of everyone in the group. Brainstorming, as a causal analysis methodology, begins with a question or problem to be explored. The problem should be stated in measurable or observable terms whenever possible to provide clarity and facilitate common understanding. For example, “During the month of January, production in the kiln department was 8,500 tons of brick. The target was 10,000 tons, equating to a gap of 1,500 tons.” Using a flipchart or white board helps to provide a common visual focus. If group brainstorming is being used, everyone should have a clear understanding and agreement on the problem before proceeding. There is typically a set of basic ground rules, or guidelines, that are introduced when brainstorming sessions are conducted. A sample set of rules is shown in Figure 2-12. While brainstorming is an effective technique for generating a list of possible causes for problems, the results should not be taken as absolute truth. The causes identified through the brainstorming process represent possible reasons only. It is strongly recommended that HPI practitioners or teams—such as action learning teams (Rothwell, 1999)—collect data to either support or refute the causes listed in the session. In other words, brainstorming is not an effective substitute for data, and the causes generated from a brainstorming session or focus group must be substantiated through further investigation. No discussion of ideas. No criticism of ideas. All ideas are valuable. Think “outside the box”–be creative. Focus on quantity versus quality of ideas. Piggyback on others’ ideas. Figure 2-12 Basic rules of brainstorming. Brainstorming sessions can be conducted in structured or unstructured formats. Unstructured brainstorming typically involves a free flow of ideas with comments being voiced by any participant at any time. Ideas are called out immediately as they come to mind. Structured brainstorming, though, most often involves each person in turn either stating an idea or electing to “pass.” Ideas are generally captured on a flipchart or white board. Once an adequate list of causes has been generated, other members may subsequently evaluate the ideas by open or facilitated discussion, multivoting, or some other means. Sometimes groupthink develops during brainstorming sessions. Groupthink, as its name applies, occurs when the participants become focused on a single train of thought. Overt or covert peer pressure is placed on people who express creative ideas or ideas that fall outside the group’s line of thinking. In addition to establishing ground rules, another way to overcome groupthink is to use a technique called the “trigger method” of brainstorming. Before the brainstorming session begins, people are given an opportunity to write their ideas on a sheet of paper. Doing this gives people a chance to consider the topic before brainstorming begins. In addition, when ideas have been documented, it often becomes easier for people to express them. There is a greater likelihood of divergent thoughts, which can help to prevent the onset of groupthink. Groupware is the generic name for software programs that can be used to conduct electronic brainstorming, plus a number of other activities, such as categorizing information, voting, evaluating options, and making decisions. A groupware session would typically entail a room, often set up in a horseshoe shape, of networked computers at which participants sit. A brainstorming question or topic is introduced and participants type in their responses or ideas, which are collected anonymously via the software. This data is then used to foster discussion, evaluation of ideas, and decision making. The technology is a means to level the playing field because responses are anonymous. Thus, it helps to prevent groupthink from occurring. It is recommended, however, that groupware software not be a substitute for group discussion, dialog, and debate, but rather as a means to avoid negative group dynamics, generate and capture ideas, and expedite the process. Cause-and-Effect Analysis Cause-and-effect analysis, as its name implies, identifies and organizes potential causes of performance problems. The primary strength of this tool is that it visually organizes information and shows the linkages between the problem and its possible causes. Arguably the most popular cause-and-effect tool developed by Kaoru Ishikawa is known as the Ishikawa diagram or the fishbone diagram, named for the shape it takes. Another version of the cause-and-effect methodology is known as a tree diagram because it displays potential causes in a branch-like format. A fishbone diagram is shown in Figure 2-13. As is shown, the problem statement, or effect, is posted in the box at the far right of the diagram. Next, cause categories are determined and written in the appropriate boxes. A rule of thumb is that three to six cause categories should be used. Examples of a set of categories that could be used include people, methods, materials, measurements, and machines. Another set of categories that might be useful in administrative areas are the four P’s—policies, procedures, people, and plant. Yet another might be customers, employees, materials, policies/procedures, and environment. A more generic example is to simply ask such simple questions as these: Who? What? Where? When? How? and Why? As might be suspected, developing categories and identifying possible causes within each is a primary benefit of the fishbone diagram. The specific causes are then listed under the appropriate category branch. These are obtained by asking the question, “Why does this happen?” Brainstorming, which was covered earlier, is a useful technique that can be used at this juncture. Of course, categories can be moved, edited, added, or dropped based on relevance to the problem and situation. The analyst should attempt to generate as many causes as possible for each category. These causes should be related to the problem statement, which is written in the box at the far right of the diagram. As with brainstorming, it is critical to narrow the list and collect data, whenever necessary, so as to verify and validate the causes that might be generated. The Five Why’s Technique The five why’s technique is a variation on the cause-and-effect analysis method. It can complement traditional methods, such as the fishbone diagram, or it can be used by itself. The intent of the five why’s approach is to exhaust the list of potential causes, many of which may, in reality, be only symptoms, until the root cause is all that remains. This technique is simple yet powerful, because it forces the analyst to think through potential causes and to drill down to deeper levels that are more representative of the root cause. A simple example of the five why’s method is shown in Figure 2-14. Figure 2-13 Fishbone diagram. Statements/Responses “Why” Questions “I have a bad headache this morning. ”Really, why do you have a headache?”   1st Why “I only got four hours of sleep last night.” “Why did you only get four hours of sleep last night?”   2nd Why “I was up working until 3:00 a.m.” “Why did you work until 3:00 a.m.?”   3rd Why “I was late meeting an important deadline.” “Why were you late meeting a deadline?”   4th Why “I procrastinated and put off doing the work until the last minute.” “Why did you procrastinate?”   5th Why “I’m bored with my work.” “Why are you bored with your work?”   6th Why Additional Statements Additional Why Questions Figure 2-14 Example of the five why’s technique of causal analysis. The initial problem statement in this scenario was that the person had a headache. A simple solution or remedy, such as “take an aspirin,” probably could have been applied at this point. This approach, however, would only address the visible symptom of the problem rather than its root cause. This quick fix approach is too shallow and only masks the true problem, which is likely to persist. By continuing to ask “why?” for each symptom that is identified, the analyst digs closer to the root cause. The example in Figure 2-14 actually asked why six times and still may not have surfaced the root cause of the problem. Upon digging through six layers of symptoms, though, the analyst is much closer to the root than at the beginning of the process. By addressing the boredom with work issue, a longer-term solution that actually removes this problem is much more likely than by the shallow solution of taking aspirin. Other Analytical Tools In addition to the performance and cause analysis processes that have been discussed, there are a number of tools that are helpful to the analyst. This section discusses two such methods—system modeling and flowcharting. The next section covers some common methods and tools for data presentation, which are often used in conjunction with analytical methodologies. System Modeling The world is comprised of systems and subsystems. The HPI practitioner must adopt a systems perspective to see the complex interrelationships between various components of an organization. When changes are made to one part of a system through interventions, the result can be negative or positive effects on other parts of the system. A common phenomenon that compounds the issue is that there is often a lag or delay between the intervention and the resultant changes throughout the system (Senge, 1990). This delayed ripple effect highlights the importance of thorough analysis and the selection of appropriate interventions to human performance problems. In addition, viewing parts of the organization as systems and subsystems helps the analyst take a more focused approach because a clear delineation between various components can be made. The most basic system contains the three components: inputs, processes, and outputs, or I-P-O (see Figure 2-15). Inputs are the resources that feed into the processes. They may be in the form of raw materials, information, human resources, or equipment. Processes are the tasks, activities, methods, and procedures that convert these inputs into outputs. Outputs are the products and/or services produced by the process. Often, the output of one system becomes the input to the next system. Effects and feedback are other elements that can be added to the basic systems model shown in Figure 2-15. Effects are the changes, impacts, or outcomes resulting from the outputs of the system. Feedback is information regarding the system and its operation. When systems are modeled by analysts, they are rarely as simple as the I-P-O model depicts. Systems often have many inputs, subsystems, and supporting systems, multiple processes, and numerous outputs. One primary benefit of system modeling is that it helps to isolate and document the multitude of interconnected components that exist. Modeling a system reveals the linkages or relationships between each element and the impacts they have on each other. System modeling also provides a big-picture view and helps the analyst pinpoint where to start in identifying problems or their causes. Figure 2-15 Elements of a basic system. To engage in system modeling, the analyst must first decide upon which process or system to focus (see Figure 2-16). Processes that have never been modeled or that are experiencing painful problems or symptoms are likely to be candidates for selection. The processes are drawn as boxes and labeled appropriately. They are often depicted as high-level steps or tasks. Next, the analyst should identify the specific outputs that are generated by the process. Sometimes it is useful to determine the effects as well, which may be directly or indirectly related to the outputs. Whenever possible, each output should be described in observable and measurable terms. Measures of success should also be captured so that the analyst and other stakeholders can determine whether the system is functioning adequately. Each output should be drawn as an individual box and labeled accordingly. Inputs that are necessary to drive the process should be identified and documented, each as a separate box. Inputs may include people, information, material, and resources. It will sometimes be necessary or useful to identify the support systems that produce these inputs. An example of a support system is an information system. While it may not be necessary to diagram the entire information support system, it can be helpful to identify and document it in a box that is connected to an input. Figure 2-16 System modeling. Once a system has been diagrammed, the various elements, as well as the big picture, can be reviewed. It is sometimes necessary to establish mechanisms by which to obtain data or measures to determine current and desired performance. Once data are collected or reviewed, inadequate or missing elements of the system can be pinpointed for additional analysis and intervention. High-Level Flowcharting A flowchart is a visual representation of a process. It can be used with the system modeling technique described in the previous section or as a separate analysis tool. A flowchart is a way to describe and depict a process. The most basic flowchart consists of a sequence of steps. As with the system model, a flowchart is useful for diagramming the way in which a current process is carried out. It can aid the analyst in isolating missing or inefficient elements and can provide a clear delineation between steps as well as the beginning and ending points of a process. A process flowchart helps the analyst and others involved in performance improvement efforts to describe and discuss a particular process. The visual nature of flowcharting facilitates this endeavor. While many types of flowcharts exist, the basic high-level variety is shown in Figure 2-17. Often when analysts create a flowchart to represent a process, they identify the output or outputs, results, or accomplishments that are produced at each step and substep. These results can be thought of as intermediate outputs that contribute to the production of the overall process output. A good place to start is by identifying the external or internal customers as well as suppliers involved in a particular process. While generally meant to capture the external vendors associated with an organization, the notion of “supply chain management,” around which an entire profession and body of knowledge has emerged, has relevance inside an organization when the customer and suppliers of processes are analyzed (Hugos, 2003). The general purpose of such a high-level flowchart is to obtain a pictorial representation of the process. This can generally be achieved through drawing three to five steps, which represent those most critical in the process. Then from the critical steps more detailed substeps can be added. Figure 2-17 High-level flowchart. Detailed Flowcharting A detailed flowchart expands on the high-level chart by including additional granularity. Some elements that are commonly found in detailed flowcharts include decision points, delays or bottlenecks, documentation, information into a database, cloudy steps, and feedback loops. Figure 2-18 shows some of the symbols that can be used to represent these parts of a flowchart. Adding such symbols helps the analyst to more clearly and accurately document what is happening in the process. A detailed flowchart is shown in Figure 2-19. The type of flowchart that is used by the analyst should depend on the purpose. If the purpose is to gain a basic understanding regarding the primary steps involved in a particular process, then a high-level flowchart may be adequate. If more information is needed and if sufficient time is available, then a detailed flowchart may be required. When developing a flowchart, the analyst should always involve those who are most familiar with the process. These individuals are often referred to as process owners or subject matter experts (SMEs). Several cautions related to working with SMEs are in order. Sometimes, an expert may feel threatened for a variety of reasons, such as job security, and may be resistant to providing information. For this reason, it is important for the HPI practitioner to first build trust, explain why it is being done, how the results will be used, request the person’s support, and generally address any questions and allay any concerns of the expert (Mason, 2002). Another common occurrence when working with SMEs is that because of their expertise, they may overlook steps or make assumptions because they are so familiar with the process. Related to this, it is important to find SMEs who have excellent communication skills so they are able to convey their knowledge and insights in an comprehensible manner. Finally, it can be tempting for the process owner, and sometimes even the HPI practitioner, to diagram a process as it should be (or as the SME would like it to be) rather than as it actually is. This temptation should be avoided, and flowcharts depicting the current state should always reflect the actual rather than the ideal process. Figure 2-18 Common symbols found in a detailed flowchart. Figure 2-19 Sample detailed flowchart. Data Presentation Methods and Tools Another skill that is important for HPI practitioners is the ability to communicate the results of their analysis to key organizational stakeholders. The importance of being “data driven” has already been discussed. Simply dumping data on people, though, is a recipe for disaster, since many managers and others have little time or patience to wade through reams of facts, figures, or tables. For this reason, it is essential that the analyst present a clear and compelling articulation of the key information so that the decision-making process is facilitated. In addition, analysts must collect, track, and monitor key data so that they can uncover problems and opportunities to improve performance. Fortunately, a number of methods and tools exist that make it easier to understand data, as well as present it. Many of the tools described below can be created with relative ease using commonly available software packages, such as Microsoft PowerPoint or Excel. This helps analysts to comprehend and convey important information in an understandable manner. One of the foremost authorities on presentation of complex data is Edward Tufte. His text, The Visual Display of Quantitative Information (2001), is a classic on the theoretical and practical strategies for converting numeric data into easy-to-interpret charts, graphics, tables, and other visual forms. This section highlights pie graphs, bar graphs, Pareto charts, run charts, histograms, and scatter plots. Each tool provides a visual display of data so that it becomes easier to discern, identify patterns, and make decisions. Pie and Bar Charts Pie charts and bar charts are visual representations used to compare quantities, amounts, or proportions. When such charts are used, the results become much more clear, and the differences tend to stand out much more than when displayed as numeric data only. A sample bar chart and pie chart are shown in Figure 2-20. Bar charts are generally used to compare groups or categories, while pie charts typically show the relative percentages making up the whole. Figure 2-20 Sample bar chart and pie chart. Figure 2-21 Sample Pareto chart. Pareto Charts A Pareto chart is a specialized type of bar chart. It follows the Pareto principle, which states that, when there are multiple factors affecting a situation, generally only a small number account for most of the impact. Pareto analysis is useful to the HPI analyst because it helps to determine the causes with the greatest impact. A sample Pareto chart is shown in Figure 2-21. The Pareto chart organizes the data from highest to lowest (or lowest to highest), based on the problem being investigated. For example, frequency of occurrence or time involved could be diagrammed on a Pareto chart. It makes the primary problems easily visible and powerfully communicates the magnitude and importance of the problem to others. Thus, a Pareto chart is a highly useful way to establish priorities on problems or causes by surfacing and displaying those that are most problematic. Thus, a Pareto chart helps the HPI practitioner to narrow the range of options by surfacing those that are contributing most to the problem or situation. Line or Run Charts Line charts or run charts display a series of data points and are useful for showing trends over a period of time. A sample line chart is displayed in Figure 2-22. Figure 2-22 Sample line chart. A wide variety of information, such as volume, cost, or time, can be presented on a line chart. For example, the average time a caller is “on hold” in a customer call center environment or the average die changeover times on a stamping press may be displayed using such a chart. Viewing such data on a line chart can help to detect important trends, such as a spike in customer time on hold on Mondays due, perhaps, to work schedules being released first thing on Monday morning, causing confusion and delay. Data points on a line chart are displayed chronologically. Summary This chapter was about the first of the four HPI roles, the role of analyst. Analysis has received much attention, and its pivotal role in the HPI is clear. The role of the analyst was defined as someone who “conducts troubleshooting to isolate the cause(s) of human performance gaps or identifies areas in which human performance can be improved” (Rothwell, 2000). A total of six competencies were identified in ASTD Models for Human Performance Improvement as important to the role of analyst. In addition, the outputs linked with the competencies were presented. Next, the distinction between performance and cause analysis was made. These are the two steps of the HPI process model that are associated with the role of analyst. Performance analysis is “the process of identifying the organization’s performance requirements and comparing them to its objectives and capabilities” (Rothwell, 2000), while cause analysis is “the process of determining the root cause(s) of past, present, or future performance gaps. It follows, but is integrally related to, performance analysis.” It was also noted that analysis can be carried out at three levels—the organizational, process, and individual levels. The remainder of the chapter was dedicated to reviewing some important models and tools that can be used by HPI practitioners engaged in performance and cause analysis. Included were models devised by Gilbert, Rummler and Brache, and Mager and Pipe. These models and tools can be used by practitioners as they analyze performance problems. Data presentation tools were also covered as a way to communicate findings. References Carr, C., and Totzke, L. (1995). The Long and Winding Path: From Instructional Design to Performance Technology: Installment IV—Two Basic Tools of Human Performance Technology. Performance & Instruction, 34(6), 12–16. Cooperrider, D.L., Sorensen, P.F., Whitney, D., and Yaeger, T.F. (Eds.) (2000). Appreciative Inquiry: Rethinking Human Organization Toward a Positive Theory of Change. Champaign, IL: Stipes Publishing. Cooperrider, D.L., and Whitney, D. (2005). Appreciative Inquiry: A Positive Revolution in Change. San Francisco: Barrett-Khehler. Deterline, W.A., and Rosenberg, M.J. (Eds.) (1992). San Diego Unified School District: The Power of Performance Analysis. Workplace Productivity: Performance Technology Success Stories. Washington, DC: International Society for Performance Improvement, 21–22. Elliott, P. (1996). Power-Charging People’s Performance. Training & Development, 50(12), 46–49. Gilbert, T.F. (1978). Human Competence: Engineering Worthy Performance. New York: McGraw-Hill. Gilbert, T.F. (1982). A Question of Performance Part I: The PROBE Model. Training and Development Journal, 36(10), 21–30. Harless, J. (1973). An Analysis of Front-End Analysis. Improving Human Performance: A Research Quarterly, 4, 229–244. Harless, J. (1995). Performance Technology Skills in Business: Implications for Preparation. Performance Improvement Quarterly, 8(4), 75–88. Hugos, M.H. (2003). Essentials of Supply Chain Management. Hoboken, NJ: John Wiley & Sons. Hutchison, C.S. (1990). What’s a Nice P.T. Like You Doing? Performance & Instruction, 29(9), 1–5. Ishikawa, K. (Lu, D.J. trans.) (1985). What Is Total Quality Control? Englewood Cliffs, NJ: Prentice-Hall. Kaplan, R.S., and Norton, D.P. (1996). The Balanced Scorecard: Translating Strategy Into Action. Boston: Harvard Business School Publishing. Kaplan, R.S., and Norton, D.P. (2006). Alignment: Using the Balanced Scorecard to Create Corporate Synergies. Boston: Harvard Business School Publishing. Kaufman, R. (1986). Obtaining Functional Results: Relating Needs Assessment, Needs Analysis, and Objectives. Educational Technology, 26(1), 24–26. King, S.B. (1998). Practitioner Verification of the Human Performance Improvement Analyst Competencies and Outputs. Doctoral dissertation. University Park, PA. Kirrane, D. (1997). The Role of the Performance Needs Analyst. Alexandria, VA: American Society for Training and Development. Mager, R.F., and Pipe, P. (1984). Analyzing Performance Problems, or, You Really Oughta Wanna, 2nd ed. Belmont, CA: David S. Lake. Marker, A. (1995). The Harvest of PT: ISPP’s Past Presidents’ Recommendations for the Preparation of Performance

Human Performance Improvement (Improving Human Performance) Author: Pershing

2nd Edition: Rothwell, Hohne, King