ISPI: Performance Improvement Journals


Back to August Table of Contents
Back to Performance Improvement Journal home page

August, 1999
Volume 38 / Number 7

page 6
Performance Support in Perspective 
by Ashok Banerji, PhD

Performance support (PS) is concerned with human-task interactions within a human activity system. It can be classified into three types, depending on the interaction of the people system, tools system, and the task system. The three types are software-integrated, job-integrated, and operation-integrated PS. If suitably designed, an electronic PS system can reduce task performance time as well as reduce operational error, improve the quality of task performance, and-of course-reduce cost. The design approach and examples are described in this paper.

page 10
Teaming Up for Performance Support: A Model of Roles, Skills, and Competencies 
by Burt Huber, Jenifer Lippincott, Cathie McMahon, and Catherine Witt

A common concern among professionals engaged in creating electronic performance support systems (EPSS) is which set of skills, competencies, and roles comprise a development team. It is generally agreed that diverse disciplines converge to create an EPSS. The nature of EPSS varies between those tightly integrated with work-enabling software (intrinsic) to those that are totally separate from the core application (external). Partially integrated solutions are generally referred to as extrinsic EPSS. The EPSS team model presented in this article is the outgrowth of the work of the PSS Group, a consortium of companies and consultants working in the EPSS field. The independent work of several member companies is presented in three case studies. While many of the roles and skills required to create a successful EPSS are specified within traditional systems development life cycles, there is a lack of emphasis in these models on performance roles and emerging roles (e.g., hypertext engineering and knowledge management are often omitted entirely). Intrinsic, extrinsic, and external EPSS projects were studied and the roles and skills were identified by solution type. A one-to-one correspondence between roles and individual team members did not necessarily exist. Roles were often shared or split among people, depending on system requirements. Generally, the larger and more complex and integrated the project, the more specifically roles were defined. The PSS Group concluded that a successful EPSS is developed by a group of creative people with diverse, unconventional skills that function in a disciplined systems development environment.

page 15
A Role by Any Other Name: The Availability of Skills in Project Teams 
by Duane Degler

Although there is a recognition of the value of project teams in the development of performance improvement interventions and technology, there are increasing problems in the communication within such teams. The problems are not exclusive to the involvement of performance-centered design specialists. One of the reasons appears to be that there is a growing cross-over of skills among specialist members of project teams. A paradox lies in the dynamic way these skills both overlap and leave gaps in the team's understanding of performance needs. This article attempts to outline the balance between traditional team roles and the skills that are actually available to support successful project completion.

page 20
Knowledge: Bashful Partner or Leader of the Dance? 
by Stanley E. Malcolm, PhD

This is the story of a recent project to support several customer service call centers that were being merged into one. Customer service representatives were being asked to support a broader range of calls (i.e., various service plans, each with slightly different terms and conditions). The project's evolution raises some issues critical to achieving the full potential of knowledge management in support of business performance.

page 23
Gathering Knowledge for Your Knowledge Management System 
by Barbara Cowley-Durst

Critical to ensuring that you develop a knowledge management (KM) system that takes flight are the first steps you take to gather knowledge about the company, its people, and its knowledge requirements. A KM system should not be viewed merely as a repository of information; your company is considering building it because it is viewed as one additional way to enable performance. Thus KM practitioners must first seek to understand the performance goals of the business and its employees, the work context and tasks, and the nature and degree of the knowledge gaps that exist. If they don't, their KM initiative will never get off the ground. This article provides a context for the early information-gathering stage of a KM initiative, with emphasis on a business perspective and on the use of focus groups to gather requirements.

page 33
Book Review: The Invisible Computer: Why Products Can Fail, the Personal Computer Is So Complex, and Information Appliances Are the Solution 
by Donald A. Norman 
reviewed by Gary J. Dickelman

The Invisible Computer is about that which creates successful technology-based consumer products. It underscores the need for a solid business case while giving equal time to user experience, technology, and marketing. It underscores the development and business life cycles that are realities with respect to creating and sustaining successful technology-based products. But author Don Norman points out that the personal computer (PC) is all wrong as the platform for technology-based products. Why? Because the PC is complex, difficult to learn, difficult to use, difficult to maintain, and is a single device designed to do an unlimited number of unrelated tasks. We can overcome this problem with information appliances: simple, reliable, pleasurable-to-use devices that focus on specific tasks while their technology is hidden in the infrastructure. This article not only reviews The Invisible Computer but also shows how it explains the difficulty we have creating performance support systems. Enabling task completion by properly structuring tasks, helping performers to quickly establish goals, and bringing knowledge to the performer at the time of need require the task and the goal be quite simple and the process of achieving performance to be unencumbered by technology. Don Norman shows us why the personal computer is the wrong environment to reasonably achieve these things-and what we can do about it.

 


ISPI
info@ispi.org
Would you like to receive more information?