A Role by Any Other Name:
the Availability of Skills in Project Teams
Performance Improvement, ISPI, 38(7), August 1999
Read my additional
thoughts on the subject, March 2002
"Before we start, can you remind me why
were here and what you expect me to do?"
-- question from a participant at a system development
project team meeting
Over the past few years, I have been growing increasingly
uncomfortable with the way many project teams are constructed. At first, I thought it had
to do with the challenge of introducing performance-centered design or performance support
(hereafter referred to as PCD/EPSS) into software development projects. However, I have
begun to recognize that the challenges stretch further back than that, and are more
In many companies, the traditional concept of
vertical departments has been under pressure due to the dramatic increase in
cross-functional working and process reorganization. The traditional concept of
roles on a project team is under pressure for similar reasons. Boundary
friction between different professional disciplines appears to be increasing, or at least
becoming more visible (Cowley-Durst, 1997). In technology development projects, this
situation appears to be exacerbated by the introduction of the PCD/EPSS designer's role,
because it crosses so many boundaries.
In this article I explore a simple premise: that the roles
traditionally associated with project teams are increasingly inadequate as a description
of the skills required for success. I focus on performance improvement and technology
development projects within organizations that are not dedicated to the task of
software development. Organizations that create software for others have unique team
challenges that are outside the scope of this article.
"So, why are you here?" (The paradox of the
PCD/EPSS designer's role)
It is probably not surprising that I have never encountered
a client whose software development methodology included PCD/EPSS activities and roles.
Often, PCD/EPSS is a latecomer, introduced after the project is already underway. So, the
inevitable dialogue occurs with the team:
What is it youre here to do?
Were helping people perform better from day
And how will you do this?
We start with a performer and task analysis
which Fred here from IT has already done, and
training is doing needs analysis, too. What else?
Well be sure that process flows match the reality
of the work requirements
Which Andrea is on the team to do.
Well want to talk to SMEs and performers about
But they havent seen or used the system yet. The
four team members at the end of the table are their representatives.
Well also work with you on the task-centered
interface and usability
Which our programmers are currently doing. By the way,
Mary is a GUI specialist. Say, werent you supposed to be doing the training?
Well actually, were trying to reduce the need for
But then why are Marc and Alison still on the team?
Because there are always knowledge bases, some training
may be embedded in the system, and some may still be required
so were doing the training, only less of it,
you say. Anything else?
Wed like to be sure that evaluation focuses on
key performance criteria
Have you talked to the QA department? Peter here can
introduce you, he is supposed to be doing evaluation. Can you tell me again what you do
that we dont do?
What's going on with project teams?
Virtually all statements of best practice and
methodologies encourage collaborative development in some form. The larger and more
complex the project, often the greater the number of people involved. But why are
they involved? Over the years, I have observed three reasons why people are assigned to
- Skills. Some of the team members bring specific skills
to the design and development of technology. These participants are typically designated
to fill certain pre-defined roles on the project team, such as systems analyst,
trainer, interface designer, project manager.
- Subject expertise. Some of the team members bring
expertise in the subject matter or work context. Their knowledge and experiences provide
some of the raw material for the design.
- Organizational communication. Some of the team members
are recruited for the sake of organizational communication. They serve as project
missionaries to improve communication with other parts of the company during and after
project implementation. Their involvement in participative design may lead to greater
emphasis on buy-in at every level of the organization.
Within the first group, among the people who are assigned
to fill certain roles, there is an increasing cross-over of skill sets and individual
experiences. I have seen IT people writing training modules and evaluating business
performance indicators. Technical communicators are increasingly creating online help, web
pages, and training materials. Training staff with experience in multimedia development
know more about certain aspects of software and web programming than IT staff. Business
process and quality analysts who investigate performance issues become actively involved
in specifying both IT and training interventions. Thus, the potential confusion over the
PCD/EPSS role on the team is only a symptom of a more widespread condition (Sherry &
In the early 90s, the British Computing Society
described the need for hybrid managers (Skyrme & Earl, 1992). These
hybrids were people with both business experience and IT experience, who could achieve
business performance from IT systems. Unfortunately, after a number of years, there is
still uncertainty about how to create, or educate, hybrid managers. Most professions are
now heading that way, and the genesis and evolution of PCD/EPSS shows clearly
The cross-over of skill sets on a project team can be
beneficial in many ways. In one project, developing a manufacturing administration system
for an international beverage company, my documentation group took on process mapping
tasks outside the original scope. In the course of documenting work processes for the
system, the documentation group became increasingly involved in the creation of the
processes themselves, even to the point of arbitrating decisions. The benefit was close
integration between the system, the documentation and the training. One clear advantage of
common skill sets is that when you need something done and the role is not
available, the outcome can still be achieved. At best, this cross-over creates an
opportunity for improving the collaborative creative output and introducing efficiencies
where fewer people can achieve results.
However, the cross-over of skill sets can sometimes be
harmful to the functioning of a team. At worst, it complicates the development of the team
and the relationships between people, where communication problems and the potential for
confusion could and have put entire projects at risk.
The role skill paradox
Ive heard it said many times that if people just did
what was in the textbooks, projects would succeed. Every professions formal
education system teaches techniques for how to get it right. Formal
methodologies and processes help codify best practice. Professional associations encourage
knowledge sharing. However
it is somehow rarely practical to use the techniques in
project situations (Sleezer, 1996).
Does the profession define the role (trainer, computer
programmer, etc.), and the constraints define the skills applied? This may be the crux of
a paradox in project team relationships: a contrast between overlapping territory and
performance gaps caused in part by confusion over the use of common terms to describe
- Project participants can become defensive at incursions into
what is seen to be their roles specialist area. This is particularly true if an
incursion may impact schedules or deliverables, and is perceived to risk a negative
outcome. For example, on one data warehouse project, I saw IT developers take offense at
the introduction of a PCS/EPSS designer to the team. They saw this person as a usability
specialist, and usability supposedly fell within their territory. After all, they had
their own GUI specialist who was already doing usability.
- On the other hand, people are increasingly using the same
terms to describe different things, so it appears that key activities are completed, when
in fact the performance information derived is inadequate to the needs of the overall
project. When starting an EPSS analysis, I was told "But weve already done a
task analysis. Why are you doing it again?" Of course, the goal of a
so-called task analysis may differ depending on the perspective of the
analyst. An information technology (IT) task analysis, focused on data, is different from
an instructional systems design (ISD) task analysis, looking for user skill gaps, which is
different again from a BPR task analysis, modelling detailed work flows. Task analysis
definitions can even vary within a particular discipline (Loughner & Moller, 1998).
What is the key to the PCD/EPSS skill set?
This operation of removing a problem from its traditional
context and placing it into a new one
has always seemed to me of the very essence of
the creative process. It leads not only to a revaluation of the problem itself, but often
to a synthesis of much wider consequences, brought about by the two previously unrelated
frames of reference. (Koestler, 1959)
EPSS was born out of dissatisfaction with the outcomes of
traditional training and traditional IT development. Although the name is only a decade
old, EPSS is not a new approach. Its analysis activities and methodologies are derived
from the disciplines of instructional design, process reengineering/O&M,
organizational communication, and software engineering, among others (Benko & Webster,
1997, Karat, 1997, Marion, 1997). PCD/EPSS practitioners are trained mostly through
experience, shared dialogue, and the growth of a common body of literature and examples.
The value of talented PCD/EPSS practitioners is to be found
less in their specific skills and more in the way they come to those skills. They bring:
- Insight into performance barriers (sometimes almost a sixth
sense born of experience)
- An outsider's perspective (they don't treat tradition as
gospel, and so challenge assumptions)
- Hybrid elements (the ability to frame questions, problems
and solutions in more than one professional language)
- Understanding of, and commitment to, business context (this
is where PCD/EPSS often rubs shoulders with knowledge management).
Another key skill that PCD/EPSS practitioners contribute is
the ability to work with uncertainty. There is tremendous uncertainty about the business
outcomes of any IT project. At the start, it is impossible to say what the end result will
be. Often, the project involves fundamental changes and re-thinking of working practices.
The business impact of these changes may be huge. The people who will be affected may have
strong feelings about it: a desire for things to be different, and also a fear of what the
change may bring.
In the face of this uncertainty, it is the responsibility
of project participants to undertake a creative process of exploration and identify
possibilities how the business might work and what the associated performance
standards might be (Mumford, 1983, Lippitt, et al, 1985). Working through uncertainty
requires some facilitation, and this may become an important contribution for the PCD/EPSS
As an aside: if EPSS practitioners are particularly good at
building a mental model of a new system or process, does that make them the most emotionally
secure people or the least? Are they able to cope well with the ambiguity, or do
they have the greatest motivation to resolve it?
Changing the focus: skills and responsibilities
So, lets back up and take a fresh look. Maybe we
need to approach the team idea differently. I propose the following steps to change the
focus of teams:
Build teams around skills sets rather than roles.
The management of project teams should lessen the emphasis on roles and place a greater
emphasis on 1) skills required to achieve specific outcomes, and 2) allocation of direct
responsibility for those outcomes based on the skills applied. The introduction of clearer
contributions and responsibilities for outcomes should help to clarify where the
relationship boundaries are between the skills that people bring to the team.
Reduce teams to a core group of skilled participants.
Identify what formal and informal skills you need to get the job done, regardless of the
roles defined in a methodology. When a range of skills are embodied in an individual, this
may increase the efficiency of the group as a whole. If possible, be flexible enough to
change the size and scope of the team over time as different skill sets are needed.
Identify timely and efficient opportunities for SME
involvement. Input from subject experts and the people who perform the tasks is vital
to project success. Given the uncertainty factor in design, there is immeasurable value in
performers working to build the mental model of the working practices that they will
eventually use. But their contribution must be timely and efficient. I have seen too many
instances of SMEs and performers seconded into a project team to then become either bored
with the technical detail that they feel is a waste of time, or demotivated by the
uncertainty of the dynamic, creative process of system development.
Identify opportunities for organizational communication.
Representatives are needed from all parts of the organization to get buy-in. In large
organizations, this can become a really large group of people (representatives from each
department and each hierarchical layer). Involvement is vital, but its not about
getting the job done it's about getting the job accepted. This is a
communications management issue, and can take many forms (Baetz, 1985). In one case,
analysis and usability formats have been designed in part to allow subject experts to take
a copy, and it has encouraged further discussion with their colleagues, resulting in wider
There is no simple panacea to resolve project team
performance and communication. However, below I list some thoughts that might encourage
- Begin to develop and agree more complete definitions of
project activities, such as task analysis, that encompass the performance information
needs of the whole team.
- Develop techniques that focus on identifying individual
skill sets, both formal and informal, rather than roles.
- Articulate further the linguistic and interpersonal
communication issues that are raised by the increasing harmonization of skills.
- Define simple techniques for greater integration of
communication theory into practical team building.
- Identify knowledge-sharing and, most importantly, understanding-sharing
tools and techniques which are flexible enough to be implemented on a project basis.
I believe the skills and insights we currently think of as
belonging to the performance support role are very important to the overall
success of any project. They may already be on the team. I would hope for the future that
project teams do not need to add a separate person to ensure that these skills are
represented. After all, my commitment to performance improvement within the design and
technology professions includes at least partly the desire to work myself out of a job!
Thanks to Lisa Battle for her critique of the
Baetz, Mary L. (1985). The Human Imperative:
Planning for People in the Electronic Office. Toronto: Holt, Rinehart and Winston.
Benko, S. and Webster, S. (1997). Preparing for EPSS
Projects. Communications of the ACM, 40(7), 60-63.
Cowley-Durst, Barbara (1997). Breakthrough Thinking on
EPSS Teams. Online. Internet. 1997. Available
Karat, John (1997). Evolving the Scope of User-Centered
Design. Communications of the ACM, 40(7), 33-38.
Koestler, Arthur (1959). The Sleepwalkers. London:
Hutchinson, 1959 (as published in paperback by Penguin Books, 1964, p341).
Lippitt, G, Langseth, P. and Mossop, J. (1985). Implementing
Organizational Change. San Francisco: Jossey-Bass Publishers. (61, 143)
Loughner, P. and Moller, L. (1998). The Use of Task
Analysis Procedures by Instructional Designers. Performance Improvement Quarterly,
Marion, Craig (1997). Implementing Performance-Centered
Design. Online, Internet. 1 May 1997. www.chesco.com/~cmarion/academic/useeng.html.
Mumford, Enid (1983). Successful System Design. In Otway
& Peltu, New Office Technology: Human and Organizational Aspects. Great
Britain: INSIS Programme of the Commission of the European Communities. (72)
Sherry, L. and Wilson, B. (1996). Supporting Human
Performance Across Disciplines: A Converging of Roles and Tools. Performance
Improvement Quarterly, 9(4), 19-36.
Skyrme, D.J. and Earl, M.J. (1992). Hybrid Managers: What
Do We Know About Them? Journal of Information Systems, 1(2), 169-187.
Sleezer, Catherine M. (1996). Quoting Ng, 1988 and Philips
& Holton, 1995. Using Performance Analysis for Training in an Organization
Implementing Integrated Manufacturing: A Case Study. Performance Improvement Quarterly,
Copyright, Reuse and
The content of this article may be referenced with the
appropriate citation information included (see below). The entirety of the article must
not be reproduced without written communication with ISPI (www.ispi.org).
Also, I would appreciate your notifying me if you intend to use these concepts or
images, as I am curious to know where they prove valuable.
To cite the material, please include the following
information. I recommend the format:
Degler, Duane (1999). A Role by Any Other Name: the
Availability of Skills in Project Teams. Performance Improvement (EPSS
Special Edition). ISPI, 38(7), August 1999. As viewed online,