CHAOS: A Recipe for Success - Software and Systems Engineering

The Standish Group believes three key metrics canpinpoint a project’s success potential: project size,project duration and team size.Size matters. CHAOS research confirms that smallprojects are more likely to succeed than large projects.As project costs rise, typically through theaddition of features and functions that are rarelyor never used, the likelihood of success falls.Although one school of thought would argue thatlarger projects with more funding and resourcesshould be more successful, and should producemore function, the reverse appears to be true.Smaller projects tend to be more manageable, andit’s usually easier to ensure they meet the CHAOSTen success criteria. Simply throwing more moneyat a project is no solution.We have long been convinced that shorter timeframes, with delivery of software componentsearly and often, increase the success rate. Shortertime frames foster an iterative process of designing,prototyping, developing, testing and deploying smallelements. “Growing” (instead of “developing”) softwareengages the user earlier and confers ownership. Becauseeach software component has a precise statement and setof objectives, realistic user expectations are set.THE 3 PILLARS OFPROJECT SUCCESSProject Duration, Team Size Affect Project SuccessProject SizeLess than $750K$750K to $1.5M$1.5M to $3M$3M to $6MPeople6122540Time(mos.)691218SuccessRate55%33%25%15%Certain industries breed success. The Standish Group’sCHAOS research shows that in 1998 the retail industry hadthe highest project success rate (59%)—almost twice thesuccess rate of the financial sector (32%), more than twicethat of the manufacturing sector (27%), and three times thatof government projects (18%). Of all industries, retail alsohad the fewest challenged (28%) and failed projects (12%).Over $10M$6M to $10M$3M to $6M$1.5M to $3M$750K to $1.5MLess than $750KSuccess by Project Size0%8%15%25%33%55%0% 10% 20% 30% 40% 50% 60%Small is beautiful. Projects costing less than $750,000 are more successfulthan any others. Project managers should realize at the outset that the moreexpensive a project becomes, the less likely its chance of success.We believe the retail project success rate is a function ofthat industry’s tight cost controls. The low-margin retailindustry cannot tolerate waste. The government, on theother hand, faces no such challenge.Company size does not guarantee success. The StandishGroup has found no correlation between a company’s sizeand its project success rate. As with project size, bigger isnot necessarily better. While large companies (over $500M)do experience more failures and fewer successes thanmedium companies ($200M-$500M), project failure rates aregenerally distributed quite uniformly across companies ofall sizes. Project failure is everyone’s problem.$6M to $10MOver $10M+250+500+24+36The smaller the team and shorter the duration of the project, thegreater the likelihood of success. Obviously, this does not suggest thatcompressing the schedule and reducing the resources of a largeproject will make it successful. Nor should it be construed that largeprojects with large teams cannot be successful. The Standish Groupbelieves any project can be successful if all the key criteria are met.8%0%Another way to look at project resolution is to compare thevalue of successful projects with the waste of challengedand failed ones. Along with improvements in time and costoverruns, companies’ waste to value ratios have improvedsubstantially. In 1996, CHAOS research found 50% waste inIT projects. By 1998 the data identified only 37% waste.COPYRIGHT ©19993THE STANDISH GROUP INTERNATIONAL, INC.

CHAOS TenWhat makes a projectsuccessful? Theoriginal CHAOSstudy identified 10success factors. Noproject requires all10 factors to besuccessful, but themore factors, thehigher theconfidence level.User InvolvementExecutive SupportClear Business ObjectivesExperienced Project ManagerSmall MilestonesFirm Basic RequirementsCompetent StaffProper PlanningOwnershipOther20 Points15 Points15 Points15 Points10 Points5 Points5 Points5 Points5 Points5 PointsRECIPE FOR PROJECT SUCCESS: CHAOS TenThe three biggest contributors to project success are userinvolvement, executive support and a clear statement ofbusiness objectives. Together they account for 50% of aproject’s chances for success. Bring on board an experiencedproject manager, and the chance for a successful resolutionrises to 65%. The number one contributor to project successis user involvement. Not surprisingly, the absence of userinvolvement is a major cause of project failure. Even whendelivered on time and on budget, a project can fail if it doesnot meet users’ needs.Participants in The Standish Group’s focus groups conductedin 1998 were virtually unanimous in citing increased userinvolvement in the project planning stage as the most notablechange in application development over the past two years.Participants recognized the benefits of early and continuoususer involvement. When users are actively involved inplanning, IT cannot second-guess them. Users who are fullyengaged in design, implementation and testing feel a deepersense of ownership.Validated in The Standish Group’s research results and focusgroups, the CHAOS Ten success factors continue to be avaluable tool to assess project success potential. While thereis no magic formula that can guarantee project success,ensuring the presence of the CHAOS Ten can increase theodds in one’s favor.Better Project Management Through Communication. TheStandish Group has compared project success with a threeleggedstool. One leg is communication. The other two legsare scope minimization and standard infrastructure.Standard Infrastructure. Requirements are in a state ofconstant flux, but the infrastructure needs stability. TheStandish Group’s research shows that seventy percent ofapplication code is infrastructure. Some of this code is uniqueto the application; nonetheless, much of it is code that couldbe purchased from an infrastructure vendor. By using standardinfrastructure, the application development team canconcentrate on business rules rather than technology.Many application development projects fail not in thedevelopment of the stand-alone application, but in theintegration of existing applications. Here standardinfrastructures can shortcut application integration.The Standish Group estimates that by the year 2000 the peopleof this earth will generate 100 million transactions everysecond. World businesses currently have over one millionbusiness-critical applications in place. Every five years thenumber of mission-critical applications doubles: moretransactions, more applications, and more interfaces. This, ofcourse, does not include the number of applications theenterprise may need to integrate with other companies andpartners.THE STANDISH GROUP INTERNATIONAL, INC. 4COPYRIGHT ©1999

The Triad of Project ManagementWhat has become clear since 1996 is thatpeople and process have a greater effecton project outcome than technology.Through a series of multi-city focusgroups and workshops at CHAOSUniversity ® ’98, The Standish Group setout to explore the proper roles,responsibilities and relationships ofproject stakeholders.These stakeholders include the FunctionRepresentative, Executive Sponsor andProject Manager. We wanted to knowwhat qualities and characteristics eachstakeholder should possess, as well aswhat kinds of executive behavior mightdetract from a project’s success.The relationship between the projectmanager and the business andtechnology stakeholders is shown in thechart below. In the ideal triad, the projectmanager is the lone interface betweenthe business and technology sides of thecompany.FunctionRepresentative:The Business PersonThe function representative knows thebusiness of the corporation better thanany other member of the team does. Thisperson is in an executive position, buthas the knowledge to drill down into allkey user departments for the essentialdetails about how the organization works.The function representative also knowsthe expectations, doubts, fears andprevious negative experiences of the usercommunity.The most important task for the functionrepresentative is goal definition, whichis twofold. First, the functionrepresentative must take a detailedsnapshot of the organization at themoment before project planningcommences; then he or she must havethorough understanding of what the userorganizations want tomorrow. These willhelp build the project goals. And thebusiness person must also be in chargeof milestone recognition, an ongoing taskto chart ongoing progress.The Function Representative shouldbe the “Operations Person”.Operational knowledge is important tothe function representative, who must beable to answer operational questions.His/her role must be defined with clearresponsibility and clear ownership, butalso with a limited scope of responsibility(the user representative is NOT theexecutive sponsor). The functionrepresentative does not own thetechnology, does not control or schedulewallFunctionRepTechnicalInfrastructureOrganizationproject resources, and does notdetermine the project approach. But heor she does speak with a loud voice forall user departments.The Function Representative shouldbe the “Minuteman”. The functionrepresentative can be most effectivewhen using physical separation of regularwork assignments from those on theproject management team. Physicalseparation, such as a different workspace,encourages mental compartmentalizationand focus on the project dynamics.The function representative is the team’ssubject matter expert and as such bestqualified to become the project’sevangelist — selling the benefits of theproject internally to the user community.BusinessProjectManagerTechnologyLike Paul Revere, the functionrepresentative can rally the troops.The Function Representative can belead astray. There is a constant potentialfor overlap or conflict with the projectmanager. The tendency of the functionrepresentative is to exceed his or herauthority and to devise potential solutionsor suggest deployment of certaintechnologies. Neither of these is withinthe responsibilities of the functionrepresentative, whose contribution is toexplain and reinforce the user’srequirements, and to keep the projectfocused on them. Most importantly, theExecutiveSponsorwallSoftwareDevelopmentOrganizationfunction representative must emphasizethe business value of the project, nottechnology implementation.The Function Representative shouldbe “Sherlock Holmes”. Elementary asit may seem, the function representativemust be prepared to explain the businessprocess in detail to the IT organization.He/she must be trained to follow theproject management process and mightneed a business analyst assigned to workwith him/her.The Function Representative shouldbe the “Cheap Date”. The functionrepresentative should be encouraged toset realistic expectations, be involvedfrom the start and recommendprototyping.COPYRIGHT ©19995THE STANDISH GROUP INTERNATIONAL, INC.

The Executive Sponsor: Project ChampionThe executive sponsor provides the vision for the project. Often the executive sponsorprovides the funding and some of the major resources, as well. When choosing asponsor, it is crucial that the executive have a vested interest in a successful outcome.To ensure this interest, answer the following questions:• Is there clear understanding of what will motivatethe executive?• Have the political issues affecting the executivebeen identified?• Can the executive afford to have the project fail?• Will the executive gain stature from a successful project?Once a project has the backing of the right executive sponsor,it’s vital to encourage positive and discourage negative traits.Our CHAOS University ® participants identified the followingways to accentuate the positive:The Executive Sponsor should be “The Visionary”.An executive sponsor should have a global view of the project,how it supports corporate goals and benefits the organization.The executive sponsor should set the agenda, arrange the fundingand articulate the project’s overall objectives.The Executive Sponsor should be the Project’s Champion.The project should live and die by the executive sponsor. IT canencourage the executive sponsor to champion the project bysupplying full disclosure and minimizing blindsides, having welldefined goals and milestones, and focusing on business ratherthan technology issues.The Executive Sponsor should be a “Minesweeper”.An effective executive sponsor should positively reinforce thewinners and neutralize the losers on the project team. Theexecutive sponsor must pave the way for success and guaranteethat the project does not get sidetracked.The Executive Sponsor should be a “Gen. Schwarzkopf”.The executive sponsor will muster the resources necessary tocomplete the project. If IT identifies those resources quickly,the executive sponsor will have adequate time to marshal them.The Executive Sponsor should be the “Fall Guy”.It is imperative that the executive sponsor claim total ownershipof the project, including blame if the project fails. The buckstops here. Sometimes knowing what not to do is as importantas knowing what to do. CHAOS University ® and focus groupparticipants delineated the negative traits for an executivesponsor.The Executive Sponsor should not be the Project Manager.Too much executive involvement can be as disastrous as toolittle. IT must clarify roles and responsibilities early on bydefining the rules of engagement. IT also should provide weeklyfiltered reports that offer the executive sponsor easy anddigestible information in language devoid of techno-speak.The Executive Sponsor should not be the Function Rep.The executive sponsor is probably unaware of the true operationof the business. Enlisting committed, trusted users in the projectwill help keep the executive sponsor out of the project details.The Executive Sponsor should not be “Santa Claus”.Time is the absolute enemy of all projects. All too often, featuresand functions are added to the project with no understanding ofthe consequences for the health of the project. IT mustdiscourage scope creep by alerting the executive sponsor ofthose consequences, by having a formal change managementprocedure, and by pushing to deliver quickly.The Executive Sponsor should not be the Technical Officer.The best way to discourage an executive sponsor from being atechnical officer is to have good technologists in the company.The Executive Sponsor should not be a “Wimp”.All too often the executive sponsor will not make decisionsbecause he does not understand the project or the technology.IT must encourage the executive sponsor to make businessdecisions and to reduce political conflicts. Using the 10 positiveand negative characteristics outlined here, a development teamcan get a head start toward finding the appropriate executivesponsor to lead their project.The Project Manager: The Linch-PinThe IT community is just beginning tounderstand the true role of the projectmanager, the skill required to be a goodproject manager, and the benefits aproject manager can bring to any project.The Standish Group’s research clearlyshows that projects are likely to be lesschallenged and more successful with acompetent and experienced projectmanager on board.The package of skills most CIOs cite asdesirable in a project manager includestechnology and business knowledge,judgment, negotiation, good communicationand organization. Emphasis ison business skills rather than technicalcredentials. Moreover, project managersmust know not only the business needsof their own company, but also those ofsuppliers and partners.The Project Manager should be“Multilingual”. He/she must have theskills necessary to converse with all thestakeholders and technical teams. Theproject manager needs to have a viewof the project resources and how thoseresources come together. Giving theproject manager exposure throughout theorganization will encourage him or herto be “multilingual.”More exposure to both the businessorganization and the technical teams willincrease the project manager’s skills. Oneway to do this is to establish a mentoringand buddy system. Another way is tohave monthly “Project Managers Only”brainstorming sessions to exchange ideasand problem resolutions. Projectmanagement should be considered aprofession, not a discrete task.THE STANDISH GROUP INTERNATIONAL, INC. 6COPYRIGHT ©1999

The Project Manager should be a“Gatekeeper”. He/she must have theauthority to decide at the detail levelwhich features and functions will be partof the project, whether for the first phaseor for later release. There must be achange policy procedure in place, withassociated risk factors and cost increases.Change increases the scope of theproject, the time involved and the chanceof failure. The project manager shouldadvise the stakeholders about the risksof scope creep and its potentiallydisastrous effects.The Project Manager should be a“Maestro”. The project manager mustorchestrate all the resources so that theyplay together like a fine symphony. Inthis regard, the project manager needsto know the depth and skills of all theplayers to prevent wrong notes. Theproject manager must be empowered toacquire and keep the right talent and getrid of non-contributors.The Project Manager should be a“Cattle Driver”. The project managermust be a hard driver, able to focus onthe goal and to minimize diversions.The Project Manager should be a“Clark Kent”. Good communicationis one of the cornerstones of successfulprojects. The project manager mustcommunicate well, both verbally and inwriting. In order to encourage theseskills, IT management should considertwo training venues: Dale Carnegieclasses on how to win friends andinfluence people, and Toastmaster’sclasses on how to present. The projectmanager should be encouraged to usethe organization’s business dialect tokeep communication simple.The Project Manager should not bethe Executive Sponsor. The StandishGroup believes the surest road to projectfailure is through the IT organization.Projects are done on behalf of thebusiness organization and should havefirm executive commitment. IT must setdown the rules of engagement andclearly define the stakeholders’ roles.The project manager needs to move withthe team, while getting the project done.The best way to discourage the projectmanager from becoming the executivesponsor is to have an effective sponsoralready.The Project Manager should not bethe Function Representative. TheStandish Group has seen many caseswhere the project manager thought he/she knew more about the organizationthan the function representative did.However, in most cases this is not so.The best way to discourage a projectmanager from being a functionrepresentative is to have strong userrepresentation.The Project Manager should not bea “Santa Claus”. Learning to say “no”is the hardest lesson for many projectmanagers. Each feature and functionmust be measured against businessvalue, project quality, resources, risk andschedule. With eighty percent ofdelivered features and functionsultimately unused, enlarging the project’sscope should not be taken lightly.The Project Manager should not bea “Control Freak”. While the projectmanager must control the resources andknow all the project details, he/she10 FUNDAMENTAL QUESTIONS FOR EVALUATING A MENTOR:1.2.3.4.5.6.7.8.9.10.cannot look over the shoulders of theother stakeholders. Establishing peerreview processes, focusing on goals andhaving status communications meetingscan discourage a control freak.The Project Manager cannot be“Superman”. Projects are risky, andeven a remarkable project managercannot save a failing project. It takesthe active participation of all thestakeholders to create a successfulproject. Setting correct expectations earlyin the project can have a positive effect.Minimizing project scope will result inbetter estimates, and over-promisingshould be discouraged.A Project Manager is much like aPresident of a Small Company. Theexecutive sponsor is the venturecapitalist, the function representatives arethe customers, and the developers arethe workers. Keeping the project ontrack is like keeping a small companyon track — no easy feat.MENTORING FOR THE PROJECT MANAGERSince the time of the ancient Greeks, the concept of mentoring has defined aconstructive personal relationship between individuals who provide support,guidance and assistance in the achievement of their full potential.The role of today’s business mentor is as friendly advisor, coach and teacher. Liketheir predecessors, today’s mentors share experience in pursuit of higher levels oforganizational performance. With mentors, skills and expert knowledge aretransferred and institutionalized within the organization.From a management perspective, mentoring offers a safety net to the organizationas it undertakes new projects, pursues new strategies or applies new techniques.Thus, the best mentors are alert to situations where methods, tools and strategiesare inconsistent or incompatible with those currently in use, so that managementgoals and objectives are not compromised, and process improvement opportunitiesare not missed.Engaging a mentor requires care. Selecting the wrong mentor can have devastatingconsequences that could potentially take years to undo.What direct experience does the contractor/mentor have?Has the contractor/mentor proposed constructive suggestionsand/or strategies?What methodologies has the contractor/mentor offered?What training has the contractor/mentor received?What are the characteristics of the contractor/mentor?What are the greatest strengths of the contractor/mentor, and why?In which areas are the contractor/mentor weak and why?Has the contractor/mentor made viable observations or suggestions forimmediate change?Why does the contractor/mentor want to work on this assignment?Has the contractor/mentor answered any questions that should have beenasked but were not?COPYRIGHT ©19997THE STANDISH GROUP INTERNATIONAL, INC.

Does Formal ProjectManagement Have Value?In 1986 Alfred Spector, former president of TransarcCorporation, co-authored a paper comparing bridgebuilding to software development. The premise was thatbridges are normally built on time, on budget, and do notfall down. Software, on the other hand, never comes inon time or on budget, and it always breaks down.One of the reasons bridges are built on time, on budget,and structurally sound is the extreme detail of design.The design is frozen, and the contractor has littleflexibility in changing the specs. However, in today’sdynamic business environment, a frozen design doesnot accommodate rapid changes in business practices.A more flexible model is required.Another difference is that when a bridge collapses, theevent is thoroughly investigated, and a report is writtenon the cause of the failure. In software development,until recently, failures were covered up, ignoredor rationalized.Project management, used successfully for decades inthe construction industry, is still an evolving disciplinein information technology.Eighty CIOs in workshop sessions at both CHAOSUniversity ® ’98 and European CHAOS ’98 discussedthe value of formal project management disciplinesand the merits of adopting formal project managementprocesses to large scale software development. Inother words, why bother?CHAOS participants said that a formal projectmanagement process is the only way large-scalesoftware development can be structured for success.All-encompassing methodologies address the typicalarray of development problems such as inadequateplanning, inadequate user input, unstable requirements,evolving technology, loose specifications andunrealistic cost estimates.Like scaffolding, project management supports definedroles and responsibilities to achieve project objectives.The project framework is procedural, rigorous,standardized and documented. Standards arerepeatable. Monitoring, reporting and change orderprocedures are in place. Resources can be allocatedfor maximum effect.Formal project management provides a realistic pictureof the project and the resources committed to it.Certain steps and procedures are reproducible andreusable; thus minimizing the tendency to reinvent thewheel, and maximizing project-wide consistency.Lessons learned can be incorporated into activeprojects. The process encourages go/no go decisioncheck points, so a project team can proceed with ahigher confidence level, or steps can be halted oraltered to fit changing requirements. This abilityto adjust in real time reduces project risk andenhances skills.Predictability is a big benefit, CIOs said. Predictabilityreduces uncertainty, making use of resources moreefficient. A project manager has the ability to predictand manage human and capital resource issues; andcan also direct user expectations.Formal project management adds value by mitigatingrisk in almost any development effort. But projectmanagement is valuable in other circumstances, too,such as in complex situations, when certainty isneeded, or when projects require an extended time tocomplete. Formal project management processesdiminish the level of complexity and reduce thecorresponding program risk when structured andcontrolled implementations are planned. That reducedrisk includes this project, future projects andoverall business.Project management is most valuable when planningnew projects or enlarging existing ones. However, notall projects warrant formal project managementtechniques. Project management adds no value to small,simple projects. Emergency, time-critical projects thatrequire quick delivery bog down under the weight offormal project management techniques. In very maturesituations, where sound processes already exist, formalproject management adds nothing, and projectmanagement probably should not be used wheninnovation is required, or when the overhead isgreater than the project value.THE STANDISH GROUP INTERNATIONAL, INC. 8COPYRIGHT ©1999

Project Estimating:Lucky or LousyYogi Berra once quipped, “Predictions are hard,especially about the future”. Countless times duringfocus groups, project group therapy sessions andfailure post mortems, IT executives echoed, “We didour best estimate, we doubled it, added some more,and we still missed the mark”.Project and program estimating is nothingmore than predicting the futureoutcome of a project or program.It is difficult.In this regard, there are only two kinds of estimates:“Lucky” or “Lousy”. Frequently, different peoplemake these estimates at different times usingdifferent methods. Clearly a more standardestimating process could generate significantimprovements.One must be realistic; there isno such thing as a reliableestimate. Learning to workbetter with poor estimatesrather than developing betterestimating techniques iscrucial. Nevertheless, projectmanagers who recognize theirlimitations can use someformal estimating tools andthese tools can greatlyimprove their luck.Many tools offer acombination of statistical andjudgment forecasts. Thesetools combined with aniterative process developmentstyle enable a projectmanager to react correctly tothe changing programenvironment. Thus, theestimating process itself is iterative through thelife of the project. This will give little comfortto the financial officer trying to decide onfunding the project in the first place. It isimperative to know if there is a kill switch andhow it gets pulled.COPYRIGHT ©19999THE STANDISH GROUP INTERNATIONAL, INC.

Project ManagementToolsThe growth of the project management field has beenaccompanied by the emergence of planning, estimating,scheduling and tracking tools designed to support theprocess. The need to utilize project management tools incomplex environments is inescapable. Today’s projectsare huge, often spanning the enterprise and globalboundaries. It is virtually impossible to create acomprehensive project plan for a large or enterprisewideproject without using a tool.The purpose of projectmanagement tools is to supportthe project management processby providing a vehicle forplanning, executing andcontrolling the project. The tooldoes not manage the project, theproject manager manages theproject by utilizing the tool.• TrackingUsers are assured that all toolswill perform the basic uses but• Planningthey still need selection criteria to • Schedulingassess the many available tools onthe market. To this end, TheStandish Group has defined 10 fundamentalrequirements that we use to compare and evaluateproject management tools. These fundamentals are the“must have” attributes that influence which tool meetsan organization/enterprise’s needs.Ease of Use: Project management tools must provideease of use features to avoid the undesirable fate ofbecoming shelfware. Market availability, a reasonablelearning curve, good support and documentation, andeasy implementation are some of the critical easeof use features.Adaptability: Project management tools must beflexible and customizable. While projects share manyProject managementtools are used for:• Defining and assigning resources• Reporting/communicating progress• Identifying and managing dependencies,contingencies and riskscommon attributes, they can be widely diverse withunique plan attributes that must be accommodated bythe tool. Multiple projects can be embedded in a largerone, with each individual project having its own team.Today’s enterprise-wide projects mandate flexibility inproject management tools.Scalability: Project management tools must supportprojects ranging from department size to enterprisewide,multi-project, multi-site, and distributedenvironments. Projects such asmigrating an entire enterprise to• Analyzing• Organizing• Estimatinga standard platform or addressingthe year 2000 problem in a globalcorporation demonstrate theneed for scalabilty.Affordability: Projectmanagement tools must beaffordable or risk being deemedunjustifiable in today’senvironment of cost constraintsand limited funding. The StandishGroup believes that the use of aproject management tool can savesubstantial amounts of time and money throughproductivity gains and more effective planning.Interoperability: Project management tools must workwith other tools. This can be accomplished throughgeneral interoperability via standard APIs and commoninterfaces or through integration.Security: Project management tools become repositoriesof highly sensitive data such as dates, costs, resourcerates and other confidential or restricted information.Security, therefore, becomes a critical issue. Featuressuch as version control, access control, passwordprotection and field level control are desirable.THE STANDISH GROUP INTERNATIONAL, INC. 10COPYRIGHT ©1999

Portability: Any project manager can attest to lateSunday evenings or “off hours” at home spent updating aproject plan. The tool must be able to run independent ofthe environment.Distribution of Data: Project management tools are amajor source of communication throughout the lifecycleRole of the Internetand the Cybernetic WorkerInternet technology changes everything. As a ubiquitouscommunications infrastructure, the Internet enablesenterprise-wide project management and the building ofvirtual project teams within a global, collaborative projectmanagement environment.Because the Internet is the only widely available platformfor accessing process and project information, it is a costeffective backbone for extending project planning andexecution to every corporate location using the TCP/IPcommon denominator. A number of project managers aretapping the power of the Internet, corporate Intranets andcorporate Extranets to provide all stakeholders withinstant access to project plans and status reports.However, project management on a global scale will notbe easy. Most project management techniques weredesigned for co-located project teams. Those techniquesmay prove ineffective in global, multi-site organizations.of a project to a variety of audiences. The tool mustcontain features/functions to support their differingcommunication requirements, from the high levelexecutive view to the more detailed level required by aproject manager. This can be accomplished throughreport facilities, online queries, Web access, e-mailnotification, and/or integration and interoperability withother tools providing these functions.Integrity: Project management tools must maintain theintegrity of the data/plan input into the tool. In essence,a project management tool is just a productivity aid.It does not “manage” a project or ensure its success; itsimply assists the project manager in planning andexecuting a project. The project plan, as the primaryoutput of a project management tool, is the bible of theproject. A project manager must be confident that thetool will not alter the content of a project plan.Rapid Response Time: Project management tools mustaccommodate resource movements, task/activityadditions, expansions or deletions, constant schedulechanges occurring throughout the lifecycle of a projectand rapidly reflect those changes to all participants,whether they are local or geographically dispersed.The Standish Group anticipates that tool vendors willplace more emphasis on enterprise-wide projectmanagement via Internet enablement, multiple nestedprojects support, and enterprise-wide collaborationfeatures. Interoperability will be a primary objective.Globally distributed software development projects mustcontend with different languages, cultures, time zones,work ethics, legal systems, and hardware and softwarerequirements. The development of large softwaresystems will require larger teams of people with differentknowledge and educational backgrounds to work togetherat multiple locations. This fact of life must somehow beweighed against CHAOS findings that project size andscope creep threaten project success.Coordinating and managing the work of geographicallydistributed high performance virtual project teams,providing global access to project plans and dynamicproject data, and internalizing the experience of pastprojects to make it usable for future projects arechallenges to be addressed.Despite the hurdles, The Standish Group’s research foundthat project management is one process cited by CIOs asmost adaptable to virtual environments. CIOs understandthat managing a virtual project workforce is nottechnology dependent. From e-mail to cell phones andpagers, communications abound. Again, people andprocesses are at the heart of project management, nottoolsand technology.CHAOS University ® participants engaged in building orsupporting virtual enterprises reported that the top threecyberworker issues are measuring productivity, managingcommunications and motivating isolated workers. Projectsize magnifies these human challenges. Building virtualteams with a minimum of face time, clearly defining work,measuring cybernetic worker productivity and managingemployee communications across time zones are majormanagement priorities.COPYRIGHT ©199911THE STANDISH GROUP INTERNATIONAL, INC.

RecipeforProject SuccessThe Standish Group’s recipe for success combines reducing requirements to the stark minimum,providing constant communication systems and coupling those with a standard infrastructure.Mix these ingredients with a good project manager, an iterative development process, projectmanagement tools and adherence to key roles, and success is practically in the oven. This recipefor success works and we have seen it work again and again for the last two years. It’s a simplerecipe that produces incredible success rates.RECIPE FOR SUCCESSIngredients: Minimization - Communications - Standard InfrastructuresMix With: Good Project Manager - Interactive Process -Project Management Tools - Adherence to the Key RolesBake: No longer than six months - No more than six people -At no more than $750,000However, too many cooks will definitely spoil this stew; so use no more than six people for sixmonths and at a cost of no more than $750,000. This recipe may sound like magic, but it is justcommon sense. When it comes to project success, the fewer features and functions put in,the greater the yield. While many have tried to break up large projects into small fragmentsto increase the success rate, this strategy is fatally flawed. Only when you break thedependencies of one fragment to the next do you truly accomplish minimization. Featuresand functions add time, and time is the absolute enemy of all project success.Although project management makes steady progress in reducing project failure rates andproject waste, there is a long way to go. Even our optimistic projection of 30% waste by 2000is too high. Certainly, project management is only beginning to understand the different rolesand responsibilities of the stakeholders. Major research must be conducted to betterunderstand the motivations of each of these constituencies.Through CHAOS research and CHAOS University ®, The Standish Group will continue toinvestigate better ways to improve project success. It will be a long journey, but we have come along way already.THE STANDISH GROUP INTERNATIONAL, INC. 12COPYRIGHT ©1999