Structuring risk into projects

National ICT Australia (NICTA) and School of Computer Science and Engineering, University of New South Wales (NSW), Sydney, Australia

Abstract

Experience tells us that projects can and do fail for many reasons. However, it would be most unfortunate if the propensity to fail was structured into the design of a project before it even started. This paper extends recent research on structure-related risk, which suggests that the organizational entities involved in projects, including the project itself, bring with them certain risks associated with their structural forms that can influence the performance and outcomes of projects. These risks can predispose a project to problems from the outset of its activities. The paper extends this research by considering how structure-related risks might arise and be managed in practice. Furthermore, since management of such risks tends to fall outside of the capabilities of the project and project manager, a new role for project governance is proposed in mediating and mitigating these risks. The propositions are illustrated with project examples and a case study. The arguments are presented within the application domain of software development projects but, conceptually, the principles can also be applied to other application domains such as engineering, construction, and defense. The research is still in its infancy but early results point to a potentially significant source of risk that has previously been overlooked.

Introduction

There are many ways to build risk into a project. For example, by their very nature as temporary activities producing a unique product, projects are subject to a liability of newness, which brings a higher propensity for failure (Bannerman, 2008). In software projects, one of the most common ways of structuring risk into projects is by choosing the wrong development methodology. Using a plan-driven methodology for an uncertain requirement, rather than an agile method, creates major risks and places great stress on a project (Boehm & Turner, 2003). Another sure way to overburden a project with risk is to make it too large, thereby creating a ‘death march’ project (Yourdon, 1997). Also, the nature of the task and the project's context may, unavoidably, be inherently risky.

This paper focuses on a source of project risk that has been largely overlooked in prior research and practice, namely, the risks that can arise from the structuring of projects. The organizational entities involved in a project–the project itself, the organization in which the project is conducted, and any other participating organizations (such as a client, vendor, or consultant)–bring with them structural characteristics that can generate risks for a project that are usually overlooked during risk identification because they are part of the fabric of the project itself. Indeed, some risks that are recognized may be symptoms of this underlying cause. Without recognizing the underlying cause, risk treatments are likely to be less effective.

Projects and other organizations involved in projects are usually structured according to common forms recognized in organization theory. These structural forms include functional bureaucracies, project-based organizations, matrix-based organizations and more flexible innovation-oriented structures. Recent research has found that specific risk sets can be associated with major structural forms (Bannerman, 2009). The organizational entities involved in a project interact with each other, creating an environment in which risks relating to their structural forms can impact the project and its performance. Without being aware of it, risk can be built into a project by the structural characteristics of the entities involved. In this way, risk can be structured into a project before it even starts.

This paper extends the earlier research in four ways. First, it considers the contexts in which structure-related risks might arise. Second, it illustrates the risk with examples of projects of three common structural forms from the original study. Third, it identifies a new role for project governance in mediating and mitigating these risks. Fourth, it proposes new and adapted analysis techniques in an integrated process for managing structure-related risks.

The paper focuses on threats rather than opportunities and argues from the application domain of the original study, namely, information technology (IT) software projects. However, the problem is also likely to arise in projects in other application domains. For example, public private partnerships (PPPs) in the construction industry have attracted much attention in research and practice. While risk management considerations have featured in the literature, risks inherent in the organizational structures involved in PPPs have received little attention.

Fundamentally, organization structure is about how organizational work is designed. Simplistically, it is reflected in an enterprise's organization chart. Common approaches to organization design are to group work together under an authority structure based on common business functions or processes, projects or products, customer segments or geographic areas, according to the purpose of the organization. Common structures include the functional form (including the simple form, the machine bureaucracy, and multidivisional form), project-based organization, matrix organization, professional bureaucracy, and adhocracy or innovative organization form (Galbraith, 1971; Hobday, 2000; Mintzberg, 1979). Each structural type has characteristics which, individually and in combination with others, can create structure-related risks that predispose a project to major threats before the project begins, regardless of the nature of the work to be undertaken by the project.

Understanding and managing structure-related risk is critically important in improving the quality and outcomes of projects. Because these risks are inherent in the structural makeup of projects, they tend to be overlooked or viewed as being outside of project and risk management's control. Consequently, it is argued that an external authority is needed to facilitate and coordinate risk management of structure-related risk. The project governance framework is viewed as being ideally positioned to perform this role.

The paper is structured as follows. The next section reviews prior research on project organization, structure-related risk and project governance, as background to the main contributions of the paper. The argument is supported by examples of projects of different structural forms and an integrative case study of how one organization used a governance mechanism to manage structure-related risk in a multi-vendor project. Finally, the contributions are discussed and implications drawn for research and practice before concluding.

Prior Research

This section reviews prior work on project organization, organization structure-related risk, and project governance.

Project Organization and Risk

Organization structure in projects is recognized in some standards-based bodies of knowledge but the risk implications of structure are not explicated or applied in project and risk processes. For example, the Project Management Institute's (PMI) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) recognizes that organizational structure is an enterprise environmental factor that can enhance or constrain project management options and affect project outcomes (PMI, 2008). Here, organization structure refers to the structure of the organization in which the project is conducted rather than to the project itself. The PMBOK® Guide distinguishes functional, matrix (weak, balanced and strong), and project forms of organization. It suggests that these structures can influence the availability of resources and how projects are conducted but the effects are not developed or applied in the knowledge process areas prescribed.

Consistent with this approach, Practice Standard for Project Risk Management (PMI, 2009) focuses on the generic processes of the project risk management knowledge area. It does not identify specific source categories of project risk other than to provide a general guideline that “Project Risk Management activities should be consistent with the value of the project to the organization and with its level of project risk, its scale, and other organizational constraints” (p. 7). Nor does it address the possibility of threats being built into the design of projects before project execution begins.

Similarly, the new risk management standard, AS/NZS ISO 31000:2009, has a process for “establishing the context” of risk management that includes consideration of “organizational structure”, but this is not explained or developed further. It also generally recognizes that risk management processes should be integrated into the organization's overall governance and management processes but no guidelines are provided on how this might be done.

Further to these practice standards, research has examined project and parent organization integration (Lehtonen & Martinsuo, 2009), structural contingency and risk (e.g., Roy, 2008), projects of different structural types (e.g., Hobday, 2000; Shenhar & Dvir, 2004), and the relationship between structure and project risk and performance (e.g., Larson & Gobel, 1989; McFarlan, 1981). For example, Larson & Gobel (1989) found that functional organization was least suitable for software projects, followed by functional (weak) matrix, with balanced matrix, project (strong) matrix, and project form structures achieving the best overall results. But these findings are not related to risk.

Organization Structure-Related Risks

Recent research has examined the risk implications of organization structures in software projects in public sector agencies (Bannerman, 2009). The current paper reports further on this study. The study of 17 projects found that the agencies adopted a range of structural arrangements and that these arrangements had project and risk management implications. By analyzing characteristics of the project structures, specific sets of risk factors were identified for common organizational forms. Table 1 summarizes the risk profiles developed in the study for the three main structural forms identified in the PMBOK® Guide: the functional, project, and matrix forms (the matrix form used is equivalent to the balanced matrix in the PMBOK® Guide).

The functional form is the most common way of organizing, namely, according to functional expertise. This form features strong hierarchical authority and control; highly structured and routinized work; formal coordination and communication; and a drive for achieving efficiencies based on economies of scale. It is optimized for routine, ongoing, efficient operations based on functional specialization of work. Mintzberg aptly names this form the ‘machine bureaucracy’ (Mintzberg, 1979). Five risks were identified as being associated with the functional form (summarized in Table 1):

  1. Preoccupation with routinized functional specialization has the potential to make it difficult for organizations of this form to complete one-off activities within schedule, budget and specification, resulting in projects tending to fall behind.
  2. Differing functional objectives can interfere in interdepartmental interactions, leading to tensions and conflicts between functional units, which may divert attention and distract or delay engagement in project activities.
  3. The hierarchical nature of command and control in functional structures may lead to operational inflexibility at lower levels in the face of unfamiliar, uncertain, and non-routine project activities.
  4. Standardization-based drivers toward efficiency and economies of scale in the functional form may not be conducive to innovation and change (a common objective of projects).
  5. Size can bring inefficiencies that can be the “death march” for projects (Yourdon, 1997).

The project form emerged during and after World War II as a reaction to the rigidities of the functional form. The aim and design of the project form is the opposite of the functional form. Here, projects are the main unit of organization rather than functions and the aim is to organize around achieving specific and often unique outcomes rather than to routinize repetitive work. Also, activities and reporting are designed to optimally suit the nature of each project. In a project-based organization, multiple projects are usually clustered under central management and shared support units. In this form, adopting ‘best practice’ project management standards is paramount. Seven risks were identified for the project form (summarized in Table 1):

  1. Functional inefficiencies in the project form can generate cost pressures and other performance issues in projects.
  2. As independent structures, projects can become detached from their strategic base, leading to a loss of direction.
  3. By contrast, this independence enables great flexibility and adaptability in project activities that, if left unchecked, may lead to problems of operational control if they become self-serving.
  4. Achieving stakeholder buy-in can be difficult due to the structural separation of the project.
  5. The insular nature of projects, focused on their own goals and practices, can lead to myopia with respect to the context and purpose that motivate their existence.
  6. Projects are dependent on a range of skills and, due to their tight constraints, may not always be able to obtain all of the right skills needed for the job.
  7. Unlike the functional form, projects are not resourced or scoped for developing capabilities for future projects. They offer strong learning opportunities but weak potential for accumulating learning and carrying it forward.

Finally, the matrix form aims to achieve the best of the functional and project forms. Typically, matrices are structured functionally vertically, overlaid by projects horizontally, with dual authority and reporting lines. Contrary to the design intentions, matrix-based organizations often become unworkable in practice, with decision making paralyzed and/or politicized. Five risks were identified for the matrix form (summarized in Table 1):

  1. The dual reporting nature of the matrix often results in loyalty conflicts and unclear accountabilities.
  2. Localized claims to authority can result in decisions and actions being taken in isolation of other relevant interests, resulting in poor decision-making.
  3. Overlapping responsibility domains under separate authorities and interests can distract attention from project objectives and lead to slow response times.
  4. Internal preoccupation with sectional interests and infighting can result in a degradation of operations and project-related control problems.
  5. The absence of clarity and freedom to act that can arise in matrix structures can be highly stressful for staff, resulting in project staffing problems and turnover.

Table 1: Threats associated with dominant organization structure types1

Structure-related driver Threat
Functional Structure:
Functional specialization dominates; inefficient in one-off, discrete activities Projects fall behind
Functional conflicts; conflicting objectives and tensions distract focus Engagement distraction
Hierarchical control; tight vertical authority and reporting lines, rigid roles Operational inflexibility
Drive for functional efficiency and scale economies favor the status quo/stability Innovation suppressed
Drive for scale efficiencies leads to large organizations Size-related inefficiencies
Project Structure:
Non-routine; does not scale well, weak in coordinating processes Cost pressures
Detached; can lose connection with the strategic centre Strategic control
Operationally decoupled from functional controls; can be responsive and reactive Operational control
Stakeholders can become strategically and operationally detached Stakeholder participation
Myopic; insularity can result in loss of grounding in the originating purpose Contextual blindness
Team resources are acquired sparingly; the acquired skills may not match needs Adequacy of personnel
Weak in learning; limited mechanisms or incentives for learning from experience Capability development
Matrix Structure:
Dual reporting; has competing authority structures and split loyalties Unclear accountabilities
Stronger authority lines can dominate decisions, creating an authority bias Poor decision-making
Power, authority and accountability often lie with different people Slow response time
Tendency toward anarchy; control can break down, self interest can take over Control problems
Dual reporting, conflict and ambiguity can result in personnel issues and stress Staff stress and turnover

In establishing a project with multiple participating organizations, stakeholders are potentially structuring in risks associated with each organization type. This paper extends the prior research by considering the contexts in which structure-related threats might arise and a new role for project governance in mediating and mitigating the threats through a customized risk management process. It also illustrates the threats with project examples.

However, before considering this new role for project governance in managing structure-related project risk, current views on governance in the research and practice literature are briefly reviewed.

Governance and Risk

Research in organizational governance has its origins in political science and institutional economics. In general in these views, the spirit of governance is good order and workable arrangements (Williamson, 1996). At the board and executive level, corporate governance is concerned with enacting arrangements to direct, administer, and control a corporation to the satisfaction of major stakeholders and regulators. This includes managing risk. Subordinate to this level are other domain-specific governance arrangements such as IT governance and project governance.

Within the IT domain, the scope of IT governance is usually assumed to include: strategic alignment, risk management, delivery of business value through IT, control and accountability, performance management, and capability management (Willson & Pollard, 2009). IT governance is viewed as comprising structures, processes and relational mechanisms (Van Grembergen & De Haes, 2009; Weill & Ross, 2004). Apart from some early interest in the structuring of the IT function in organizations (for example, whether it should be centralized, decentralized, or positioned in a hybrid/federated form) (Brown & Grant, 2005), IT governance research has focused mainly on strategic and operational alignment rather than structural alignment. More recently, IT governance standards have started to emerge; in particular, ISO/IEC 38500:2008 (based on the Australian Standard AS 8015-2005), and a derivative draft Australian Standard on the corporate governance of projects involving IT investments (DR 08145). Industry frameworks such as Information Technology Infrastructure Library (ITIL) and Control Objectives for Information and related Technology (COBIT) are also popular in practice, providing guidance on IT governance, among other things. A recent integrative view is provided by Van Grembergen & de Haes (2009). Also, a comprehensive list of IT governance frameworks is provided in Parent & Reich (2009).

Interest in project governance is more recent than IT governance but is not yet well established as a stream of research or a formally prescribed discipline in practice. Notable recent contributions have been made by Müller (2009) (research-oriented), and Garland (2009) (practice-based). Müller (2009) defines project governance as “the value system, responsibilities, processes and policies that allow projects to achieve organizational objectives and foster implementation that is in the best interests of all the stakeholders” (p. 4). Its overall aim is “a consistent and predictable delivery of projects and programs in accordance with their planned contribution to corporate strategy and stakeholder expectations” (Müller, 2009, p. 16). He describes roles and tasks for governance of projects, programs, portfolios, and project management and links them together is an integrative framework underpinned by several organization theories.

Garland (2009) defines project governance as “the process of project decision making and the framework, models, or structures that are established to enable this” (p. 1). His approach to project governance is based on four principles derived from experience: (1) ensure a single point of accountability for the success of the project; (2) service delivery ownership determines project ownership; (3) ensure separation of stakeholder management and project decision-making activities, and; (4) ensure separation of project governance and organizational governance structures. This last point reflects a perception that organization structures may be important in projects and may impinge on the role of project governance. Garland observes that the organization's structure is not designed for project delivery and argues that the project's governance should have the authority and autonomy to make project decisions independently of the organization's governance structure. However, the rationale is efficiency-based rather than risk-based, that is, that it avoids the delays and inefficiencies associated with multi-layered decision making.

More broadly, turning to practice standards, the PMI's PMBOK® Guide and methodologies such as PRINCE2 imply governance through the structured frameworks they propose but do not describe a discrete project governance function or highlight a governance role in risk management. For example, Projects in Controlled Environments, second version, (PRINCE2®) contains a Directing a Project (DP) process group, owned by a Project Board comprising the customer, senior user, and senior supplier. The Board's responsibilities are to provide the project manager with decisions relating to the progress of the project and to assist in overcoming any problems (OGC, 2009a). The Board's processes cover project initiation, stage boundaries, ad hoc direction, and project closure. However, PRINCE2® provides little specific guidance on governance. In a recent attempt to overcome this limitation, a new manual on directing projects has been introduced for executives, sponsors, and board members to further explicate the DP processes (OGC, 2009b).

The PMBOK® Guide is less specific. Its only statement on the topic is that “Project governance provides a comprehensive, consistent method of controlling the project and ensuring its success. The project governance approach should be described in the project management plan. A project's governance must fit within the larger context of the program or organization sponsoring it.” (PMI, 2008, p. 20). The PMBOK® Guide appears to assume that the project, program, and portfolio management structures and practices it describes provide de facto governance (supported by PMI's Organizational Project Management Maturity Model (OPM3®)-Second Edition).

By contrast, the Association for Project Management (APM) does include governance in its body of knowledge to ensure that the organization's project portfolio is aligned to its objectives, is delivered efficiently, and is sustainable (APM, 2006). However, its focus is governance of project management rather than of projects per se (APM, 2004). It aims to inform boards on project portfolio direction, project sponsorship, project management effectiveness and efficiency, and disclosure and reporting. In contrast (and consistent with Müller, 2009), this paper views effective project governance as including governance of an organization's project management capabilities and practices as well as the direction, execution, and control of its programs and projects.

It appears, therefore, that project governance is still an emerging practice. Governance is undeveloped as a discrete focus in project management practice standards, which suggests it is open to further definition. This view is supported by work on standards. The draft Australian Standard on the corporate governance of projects involving IT investments (DR 08145) applies the framework and principles of AS 8015-2005 to projects. It defines three main processes (direct, evaluate, and monitor) and six principles:

  1. Roles for the governance and management of projects and responsibility for project outcomes are clearly defined and understood.
  2. Projects are aligned with the organization's business and IT strategies.
  3. Projects are undertaken validly and transparently.
  4. Projects are governed to achieve agreed objectives with risks to the organization managed.
  5. Projects conform to policies and regulations.
  6. Projects demonstrate respect for human behavior.

This reflects a strong orientation toward strategic and operational alignment. However, there is no specific mention of meditation or alignment of the disparate organization structures involved in projects, or management of their associated risks.

Finally, other recent research has focused on the project management office (PMO) as a locus of project and project management governance (e.g., Block & Frame, 1998; Hill 2008). Much of this research is empirically based and is struggling with the diversity of PMOs found in practice (e.g., Aubry et al., 2007; Dai & Wells, 2004; Hobbs & Aubry, 2008). However, the research does point to the potential importance of the PMO as a governance mechanism and as a learning center for carrying forward lessons learned from individual projects to future projects, both of which can contribute to risk management.

Managing Structure-related Threats

In this section, we extend the prior research on structure-related risk by considering how such risk might arise in practice (that is, how risk can be structured into projects) and how it might be managed. First, common sources of structure-related risk are considered and examples of the three main structures discussed in the previous section are provided to illustrate how risks can arise from these structures. Then a new role is proposed for governance to mediate between the structural entities involved in projects and mitigate structure-related risks. Finally, an integrated structure-related risk management process is proposed. Following this section, an integrative case study highlights the experiences of one organization in managing structure-related risks in a multi-vendor project.

Sources of Structure-related Threats

In the previous section, we saw that organizational structure is often viewed as applying only to the organization conducting the project. However, other organizational entities, with concomitant organization structures, are also involved in projects, including the project itself. These can be sources of significant influence on a project as well as interactions between the different organizational entities involved. Consequently, four main sources of structure-related risk factors can be identified in software projects:

Project organization. Projects are usually organized according to one of the structure types described in the previous section. This structuring relates to the project team itself, independent of any associated project governance structures, contributing business units, and participating third-party organizations that might also be involved in the project. Each project is subject to potential risk factors from the risk profile of its structural type described in Table 1 (functional, project, or matrix). For example, most projects in the public sector study were structured as temporary project teams under the direction and control of the project manager, either within a business unit or corporate function (i.e., functional structure), or independent of all other functional and divisional line management structures (project structure).

Parent organization. The parent organization is the organizational entity with the most direct responsibility for establishing and executing the project, and ensuring that the objectives of the project are achieved. The parent may or may not be funding the project investment (depending on whether it is for internal use or external delivery to a client). This source relates to the organization design of the parent organization independent of the project structure that operates under its control. Again, the structure of the parent can generate type-specific risk factors (from the risk profile of the associated organization structure in Table 1) that may impact its interactions with the project and any other involved parties. In the public sector study, all agencies conformed to the classical functional form.

Note that for project-based organizations (a common form in construction, engineering and software companies), the project and parent organizations may be closely related. The project may be one of the projects in the company's portfolio of client-based projects. The key difference is that the project organization would relate to the project ‘silo’ (conceptually, the equivalent of a function in the functional form or division in the divisional form) while the parent organization would relate to the overall corporate entity, encompassing the corporate office components and all projects that are active at a particular point in time.

Other influencing organizations. It is common for other parties to be involved in software (and other) projects in addition to the project and parent entities. These third parties can include, for example, clients, consultants, vendors, and developers. These organizations are often in a position to significantly influence the project. Therefore, the potential threats arising from their structural forms, and/or the interaction of these entities with the other entities involved in the project activity, may also critically impact the project's performance and outcomes. For example, the case study in the next section features a multi-vendor project involving eight vendor companies of either functional/divisional or matrix organization forms.

Other structural entities within and external to a parent organization may also influence a project. Examples include governance-related structures, standards bodies, regulatory authorities, and compliance entities. However, analysis of the structure-related risks associated with such entities and their influence on software projects are subjects for future research.

Interactions. Finally, interactions between these organizational entities during their involvement in a project can compound the threat to projects. In practice, common interactions are found to occur between: (a) the project organization and the parent organization (and/or its subunits, such as functional divisions or business units); (b) the project organization and external organizations; and (c) the parent organization and external organizations. Different combinations of organizations of different structural forms can result in many project configurations and, consequently, many combinations of structure-related threats. This diversity implies that while it may become possible to identify common or generic patterns of structure-related risks associated with common project configurations (known as generic risks), analysis of context-specific, structure-related risks is likely to be essential.

Project Examples

Before proceeding, three examples of public sector projects are profiled to illustrate projects organized according to the three main forms described in Table 1 (functional, project and matrix forms). Each example identifies the organizational entities involved, their structures, and the structure-related threats from Table 1 that were encountered during the project.

Functional structure. The first project involved customization, testing, and implementation of a new enterprise resource planning (ERP) software module. Apart from the project entity, three functionally structured departments from the parent agency were involved in the project and one project-oriented external vendor. The main structural relationships are shown in Figure 1.

The six-month project was managed by the IT department, but each department contributed by taking time out from its normal functional roles, as and when necessary. Project management was weak. There was no formal project team and no project steering committee. The project was essentially a discrete activity performed within the functional structure of the IT department, to which the other departments periodically contributed. However, the project had a specific objective, budget, and schedule. Much of the technical work of customizing and implementing the ERP module was done by the software vendor.

Structural relationships in a functional structure-based project

Figure 1: Structural relationships in a functional structure-based project

Three functional-form threats and one project threat, all of which are identified in Table 1, were realized in this project (the occurrence of threats from the project structure in a functional form entity is likely due to the functional form project still being a project, which may experience risks in common with projects of a purer project form):

  • Projects fall behind–delays and extra costs were incurred by Finance (the main business facilitator) over functional interests.
  • Engagement distraction–issues arose between IT and Facilities (the main business user), over which unit was responsible for providing training.
  • Innovation suppressed–only necessary tasks were performed; no one sought to leverage added value.
  • Capability development–lessons were recognized but not acted upon in the next project.

The project was considered a success by IT because the specified deliverables were produced. Later, however, further work had to be done to introduce another interface, which was recognized during the initial implementation but ignored because it was not in the description of works for the project. A more formal approach to project management may have avoided this issue. This, supported by effective project governance, may have mediated the relationships (which were mostly internal) and mitigated the risks (perhaps avoiding them being realized as project issues) and produced a better result.

Project structure. The second project involved development of a web-based records search-engine system by a small agency to provide public access to information. Apart from the project entity and parent agency, one external developer was involved in the project. The agency was functionally structured, the internal project was organized formally according to a project form, and the external software developer was project-oriented. The main structural relationships are shown in Figure 2.

The six-month project was led by the Chief Information Officer as project manager, with records specialists from two business units as project team members. The project's scope comprised mostly software development, provisioning of some web infrastructure and implementation. A project steering committee (PSC) was established, headed by an executive director, and included business unit managers, records specialists and the project manager. As the agency had few IT resources, the development work was contracted to an IT services firm.

Structural relationships in a project structure-based project

Figure 2: Structural relationships in a project structure-based project

While formal project governance existed, it was weak and did not include the contractor. Consequently, it was ineffective as a mediating mechanism between the project and its agency stakeholders, and provided no alignment between the agency and the developer. All seven project form risks from Table 1 were encountered by the project:

  • Cost pressures–insufficient funds were obtained from the central funding authority so the project placed significant cost pressures on the agency.
  • Strategic control–the project focused on the technology solution, not the business problem.
  • Operational control–the developer set the project schedule, made all architecture decisions and operated independently (offsite).
  • Stakeholder participation–poor buy-in by business unit personnel resulted in inadequate testing and insufficient loading of records into the database.
  • Contextual blindness–the project focused only on the technical solution; it was considered a success because the developed system worked as intended.
  • Adequacy of personnel–the project did not have enough testers or skilled internal technical staff.
  • Capability development–nothing was learnt; the agency repeated this model on a subsequent project.

Despite these issues, the project was considered to be a technical success. However, the records system had insufficient data loaded for it to satisfy public needs. The agency was under too many cost pressures to spare subject matter specialists to load the available information or to hire temporary staff to assist. Better governance may have created more effective alignment with business stakeholders and created an integrative bridge with the contractor organization to mitigate these problems.

Matrix structure. In the third project, a web-based system was developed by a government agency to manage the process of contractors tendering for government work. Apart from the project entity, two agency departments were involved (the sponsoring department and IT), operating as matrix organizations, and an external project-oriented organization, which developed the software. The main structural relationships are shown in Figure 3.

Planned as a six-month project, the project was sponsored and managed by the agency's Procurement business unit, responsible for managing contract tendering, and the IT department, whose primary role was to provide IT infrastructure for the new system. The system was to be offered on a ‘Software as a Service’ basis to the procurement units of other government agencies. The system was developed by the external developer based on specifications prepared by the agency. The project was set up as a formal project under a project manager but without explicit project governance.

Structural relationships in a matrix structure-based project

Figure 3: Structural relationships in a matrix structure-based project

Three matrix form risks and three project form risks from Table 1 were realized during the project (again, the existence of risk factors from the project form structure in a matrix form organization is most likely due to the matrix form being a composite of the functional and project forms):

  • Unclear accountabilities–the project experienced difficulties with functional silos, especially from IT, which provided inadequate input to the project because the required system was nonstandard.
  • Poor decision-making–the vendor was chosen in isolation of other decision-making authorities based on its prior experience with the application; however, it went into receivership before the project finished.
  • Control problems–the vendor focused more on features it had delivered to prior clients than understanding the agency's requirements, change control was a problem, and staff-related change management was ad hoc.
  • Strategic control–sponsors were ‘dreamers'; there was no strategic grounding (as evidenced by the absence of project governance).
  • Stakeholder participation–the main business sponsor had no involvement after initiation; IT buy-in was also low.
  • Adequacy of personnel–IT was unskilled in the targeted Unix-based platform.

The project was delivered late and software development had to be brought in-house because the contracted developer organization failed. The project team was able to superficially recognize the issues as they arose but not their underlying causes. An effective project governance body may have had the necessary oversight of the project and vision of the structural drivers, to enable the agency to ensure that actions were taken to avoid or minimize the effects of these issues, especially relating to selection of the developer and the contribution of the IT department.

Role of Governance in Structure-related Risks

In the preceding examples of structure-related project risks, in addition to the possibility of improved project management in some cases, the opportunity was identified of project governance supporting the projects by mediating and mitigating these risks. This possibility is now considered more closely.

Structure-related risks differ from other project risks in a manner that makes them difficult to manage adequately within traditional risk management processes:

  1. Structure-related risks tend to have low visibility within projects. After a project is initiated, the structural context of the project is already determined and is usually taken as a fixed characteristic of the project. After initiation, risk management tends to focus on operational rather than structural or contextual concerns. Consequently, structure-related risk may not receive the attention it deserves.
  2. Once initiated, structure-related risks are essentially external to the project so, as well as lying outside of the project manager's immediate purview, they may also lie outside of his/her direct control. The project manager is constrained in the risk response strategies the project can apply to risks that arise in relation to other organizational entities involved in the project, including the parent and external parties.
  3. Additional considerations often come into play in dealing with other organizational entities that may be independent of the project engagement. These might be strategic, political, financial, legal, reputational, or purely relational. The project may not be in a position to understand or act on these broader considerations.

Consequently, while the project has a role to play in identifying and managing structure-related risk, it is unlikely that it can manage all such risks alone. This is consistent with a recent study that found that project managers, alone, are unlikely to adequately identify stakeholders, assess their risk implications, or track changes in stakeholder threats throughout the project (Jepsen & Eskerod, 2009). An authority external to the project and with the span of vision over the entities involved and the influence to consider any broader implications is required to own responsibility for structure-related risk management and work with projects to mediate and mitigate the effects of the different organizational structures involved. Accordingly, it is proposed that governance (and project governance in particular) is ideally positioned to be responsible for managing structure-related risk.

As seen from the prior research, managing structure-related risk is highly consistent with the operational and strategic alignment agenda of governance. It adds a structural dimension to the focus on strategic and operational alignment. Governance is an ideal structural, relational, and processual mechanism to mediate relationships between different structural entities and mitigate the effects of any threats resulting from these structures on the projects under its control.

Structure-related risk also adds a significant source of risk to the risk management agenda that has been ignored in the past and is beyond the ability of individual projects to adequately control. This source of risk, resulting from structural differences and incompatibilities between participating organizational entities, could explain underlying drivers of many persistent risks in software projects. Take for example two of the most commonly cited critical success/risk factors: executive support and user involvement. Due to the structural divide of the project entity from the parent organization, there is no convenient mechanism for executives of the parent organization to participate in the oversight of projects that are of high significance to the whole enterprise. A governance structure enables that gap to be bridged. Similarly, governance can bridge the gap between the project entity and business stakeholders, enabling business managers to have the visibility of the project needed for them to provide the influence and resource inputs that may be necessary for the project to succeed. This role of governance goes beyond operational and strategic alignment to include structural alignment between the organizational entities involved.

Since structure-related risk, as a source category of risks, extends beyond the traditional domain of project risk management, new analysis techniques are needed to adequately manage this risk. An existing technique, stakeholder analysis, is adapted to support risk management processes and a new technique, structure analysis, is proposed.

Stakeholder analysis is an existing technique that can also be used for managing structure-related risks. In general, stakeholders are individuals or groups who have a vested interest in a project, what it produces and/or its outcomes. Stakeholders may be involved in or affected by a project. In the current context, the focus of interest is stakeholder groups (organizations or parts thereof) rather than individuals. Stakeholders with convergent interests may be enlisted to support a project and help it progress while stakeholders with divergent interests may impede the project, either overtly or covertly, and therefore necessitate their potential impacts being mitigated.

Two main stakeholder analysis process steps are specifically relevant in managing structure-related risk. The first is to identify the key organizations that have a stake in the project. The second is to identify potential stakeholder interests, relating to their structural type that might positively or negatively impact the project. The risk profiles described in Table 1 are a starting point for identifying potential structure-related interests. Stakeholder theory, analysis, and mapping techniques can be readily found in the literature (e.g., Friedman & Miles, 2006) and on the Web.

Structure analysis similarly has two main steps: first, to determine the structural form of each organizational entity involved in a project, and second, to identify potential structure-related risks that might arise from the entity's involvement and/or from its interaction with other involved parties. The first analysis process examines each entity against its organization chart and structural profiles developed from the literature (such as those summarized in Bannerman, 2010), and classifies it according to the closest matching structural form. (Note that in organization theory, these forms are ideal generic types; actual organizations may not exactly match the form of an ideal type.) Structural form is usually stable so the analysis may only need to be done once, as early as possible in the project life cycle. However, monitoring for structural change should be included in the risk management cycles. The second analysis process examines each entity against structure-related risk profiles (such as described in Table 1), and its espoused and likely interests, to identify potential risks (opportunities and threats).

These two techniques can be combined with traditional project risk management processes to form an integrated approach to managing structure-related risk, as outlined in Table 2.

Table 2: An integrated structure-related risk management process

Step

Task

Technique

1

Identify the key organizations involved in the project

Stakeholder analysis

2

Determine the structural form of each key organization

Structure analysis

3

Identify potential structure-related risks

Structure analysis, stakeholder analysis and risk management

4

Assess the identified risks

Risk management

5

Formulate and apply risk response strategies

Risk management

6

Monitor and review iteratively

Risk management

In Table 2, steps 1 to 3 can be collapsed as subtasks in the ‘identify risks’ process in mainstream risk management frameworks such as the PMI's Practice Standard for Project Risk Management and the AS/NZS ISO 31000:2009 Risk Management standard, making it easy for adopters to integrate the additional analyses.

Project governance is in an ideal position to take responsibility for the management and execution of this process. It has both the perspective and span of influence to effectively manage structure-related risks. While the operational implementation of the process may be assigned to a representative (such as a process manager or even the project manager) the proposition is that responsibility and accountability for managing structure-related risk would remain with project governance, within the broader framework of the organization's governance arrangements.

Case Illustration of the Role of Governance in Structure-related Risk Management

This case illustrates a more complex project than the three earlier examples, involving multiple parties. It also provides a rudimentary illustration of how governance is ideally placed to resolve structure-related risk. This case also involved a government agency (at the national level) but, here, the agency played a comparatively passive role. Instead, the focus is on a major hardware vendor organization, which was appointed prime contractor to complete a large project on a ‘turn-key’ basis. The project's aim was to replace the agency's national IT infrastructure in 40 sites with a variety of new hardware, systems software, networks, and application software from multiple suppliers. Our interest is in the structural arrangement that was established to execute the project.

The agency wanted the security and simplicity of dealing with only one vendor so it chose a high profile hardware vendor to act as prime contractor, with the other suppliers subcontracting to it. The main structural relationships are shown in Figure 4. Each corporation conformed to either the functional or matrix structural form. However, in this case, the structure of each participant was less an issue than the structure of the project.

Structural relationships in a multivendor project

Figure 4: Structural relationships in a multivendor project

The arrangement proved to be less than satisfactory for all parties involved. Apart from needing to comply with an overall project schedule, each supplier was largely able to act independently. Furthermore, each had to coordinate with the agency so the agency adopted a practice of dealing directly with each supplier, bypassing the prime contractor. While this was not a major issue for the prime contractor (after all, it was still being paid the prime contractor fee), when the principal application developer encountered financial difficulties (a small owner-managed software house), and looked like the company might fail, the agency enforced the contract terms and insisted that the major vendor take responsibility for the performance of the developer in fulfilling the contract. The vendor had to take over management and funding of the final stages of software development, at a cost that far exceeded its prime contractor compensation. Rollout of the integrated procurement and asset management system under development was to be the main deliverable in the second half of the project.

A midterm milestone at which maintenance agreements were due for renewal (for equipment already operational) provided the opportunity to review the arrangement. The prime contractor set up a working party to consider how to resolve the problem. This governance mechanism comprised a senior manager, the project director and legal counsel from the prime contractor, a senior manager from the government agency and the owner of the developer organization. The working party considered various options and financial models to find a way forward. The net result was that to retain the present arrangement, the agency would have to pay a huge risk premium to cover the vendor's costs if the software house failed. However, neither party liked this option (the vendor did not want to take ownership of the application software and the agency could not pay the risk premium without retendering for the software).

Finally, it was agreed to restructure the project, through legal/contractual means, to release the vendor from the prime contracting role and for the agency to deal directly with each supplier, including the developer, thereby accepting all risk. To avoid the agency having to retender, the project was restructured by retaining the head contract between the agency and vendor, and novating2 each supplier subcontract from the vendor to the agency. With the commissioning of additional work by the agency, the developer was able to trade through its financial crisis, successfully completing the project.

In sum, through the mediation of the governance working party, the vendor identified, assessed, and mitigated the risk by renegotiating the contract to restructure the project, thereby avoiding the risk. In turn, the agency mitigated its risk of direct responsibility for the developer by giving it another cash stream to help it through its difficulties. The prime contractor's project team did not have the visibility of the problem or executive ‘clout’ to have achieved this outcome.

This case graphically illustrates how structure-related risk (a complex contractual arrangement and the near failure of the principal software developer) can significantly threaten the performance and success of a project, and how these threats could not be adequately handled from within the project itself. Rather, they required a project governance body with the visibility of the issues and scope of influence to remove the structural barriers to save the project. As such, this case lends direct support to the principles proposed in this paper for managing structure-related risk.

Discussion

Understanding and managing structure-related risks is critically important in improving the quality and outcomes of projects. This paper has extended prior research on structure-related risk by considering how risk that is built into project designs via the organizational structures of entities involved in the project might be managed. Structural types have characteristics that, individually and in combination with characteristics of other organizational types, can create structure-related risks, which predispose a project to major threats before the project begins, regardless of the nature of the work to be undertaken by the project or external environmental factors. It has been argued that these structure-related risks have a low visibility within projects, tending to be outside of the purview and control of the operational focus of the project manager and project team. This necessitates management support from an external authority that has the span of vision and influence to own structure-related risk management and work with projects to mediate and mitigate the effects of the different organizations involved. An integrative process combining existing and new techniques is proposed to aid in identifying and managing structure-related risks.

The research has some limitations. Work so far has focused only on common organization structures and traditional organizational interactions in projects. This does not reflect the full diversity of arrangements in practice. Further work is needed to identify the scope of structural forms and interaction configurations between participating entities to establish the boundaries of the problem. Also, empirical validation of the propositions is only preliminary, based on a small number of case studies. Further empirical investigation is required to validate the nature and scale of importance of structure-related risk in projects and the role of project governance (as opposed to some other mechanism), as the primary authority for managing such risks. Also, the proposed risk management process is generic and preliminary. It will likely need to be adapted to specific project contexts. Further work is needed on the development of management processes and guidelines to support the control of these risks in practice. Finally, the study needs to be extended beyond the IT domain by considering other domain-specific structure-related risk management challenges.

The paper has implications for research and practice. For research, it highlights that in addition to risks that are endogenous and exogenous to software projects, risks relating to the structural makeup of the project are also critically important. It also reinforces the importance of the macro process context of projects. Because of the inherent challenges in projects as temporary unique endeavors, research has tended to focus on operational project and risk management, ignoring structural (if not also strategic) considerations. Because structure-related risks may involve sensitivities outside of the capabilities of the project team to recognize, the involvement of an external authority is needed to adequately manage the risk. This positions research in project and risk management in a broader context than is traditionally considered (that is, of achieving the specified objectives of the project). Furthermore, proposing a structure-related risk management role for project governance also extends the traditional alignment role of governance beyond operational and strategic alignment within the parent organization to include structural alignment of all organizational entities involved in the project through mediation and mitigation actions.

For practice, the paper suggests that the project is not well positioned to manage all project-related risks and that the role of project governance needs to be extended beyond the passive receipt of risk register updates and general risk management oversight to actively analyze project structures, as well as, own and manage structure-related risk. Current risk management practices tend to only engage project steering committees in monitoring high-priority risk factors in the risk register, as updated periodically by the project manager. The proposed approach assigns direct responsibility to the project steering committee (project board or similar governance body) for risk management processes related to one source category of risks, namely, those risks stemming from the project structure, the structures of the organizational entities involved in the project, and their interactions. This provides a mechanism of support that projects and project managers should foster to extend their capabilities in limiting project shocks from risks that are structured into the project and are largely outside of their control, improving outcomes for all project stakeholders.

Conclusion

Project management has been actively researched for more than forty years. While some industrybased surveys have reported performance improvements from time to time (such as the Standish Group's surveys on software development projects), much scope remains for improvement. As novel, sometimes highly complex, and risky activities, there are many sources of factors that could contribute to explaining project underperformance. The current research suggests that structural characteristics of organizational entities involved in projects may be a source that has previously been overlooked. More specifically, it suggests that we may be inadvertently structuring threats into projects. This paper has aimed to show how this might occur and how such risks might be managed, supported by examples and an illustrative case study. This research is still in its early stages and needs further empirical support, so its propositions are preliminary. Ongoing interaction with the practitioner community is critical in establishing the scope of the problem and how it might be managed.

Acknowledgments

NICTA is funded by the Australian Government as represented by the Department of Broadband, Communications and Digital Economy and the Australian Research Council through the ICT Centre of Excellence program.

References

Addison, T., & Vallabh, S. (2002). Controlling software project risks–An empirical study of methods used by experienced project managers, Proceedings of SAICSIT, 128-140.

APM. (2004). Directing change: A guide to governance of project management, High Wycombe, England: Association for Project Management.

APM. (2006). APM body of knowledge. 5th Edition, High Wycombe, England: Association for Project Management.

Aubry, M., Hobbs, B., & Thuillier, D. (2007). A new framework for understanding organizational project management through the PMO. International Journal of Project Management, 25(4), 328-336.

Avison, D.E., & Fitzgerald, G. (2003). Where now for development methodologies? Communications of the ACM, 46(1), 79-82.

Bannerman, P.L. (2008). Smoothing Innovation Discontinuities. Proceedings of the IEEE International Conference on Communications (ICC ‘08), Engineering Management Mini-Conference (IEMC-China ‘08), IEEE, 19-23 May, Beijing, China, 5458-5462.

Bannerman, P.L. (2009). Risk Implications of Software Project Organization Structures. Proceedings of the 20th Australian Software Engineering Conference (ASWEC ‘09), IEEE, 14-17 April, Gold Coast, Australia, 307-316.

Bannerman, P.L. (2010). Managing Structure-Related Software Project Risk. Proceedings of the 21st Australian Software Engineering Conference (ASWEC ‘10), IEEE, 6-9 April, Auckland, New Zealand.

Block, T.R., & Frame, J.D. (1998). The project office. Menlo Park, CA: Crisp Learning.

Boehm, B.W. (1991). Software risk management: Principles and practices, IEEE Software, 8(1), 32-41.

Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley.

Brown, A.E., & Grant, G.G. (2005). Framing the frameworks: A review of IT governance research. Communications of the Association for Information Systems, 15, 696-712.

Constantine, L.L. (1993). Work organization: Paradigms for project management and organization. Communications of the ACM, 36(10), 35-43.

Dai, C.X, & Wells, W.G. (2004). An exploration of project management office features and their relationship to project performance. International Journal of Project Management, 22(7), 523-532.

Davis, S.M., & Lawrence, P.R. (1978). Problems of matrix organizations, Harvard Business Review, 56(3), 131-142.

Engwall, M., & Jerbrant, A. (2003). The resource allocation syndrome: The prime challenge of multi-project management? International Journal of Project Management, 21(6), 402-409.

Friedman, A.L., & Miles, S. (2006). Stakeholders: Theory and practice. Oxford, England: Oxford University Press.

Galbraith, J.R. (1971). Matrix organization designs: How to combine functional and project forms. Business Horizons, 14(1), 29-40.

Garland, R. (2009). Project governance: A practical guide to effective project decision making. London: Kogan Page.

Hill, G.M. (2008). The Complete Project Management Office Handbook, Second Edition, Boca Rotan, FL: Auerbach Publication.

Hobbs, B., & Aubry, M. (2008). An empirically grounded search for a typology of project management offices. Proceedings of the Project Management Institute Research Conference, Warsaw, Poland, July, 1-16.

Hobday, M. (2000). The project-based organisation: An ideal form for managing complex products and systems? Research Policy, 29(7-8), 871-893.

Jepsen, A.L., & Eskerod, P. (2009). Stakeholder analysis in projects: Challenges in using current guidelines in the real world. International Journal of Project Management, 27(4), 335-343.

Keil, M., Cule, P.E., Lyytinen, K., & Schmidt, R.C. (1998). A framework for identifying software project risks. Communications of the ACM, 41(11), 76-83.

Larson, E.W., & Gobeli, D.H. (1987). Matrix management: Contradictions and insights. California Management Review, 29(4), 126-138.

Larson, E.W., & Gobeli, D.H. (1989). Significance of project management structure on success. IEEE Transactions on Engineering Management, 36(2), 119-125.

Lehtonen, P., & Martinsuo, M. (2009). Integrating the change program with the parent organization. International Journal of Project Management, 27(2), 154-165.

McFarlan, F.W. (1981). Portfolio approach to information systems. Harvard Business Review, 59(5), 142–150.

Mintzberg, H. (1979). The structuring of organizations. Englewood Cliffs, NJ: Prentice-Hall.

Mintzberg, H. (1981). Organization design: Fashion or fit? Harvard Business Review, 59(1), 103-116.

Mintzberg, H. (1991). The effective organization: Forces and forms. Sloan Management Review, 32(2), 54-67.

Müller, R. (2009). Project Governance, Farnham, England: Gower Publishing.

OGC. (2009a). Managing Successful Projects with PRINCE2, London: Office of Government Commerce.

OGC. (2009b). Directing Successful Projects with PRINCE2, London: Office of Government Commerce.

Parent, M., & Reich, B.H. (2009). Governing information technology risk. California Management Review, 51(3), 134-152.

Peters, J. (1993). Business policy in practice: On structures, Management Decision, 31(6), 60-62.

Peters, T.J., & Waterman, R.H. (1982). In search of excellence. New York: Harper & Row.

PMI. (2008). A guide to the project management body of knowledge (PMBOK® Guide). 4th Edition, ANSI/PMI 99-001-2008, Newtown Square, PA: Project Management Institute.

PMI. (2009). Practice standard for project risk management, Newtown Square, PA: Project Management Institute.

Roy, A. (2008). Organization structure and risk taking in banking. Risk Management, 10(2), 122-134.

Sauer, C., & Yetton, P.W. (1997). Steps to the future: Fresh thinking on the management of IT-based organisational transformation. San Francisco: Jossey-Bass.

Scotto, M. (1998). Project resource planning. In J. Pinto, Project management handbook, San Francisco: Jossey-Bass, 222-236.

Shenhar, A.J., & Dvir, D. (2004). How projects differ. In P. Morris & J. Pinto (Eds.), The Wiley Guide to Managing Projects. Hoboken, NJ: John Wiley & Sons, 1265-1286.

Slevin, D.P., & Pinto, J.K. (1986). The project implementation profile. Project Management Journal, 17(4), 57-70.

Turner, J.R., & Keegan, A. (1999). The versatile project-based organization: Governance and operational control, European Management Journal, 17(3), 296-309.

Van Grembergen, W., & De Haes, S. (2009). Enterprise governance of information technology: Achieving strategic alignment and value. New York: Springer.

Weill, P. & Ross, J.W. (2004). IT governance: How top performers manage IT decision rights for superior results. Boston: Harvard Business School Press.

Williamson, O.E. (1996). The mechanisms of governance. New York: Oxford University Press.

Willson, P., & Pollard, C. (2009). Exploring IT governance in theory and practice in a large multinational organization in Australia. Information Systems Management, 26(2), 98-109.

Yourdon, E. (1997). Death march: The complete software developer's guide to surviving “mission impossible” projects. Upper Saddle River, NJ: Prentice Hall PTR.

 

1 The structure characteristics represented in this table were drawn from a wide range of literature including: Addison & Vallabh (2002), Avison & Fitzgerald (2003), Boehm (1991), Constantine (1993), Davis & Lawrence (1978), Engwall & Jerbrant (2003), Galbraith (1971), Hobday (2000), Keil et al. (1998), Larson & Gobeli (1987), Mintzberg (1981, 1991), Peters (1993), Peters & Waterman (1982), Sauer & Yetton (1997), Scotto (1998), Slevin & Pinto (1986), Turner & Keegan (1999) and Yourdon (1997).

2 In this context, novation transfers the obligation of the vendor to the agency in each supplier (sub)contract.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010 Project Management Institute

Advertisement

Advertisement

Related Content

  • PM Network

    Rookie Revelations member content locked

    PM Network asks the project management community to share their mistakes made at the beginning of their careers.

  • PM Network

    Interior Motives member content locked

    By Wenger, Fred Project managers are accustomed to looking outside their projects for risks—at competitors, clients, suppliers, the economy, even the weather. But experience has taught me that all projects face a…

  • PM Network

    New Digs member content locked

    By Waity, C. J. Ore deposits are hardly the only factor project leaders use to determine future mining sites in Latin America. Everything from geopolitical turmoil to local labor markets can impact a mining…

  • PM Network

    Past Is Prologue member content locked

    By Hendershot, Steve Organizations can't escape the past when they pump money into tech upgrades. Before they start rolling out cool new tech, project teams need to identify and mitigate the risk of putting fancy new…

  • PM Network

    Bank Breach member content locked

    Dankse Bank A/S came under scrutiny for failing to prevent suspected money laundering at its Estonian branch, and a shelved IT project may be to blame.

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.