This article appeared in CBT Solutions Magazine, January/February 1998.

by Gary J. Dickelman

EPSSsss…EPSSsss…EPSSsss…EPSSsss…EPSsss…. That’s what I found myself chanting upon my return from RMR’s Performance Support ’97 conference. Like most of the attendees, I was excited, motivated, charged, and filled with a renewed sense of how I would change the world of software development, where technology would reflect the very best practices of doing work effortlessly. But as the phenomenon Gloria Gery calls "The Law of Diminishing Astonishment" claimed its next victim, I drifted into post-conference depression. Limited tools, mismatched techniques, uphill battles with system development teams, and a litany of inconsistent definitions of performance support returned to focus.

Entertainment is often a cure for the blues, so I popped The Muppet Movie into my VCR:. I was delighted to find more than just comic relief manifested in one of its running gags:

That’s the ticket, I thought to myself. I imagined that somewhere the perfect master exists, the Guru of performance support. In my mind’s eye, I would make the journey to this technological Yoda of sorts and learn the secrets of what lies beyond the here-and-now. Exactly what would I find on the utopian plane of Effortless and Perfect Performance Solutions (the future EPSS, of course)?

My Guru would undoubtedly show me a world of Performance Analysis Objects, from which all performance centered systems could be constructed. As in Plato’s world of Forms, there would be a collection of perfect design metaphors that represent each and every process and task structure that exists on the mundane physical plane of work. These Performance Analysis Objects would make it immediate possible to:

1. Identify a performance gap and associated performance goal,
2. Determine the precise workflow (sequence of work steps) through which the performance goal can be measured, and
3. Determine the nature of performance support that best enables a worker to achieve the performance goal when embedded within the workflow steps.

These objects would be constructed by the performance analyst from a perfect Task Object Model, and the performer’s mental model of work would be represented by objects called Performer Frameworks - precisely what are required to fill the performance gaps at hand. EPSSsss…EPSSsss.

Task objects would fall into a number of perfect categories. My Guru would say, "Just because people feel that their work and the problems they encounter on the job are unique, it does not follow that each performance problem requires a different solution. On this earthy plane, there are but a few different categories of human challenges. If one focuses inward on the world of perfect task objects, once sees but a few simple categories:"

Communicate - tasks such as telephone calls, FAXes, and meetings, where people come together;

Document - tasks such as write, word-process, and photocopy;

Manipulate - tasks such as gather, distribute, sort, assemble, and disassemble;

Transfer - tasks such as carry, mail, and e-mail;

Access Systems - tasks such as query, enter data, search, open files, create reports;

Delay - tasks in which the powers of nature hold up work for specified periods of time;

Store - tasks that accumulate things according to time rules, quantity rules, or other conditions;

Branch - tasks which route work along one of two possible paths based on "if…then…else" condition;

Process - for the limited minds of earthly creatures, there is the universal "black box" containing more than one elemental task, but which otherwise cannot be specified without additional help from the Guru.

Through methods of meditation we could actually experience the upper regions and see perfect task objects:

Figure 1: The Universal Task Object Model

Constructing Performance Analysis Objects would be a simple matter of considering the work that people do, then selecting the appropriate task objects from the Universal Task Object Model. Like the great master painters who had nothing more than their mind’s eye, palette and canvas, the performance analyst would pluck task objects from Universal Model and create a workflow which best represents what the performer does, or better yet, what the performer could do to make work effortless and painless.

Figure 2: Workflow Constructed from Universal Task Objects

If task objects are the perfect, universal icons representing how all human work is performed, then there must be universal attributes that focus on performance gaps, performance goals, measurement criteria, and the types of performance support that are most appropriate for filling the performance gaps:

Table 1: Essential Attributes for Universal Task Objects

The essential performance attributes associated with each task object would help the performance analyst to build the perfect Performer Framework and ultimately the best performance-centered system. Which are the best? They are the systems that answer the performers’ most pressing questions and meet the performers’ most urgent needs at just the right time. When a performer thinks, "I’m stuck…please guide me through this," the performance-centered system provides guidance. When the performer recognizes a task or process as repetitive and thinks, "It would be nice if the system did these steps for me next time," it would identify occurrences of the sequence and perform them for the performer. Other performance needs include "Teach me how to do this…," "Let me try it and make sure I do it right," and "I’m lost…tell me where I am."

Further, the performer might realize that something from another software program would be useful at this time and wish for it to be available now. After all, our work is seldom restricted to the preconceived boundaries of the software packages that Microsoft, Lotus, and others provide. Our work consists of a flow of task that requires many and varied tools. Perfect performance is therefore possible only when the workflow is like the musician’s score, orchestrating and blending the various instruments so that one note inevitably follows the previous.

The perfect Performer Framework is therefore a reflection of the most efficient and effective workflow, but which commands the many varied pieces of desktop software that are required to get the job done. For example, when a manager commences creating a required annual business plan from the corporate strategic plan, she may require a review of existing (word-processed) documents that comprise the strategic plan, a document template for creating the annual plan, and a set of spreadsheets for constructing the annual budget. Guidance is also required in the form of coaching paragraphs, and perhaps checklists. The Performer Framework is therefore an object which delineates the workflow steps, assembles the work products and tools as they are needed, and couches the entire experience in the form of pertinent performance elements:

• Guide me…
• Do this for me…
• Teach me how to do this…
• Let me try this and let me know if I’m doing it right…
• I’m lost! Tell me where I am…
• There’s another piece of software that’s relevant right now. Run it.

A conception of the Performer Framework is shown in Table 2:

Table 2: Performer Framework

In this perfect world, there are no longer "stovepipes" of computer applications consisting of mountains of features for doing general-purpose things that the vendor dreamed up - and laying a heavy cognitive burden on the performer. Rather, there are processes - workflow objects - which contain the step-by-step procedures, assemble the software functions that the performer needs at the time they are needed, and attach all necessary guidance, automation, examples, practice, and the like. Learning how to use computer applications would become all but irrelevant; getting the work done would be paramount and inevitable.

Besides the performance elements that the Performer Framework commands, the perfect performance objects would also monitor the performer’s work to see what successes, difficulties, and patterns exist. The system would act on what it sees, providing additional guidance to fill newly identified performance gaps, automating more of the repetitive, routine tasks, and implementing the very best practices of doing work effortlessly. My Guru says that in the world of perfect performance objects, support is dynamic: always improving, always creating an environment for the most pertinent things to get done in the most effortless ways.

The wonderful thing about Performer Frameworks is that they are reusable performance objects. Imagine that each time a performance analyst creates a performance support object, it becomes part of a universal repository of support, available for future performance support interventions. Performance analysts would be able to reuse them in a variety of ways: make changes to the guidance components for different work settings (but the same work steps), combine several of them in series (concatenate them) in support of a new job that is a combination of several existing ones, nest them when recursion is required, and loop them when task performance is conditional. Performance just keeps getting easier for everyone in this connected world as the universal performance objects are combined and refined.

Figure 3: Building the Universal Performance Framework Object Model

My Performance Guru would no doubt point out that this earthly plane is a very small place without any great abundance of uniqueness with respect to performance problems and their solutions. That is why the model is one of universal, reusable objects. The Guru provides us with a framework and boundaries against which all performance analyses are conducted. What appears to be new is simply a reworking of that which we are already familiar but accommodates small variances in sequences of tasks and constituency of performers.

What brings the framework and boundaries into view is the brave, new connected electronic world. We are no longer isolated from each other in the work we do, in the games we play, or in the recreation we engage. As Stan Malcolm points out in his insightful speculations of "EPSS Tomorrow," performance support will be supportive of groups, reflective of workflow, and dynamically variable. People now see themselves as working together, playing similar roles, although with some variability in the sequencing and therefore the precise kinds of support necessary to ensure performance. Consequently, the dynamics of performance must be monitored and fed back to an ever-refining collection of performance objects. In this respect, performance support becomes a knowledge management enterprise.

The more I think about my Performance Guru and these universal performance objects, the more I realize that the ideas are not so lofty. Performance support is indeed reducible to always providing the performer with the answers to "What is it? What does it do? And how do I do it?" at the precise time a task or sequence of tasks must be performed. As the world shrinks electronically, the more we realize that there are fewer and fewer differences in task sequences within industries, and ultimately across disciplines. So we must turn our attention to commonality, classification, and refinement. Is this an "other worldly" view of performance objects? Hardly. What I’ve described above is quite down-to-earth, and the focus of a great many performance and learning initiatives today (e.g., The DoD’s Advanced Distance Learning project - see www.imsproject.org/adl/, Oracle’s recent work toward an infrastructure for reusable content objects, and similar work by IBM’s Enterprise Knowledge Solutions group).

I will nonetheless continue making a Pilgrimage to the Performance Guru in my mind’s eye - if not for a vision of reusable performance objects, then for a set of tools for building them. In this regard, perhaps the Guru has to be more of an techie than a mystic. What we need is perhaps less insight into the elegance of performance centered system concepts, and more performance-centered tools for constructing the things that make us able to perform. For that we should continue our journey to the Guru. EPSSsss…EPSSsss…EPSSsss.

Gary J. Dickelman is Vice President of Consulting for GURU, Inc. He specializes in the application of human factors engineering, learning technology, information technology, and business process engineering to a unique lifecycle for developing performance-centered systems. He is the only known EPSS practitioner to deliberately assume an IT management position for the purpose of making performance-centered design more accessible to and accepted by systems engineers. Dickelman writes regularly for CBT Solutions Magazine, where his articles reveal a variety of diverse interests, including Dilbert, unsolved problems in mathematics, The Blues Brothers, mysticism, and the collected works of John Irving. You can reach him by e-mail at gdickelman@guruinc.com. or by phone at (301) 908-5632.