Appendix A Selected Detail From the PERIL Database

The following information is excerpted from the Project Experience Risk Information Library (PERIL) database.

Schedule Risks

• Each stakeholder approved the project individually, but, at the meeting to grant final approval, disagreements surfaced that delayed the project.
• Sponsorship was not sustained, delaying decisions and limiting resources.
• Access to management was limited. Decisions and escalations were too slow.
• The system for approving requests failed; ordering parts was delayed.
• Document reviews slipped due to conflicts and low priority.
• Required end-of-phase review was delayed.
• Disaster recovery tests were delayed at project end because the hardware needed was tied up with an actual customer problem.
• Test systems were shared by several projects, causing queuing delays.
• Flooding in a data center caused delay for restoration and cleanup.
• Customer-supplied hardware failed and required replacement.
• Needed equipment was shipped from a pool of hardware in another country and was delayed by customs.
• New technology planned into the project was not available on time.
• Needed systems were down for scheduled maintenance not in the plan.
• New systems were delivered to the wrong building and were lost for weeks.
• Parts of the development team had a twelve-hour time difference. Bugs took two to three extra days to fix, on average.
• System components were all shipped separately, so installation was delayed until the last one arrived.
• Defective parts were received, and all had to be reordered.
• Paperwork and customs delayed delivery on international shipments.
• The process for developing integrated circuits failed, creating delays.
• In error, parts were shipped by sea, not by air, from Asia.
• Some activities were assigned only by function, not by name. No one was actually working on them.
• A dependency on another project was not discovered until project end.
• Clear responsibility for work to be done by the project team and by the customer was never delegated. Confusion led to delay.
• A deliverable from one project was "done," but the receiving project could not use it.
• Lack of coordination between projects caused delay.
• Interdependencies in complex programs were underestimated and detected late.
• A move from a former location was planned, but the new space was not ready on time. An interim move to temporary space required extra time and money.
• Support for the operating system used was inadequate for timely solution of conversion and delivery problems.
• Scheduling was based on a small pilot installation, but, when scaled up, systems lacked capacity, and the project was delayed.
• An old application had to be modified for the project, but no one left knew it well enough, and there was no documentation.
• An unrealistic project deadline was set; slips were unavoidable.
• Planning a project for new customer was based on similar work for an existing customer. Differences in relationships, infrastructure, jargon, and other factors required 50 percent more effort.
• Development scheduled in parallel led to frequent rework.
• Chronic optimism on completion dates for work led to missed deadlines.
• Neophyte project staff lacked technical expertise and required extra training time.

Resource Risks

• Project was delayed because of a major program budget cutback.
• Project expenses for supplies were limited (running the project at the scheduled rate necessitated 50 percent more money per month).
• A key supplier proved unreliable, delivering components late.
• Third-party deliverables were of poor quality and required major rework.
• A supplier agreed to needed changes but failed to deliver.
• A supplier contract included no penalties for missed dead-lines, so its work was chronically late.
• A supplier was changed near the end of a project, causing delay and cost overrun.
• A subcontractor went out of business, causing a two-month delay for replacement.
• A key supplier was purchased and reorganized. Ultimately, the project had to find a new supplier.
• The project had a slow start due to difficulty in finding a qualified supplier.
• Pricing negotiation with a supplier stalled project work.
• Qualification and paperwork caused delays in beginning to work with a supplier in another country.
• High turnover at a supplier led to delays and crisis management.
• Two projects with similar objectives were taken on in different locations at the same time. The redundancy caused interference and arguing.
• Legacy systems were not retired as planned; the project team was tied up in unplanned support.
• Testing on a prior project was late, causing planning delays until staff was available.
• "Rolling Sledgehammer": The prior project tied up (and exhausted) staff, so the current project started late and slowly.
• The project had funding, but, due to head count limits, no staff was available.
• An expert (on supply chain) was difficult to find, causing delay.
• Needed people were still on a prior project.
• A key person was reassigned to other work in midproject.
• Staff turnover was very high, leading to delays and extra training.
• The project leader resigned and was not replaced promptly.
• Project priority was very low, leading to high turnover.
• Committed resources were reassigned to other projects and not replaced.
• Loss of staff led to tripling of activity durations on the project.
• The project was desired by management but not by the project team. Even with heavy monitoring, project work was slow.
• Enthusiasm and motivation fell because of the length of the project, so activities took longer than estimated.
• A third-party expert required for work was not available when needed.
• Key people were shared by several projects; lots of queuing.
• Training at project end took double the time, as people who required training missed the classes they were assigned to. Additional training was required.
• Key decisions were stalled when system architect was not available.
• Illness during key project work hit most of the project staff.
• An unexpected shutdown was scheduled at year-end. Work was delayed, and rescheduling it was difficult.
• A key team member was grounded in the Middle East during a war.
• Key staff was lost to a customer "hot site."
• Organizational reorganization created chaos and ownership problems.
• Manufacturing problems diverted project contributors.
• An unannounced audit in midproject caused delay due to required preparation.
• An earthquake made part of the project team unavailable for work.

Scope Risks

• The customer reorganized, and new staffing led to changed requirements.
• Project priorities were unclear, and secondary, less important work was done instead of required activities.
• Information from many sites was required, but, even after it was collected, additional time and work were necessary to make it consistent.
• A "small" client-requested change was accepted, which led to unintended consequences and major delay for the project.
• System redesign was added late in a maintenance project, creating major delay.
• Poorly managed change made the project very late.
• A "priced to win" project was badly understaffed, and the deadline was much too short.
• Scope definition changed late in the project.
• An unanticipated software upgrade was required, causing planning and training delays.
• New software installed by IT did not work, and fixing it caused delay.
• An operating system release was canceled; the project had to use a prior version.
• The project was based on standards that were still in draft form. Several options were possible for the final standards, but project was staffed to pursue only one.
• Organizational policy changes made late in a project required unplanned work.
• Project documents and expectations were not aligned. Adjustments required much additional work.
• Work was done by contractors who had too little project information; components supplied required extensive rework.
• The system was only partly specified until near the end of the project.
• Documentation was not translated into all needed languages; project was delayed.
• The product was developed for multiple platforms but worked on only two initially. Some problems were eventually fixed, but several platforms had to be dropped.
• Some project work was assigned to multiple owners. Each assumed the others were doing the work, when no one was doing it.
• Proprietary data were necessary for the project, but the owners of the data were reluctant to provide them. After delay, some partial information was shared.
• New technology promised faster results, but it failed and led to redesign and rework.
• A custom system for a customer was designed to use an Intel-based PC. A model based on a new CPU chip was shipped, but it failed to work as the older model did. The system was finally installed using a salvaged older PC.
• PC board failure required redesign and refabrication.
• Components did not work as documented. Replacements and software workarounds were required.
• Tests were not scheduled for historically reliable parts, but they were mandatory for the project and had to be added, late.
• The deliverable failed the final test, requiring rework to fix it and an additional test cycle.
• Final tests were interrupted by faulty test equipment. Repair of the equipment took time, and all the tests had to be restarted.
• Test hardware did not work properly, and performing all tests manually required extra time and effort.
• Redesign was required late in the project to meet quality goals, causing a major slip.
• A complex system was designed in pieces, and integration failed. Redesign and rework caused delay.
• A process developed worked in prototype but did not scale to production, requiring time-consuming changes.
• Problems were detected late in the project, and a solution was developed on the basis of the presumed root cause. The actual cause was something else, causing a slip.
• A purchased component was never delivered ("vapor-ware"). A brute-force workaround was developed but took time and was difficult to support.
• A key application failed during a system upgrade project, requiring unplanned effort to fix it.
• International shipment of media containing needed software was on time, but the media were unreadable and had to be replaced.
• Purchased software was limited and inflexible. The project had to develop workarounds and additional software.
• Late in the project, a software virus destroyed several crucial (and not backed-up) files, requiring rework to rebuild them.