Planning an Electronic Performance Support System project

by Jean Hollis Weber

Electronic performance support systems are software programs that directly support a worker's ability to perform tasks. Such systems go beyond passive task-oriented online help. To be effective, EPS systems should be closely interlocked with the supported product's user interface and its online help. This paper outlines some of the planning considerations and steps involved in an EPSS project, and some of the problems and complications that arose during a specific project.

Definitions of electronic performance support systems (EPSSs) vary, but they are generally agreed to be software programs or components that directly support a worker's performance when, how, and where the support is needed. EPSSs are intended to improve workers' ability to perform tasks, usually (but not necessarily) being performed on a computer. They are related to, but more than, task-oriented online help.

For detailed information on the purposes, types and uses of EPSS, see the many papers available on the subject. A definitive book and some relevant websites are listed at the end of this paper. The websites provide links to numerous other sites and extensive lists of publications and other resources.

EPSSs can be general-purpose (part of a commercially-available software package) or special-purpose (developed or tailored for a specific organization or company). If the latter, they can be custom add-ons or modifications to existing commercial software or in-house software, or they can be designed into in-house software during development.

The project on which this paper is based had an OS/2 graphical user interface. The EPSS was part of a major revision to existing software being developed for in-house use. Although the software product could be modified and customized for sale to other organizations, it was never intended to be sold as a general-purpose product to the public. However, most of the issues raised during the development would have counterparts on other types of EPSS project.

I was the Information Development team leader for this project, responsible for planning, coordinating and managing the production of the user guides, online help and other manuals. Software development and information development was done by a team in Australia. EPSS development was handled by a team in the USA. Both teams needed to work closely to integrate the EPSS and the passive online help into the software product.

This paper addresses some of the planning issues of such a project. Other speakers in this session are Don Sobeski, an instructional designer from the EPSS development team, and Sandra Charker, the writer responsible for the online help. Their papers address issues related to the planning and development of the content of the EPSS.

Planning Considerations

Technical writers know that it is vitally important for the user documentation (and especially the online help) to be planned at the same time as the user interface, and that the planning must be detailed and thorough. We also know that in far too many cases, that doesn't happen.

In the case of EPS systems, this planning and coordination is even more important because the EPS/help system must be even more closely interlocked with the product itself. Some planning considerations:

1. Does the product development team (information developers as well as software developers) have the required expertise? If not, can they get it in time and within the budget? (On a first project for a team, you may need to implement only a subset of the EPSS, while team members learn how to do it.)
2. Will there be time (and money) to do everything on the requirements list by the deadline, to an acceptable standard? (The answer is almost always "no.")
3. Are the information/EPSS developers involved early enough in the requirements, planning and design processes?
4. Do the programmers understand the implications for the help/EPSS of their decisions?
5. Do the information developers (planner, writers, trainers, etc.) have sufficient understanding of the capabilities of the code to propose/plan workable help/EPS? (This is related to item 1 above.)

Planning Steps

With the answers to these questions in mind, here are some steps to follow when planning an EPS/help system:

1. Develop a wish list, based on your audience and task analysis. The ideal program would have what EPS/help features?
2. Evaluate the wish list and do a cost-benefit analysis. Some considerations:
   • What should be in the "passive" help vs. the "active" EPSS?
   • What are the most used features of the program?
   • What features are the hardest to understand?
   • What are most significant (to the client) problems to be solved?
   • What causes the most calls to a help desk (and would save money if the EPSS minimized calls)?
   • Will a help/EPSS feature mean less training required or will it supplement the training (refresh users' memory)? Is a tutorial relevant?
   • Analyze the performance issues. Will an EPSS feature do a task for a user (or help the user do the task), or mean the user doesn't have to go elsewhere to look up something or do something, thus saving users' time?
   • Are there management priorities or company politics that you must consider?
3. Assume that you (or the software developers) don't have time to do everything. Prioritize the wish list based on your analysis.
4. Now look at the implementation side. This will require consultation with software developers. Some questions to ask:
   • Which items are most or least complex to implement?
   • Does a "simple" help/EPSS feature require major programming work?
   • Will any usability/help/EPSS features involved major tradeoffs of program speed and size?
5. Work out a preliminary budget (people and money).
6. Negotiate a clear agreement with everybody involved (programmers, trainers, writers, etc.) of who is responsible for ("owns") what, and what the working arrangements will be. Get this approved by everybody who needs to approve it.

Problems and Complications

Here are some major problems and complications that we had to deal with, all of which are common with large development projects:

1. Everyone lacked expertise in this sort of project.
2. The EPSS component was a late addition to the requirements list, so it did not get sufficient consideration during the early planning stages.
   It was not built into the design from the start.
3. We were trying to build a tool to support business processes that were still under development within the company (which was undergoing process re-engineering). This meant a lot of rework for everybody.
4. Tools and processes to track and coordinate the work were not readily available, and had to be found or developed.
5. EPSS and online help were seen by the software developers as add-ons to the software, something separate from the user interface, whereas all should have been seen as an integrated whole.
6. Although writers were involved in the user interface design, we were not involved in code design (nor did we have the expertise to be involved), so some coding decisions made the provision of helpful online help and EPSS hard to write.

For More Information

Gery, Gloria. Electronic Performance Support Systems: How and Why to Remake the Workplace Through the Strategic Application of Technology, Galagan, 1994.

EPSS Resources: http://it2.coe.uga.edu/EPSS/EPSS.html

EPSS Infosite: http://www.pcd-innovations.com/index.htm

---

Jean Weber is a senior member of the STC, with over 20 years of experience in scientific and technical editing and writing for a variety of government and private organizations. She has a Master of Science degree from the University of Maryland. The project described in this paper was with ISSC Australia Ltd.

---