Assessing Project Success Moving Beyond the Triple Constraint 2010

Association for Information Systems

AIS Electronic Library (AISeL)

International Research Workshop on IT Project        International Research Workshop on IT Project

Management 2010        Management        (IRWITPM)

1-1-2010

Assessing Project Success: Moving Beyond the Triple Constraint

Michael Cuellar

North Carolina Central University

Recommended Citation

Cuellar, Michael, "Assessing Project Success: Moving Beyond the Triple Constraint" (2010). International Research Workshop on IT

Project Management 2010. Paper 13.

http://aisel.aisnet.org/irwitpm2010/13

This material is brought to you by the International Research Workshop on IT Project Management (IRWITPM) at AIS Electronic Library (AISeL). It has been accepted for inclusion in International Research Workshop on IT Project Management 2010 by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact [e-mail].

---

Assessing Project Success: Moving Beyond the Triple

Constraint

Michael J. Cuellar

North Carolina Central University
mcuellar@nccu. edu

ABSTRACT

This paper reviews the literature on IS project success evaluation and finds that the concept of success as currently used in both academia and practice based on the notion of the “triple constraint” - project scope, budget and schedule. This notion of success, derived from engineering, implicitly separates the project to develop the IT artifact from its implementation in the work system it is intended to serve. Additionally, it leads to relativism and lack of direction for project managers. Following Alter (2003), this paper proposes a new conception of project success based on the performance of the IT enabled work system. This conception is shown to be objective, transparent to non-IT managers and to provide direction to project managers in handling changes to projects.

Keywords

Project Success, Work Systems, Triple Constraint INTRODUCTION

How do we know when a IS project is a success? Clearly one that fails to deliver a working IT artifact is a failure. But what of one that delivers an artifact that is not used? Or one that is used, but doesn’t deliver the benefits anticipated? Or what of one that delivers the benefits anticipated but runs over its budget or schedule? How far must the overrun occur for the project to be considered a failure? The 2006 Standish study reported that 46% of projects either had cost or time overruns or didn’t fully meet the user’s needs (Rubenstein 2007). Similarly, Keil and Mann found that 30 to 40% of project experienced some level of project escalation (Keil and Mann 1997). Are all these projects failures? Are they simply “challenged” as Standish suggests? (Rubenstein 2007)

The current conceptualization of project success as taught to our students is that a project must meet the “triple constraint” of scope, budget and schedule in order to be considered a success. If we set these at the beginning, and establish the stakeholder priorities as to which of these should be maintained, then we have the basis of knowing how to trade-off one priority against another. In so doing, we run into the conflicts in priorities between stakeholders and the need to manage stakeholder expectations and negotiate trade-offs between stakeholders. Then as the environment changes and events occur and we go enact changes in the project in terms of increasing the budget or schedule or decrease the scope we run into the morass of managing the stakeholders again. And in the end a project is completed and depending on the stakeholder, it is consider a success, failure or most commonly a disappointment.

To avoid this conundrum and attempt to provide a way forward, this paper will examine the current conception of IS project success and look at the issues arising from such conceptions. It will then propose a new conceptualization of IS project success that provides a more objective approach to the assessment of IS project performance. The contribution of this paper is to provide a reconceptualization of project success based on the Alter’s Work System model that is objective, transparent to non-IT managers and provides direction to project managers in handling changes to projects.

THE TRADITIONAL VIEW: THE TRIPLE CONSTRAINT

The PM textbooks tell us that project success is composed of meeting the functional requirements of the project on- time, and on-budget. For example, some of the leading textbooks tell us:

To create a successful project, a project manager must consider scope time and cost and balance these three often-competing goals. (Schwalbe 2007, p. 8)

---

Every project is constrained by a list of customer-requested requirements (scope), the amount of time available to produce the system in support to the requirements (time), and the limit of the money available (cost). This is referred to as the triple constraint of project management.

These three basic criteria are generally used to evaluate the success of a project. (Brewer and Dittman 2010, p. 14)

The most commonly recognized project metrics are time, cost and performance. In combination, they form a set ofpotentially competing project priorities known as the triple constraint. ... [The]

[tjriple constraint definitions ... form a successful program. (Brown and Hyer 2010,p. 9)

Successful project management can ... be defined as having achieved the project objectives:

Within time Within cost

At the desiredperformance/technology level

While utilizing the assigned resources effectively and efficiently

Accepted by the customer (Kerzner 2009,p. 3)

Quality and the ultimate success of a project is traditionally defined as meeting and/or exceeding the expectations of the customer and/or upper management in terms of cost (budget), time (schedule), and performance (scope) of the project. (Larson and Gray 2011, p. 106)

From these definitions, we can see that the received wisdom taught to our students is to be able to hit each of the components of the “triple constraint”: on time, on budget and with agreed upon functionality. Each of these components, the textbooks tell us is to be taken relatively equally with the others and balanced against them. For example: