By Fred Nickols
There is no better instance of knowledge work than that done by the performance improvement professionals who are members of ISPI; namely, performance engineering. My goal in this column is to lay out what I see as the heart of the value proposition offered by ISPI; that is, developing, documenting, disseminating, advancing, and advocating the know-how used to engineer performance in three related and connected domains: people, processes, and organizations. Performance engineering, as explained here, is a variation of a problem-solving approach known as “solution engineering” (Nickols, 2013). Performance engineering is marked by two phases: investigation and intervention (see Figure 1). These are discussed next, and we will then examine the two key terms in the title of this column: performance and engineering.
Figure 1. The Performance Engineering Process
The first phase, investigation, is triggered by what Dewey (1910) called a felt difficulty, “a state of perplexity, hesitation, doubt” (p. 9). This might owe to a sense of unease–that something is wrong but no one knows exactly what or for sure. Or it might owe to the fact that although it is quite clear as to what is wrong, what to do about it is not immediately apparent. Both cases are marked by uncertainty regarding action.
The aim of investigation, then, is to eliminate or reduce uncertainty regarding action–its basis, the result to be achieved, and what variables should be changed and how to change them. In effect, this amounts to specifying a solution, a course of action that will lead to the desired results.
Once a course of action has been specified, attention turns to the second phase, intervention–to doing what has been figured out. To intervene is to change things with some purpose or outcome in mind. Change is typically indirect; you change things over here to realize some effect over there. “Over here” is where you change things in direct and immediate ways–the points of intervention. “Over there” is where you will gauge success–the points of evaluation. This is where you will assess the eventual efficacy of any actions taken.
“Over here” is marked by proximal targets, variables that are directly accessible. “Over there” is marked by variables that cannot be directly accessed in space or time. These are the ultimate targets. Between proximal and ultimate variables lie intermediate variables. These constitute the paths through which changes made to proximate variables make themselves felt on ultimate variables. In the words of Newell and Simon (1972), this is the “solution path.”
Let’s visit now the second of the two terms serving as the focal point for this column: engineering. At its heart is “engineer,” which can be both noun and verb. We are concerned here with engineer as a verb. To engineer is first of all to do the work of an engineer. But there is a second, more important meaning when it comes to engineering performance. Engineer, as a verb, also means to “to arrange, manage or carry through by skillful, artful contrivance” (Webster’s, 1989) as in, “She engineered a successful new product launch.” To engineer performance, then, is to bring about desired performance “through skillful, artful contrivance”; namely, through the reasoned, intelligent, and systematic application of relevant models, methods, tools, and techniques. In short, to engineer performance is to skillfully apply selected, relevant performance technologies.
Now let’s take a look at the first term: performance. I use the term “performance” to refer to actions and their effects, outcomes, and the actions that produce them. All organizations are marked by at least three domains of performance. First, of course, is the domain of people. This includes individuals, groups, and teams. A second domain is that of processes. Here three basic categories of process are of interest: production, transaction, and adaptation. Product processes are transformative; they convert inputs into outputs. Transactional processes are exactly that, concerned with exchanging one thing (e.g., products) for another (e.g., money). Adaptation processes are concerned with achieving and maintaining a good fit between the system or organization under study and its larger context or environment. A third domain of performance is that of the organization itself, often measured in financial ways (e.g., profit) but also in operational ways (e.g., share of market) and in terms of its societal impact (see Figure 2).
Figure 2. Performance Domains
Performance can be engineered in all three domains and in all three subsets of each. Doing so is what ISPI is all about. No other organization, not ASTD nor ASQ nor SHRM nor the OD Network nor any other organization of professionals, has that aim as its core. And only at ISPI are these three domains dealt with in integrated, evidence-based ways. All those other organizations, like the fabled blind men, have their hands on parts of the elephant.
So if you are wondering why you should stay with ISPI or why you should join, my belief is that only at ISPI can you learn how to engineer the performance of people, processes, and organizations, singly and in concert. No other organization has or offers that kind of know-how. Those who master it are knowledge workers in every sense of that term.
Dewey, J. (1910). How We Think. Boston: Heath.
Newell, A., and H. Simon (1972). Human Problem Solving. Englewood Cliffs, NJ: Prentice-Hall.
Nickols, F. (2013). “Solution Engineering: A Tutorial.” Retrieved from http://www.nickols.us/Solution_Engineering_Tutorial.pdf
Webster’s Encyclopedic Dictionary of the English Language. (1989). Gramercy
About the Author
Fred Nickols is a Certified Performance Technologist (CPT), which means he is a performance improvement professional. He is also a longtime member of ISPI; his interactions with the society began in 1968 when ISPI was NSPI and Fred was an instructor at the Navy’s Instructor Training School in San Diego, where he later ran the Programmed Instruction Writer’s Course. Currently, Fred is the managing partner of Distance Consulting LLC, a firm he started in 2001 when he left Educational Testing Service. He can be reached via email at firstname.lastname@example.org.