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.

Identifying and Managing Project Risk
Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project
ISBN: 0814413404
EAN: 2147483647
Year: 2005
Pages: 130

Similar book on Amazon © 2008-2020.
If you may any questions please contact us: