INTERNATIONAL JOURNAL OF

PROJECT MANAGEMENT
International Journal of Project Management 23 (2005) 428436 www.elsevier.com/locate/ijproman

Developing a value-centred proposal for assessing project success

Angus G. Yu *, Peter D. Flett, John A. Bowers *
Department of Management and Organization, University of Stirling, Stirling FK9 4LA, Scotland, UK Received 2 July 2004; received in revised form 27 August 2004; accepted 25 January 2005

Abstract This conceptual paper proposes a value-centred approach to measuring project success. The paper adopts a product-based project denition and a corresponding project lifecycle model. After reviewing briey the literature, the paper denes the concepts of the net project execution cost (NPEC) and the net product operation value (NPOV). Twelve possible project outcomes are outlined based on values of NPEC and NPOV at project completion compared with their initial estimates. The proposed scheme potentially enables project stakeholders to reach the same project success or failure verdict. It also addresses many issues hitherto encountered in the quest for project success criteria. 2005 Elsevier Ltd and IPMA. All rights reserved.
Keywords: Value and benet; Cost; Time; Quality; Project success criteria; Project conception; Project execution; Product operation

1. Introduction A conceptually coherent set of project success criteria can potentially help project participants to channel their eorts to achieving successful projects. It may also facilitate project post mortem analysis and help addressing a series of other issues in project management. The quest for project success criteria has resulted in many publications (e.g. [110]). However, it has been dicult to reach a consensus [11]. This conceptual paper provides a brief review of the current approaches and proposes a product-oriented and value-centred scheme for assessing project success. The paper starts by examining two concepts closely related to success criteria. One is the denition of the term project. It is suggested that dierent project denitions might warrant dierent success criteria. The other concept is the project lifecycle, with which the related concepts of project management and product operation can be clearly envisaged.
*

By reviewing the literature, this paper identies two approaches addressing the inadequacies of the traditional criteria of cost, time and quality. The value-centred approach is adopted in this paper. To implement this approach, the paper denes two key concepts: the net project execution cost (NPEC) and the net product operation value (NPOV). Twelve possible project outcomes are outlined based on values of NPEC and NPOV at project completion compared with their initial estimates. A number of traditional issues are then discussed in light of the proposed scheme. Throughout the paper, a number of published project cases are cited in aid of the discussions. However, due to space constraint, full-scale case studies based on the proposed approach are not included and are left for further studies.

2. Project and product When considering project success criteria, it is essential to be clear of what a project is. There are two common approaches to dening a project [12]. One is the product-oriented denition, exemplied by PMI [13]:

Corresponding authors. Tel.: +44-1786-467323. E-mail address: agy1@stir.ac.uk (A.G. Yu).

0263-7863/$30.00 2005 Elsevier Ltd and IPMA. All rights reserved. doi:10.1016/j.ijproman.2005.01.008

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

429

A project is a temporary endeavor undertaken to create a unique product or service (p. 4). The other approach is objective-oriented, such as the one proposed by Turner and Muller to deliver bene cial objectives of change [14]. Both approaches emphasize a projects temporariness and uniqueness. The dierence lies in the description of the project outputs, one being the creation of a unique product or service and the other benecial objectives of change. Turner and Mullers denition is broader than that of the PMIs, since the outcome of a project could include the creation of a product in order to achieve certain benecial changes [15]. Turner and Mullers denition may also in clude research projects that may be excluded from the PMI denition since they often aim to increase human understandings rather than to create products and services. A detailed critique of the two denitions is beyond the scope of this paper. Suce it to say that dierent ways of dening projects emphasise dierent objectives and thus may warrant dierent approaches to dening their success criteria. This paper adopts the PMI denition due to its output focus. The term product is used to refer to both product and service in the rest of the paper. A product usually embodies the project value that may accrue to the project client. Here the client refers to the individual or the organisation that initiates and invests in the project. In contrast, an end user is someone who uses the product. The PMI denition leads to a productbased project lifecycle that is helpful in examining how a client may benet from a project. The concept of project lifecycle is described briey below for the purpose of this paper.

For the purpose of discussing success criteria, two further important aspects are highlighted here. The rst is the ownership for each stage. For Stage 2 (project execution), a client hires a project team and delegate project management responsibilities. At the same time, the client and the project team forms a principalagent relation [17] which results in the problem of information asymmetry, preventing the client from being be fully involved. As shown in Table 1, the project team might be considered to own Stage 2 while the client owns Stages 1 and 3 directly. It is perhaps in this sense that Stage 2 has been referred to as the project in the micro sense [18]. The ownership therefore changes between the client and the project team from one stage to the next. The ownership changes are associated with project milestones or gates in between project stages [16]. As shown in Table 1, each milestone is marked by actions performed by the owner of the previous stage. Thus at Milestone 1 after project conception (Stage 1), the client commits to the project and appoints a project team. The immediate ownership for the next stage is passed on to the project team, though the client theoretically retains the ultimate control. At Milestone 2 after project execution (Stage 2), the project team delivers the created product to the client. Though the project is completed, the product lifecycle typically continues. The client has the ownership to operate or dispose of the product as it wishes. In this context, disposal may mean selling or scrapping the product in contrast to operating it. To examine project success criteria, it is necessary to consider all three stages.

4. Project success criteria: A brief review 3. Project lifecycle and product operation The lifecycle for a product-based project can be divided into three stages separated by two milestones (Table 1, mainly based on Wideman [16]). Examining the lifecycle reveals that:  The product is conceived together with the project (Project Conception/Product Feasibility).  The product survives the project (Product Operation after Project Closure).
Table 1 Project/Product lifecycle stages and milestones Project lifecycle Stage 1 Project conception Milestone 1 Project commitment Stage 2 Project execution Milestone 2 Project closure Stage 3 N/A Product lifecycle Product feasibility High level product requirement produced Design, development or acquisition Product created Product operation Owner/Actions The The The The The client organisation, assisted by specialists client commits to the project and appoints a project team project team (the prime contractor assisted by subcontractors) project team delivers the created product to the client client organisation, possibly transferred to a customer/user

The basic criteria of cost, time and quality, the socalled Iron Triangle or Golden Triangle, have been traditionally used as project success criteria. However, these criteria have been criticised for being inadequate for many reasons (e.g. [38,10]). Over the years, various attempts have been made in overcoming the perceived inadequacies. These attempts may be grouped into two dierent approaches: one is to add more dimensions to the basic criteria while the other to abstract to fewer dimensions.

430

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

Chan and Chan [19] focus on the rst approach. Having reviewed the literature since the early 1990s, Chan and Chan conclude that time, cost and quality forms the basic criteria to project success in almost every article on the subject. They produce a consolidated framework including additional dimensions of user expectation, participants satisfaction, environmental performance, health and safety, and commercial value. This approach is exemplied by Morris and Hough [1], Hamilton [20], Shenhar et al. [6,7] and Atkinson [8]. Due to the multi-dimensional nature, this approach believes that project success should be viewed from different perspectives of the individual owner, developer, contractor, user, and the general public and so on [18,19]. However fair it may be, this approach is dicult to implement [21] and may lead to dierent verdicts on project success depending on the perspective taken. In contrast, the second approach reduces the dimensions considered for project success. This approach regards the traditional criteria of cost, time and quality as both excessive and incomplete. The excessiveness is due to the inclusion of time, which is merely a variable in the project cost function. In other words, for a given quality, there exists a relationship between cost and time [22]. As a result, time is not an independent variable and should not be used as such to measure project success. The incompleteness of the traditional criteria becomes obvious if we ask quality of what. Quality does not stand on its own. Quality is a collection of concomitant characteristics of something. When that something is not specied, quality might refer to project inputs or activities. Relevant as they might be to the management of a project, project success criteria should be primarily concerned with project outputs [23], or the product in the project denition adopted above. It is the product in its totality, not just the quality of the product that should be used for assessing project success. The product may have functions and features, each of which has quality dimensions like reliability and performance, etc. In other words, quality is merely one aspect of the product. The success or failure of a project might be equated to that of the intended product. Product success is much emphasized by de Wit [2] and Baccarini [9]. The focus on product success leads to the concept of product value, which can be compared with cost. Maude and Willis [24] propose what might be considered a pure value-based approach in the context of software development projects: Software development projects can be said to fail if, for whatever reason, it would have been more economic not to have run the project at all (p. 15). Taking a product-oriented view, the above denition might be paraphrased as:

A project is a failure if it would have been more economic not to create the intended product. Alternatively, a project is a success if its created product adds value to the client, considering the cost to the client at the point of acceptance. Since cost and value might be perceived to lie on the same cost-value axis, the value-centred approach might be referred to as single-dimensional. This approach is adopted by Freeman and Beale [25] when they advocate the use of the net present value (NPV) for measuring project success. Freeman and Beale successfully demonstrate that time is a variable in the project cost function. They also show that project success depends on both project management and product operation. The NPV approach is also adopted by Gardiner and Stewart [10]. They recommend the success criteria to be changed from time, cost and quality to the best achievable NPV and to the required quality. As discussed earlier, it is not necessary to list quality separately since it is only one aspect of the product, the value of which is being measured already. However, there are a number of issues with the singledimensional, value-centred success criteria as has been proposed so far. First of all, the term value is dened rather narrowly. The traditional concept of NPV focuses on cash ows in the accounting sense. As a result, Freeman and Beale [25] concede that, in some cases, it might be very dicult to measure projects with cash equivalents. The second issue is that the concepts of project and product are not always clearly separated. Therefore, project value is often discussed in vague terms without taking into account of product value that may accrue to the client long after project completion. A related issue is the calculation of a single NPV incorporating the cost incurred in projects and value derived from product operation. Since project cost and product value are accounted for in stages with dierent owners (Table 1), they should be separated for consideration. Nevertheless, the approach with fewer dimensions is supported by empirical research. Baker et al. [26] suggest that client satisfaction is important while time and cost are less so. Lipovetsky et al. [27] conclude that some dimensions of success are more important while others are negligible. Odusami [28] concludes a survey by stating that [c]ontrary to expectation, construction cost and time are not regarded as highly important. This paper builds on the single-dimensional, value-centred approach. Before proposing the scheme, two key concepts are dened. 5. The net project execution cost and the net product operation value In line with the project denition and the project lifecycle adopted earlier, a typical project may be regarded

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

431

as an investment. As such, the project consumes resources throughout project execution (Stage 2). Though some benets may materialise during Stage 2, it usually takes a stage of product operation (Stage 3) before full benets are realised. Since a project manager is typically responsible for project execution only, it is useful to separate project cost and product value to reect the project/product lifecycle reality. The NPEC is dened as the net of all the costs borne by the client minus all the benets accrued to the client during project execution. If Cproject denotes all project costs and Bproject denotes all benets realised in the project execution, we have NPEC C project Bproject . 1

The concept of NPEC is broader than the traditional concept of project cost. A project consumes resources, and therefore incurs project cost in the accounting sense. At the same time, the project may preclude other projects to be undertaken and is therefore associated with opportunity cost. In addition, NPEC accounts for any benet the project might bring to the client during project execution. For example, in the course of a big dam project, partial generation of power may generate cash revenue prior to the end of the project. Therefore, NPEC takes into account of the project opportunity cost, and any project revenue as well as the project cost in the traditional sense in project execution. The NPOV is dened to capture all the benets a client derives from the created product during product operation (denoted as Boperation) minus any associated operational cost (Coperation). In other words: NPOV Boperation C operation . 2 NPOV is a function of the products functional and quality characteristics, including the products aesthetics. It is also inuenced by the products operating environment. NPOV is dierent from NPV in at least two ways. First of all, NPOV is more broadly dened in that it is not limited to cashows in the accounting sense. NPOV may include less tangible benets (strategic benets, competitive advantages, positive externalities, etc.) and less tangible costs (e.g. negative externalities). Secondly, the NPV for measuring project success has been calculated by including all discounted cash inows and outows throughout project execution and product operation [10,25]. In contrast, NPOV is limited to product operation only. The separation of project execution and product operation is important in providing a meaningful measurement of the project in the micro sense [18]. Though NPEC and NPOV are dened dierently from NPV, all three are seen from the clients viewpoint. In addition, analogous to the concept of NPV, NPEC and NPOV may be discounted to a particular

point in time for the purpose of comparison. Theoretically, NPEC and NPOV exist for every project and its associated product from the clients viewpoint. Their measurements may or may not be easy, particularly for NPOV. In some special cases value measurement may be straightforward. For example, when a product is sold by the client to another party at the end of a project, the product value is eectively the selling price in the market. If the price is at or is higher than the NPEC, the project is a success. In this case, NPOV has a quantitative value. Another situation is when the client is able to evaluate a product and decides to take it or not. The black-box product development in the Japanese auto industry provides such an example [29]. The client tests two products and one is rejected. It is reasonable to conclude that the accepted product provides higher NPOV than the rejected one in the clients viewpoint. Here the NPOV is established relatively. Often, however, the measurement of NPOV, or even its estimate can be dicult [30,31]. Such diculties have been discussed in the considerable body of the cost-benet analysis (CBA) literature (e.g. [31]). Further research should be carried out to develop NPEC and NPOV functions for dierent types of projects, products and clients.

6. Measuring project success Based on the concepts of NPEC and NPOV, this section demonstrates how project success might be assessed. The narrative below proceeds with reference to the three project stages and two milestones in Table 1. 6.1. Stage 1: Project conception and product feasibility This is a stage during which a client decides whether to pursue a particular project or not. For product-based projects, decisions are usually based on product feasibility studies (Table 1). Often, such a feasibility study takes the form of a cost and benet analysis. The objective for the client is to assess NPEC and NPOV as dened above. Since the project has not been initiated yet, the client only has estimated NPEC and NPOV at this stage. 6.2. Milestone 1: The client commits to the project Let C0 be the estimated NPEC for the project and V0 be the estimated NPOV for the intended product. The client commits to a project if C0 < V 0. Theoretically, the client would be ambivalent in committing to the project or not if the above two items equal. If C0 > V0, the client would not start the project.

432

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436 Table 2 Project outcome scenarios based on comparing C0, V0, CT and VT Scenarios C0 and V0 at Milestone Comments 1 compared with CT and VT at Milestone 2 1 CT 6 C0 < V0 6 VT Total success:  Cost within budget  Expected NPOV met or exceeded  Positive project value Qualied success:  Cost over budget  Expected NPOV met or exceeded  Positive project value Qualied success:  Cost far over budget  Expected NPOV exceeded  Positive project value Total failure:  Cost far over budget  Expected NPOV met or exceeded  Negative project value Qualied success:  Cost within budget  Expected NPOV not realised  Positive project value Qualied success:  Cost over budget  Expected NPOV not realised  Positive project value Total failure:  Cost over budget  Expected NPOV not realised  Negative project value Total failure:  Cost far over budget  Expected NPOV not realised  Negative project value Qualied success:  Cost within budget  Expected NPOV not realised  Positive project value Controlled failure:  Cost within budget  Expected NPOV not realised  Negative project value Total failure:  Cost over budget  Expected NPOV not realised  Negative project value Total failure:  Cost far over budget  Expected NPOV not realised  Negative project value

It is important to bear in mind that both C0 and V0 are estimated based on available information at this point of time. In real world projects, clients do not have perfect information, or they may be under pressure to mis-represent either or both items [32]. These are issues to be dealt with in assessing specic projects. 6.3. Stage 2: Project execution and product development This stage is the project in the micro sense [18]. A project team is appointed with outlined deliverables and with cost and time targets more or less decided. The focus of the project team is on developing and delivering a product within the cost and time constraints. 6.4. Milestone 2: The project team delivers the product to the client This milestone is an abstraction of what might happen in real world projects over a period of time. It eectively symbolises the end of the project and the start of the product operation. Prior to this milestone, the project team designs and develops the product. After that, the client derives value from the product. Provided that the cost information has been properly accounted for, the client knows the project expenditure as historical information at this point. Thus the client has more reliable information for forming a view on NPEC, though less tangible costs may be dicult to measure [30]. As for NPOV, the client has a better estimate at the time of project completion due to the availability of the actual product. Environmental uncertainties, if any, are also reduced for product operation compared with the time of Milestone 1. However, the client is still not certain of NPOV. This is because, analogous to NPV, NPOV is a discounted sum of future benets and costs, which cannot be predicted with certainty. Nevertheless, with the available information of the initial estimated NPEC (C0) and NPOV (V0), the more informed NPEC at the project completion time T (CT), and the revised NPOV estimate at time T (VT), it is possible for the client to assess project success or failure. The client makes three-way comparisons for assessing project success:  comparing CT with C0, and  comparing VT with V0, and  comparing VT with CT. The comparisons are made based on the assumption that C0 < V0. Twelve possible outcomes are shown in Table 2. The scenarios have been grouped into four types:  Total success (Scenario 1).  Qualied success (Scenarios 2, 3, 5, 6 and 9).

C0 < CT < V0 6 VT

C0 < V0 < CT < VT

C0 < V0 6 VT < CT

CT 6 C0 < VT < V0

C0 < CT < VT < V0

C0 < VT < CT < V0

C0 < VT < V0 < CT

CT < VT < C0 < V0

10

VT < CT 6 C0 < V0

11

VT < C0 < CT < V0

12

VT < C0 < V0 < CT

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

433

 Controlled failure (Scenario 10).  Total failure (Scenarios 4, 7, 8, 11 and 12). The exact mapping from the 12 scenarios to the above four types might be debatable. Broadly speaking, this paper adopts the following convention:  A scenario is a success if VT P CT. Such a project produces positive value for the client.  A scenario is a qualied success if VT P CT and CT > C0. Though the project produces positive value, the initial budget is exceeded.  In contrast, a scenario is a total success if VT P CT and CT 6 C0. This is the ideal scenario for the client.  A scenario is a failure if VT < CT. Such a project produces negative value for the client. In other words, the client would be better o without having run the project.  A scenario is a controlled failure if VT < CT and CT 6 C0. In this case, though the project produces negative value, the budget is eectively controlled.  A scenario is a total failure if VT < CT and CT > C0. This is the worst scenario since the project produces negative value with the initial budget exceeded at the same time.

 Can project participants ever agree on project success?  What about the satisfaction of stakeholders other than the client?  When should a project be assessed for success?  Who is responsible for a project/product failure?  What success/failure tolerance level is appropriate?  Can good project management prevent project failure?  Should a project meet the client requirements or client expectation?

7.1. Can project participants ever agree on project success? One problem with the multi-dimensional project success criteria is that it is dicult for project participants to agree a success verdict [21]. The use of the single cost-value dimension for the purpose avoids the problem. Both NPEC and NPOV are seen from the clients viewpoint. If NPEC and NPOV (or their estimates) can be agreed among project participants for a particular project, it is possible to have a single project success or failure verdict. Such an aligned view of project success can help project participants to make concerted efforts in projects. 7.2. What about satisfaction of stakeholders other than the client? It is questionable that If a project is to be perceived as successful, then its stakeholders must be satised [33]. Consider the Sydney Opera House as an example. The original architect could be rightly considered as a stakeholder in that project. He must have been rather dissatised for being excluded from the project before it had been completed [34]. However, that has not prevented the project from being considered as successful [7]. This paper suggests addressing the satisfaction of other stakeholders by separating value-sharing from value creation. A project brings value to the client through the product to be created. The primary concern of the project should be to create a product with the required value or more for the client given the limited resources. Other stakeholders are entitled to share part of that created value. There are many possible value-sharing mechanisms. Some take place within the scope of project management, such as paying a subcontractor for its services. Some value-sharing takes place outside the project, such as local residents enjoying the use of a new park or a new bridge. When the product value is not shared equitably, it may cause dissatisfaction to some stakeholders. Consider the case presented in Lim and Mohamed [18]. The project was completed later than scheduled and went over the initial budget. The nished

6.5. Stage 3: Product operation According to the project denition [13], the project stops at the above milestone. However, the client typically derives product value during product operation, which may continue long after the project (hundreds of years for some bridges and buildings). It is usually not possible for the client to be certain of the NPOV early in Stage 3. This is not only because the operational benets may be uncertain, the operational costs may not be fully predictable either. As time goes by, when product benets are realised (or not as the case may be) and operational costs are incurred, the client is better equipped to assess the true NPOV. By the end of product operation, the full NPOV is realised, though its exact measurement may still be open to discussions due to diculties in measuring costs and benets.

7. Discussions The proposed scheme for measuring project success is based on the simple concepts of NPEC and NPOV from the clients viewpoint. The scheme itself, however, is anything but simple. It can potentially address many conceptual diculties hitherto encountered in establishing project success criteria. This section considers the following issues:

434

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

product (a shopping complex), however, seemed to be a great success (very popular with both tenants and shoppers). The project was a qualied success, perhaps matching Scenario 2 in Table 2. However, it seemed that the NPOV had not been shared equitably from the contractors viewpoint, thus causing a legal dispute. One important point is that if there is no additional value created in a project (VT 6 CT), any prot obtained by subcontractors is eectively paid for by the clients cost. This causes dissatisfaction on the client side. The so-called incentive mechanisms in contract management aim to address such situations. It warrants further research into how value-sharing mechanisms may be devised to address satisfaction levels of all project stakeholders, especially when NPOV is uncertain. 7.3. When should a project be assessed for success? It has long been recognised that the project completion point may not be the right time for measuring project success (e.g. [35]). So when is the right time? To address this question, two issues are considered here: quality of information available and the linkage between project management in the micro sense [18] and the project success/failure verdict. Theoretically, at any time t from Milestone 1 to the end of Stage 3 (Table 1), the client has information on C0, V0, Ct, Vt, denoting the initial estimated NPEC, the initial estimated NPOV, the NPEC and NPOV as seen at time t respectively. At Milestone 1, Ct = C0. As the project progresses towards project completion time T (Milestone 2), Ct may diverge from C0 and gets closer to CT. Likewise, Vt = V0 at Milestone 1. As the project progresses towards project completion time T, Vt may diverge from V0 but remains as an estimate, albeit a better estimate than V0. The project can be assessed for its success or failure at any moment t with C0, V0, Ct, Vt according to Table 2, replacing CT, VT with Ct, Vt. What has to be noted is that before project completion, the earlier the assessment, the more it is based on estimated Ct and Vt. After project completion, the later the assessment, the more it is based on historical information for estimating Vt. In other words, the later the assessment is throughout the project/product lifecycle, the better the information is available. In this sense, a project would be best assessed at the end of product operation. However, the need for assessing project success often arises due to the need to appraise project teams and subcontractors. In addition, once product operation begins, Vt is inuenced not only by project conception and project execution, but also by product operation. It is dicult to establish the precise cause and eect link between any of these stages and Vt. Consider the Concorde Project as an example. The product value for the clients (the British and French governments) depended heavily on

the operating environments and the marketing eorts at the operation stage [1]. Balancing the two issues above, the best time for assessing project success in the micro sense [18] may be the time of project completion after all. This is the time when a completed product is available for value assessment without being inuenced by product operation. Of course, the verdict may be open to on-going revisions as information becomes available through product operation. 7.4. Who is responsible for a project/product failure? When a project fails, the question of who is responsible may have to be answered. As discussed previously, the earlier the assessment, the more it is based on estimates, and therefore the less certain the verdict is. On the other hand, the later the assessment, the more contributing factors and the less certain who contributes to the project failure. Thus the question of who is responsible may not be answered for certain. 7.5. What success/failure tolerance level is appropriate? In applying the traditional success/failure criteria, an issue is often encountered that a client may be quite happy to see a level of budget overrun without feeling that the project is a failure [1,18]. A classication of failure for such projects may contradict with the clients perception. To cater for this diculty, a tolerance level is sometimes suggested. For example, Capers Jones classied as best in class projects those that show cost over-runs are less than 5% and schedule over-runs are less than 3% [36]. However, a clients tolerance for cost and schedule overruns may be much higher in some cases. Why should this be the case? One possible explanation is that the project output might be perceived to provide much higher value than the project cost, so much so that 100% or 200% cost overruns are still tolerated. The Sydney Opera House Project provides a good example. While the project cost exceeded the initial estimate by ten times, the project is still considered as a success [7,34]. The value-centred approach suggests that the cost/ schedule tolerance setting in general is not meaningful. No consensus on the level of tolerance is realistic since each client has his own value functions. The bigger the gap is between C0 and V0, the higher the likely tolerance level. 7.6. Can good project management prevent project failure? This relates to the issue of cause and eect between project stages and project/product results. More precisely, the above question might be addressed in view of the proposed success criteria. Consider a project with

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436

435

its business case stating that C0 < V0. If, however, these values are mis-represented in such a way that the true cost should have been estimated as C 00 , which is greater than the true product value V 00 , it would be dicult even for good project management to achieve CT < VT during project execution. If the project does end up with CT > VT, the root cause is more likely to be project conception, not project execution, provided that other factors remain as predicted. This hypothetical scenario illustrates that good project management may or may not prevent project failure depending on project conception, among other things. 7.7. Should a project meet the client requirements or client expectation? A common question in considering project success or failure is whether a project team should aim to meet a clients initial requirements or the clients value expectation. The two goals are of course not necessarily contradictory to each other. Theoretically, the client expects that the project can create a product with VT > V0 simply by following the requirements specication. However, there are a number of scenarios when it is not possible to meet both. First of all, a rapidly changing environment may render the initial requirements inadequate. In other words, by following the requirements specication a project team may deliver a product with VT < V0. Project Trawlerman seems to t into this scenario [37]. In such a project, eective change management is essential for the project to meet the clients value expectation. However, requirements changes tend to be associated with project cost increases. While such changes may be necessary in ensuring VT > V0, a client is unlikely to be satised if the project cost is increased to such an extent that CT > VT. Another scenario is that a project team may attempt to manage the client expectation. While this may be legitimate, it often involves the reduction of the clients value expectation in order to contain the project cost. If, however, VT is reduced to such an extent that VT < CT, the project becomes a failure even if the original cost target is met. In all cases, when the requirements specication and value expectation cannot be both met, the client has to assess carefully the cost and value impact of any change in requirements and value expectation.

 Suggesting that project success criteria be linked to project denitions.  Proposing that project success criteria be examined within the broader context of project/product lifecycle.  Adopting the single cost-value dimension for assessing project success.  Dening the concepts of the NPEC and the NPOV.  Outlining a scheme for measuring project success based on NPEC and NPOV.  Suggesting the separation of value-sharing from value creation to address the satisfaction of project stakeholders.  Contributing to a number of discussion topics based on the proposed scheme. There are a number of future research implications. First of all, detailed studies can be carried out to examine ways to measure NPEC and NPOV for dierent types of projects, products and clients, both conceptually and empirically. This should be done bearing in mind that many relevant publications exist already in the cost-benet analysis (CBA) literature. Secondly, following the suggested separation of value-sharing from value creation, the issue of project stakeholder satisfaction may be addressed by further examining the value-sharing mechanisms within and without project management. Thirdly, the conceptual framework proposed here might be applied to the study of project abandonment decisions. In addition, since this paper focuses on product-based projects, it might be worthwhile to examine if the value-centred approach can be applied to the broader, objective-based projects in general.

References
[1] Morris PWG, Hough GH. The anatomy of major projects. Chichester, UK: Wiley; 1987. [2] de Wit A. Measurement of project success. International Journal of Project Management 1988;6(3):16470. [3] Pinto JK, Slevin DP. Project success: denitions and measurement techniques. Project Management Journal 1988;19(1):6771. [4] Wateridge J. IT projects: a basis for success. International Journal of Project Management 1995;13(3):16972. [5] Wateridge J. How can IS/IT projects be measured for success. International Journal of Project Management 1998;16(1):5963. [6] Shenhar AJ, Levy O, Dvir D. Mapping the dimensions of project success. Project Management Journal 1997;28(2):513. [7] Shenhar AJ, Dvir D, Levi O, Maltz AC. Project success: a multidimensional strategic concept. Long-Range Planning 2001;34:699725. [8] Atkinson R. Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management 1999;17(6):33742. [9] Baccarini D. The logical framework method for dening project success. Project Management Journal 1999;30(4):2532.

8. Conclusion and future research The subject of measuring project success has attracted many publications without a consensus to date. This conceptual paper addresses the topic by restricting the discussions to product-based projects and makes the following contributions:

436

A.G. Yu et al. / International Journal of Project Management 23 (2005) 428436 [23] Morris PWG. The validity of knowledge in project management and the challenge of learning and competency development. Accessed on 02-Jun-2004 at: www.bartlett.ucl.ac.uk/research/ management/Validityofknowledge.pdf. [24] Maude T, Willis G. Rapid prototyping: the management of software risk. London: Pitman; 1991. [25] Freeman M, Beale P. Measuring project success. Project Management Journal 1992;23(1):817. [26] Baker BN, Murphy DC, Fisher D. Factors aecting project success. In: Cleland DI, King WR, editors. Project management handbook. New York: Van Nostrand Reinhold; 1988. p. 90219. [27] Lipovetsky S, Tishler A, Dvir D, Shenhar A. The relative importance of defense projects success dimensions. R&D Management 1997;27(2). [28] Odusami KT. Criteria for measuring project performance by construction professionals in the Nigerian construction industry. Journal of Financial Management of Property and Construction 2003;8(1). [29] Clark KB, Fujimoto T. Product development performance: strategy, organization and management in the world auto industry. Boston: Harvard Business School Press; 1991. [30] Bannister F, McCabe P, Remenyi D. How much did we really pay for that? The awkward problem of information technology costs. Electronic Journal of Information Systems Evaluation 2002;5(1). [31] Brent RJ. Applied cost-benet analysis. Cheltenham: Edward Elgar; 1996. [32] MacDonnell H. Civil servants hid true cost of Holyrood. The Scotsman, 19-Feb-2004. [33] Shenhar AJ, Wideman RM. Improving PM: linking success criteria to project type. Accessed on 02-Jun-2004 at: www.maxwideman.com/papers/improvingpm/improvingpm.pdf. [34] Yeomans J. The other Taj Mahal. Harlow: Longman; 1968. [35] Kharbanda OP, Pinto JK. What made Gertie Gallop? Lessons from project failures. New York: Van Nostrand Reinhold; 1996. [36] Vowler J. Swimming against the tide. Computer Weekly, 14-Jan1999. [37] Select Committee on Public Accounts. Eighteenth report, ministry of defence: appropriation accounts 199798. Accessed on 05-Oct2004 at: www.publications.parliament.uk/pa/cm199899/cmselect/ cmpubacc/289/28903.htm.

[10] Gardiner P, Stewart K. Revisiting the golden triangle of cost, time and quality: the role of NPV in project control, success and failure. International Journal of Project Management 2000;18(4):22596. [11] Crawford L. Proling the competent project manager. Project management research at the turn of the millennium. In Proceedings of PMI research conference 2000, 2124 June 2000, Paris, France. Project Management Institute, 2000, p. 315. [12] Williams T. Modelling Complex Projects. Chichester: Wiley; 2002. [13] PMI. A guide to the project management body of knowledge (PMBOK guide): excerpts. Project Management Institute. Accessed on 02-Jun-2004 at: www.pmi.org/prod/groups/public/ documents/info/PP_PMBOKGuide2000Exce rpts.pdf. [14] Turner JR, Muller R. On the nature of the project as a temporary organization. International Journal of Project Management 2003;21(1):18. [15] BS6079-1:2002. British standard 6079: guide to project management. British Standard Institute, UK, 2002. [16] Wideman M. The role of the project life cycle (life span) in project management. Accessed on 02-Jun-2004 at: www.maxwideman.com/papers/plc-models/plc-models.pdf. [17] Turner JR, Muller R. Communication and cooperation on projects between the project owner as principal and the project manager as agent. European Management Journal 2004;22(3):32736. [18] Lim CS, Mohamed MZ. Criteria of project success: an exploratory re-examination. International Journal of Project Management 1999;17(4):2438. [19] Chan APC. Key performance indicators for measuring construction success. Benchmarking: An International Journal 2004;11(2):20321. [20] Hamilton MR. Benchmarking project success. In ASC Proceedings of the 32nd Annual Conference, Texas A&M University, Texas, April 1820, 1996, p. 1116. [21] Bryde DJ. Project management concepts, methods and application. International Journal of Operations and Production Management 2003;23(7):77593. [22] Khosrowshahi F. The optimum project duration and cost curve for Hong Kong housing projects. Journal of Engineering Construction and Architectural Management 1997;4(4):24969.