Cost Engineering Vol. 45/No. 4 APRIL 2003 23

O n more than one occasion, therehave been cases where a projectfalls short of expectation in one

or more of the triple constraint items. Yet,the project team collectively and officiallypronounces the project a success. In otheroccasions, the team may consider theproject a success while the clientpronounces it a failure. The disparity ofjudgment as to the success or failure of aproject might even extend into the teamand the client personnel, i.e., thepronouncement of success or failure maynot be unanimous among client personnelor among the project team. Some of thepeople in this collective group may believethat the project was a success while othersmay believe that failure would be a betterdescriptor for the project.

To put the issue in perspective, whensomeone pronounces a project a success ora failure, the judgment is usually based onsome factual evidence, although noteveryone uses the same data. Even whenthe same data is used, not the same set ofevaluation indices is used by all parties inarriving at a basis of evaluation for thedegree of success of a project.

Another parameter, complicatingobservations of the degree of projectsuccess, is people issues. Sometimes, aproject can miss some or all of the tripleconstraints and still be pronounced asuccess because of the team’s positiveperformance in attending to people issues.

Conversely, there are times that the projectis on target with respect to the originalscope, cost, and schedule, and yet theclient pronounces it a failure because ofshortcomings of the team in dealing withpeople issues. The reason for theseseemingly odd pronouncements is thatpeople related issues subtly modify theinterpretation of quantitative indices ofproject performance. These people issuesinclude trust, team spirit, morale,responsiveness, punctuality, customerfocus, communications, teamwork, conflictresolution, trust, integrity, honesty,sociability, and flexibility.

Examples of failed, controversial, ormarginal projects are hard to find. Privateorganizations do not publicize suchprojects. By and large, the private sectorprojects that get publicized are those thatwere successful; at least in the opinion ofthe upper management of the company.On the other hand, examples of failed,controversial, or marginal projects that caneasily be found are public projects that arefunded by the US federal and localgovernments. Examples of these projectsare the Boston Southeast Expressway, theSpringfield Interchange in Virginia,Denver Airport, Sydney Opera House,Reagan Office Building, and the WoodrowWilson Bridge in Metropolitan DC area.There is an ongoing debate as to whether,or to what extent, any of these projects wassuccessful.

The perception of failure and successis usually based on unspoken and personalindices, which is why two different people,usually with two different sets ofexperiences and values, would assess thesuccess of the same project differently.There is a need for a set of performanceindices that formalize the process andmake explicit what is implicit in theseseemingly subjective evaluations. Theobjective is not to standardize the indices,nor their relative weight, but ratherformalize and highlight a uniform andlogical evaluation process. The purpose ofthis article is to introduce tools that wouldallow team members and client personnelto formalize the way they evaluate projects.The primary advantage of suchformalization is the consistency inevaluation procedures, and potentialproject-to-project transferability of theresulting values

Using the same set of factors duringthe entire project life cycle will provide abaseline for informed monitoring of theprogress in achieving all of the objectives ofthe project. This consistent andmethodical information will be invaluablein tracking the effectiveness of variousproject implementation processes, sincethe resulting historical data would providea foundation for continuous improvementin planning of future projects.

It is important to stress that this articleis not advocating a specific set of attributesand a specific set of rating values, but ratherthe methodology by which the attributesand their ratings are identified, formalized,and documented. The structuresidentified and described here should bemodified in concert with organizationalculture and priorities, and in the light ofshort-term and long-term projectmanagement goals of the organization.The assignment of weights and priorities tothe various elements of the structure canbe either based on the amount of time andeffort that would be necessary to fullymanage and deliver a specific element, orbased on the importance of that element.

Two Different Sets of AttributesThe points of reference of the client

are the features of the product, althoughsometimes the perspective might gettempered by behavioral and relationshipsissues of the project team. There is noquestion that the team is primarilyconcerned with the deliverable. But

TECHNICAL ARTICLE

Project Success Attributes

ABSTRACT: The perception of failure and success of projects is usually based on unspoken andpersonal indices. Therefore, it is not uncommon that two different people, usually with twodifferent sets of experiences and values, would assess the success of the same project differently.There is a need for a set of performance indices that formalize the process and make explicitwhat is implicit in these seemingly subjective evaluations. This article introduces tools thatwould allow team members and client personnel to formalize the way they evaluate projects.The primary advantage of such formalization is the consistency in evaluation procedures, andthe potential project-to-project transferability of the resulting values.

KEY WORDS: Benchmarking, deliverables, evaluation, and project management

Dr. Parviz F. Rad, PE CCE

Technical Articles - Each month, Cost Engineering journal publishes one or more technical articles.These articles go through a blind peer review evaluation prior to publication. Experts in the subject areajudge the technical accuracy of the articles. They advise the authors on the strengths and weaknesses of theirsubmissions and what changes can be made to improve the article.

PEER REVIEWED

24 Cost Engineering Vol. 45/No. 4 APRIL 2003

sometimes, in the process of planning andexecuting the project, the team getssidetracked by the activities and processesof the project, to the determent of thedeliverables. Finally, the team mightbecome so focused on the processes, andthe deliverables that these processesproduce, that the team as a whole mightoverlook the people issues involved ininterrelationships within the team amongthe team members, and with the client. Itis ironic that these relationships in turnwill affect the quality and magnitude ofthe deliverables, albeit in subtle andnondescript ways.

Given that the client and the teamgenerally view project success differently,a set of formalized, explicit, andquantifiable indices will allow the projectteam and client personnel get an insightinto how the other group views projects.Such indices will allow the team members

to develop a needed sensitivity to theclient’s preferences and priorities. Thisnew outlook is invaluable during theplanning, scope development,implementation, and changemanagement of the current project, as itwould be in planning of future projects.The relative importance of team factorsmay change during the life of the project,although the client indicators will be morestable. For instance, the importance ofrisk management, which is one of teamsuccess factors, will diminish as projectdraws to a close. However, the clientstrong focus on the triple constraints, andsecondary focus on people issues will stayunchanged throughout the life of theproject.

If the factors are selected on a project-by-project basis, it is entirely possible thatthey would be a reflection of the projectmanager’s preferences and the specific

constraints of the project. As such, theywill be specific to that manager and mightlose their value in terms of applicability toother projects, or if the project manger orthe team members are changedmidstream. In order to achieve asomewhat universal applicability, ageneralized project success evaluationmodel is needed. The objective in theselection of the structures and categoriesdescribed here is to achievecomprehensiveness of coverage andapplicability to any project in any industry.The advantage of this approach is theavailability of benchmarking data acrossmultiple projects, and in variousindustries.

Sometimes, particularly inorganizations that traditionally award cost-plus contracts, the client gets involved inplanning the project and in designing allof the activities that are necessary to

Figure 2—The Client View of Project Success Indicators (Continued)

Figure 1—The Client View of Project Success Indicators

Cost Engineering Vol. 45/No. 4 APRIL 2003 25

deliver the final product. Thedisadvantage of this transfer of focus is thatthe contractor and the project team tendto become focused on following theprocess prescribed by client rather thandelivering the final product.

The client’s success indicators aredesigned to determine whether or not aparticular feature exists in the finalproduct that was delivered to the client.Whereas, the team success factors tend tofocus on whether or not processes,procedures, and tools were in place inorder to facilitate the activities that wouldultimately result in the final product. Thepremise in developing two sets of indices isthat the viewpoints of client and the teamare fundamentally different. This articledescribes the development of two separatestructures, very similar to a WBS, tocharacterize the elements describing theclient and the team viewpoints.

Client ViewProject success attributes, as viewed

by the client, are derived from the limitedproduct characteristics and areas ofperformance that will facilitate successfulcompetitive positioning of theorganization. Success in this limitednumber of areas will signify success for theproject.

The client’s focus is primarily on thegoals and objective of the project, andspecifically on the scope and qualityaspects of the deliverables of the project.Of secondary importance are cost andschedule attributes of the project. Tosome extent, the client does not, and neednot, become concerned with all thoseactivities and procedures that wereimplemented in the process of fabricating,assembling, crafting, or creating thedeliverables of the project.

The project objectives can beassociated with the achievement of anidentifiable level of performance orcertain attributes of the deliverable. Theobjectives will include characteristicssuch as physical size, capacity, length,height, or strength. It may also involve theachievement of a certain level ofquantified reliability, the attainment of acritical speed, the establishment of aquantified level of system availability, theability to handle a given number oftransactions within a defined period of

Figure 3—The Client View of Project Success Indicators (Continued)

Figure 4—Project Management Maturity Level Descriptions

26 Cost Engineering Vol. 45/No. 4 APRIL 2003

time, or the ability to provide a certainlevel of quantified customer satisfaction.Other deliverables and objectives caninclude physical tolerances, softwaretolerance limits, physical speed, softwareprocessing speed, software processingaccuracy, indicators of surface texture,quantified robustness features, softwareerror frequency, quantified personnelskills, or quantified measures of userfriendliness of the software.

When the client commissions aproject, either for the use of the client, orfor the use of one of the stakeholders, theobjectives of the project and thecharacteristics of the deliverables are thebasis for measuring the degree of thesuccess of the project. This view of theobjectives and deliverable would be heldregardless of whether the project will beimplemented by an outside organizationthrough a contract, or by an internalorganization through a mandate orinterdepartmental agreements. Thus, thesuccess of the project is measured by thedegree to which the desired scope andquality were achieved and by the

satisfactory values of project duration andproject cost. These items lend themselvesto quantification and therefore the resultsand observations are highly quantitative.These indices might even be precise if theproject objectives were specified withclarity at the inception, and if the changesto the project environment were trackedand managed methodically throughoutthe life of the project. The parametersthat would influence the pronouncementof success for these attributes are theaccuracy of the original value, theacceptability of the final value, and theextent to which the variance is justified bychanges in project constraints and in theorganizational environment. Within thecontext of the tone of this article, theseitems deal with things, and as such can beindependent of people issues, althoughpeople issues influence the texture andmanner of the execution of these projecttasks. In some cases the client,consciously or sub-consciously, placessome importance on two categories of thepeople issues of the project: those dealingwith client satisfaction and those dealing

with team morale. The items that wouldinfluence the client’s perception of thesuccess of the project include the team’sresponsiveness, punctuality, demeanor,trust, adversarial, and communicationcharacteristics. To a lesser extent andmuch less frequently, enlightened clientsconsider the team morale during and afterthe project delivery as an element ofproject success, particularly if the projectis an internal project.

Using a WBS-like structure for thecharacterization and calculation ofsuccess indicators, as viewed by the client,the first level of this structure will have thefollowing elements: things issues andpeople issues, as seen in figure 1. Thingsissues will include scope, quality, cost, andschedule; these items will be judged onthe basis of accuracy, sophistication of theoriginal value, attractiveness, realism, andacceptability of the final value. Peopleissues will include client satisfaction, andteam morale. Elements of the third levelof this structure are shown in figure 3.The relative weight placed on each ofthese elements will be dependent on

Figure 5—Project Success Factors, Team View

Figure 6—Project Success Factors, Team View (Continued)

Cost Engineering Vol. 45/No. 4 APRIL 2003 27

organizational objectives, strategic goals,and corporate environments. However,figures 2 and 3 provide a firstapproximation of these values.Independent of how these attributes arecreated and ranked, best results can beachieved if the project is ranked by suchformalized process as frequently aspossible and throughout the life of theproject. Thus, variations in evaluationnumbers, which can stem from personalpreferences and different viewpoints, willbe placed in proper perspective. It is animportant point that if the purpose is tomake a cursory evaluation, evaluating thelevel two elements, as shown in figure 2might be sufficient. On the other hand, ifa detailed success evaluation is necessary,one might choose to evaluate the projectsuccess by quantifying the level threeelements, as shown in figure 3, or evenlevel four elements.

In the structures presented in thisarticle, the number of points assigned toeach element indicates the relativeimportance of the elements. The totalpossible number of points that arenormally assigned to the project will thenbe 500. The reason for this particulardistribution is to have a scale of 1-5 for thesuccess of the project, somewhat akin tothe project maturity ratings assigned toorganizations; a brief description of thelevels of maturity is shown in figure 4. Itis likely that if the majority of projects inan organization are ranked at three, thatparticular organization is at the maturitylevel three. Naturally, this assessment isby inference only, but it could serve as agood first approximation for theorganization maturity. On the other hand,

if the organization has achieved a level-three maturity, most although not all ofthe projects will achieve a rating of three.There might be a statistical inferencerelationship although not necessarily alinear deterministic relationship.

Team ViewProject success attributes, as viewed

by the team, are derived from the limitedproject management activity categoriesthat should receive constant and carefulattention from the project managementteam. In order for the project to beconsidered successful, all of the activitiesindicated by the team factors must bemanaged well regardless of the phase andregardless of the incremental changes toscope, schedule, and cost. However, thetime spent on these activities, and theimpact of that activity on the deliverables,might change during the project lifecycle.

The primary focus of the project teamis the final deliverable of the project. But,a competent project team would not onlyfocus on the deliverable, but also on all ofthe activities and processes that facilitateand assure the delivery of the desiredproduct. This delivery must also be in themost efficient and cost-effective manner.Sometimes, the team members get overlyconsumed in the prescribed process andplace the product at a secondary priorityposition. This is particularly true inorganizations where clients conduct a lotof micro project management or inorganizations that traditionally performcost-plus contracts.

Many of the skillful project managersintuitively determine their own successfactors. Since these factors are not

explicitly identified and recorded, they arenot part of the project managementreporting process, nor do they becomepart of the historical project data.Therefore, if these intuitive indicesbecome formalized, managerial intuitioncan become the logical basis and thestructural foundation for an explicit andformalized evaluation system to be usedby all projects and all managers in theorganization. Since all project managersare not equal in their skill in success factoridentification, a formalized factoridentification and implementation willcapitalize on the skills of these moreexperienced and innovative managers forthe good of the organization.

Once the success factors that areappropriate for the organization areidentified and validated, the foundationfor an informed project monitoringprocess can be established. Theavailability of these quantified factors willallow the project manager to work with anestablished archive of historical data inorder to keep all aspects of the projectwithin the standards of acceptability of theorganization. Such standards andprocedures will ultimately improve theprobability of the team’s success inachieving project goals.

The mission of the project team is toplan the delivery of the desired product,implement those plans in a dynamicenvironment, and manage all of thoseissues that influence the performance ofthe team in delivering the desired product.The first level of the evaluation structurefor the team-related success factors, asshown in figure 5, includes items relatedto things and items related to people. As

Figure 7—Project Success Factors, Team View (Continued)

28 Cost Engineering Vol. 45/No. 4 APRIL 2003

shown in figure 5, the second level thingsitems are scope, cost, quality, schedule,contract, risk, integration, and change.The first four of these elements are clearlythings oriented; the second four areprimarily things oriented but are partiallyinfluenced by people interactions,relationships, communications, etc. It is animportant point that client attributes aredirectly among team’s important values.However, these values are augmented byelements dealing with projectimplementation procedures, as shown infigure 6.

All things elements are distinguishedby the fact that their quantified status canvery easily and conveniently be determinedby charts, tables, and graphs. On the otherhand, measurement, quantification, anddisplay of success in people issues aremuch more subtle, illusive, and subjective.Nonetheless, people issues can haveprofound effect on the success of projects.Elements of the third level of this structureare shown on figure 8. The relative weightplaced on each of these elements will bedependent on organizational objectives,strategic goals, and corporateenvironments. However, weighting valuesincluded in figure 7, will provide a firstapproximation of these values. Third levelelements of the things issues, for cost,scope, quality, and schedule would addressthe sophistication, accuracy, and clarity of

the original value and the extent to whichvariances are justified. Sometimes theremay be a debate between the team and theclient as to whether or not a particularvariance is justified. It is such differencesof perception that would lead to differentdeterminations of success for the sameproject. Third level elements for contract,risk, integration, and change are shown infigure 8. Management of contract, risk,integration, and change primarily involvedocuments, charts, and technical facts, butit requires dealing with people from otherorganizations somewhat extensively.Therefore, managing these items has asmall people issues component attached toit. Additionally, these items tend to bemore global and all-encompassing, andtheir field of influence include scope, cost,schedule, and quality.

Level two people elements includemanaging the team issues, client issues,vendor issues, and communication efforts.Elements of the third level of this structureare shown in figure 8. The relative weightplaced on each of these elements will bedependent on organizational objectives,strategic goals, and corporateenvironments. However, weighting valuesincluded in figure 8 will provide a firstapproximation of these values.Independent of how the weighting valuesand the corresponding structure arecreated and ranked, consistency and

uniformity will be significantly enhanced ifthe evaluators have a formalized schema ofrecognizing the importance of these issues,and a methodical approach to measuringthe success of managing the peopleinvolved with the project. As in the case ofclient issues, the points assigned to theteam issues will add up to 500 points,somewhat in line with a rating of 1-5 as iscustomary for maturity assessment. As withthe client success indicators, if theorganization is assessed to be at level 4 ofmaturity, the average rating of theirprojects would probably be near 4.However, if several projects are rated atnear 4, it does not necessarily mean thatthe organization has achieved a maturitylevel of 4.

T he viewpoints of client and projectteam on the success of project arefundamentally different because

the former is focused on the deliverablesand the latter is focused on the means bywhich the deliverables are created. Thisarticle has presented evaluation principlesand foundations that highlight andrecognize this difference. Also provided aretools for the client and the team toformalize the way they measure theelements of success of the project. Use ofthese structures, or ones similar to them,will facilitate communication andcooperation between the client and project

Figure 8—Project Success Factors, Team View (Continued)

Cost Engineering Vol. 45/No. 4 APRIL 2003 29

team. This should continue throughoutthe life of the project by quantifying thesuccess attributes from the vantage pointsof the client and the project team. �

Reprint 20570

Recommended Reading

1. Ashley, D.B., C.S. Lurie, and E.J.Jaselskis. Determinants of ConstructionProject Success, Project ManagementJournal, 18, no 2: 1987.

2. Boynton, A.C., R.W. Zmud. Assessment ofCritical Success Factors, SloanManagement Review, 26, no 4, summer1984.

3. Bullen, C.V., J.F. Rockart. A Primer onCritical Success Factors, Sloan CISRWP No. 69, June 1981.

4. Dobbins, J. H., R.G. Donnelly. CriticalSuccess Factors In DOD ProgramManagement, Acquisition ReviewQuarterly, Summer 1998.

5. Pearson, A. W. Project Selection in anOrganizational Context, IEEETransactions on EngineeringManagement, EM-21, no 4 (1974): 152-158.

6. Pinto, J.K., and D.P. Slevin. CriticalSuccess Factors Across the Project Life

Cycle, Project Management Journal, 19,no. 3 (1988).

7. Pinto J. K. and Dennis P.Slevin, CriticalFactors in Successful ProjectImplementation, IEEE Transaction onEngineering Management, 34, no.1(February 1987): page 22-27.

8. Pinto, J.K., J.E. Prescott. Variations inCritical Success Factors Over the Stages inthe Project Lifecycle, Journal ofManagement, 14, no. 1 (1988).

9. Rockart, J.F., Chief Executives DefineTheir Own Data Needs, Harvard BusinessReview, 57, no. 2 (March 1979).

10. Schwartz, M., Project Manager Priorities,Software Magazine, Barrington, (January1998).

About the Author

Parviz F. Rad is aDistinguished ServiceProfessor and Director ofProject ManagementProgram at StevensInstitute of Technology.

He holds an M.Sc. degree from Ohio StateUniversity and a Ph.D. from MassachusettsInstitute of Technology. He has over 30 yearsof professional experience during which he hasserved in governmental, industrial, andacademic capacities. He has participated inproject management activities and indevelopment and enhancement of quantitativetools in project management in a multitude ofdisciplines including software development,construction, and pharmaceutical research. Hehas authored and coauthored over 50publications in the areas of engineering andproject management. Dr. Rad has beenrecognized as a Professional Civil Engineer,Certified Cost Engineer, and as a ProjectManagement Professional. Dr. Rad is theEditor of the Project Management Journal.He can be contacted by e-mail atprad@stevens-tech.edu.