A Role by Any Other Name: the Availability of Skills in Project Teams

by Duane Degler
Performance Improvement, ISPI, 38(7), August 1999

Read my additional thoughts on the subject, March 2002

"Before we start, can you remind me why we’re 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 generic.

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 you’re here to do?

We’re helping people perform better from day one…
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?

We’ll be sure that process flows match the reality of the work requirements…
Which Andrea is on the team to do.

We’ll want to talk to SMEs and performers about their issues…
But they haven’t seen or used the system yet. The four team members at the end of the table are their representatives.

We’ll 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, weren’t you supposed to be doing the training?

Well actually, we’re trying to reduce the need for training…
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 we’re doing the training, only less of it, you say. Anything else?

We’d 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 don’t 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 project teams:

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 & Wilson, 1996).

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 ‘hybrid’ elements.

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

I’ve heard it said many times that if people just did what was in the textbooks, projects would succeed. Every profession’s 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 different activities.

Project participants can become defensive at incursions into what is seen to be their role’s 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 we’ve 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 practitioner.

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, let’s 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 it’s 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 information dissemination.

In conclusion

There is no simple panacea to resolve project team performance and communication. However, below I list some thoughts that might encourage further research.

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 ideas presented.

References

Baetz, Mary L. (1985). The Human Imperative: Planning for People in the Electronic Office. Toronto: Holt, Rinehart and Winston. (50)

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 www.epss.com/lb/artonlin/articles/bdc.htm

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, 11(3), 79-100.

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, 9(2), 25-41.

Copyright, Reuse and Citation

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, www.ipgems.com/writing/rolearticle.htm.

� Duane Degler 1999-2008