# Defining Leadership as Process Reference Model: Translating Organizational Goals into Practice Using a Structured Leadership Approach

David Tuffley

► To cite this version:

David Tuffley. Defining Leadership as Process Reference Model: Translating Organizational Goals into Practice Using a Structured Leadership Approach. IFIP TC 5 International Conference on Enterprise Architecture, Integration and Interoperability (EAI2N) / Held as Part of World Computer Congress (WCC), Sep 2010, Brisbane, Australia. pp.11-20, 10.1007/978-3-642-15509-3_2. hal-01054823

HAL Id: hal-01054823

https://inria.hal.science/hal-01054823

Submitted on 8 Aug 2014

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Defining Leadership as Process Reference Model:
translating organizational goals into practice using a
structured leadership approach

David Tuffley

School of ICT, Griffith University
Nathan, Brisbane, Qld. 4111, Australia
d.tuffley@griffith.edu.au

**Abstract.** Effective leadership in organisations is important to the achievement of organizational objectives. Yet leadership is widely seen as a quality that individuals innately possess, and which cannot be learned. This paper makes two assertions; (a) that leadership is a skill that not only can be learned, but which can be formalized into a Process Reference Model that is intelligible from an Enterprise Architecture perspective, and (b) that Process Reference Models in the strict sense can be redefined to include a new category of PRM called provisionally a Reference Model of Organisational Behavior which focuses on organisational behavior in pursuits of goals.

**Keywords:** leadership, complex teams, virtual teams, process reference model, process assessment model.

## 1 Introduction

Enterprise Architecture can be thought of as an *informing principle* that enables the translation of an organisation's high-level aspirations into the structures and processes that are designed to realise these aspirations [1]. This includes the technological infrastructure and associated data that allows the enterprise to function. No less important to the realisation of the enterprise's goals is the exercise of leadership at various levels within the organisation.

Indispensable as leadership is to high-performance enterprises, there is still no commonly agreed definition of leadership [2], much less a meaningful definition of leadership in process terms that can be used to facilitate more effective leadership in a process-driven enterprise. This paper describes a Process Reference Model for the leadership of complex virtual teams with which an enterprise might better facilitate the translation of those high-level aspirations into concrete reality.

A Leadership Process Reference Model is arguably consistent with the generalized view of Enterprise Architecture as concerning itself with describing in a formal, structured way the relationships between the elements (including people and technology) of an organisation in such a way that they can manage on-going change and achieve their goals [3].
Process Reference Models in the software engineering sense must conform to certain prescribed criteria (that they be developed in conformance with ISO/IEC 15504 and ISO/IEC 24774). The leadership model discussed in this paper conforms to these standards. A second issue is that of whether leadership is something that can even be described in a Process Reference Model. Both of these issues will be discussed below.

## 2 Process Reference Models in organisations

Process models developed in conformance with ISO/IEC 15504 and ISO/IEC 24774 can arguably be called a Process Reference Model (PRM), particularly when the draft model has had all of its outcomes validated by the existence of artefacts and/or activities identified during multiple review iterations involving practitioners and process model experts. In addition, the model may be used by an external observer to describe the behavior of an effective leader. Combine these factors and a strong argument exists for this position.

But the orthodox view in software engineering sees PRMs as high-level descriptions of what tasks to perform and in what order to perform them in order to achieve desired project outcomes. The focus is on external entities that can be observed and assessed against an objective assessment model.

A difficulty arises though when trying to reconcile the orthodox view of PRMs with a specific PRM focused on the elusive qualities of Leadership. Despite thousands of books and papers written on the topic of leadership over centuries, no commonly agreed definition yet exists [2]. Leadership qualities derive partly from a set of personality factors residing in the leader and partly from explicit actions performed by the leader at the team and organisational level. While the explicit actions can be directly observed, the implicit qualities cannot be observed, only their effects (as manifested by the attitudes and activities displayed by the leader).

A PRM for the leadership of complex virtual teams describes aspects of desired organisational behavior that if performed repeatedly will become institutionalised and which will result in consistently achieving the prescribed purpose (i.e. working towards the achievement of organisational goals). This approach re-focuses attention from conformance to prescribed activities and tasks, to a focus on the demonstration of desired organisational behavior, taking us away from the traditional role of a PRM. And leadership is potentially just one of many desirable organisational behaviors that might be facilitated by a PRM.

How then to reconcile these differences? A logical answer is to conclude that the Leadership PRM is in fact a new category of process reference model, described provisionally as a *Reference Model for Organisational Behavior (RMOB).*

The creation of this new category of PRM and its associated assessment model opens up the field across a diversity of disciplines for others to develop models of organisational behavior covering a range of activities (for example IT governance), giving them the means to assess and improve organisational behavior.

*Reference Models for Organisational Behavior (RMOB)* therefore represent a significant new application of Process Reference Models and Process Assessment
Models in domains outside software, systems engineering and service management. RMOBs have relevance to Enterprise Architecture since they are concerned with formal, structured descriptions of the relationships between the elements (including people and technology) of an organisation, and how these can be used to manage on-going change and achieve organisational goals [3].

### 3. Can leadership be described as a process?

Leadership is not alone in the broad category of behaviors engaged in by organisations as they pursue their objectives. If leadership can be described in a Process Reference Model (PRM) and supported by a PAM, then theoretically so too might these other behaviors not yet serviced by a PRM. For example, ISO/IEC 15504 offers organizations the means to develop and assess their integrated teaming capability against the measurement framework prescribed by ISO/IEC 15504 [4].

We begin by examining whether there are grounds to believe that PRMs are applicable in addressing leadership in a software engineering environment? It will be seen from the discussion that PRMs and Model Based Process Improvement (MBPI) can arguably be applied to a range of software engineering challenges, including the challenge of project leadership

As seen in Figure 1, there are two broad justifying reasons; first that Leadership can be taught and learned by those who would practice it [5] [6] [7]. Second that the defining of processes is necessary for organisational effectiveness [8]. As Deming said, *if you cannot describe what you are doing as a process, then you don't know what you are doing* [9].

<figure><img src="image_2.png" /><figcaption>**Figure 1.** Model-Based Process Improvement enables definition of leadership processes</figcaption></figure>

The conceptual overview diagram in Figure 2 illustrates the evolution of the question *how can the challenge of more effective virtual team leadership be met?* Assuming that the leadership factors could be identified from a broad literature review, then a Process Reference Model is a logical way for these factors to be formalised and applied in real situations.
The basic topic of team functioning was examined first, which led to the identification of what characteristics are likely to create a successful team. Arising from this work on successful teams, leadership is clearly identified as being of critical importance.

The conceptual overview acknowledges the basic distinction between co-located and virtual teams, and that integrated teams can be either. Virtual teams do not have to be integrated but commonly are. Integrated teams do not have to be distributed, but commonly are. Therefore, the characteristics of successful teams and successful leaders are considered for both co-located and virtual teams, culminating in the characteristics of successful leaders of integrated teams operating in virtual environments.

<figure><img src="image_3.png" /><figcaption>**Figure 2.** Conceptual overview of how Leadership PRM & PAM evolved</figcaption></figure>
## 4. Model-Based Process Improvement as a solution to rising organizational complexity

The business of managing complex projects across dispersed geographical locations has never been more difficult, given the rising complexity of the global economic environment and the multi-national corporate entities that now inhabit this world. There is a clear need to find improved ways of managing this often difficult process now and into the future [10].

Model Based Process Improvement (MBPI) potentially offers the means by which organisational challenges such as the leadership of complex virtual teams can be met. MBPI has not (to the knowledge of the author) been used to address leadership, though there is arguably a sound basis for thinking that it can be used in this way.

MBPI aims generally to improve the performance and maturity of an organisation's processes. It combines the discipline of process improvement with the several international standards and frameworks now in use (i.e. ISO/IEC 15504, CMMI). Combining this awareness of process performance with internationally recognised standards is advantageous to organisations. It affords a structured and comprehensive framework as a way forward and prescribes in general terms the scope of activities required to systematically improve their process maturity.

Heston and Phifer [11] ascribe the following organisational benefits to MBPI:

* *Improving consistency and repeatability:* consistency and repeatability assist with minimising process variation, a major source of product defects. It also allows project staff to move into and out of projects more easily by having clearly defined roles and responsibilities.

* *Improving communication:* achieved through the adoption of a common vocabulary with clearly prescribed meanings that allows project staff, clients and business partners to communicate with less ambiguity.

* *Enabling more improvement:* process improvement programs create an environment which is conducive to further improvement. Beyond consistency and repeatability comes the ability to measure and record process performance. This performance data can then be used to plan further improvements and to benchmark against best practice.

* *Providing motivation:* objective targets, for example being assessed at a certain level of maturity, become a visible motivator for project staff to maintain their efforts to improve process performance.

## 5. Leadership PRM in practice

The Leadership PRM was developed using a Design Research approach in which an initial prototype was developed based on the broad literature and reviewed in a series of design iterations over an 18 month period (a total of six reviews). The reviews included the standard PRM-developer's method of practitioner and expert reviewers, plus an ISO/IEC 24774 conformance review to ensure the model met the requirements of that standard. The PRM was also validated with Dromey's Behavior
Engineering [12], a formal method for checking content and syntax for errors and ambiguities that was developed initially for validating software requirements for complex systems, but which has proven a highly effective method for validating PRMs [13].

Having passed through these six reviews, the V1.0 PRM was released and reviewed again by a focus group over a full day. The group comprised two practitioner project managers and two experts on process models in software engineering. The terms of reference of this post-release review was to *evaluate the efficacy of the leadership PRM, particularly in relation to (a) fitness for purpose, (b) organisation of and content of elements, and (c) what would make it more usable from a practitioner's point of view*?

As a result of the review, V1.1 PRM was produced. This version incorporated the accumulated feedback from the focus group and resulted in substantial changes by (a) consolidating and merging several processes, (b) reordering the processes to reflect a sequence more naturally performed in projects, and (c) adding additional informative material relevant to virtual and/or integrated project environments. All of these changes were consistent with the review's terms of reference.

Importantly for the purposes of this paper, the consensus opinion of the focus group was that the *Leadership PRM is a usable model*. They each wanted a copy of the update V1.1 PRM for use in their own projects. This feedback lends support to the argument that a Reference Model of Organisational Behavior that conforms to the requirements of a PRM in a software engineering sense can be a useful and usable artefact.

Also emerging from this first post-release review was a *Process Assessment Model* (PAM) based on the Leadership PRM. This PAM was developed in accordance with ISO/IEC 15504-1:2004 Parts 1 and 2,

<table><caption>**Table 1.** Structure and content of Leadership Process Assessment Model.</caption><thead><tr><th colspan="2">Leadership Process Assessment Model</th></tr></thead><tbody><tr><th colspan="2">Individual Process Group (IND)</th></tr><tr><td>IND.1</td><td>Vision</td></tr><tr><td>IND.2</td><td>Objective(s)</td></tr><tr><td>IND.3</td><td>Integrity</td></tr><tr><td>IND.4</td><td>Action-orientation</td></tr><tr><td>IND.5</td><td>Intelligence</td></tr><tr><td>IND.6</td><td>Individualized consideration</td></tr><tr><td>IND.7</td><td>Management-by-exception</td></tr><tr><th colspan="2">Team Process Group (TEM)</th></tr><tr><td>TEM.1</td><td>Team structure</td></tr><tr><td>TEM.2</td><td>Team requirements</td></tr></tbody></table>
<table><tr><td>TEM.3</td><td>Team recruitment</td></tr><tr><td>TEM.4</td><td>Team environment</td></tr><tr><td>TEM.5</td><td>Team formation</td></tr><tr><td>TEM.6</td><td>Team roles</td></tr><tr><td>TEM.7</td><td>Team rules</td></tr><tr><td>TEM.8</td><td>Team authority</td></tr><tr><td>TEM.9</td><td>Team performance management</td></tr><tr><td>TEM.10</td><td>Team development</td></tr><tr><td colspan="2"><strong>Organisation Process Group (ORG)</strong></td></tr><tr><td>ORG.1</td><td>Team boundaries</td></tr><tr><td>ORG.2</td><td>Team collaboration</td></tr><tr><td>ORG.3</td><td>Team & home organization balance</td></tr></table>

An example process from the PAM (*Vision*) is shown in Table 2 below. It and the other 15 processes have now been elaborated into a draft PAM. The first review established that a PAM which embodies at least the Process dimension is viable.

The second and subsequent reviews (V1.2 onwards) will investigate the feasibility of including the Capability dimension in the Leadership PAM. While it has been established during the validation of the PRM that each of the outcomes can be substantiated by the presence of artefacts and/or activities, it is not yet clear whether the discernable process indicators can be distinguished with sufficient clarity to establish the capability dimension. Only by performing a number of assessments using the draft PAM and accumulating data in the *Work Products / Activities / Conditions* section will we know whether a capability dimension is feasible. This work is on-going.

<table><caption>**Table 2.** Structure and content of PAM Example 1.</caption><tr><td>Process ID</td><td>IND.1</td></tr><tr><td>Process Name:</td><td>Vision</td></tr><tr><td>Process Purpose:</td><td>The purpose of the vision process is to create and communicate a shared vision in ways that inspires people to realise that vision.</td></tr><tr><td>Process Outcomes:</td><td>As a result of successful implementation of the vision process:<br/>1) A vision of the goal(s) is created.<br/>2) The vision of the goal(s) is communicated to the team<br/>3) Commitment by team to the shared vision is gained</td></tr><tr><td>Base Practices:</td><td>IND.1.BP1: Create the vision. The leader envisions a</td></tr></table>
<table><tr><td>desirable future condition [Outcome 1]</td></tr><tr><td>IND.1.BP2: Communicate the vision. The leader communicates the vision in a way that creates positive expectation in the team members [Outcome 2].</td></tr><tr><td>IND.1.BP3: Commitment to vision by team. The leader obtains commitment from the team members for the realisation of the vision, making it a shared vision [3].</td></tr></table>

<table><thead><tr><th colspan="3">Work Products / Activities / Conditions</th></tr><tr><th>Inputs</th><th></th><th>Outputs</th></tr></thead><tbody><tr><td>Business goals [Outcome 1]</td><td></td><td>Team Charter [Outcome 1]</td></tr><tr><td></td><td></td><td>Imperative Objectives [Outcome 1]</td></tr><tr><td>Customer requirements [Outcome 1]</td><td></td><td>Project Plan [Outcome 1]</td></tr></tbody></table>

Note that the PAM can be used in three possible ways, (a) by project managers to evaluate their own practice, and engage in self-improvement by benchmarking against best-practice, and (b) by organisations wishing to improve their internal management capability, and (c) theoretically by external agencies wishing to evaluate a potential supplier's management capability (though this would be some distance away since the capability dimension has not been established).

<table><caption>**Table 3.** Structure and content of PAM Example 2.</caption><tr><td>Process ID</td><td>IND.2</td></tr><tr><td>Process Name:</td><td>Objectives</td></tr><tr><td>Process Purpose:</td><td>The purpose of the objectives process is create and communicate objective(s) based on the vision and derived goals.</td></tr><tr><td>Process Outcomes:</td><td>As a result of successful implementation of the objectives process:<br>1) Practical objective(s) for goal(s) achievement are developed.<br>2) Positive expectation for achieving objective(s) is encouraged.</td></tr><tr><td>Base Practices:</td><td>IND.2.BP1: Develop objectives. The leader derives a set of practically worded objectives from the shared vision and subsequent goals that give the team a concrete set of outcomes to achieve. [Outcome 1]<br>IND.2.BP2: Encourage positive expectation. The leader generates an optimistic mind-set and outlook in the team towards the achievement of the objectives [Outcome 2]</td></tr></table>
<table><thead><tr><th colspan="2">Inputs</th><th>Outputs</th></tr></thead><tbody><tr><td rowspan="2">Vision [Outcome 1]</td><td>statement</td><td>Goals [Outcome 1]</td></tr><tr><td></td><td>Objectives [Outcome 1]</td></tr><tr><td rowspan="2">Project plan [Outcome 1]</td><td>launch</td><td>Goals [Outcome 1]</td></tr><tr><td></td><td>Objectives [Outcome 1]</td></tr><tr><td>Project [Outcome 2]</td><td>launch</td><td>Positive expectation re vision [Outcome 2]</td></tr><tr><td>Team briefing [Outcome 2]</td><td></td><td>Commitment to vision [Outcome 2]</td></tr><tr><td>Yearly [Outcome 2]</td><td>kick-off</td><td>Positive expectation re vision [Outcome 2]</td></tr><tr><td>Quarterly [Outcome 2]</td><td>review</td><td>Commitment to vision [Outcome 2]</td></tr></tbody></table>

## 6. Conclusion

This paper discusses the issue of effective leadership in organisations and argues the case that (a) leadership is a skill that can be learned, and which can be formalized into a Process Reference Model that is intelligible from an Enterprise Architecture perspective, and (b) Process Reference Models in the strict sense can be redefined to include a new category of PRM called provisionally a Reference Model of Organisational Behavior which focuses on organisational behavior in pursuits of goals.

In support of the case that leadership can be learned is the extensive body of work by influential researchers on leadership like Warren Bennis [5] and Peter Drucker [6]. This does not ignore the innate charisma of so-called ‘born leaders’, but makes the case that leadership can be understood and applied more effectively in a practical sense.

In support of the case that leadership can be described as a process reference model is the work of process pioneer W. Edwards Deming who observed that if you cannot describe what you are doing as a process, you don't really know what you are doing [9]. While the Leadership Process Reference Model conforms to the normative reference, qualifying it to be called a PRM, the broader, more organizationally-focused nature of this model suggests it might be best described as a new category of PRM, provisionally called a *Reference Model for Organisational Behavior*.

A Leadership PRM developed by a rigorous Design Research process and tested in preliminary trials and found to be useful by practitioners and experts is arguably a viable model. Strengthening this position is the draft Process Assessment Model that considers initially the process performance dimension, but which will be elaborated in on-going trials for the inclusion of the capability dimension.
The results so far have been encouraging. Not only is a Leadership PRM & PAM
useful its own right, but it also points to the possibility of developing other Reference
Models for Organisational Behavior and PAMs covering a range of organisational
behaviors in a range of disciplines including but not limited to financial institutions
and banks, automotive systems and software, aerospace systems and software,
medical device systems and software, IT service management, test process
improvement, small and very small enterprises. This would significantly extend the
breadth of application of the standardised approach to process assessment.

From an Enterprise Architecture perspective, a Leadership Process Reference Model and its derived Assessment Model are arguably consistent with a generalized view of Enterprise Architecture as optimized formal descriptions of the elements and relationships (including people and technology) of an organisation in order to achieve their goals [3]. As such they make a worthwhile contribution to the EA domain.

References

1. Institute for Enterprise Architecture and Developments Enterprise Architecture Standards Overview, http://www_enterprise-architecture.info/EA_Standards.htm accessed 22 January, 2010.

2. Yukl, G.., Leadership in Organisations. Englewood Cliffs, N.J. Prentice-Hall (1994)

3 Bernus, P., Mertins, K., Schmidt, G. (Eds), Handbook on Architectures of Information Systems. 2nd Revised and extended edition. Berlin : Springer Verlag. 896 p. 2-6 (2006).

4. Tuffley, D., Implementing Integrated Teaming According to ISO15504, in Proceedings of the 6th International SPICE Conference on Process Assessment & Improvement, Centre de Recherche Public Henri Tudor, Luxembourg (2006).

5. Drucker, P. Managing in a Time of Great Change, Butterworth Heinemann, London (1996).

6. Bennis, W., On Becoming a Leader, What Leaders Read 1, Perseus Publishing, p 2 (1994).

7. Humphrey, W.S., Winning with Software. Addison Wesley Longman, Reading Massachusetts (2002).

8. Repenning, N.P., Sterman, J.D., Getting Quality the Old-Fashioned Way: Self-Confirming Attributions in the Dynamics of Process Improvement. Sloan School of Management, MIT., Cambridge, MA. (Available at: http://web.mit.edu/jsterman/www/SDG/Attrib.pdf )

9. Deming, W.E., Out of the Crisis, MIT Press, Cambridge MA, (1997).

10.Herbsleb, J. Moitra, D., Global Software Development, IEEE Software, Vol 18, Issue 2, p16-20, (2001).

11.Heston, K.M, Phifer, W, The Multiple Quality Models Paradox: How Much ‘Best Practice’ is Just Enough? Software Process Improvement and Practice. Wiley InterScience (2009).

12.Dromey, R.G. Climbing Over the 'No Silver Bullet' Brick Wall, IEEE Software, Vol. 23, No. 2, pp.118-120, (2006).

13.Tuffley, D., Rout, T, Applying Behavior Engineering To Process Modelling, in Proceedings of the 1st Improving Systems and Software Engineering Conference (ISSEC), National Convention Centre, Canberra, Australia, 10-12 August 2009.