Complete List of Schedule Risks ------------------------------------------------------------------------ Overview of Complete List of Schedule Risks [Image] Schedule creation [Image] Organization and management [Image] Development environment [Image] End-users [Image] Customer [Image] Contractors [Image] Requirements [Image] Product [Image] External environment [Image] Personnel [Image] Design and Implementation [Image] Process Schedule creation * Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance * Schedule is optimistic, "best case," rather than realistic, "expected case" * Schedule omits necessary tasks * Schedule was based on the use of specific team members, but those team members were not available * Cannot build a product of the size specified in the time allocated * Product is larger than estimated (in lines of code, function points, or percentage of previous project’s size) * Effort is greater than estimated (per line of code, function point, module, etc.) * Reestimation in response to schedule slips is overly optimistic or ignores project history * Excessive schedule pressure reduces productivity * Target date is moved up with no corresponding adjustment to the product scope or available resources * A delay in one task causes cascading delays in dependent tasks * Unfamiliar areas of the product take more time than expected to design and implement Organization and management * Project lacks an effective top-management sponsor * Project languishes too long in fuzzy front end * Layoffs and cutbacks reduce team’s capacity * Management or marketing insists on technical decisions that lengthen the schedule * Inefficient team structure reduces productivity * Management review/decision cycle is slower than expected * Budget cuts upset project plans * Management makes decisions that reduce the development team’s motivation * Nontechnical third-party tasks take longer than expected (budget approval, equipment purchase approval, legal reviews, security clearances, etc.) * Planning is too poor to support the desired development speed * Project plans are abandoned under pressure, resulting in chaotic, inefficient development * Management places more emphasis on heroics than accurate status reporting, which undercuts its ability to detect and correct problems Development environment * Facilities are not available on time * Facilities are available but inadequate (e.g., no phones, network wiring, furniture, office supplies, etc.) * Facilities are crowded, noisy, or disruptive * Development tools are not in place by the desired time * Development tools do not work as expected; developers need time to create workarounds or to switch to new tools * Development tools are not chosen based on their technical merits, and do not provide the planned productivity End-users * End-user insists on new requirements * End-user ultimately finds product to be unsatisfactory, requiring redesign and rework * End-user does not buy into the project and consequently does not provide needed support * End-user input is not solicited, so product ultimately fails to meet user expectations and must be reworked Customer * Customer insists on new requirements * Customer review/decision cycles for plans, prototypes, and specifications are slower than expected * Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so—resulting in unstable requirements and time-consuming changes * Customer communication time (e.g., time to answer requirements-clarification questions) is slower than expected * Customer insists on technical decisions that lengthen the schedule * Customer micro-manages the development process, resulting in slower progress than planned * Customer-furnished components are a poor match for the product under development, resulting in extra design and integration work * Customer-furnished components are poor quality, resulting in extra testing, design, and integration work and in extra customer-relationship management * Customer-mandated support tools and environments are incompatible, have poor performance, or have inadequate functionality, resulting in reduced productivity * Customer will not accept the software as delivered even though it meets all specifications * Customer has expectations for development speed that developers cannot meet Contractors * Contractor does not deliver components when promised * Contractor delivers components of unacceptably low quality, and time must be added to improve quality * Contractor does not buy into the project and consequently does not provide the level of performance needed Requirements * Requirements have been baselined but continue to change * Requirements are poorly defined, and further definition expands the scope of the project * Additional requirements are added * Vaguely specified areas of the product are more time-consuming than expected Product * Error-prone modules require more testing, design, and implementation work than expected * Unacceptably low quality requires more testing, design, and implementation work to correct than expected * Development of the wrong software functions requires redesign and implementation * Development of the wrong user interface results in redesign and implementation * Development of extra software functions that are not required (gold-plating) extends the schedule * Meeting product’s size or speed constraints requires more time than expected, including time for redesign and reimplementation * Strict requirements for compatibility with existing system require more testing, design, and implementation than expected * Requirements for interfacing with other systems, other complex systems, or other systems that are not under the team’s control result in unforeseen design, implementation, and testing * Pushing the computer science state-of-the-art in one or more areas lengthens the schedule unpredictably * Requirement to operate under multiple operating systems takes longer to satisfy than expected * Operation in an unfamiliar or unproved software environment causes unforeseen problems * Operation in an unfamiliar or unproved hardware environment causes unforeseen problems * Development of a kind of component that is brand new to the organization takes longer than expected * Dependency on a technology that is still under development lengthens the schedule External environment * Product depends on government regulations, which change unexpectedly * Product depends on draft technical standards, which change unexpectedly Personnel * Hiring takes longer than expected * Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time * Poor relationships between developers and management slow decision making and follow through * Team members do not buy into the project and consequently does not provide the level of performance needed * Low motivation and morale reduce productivity * Lack of needed specialization increases defects and rework * Personnel need extra time to learn unfamiliar software tools or environment * Personnel need extra time to learn unfamiliar hardware environment * Personnel need extra time to learn unfamiliar programming language * Contract personnel leave before project is complete * Permanent employees leave before project is complete * New development personnel are added late in the project, and additional training and communications overhead reduces existing team members’ effectiveness * Team members do not work together efficiently * Conflicts between team members result in poor communication, poor designs, interface errors, and extra rework * Problem team members are not removed from the team, damaging overall team motivation * The personnel most qualified to work on the project are not available for the project * The personnel most qualified to work on the project are available for the project but are not used for political or other reasons * Personnel with critical skills needed for the project cannot be found * Key personnel are available only part time * Not enough personnel are available for the project * People’s assignments do not match their strengths * Personnel work slower than expected * Sabotage by project management results in inefficient scheduling and ineffective planning * Sabotage by technical personnel results in lost work or poor quality and requires rework Design and Implementation * Overly simple design fails to address major issues and leads to redesign and reimplementation * Overly complicated design requires unnecessary and unproductive implementation overhead * Inappropriate design leads to redesign and reimplementation * Use of unfamiliar methodology results in extra training time and in rework to fix first-time misuses of the methodology * Product is implemented in a low level language (e.g., assembler), and productivity is lower than expected * Necessary functionality cannot be implemented using the selected code or class libraries; developers must switch to new libraries or custom-build the necessary functionality * Code or class libraries have poor quality, causing extra testing, defect correction, and rework * Schedule savings from productivity enhancing tools are overestimated * Components developed separately cannot be integrated easily, requiring redesign and rework Process * Amount of paperwork results in slower progress than expected * Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project * Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream * Inaccurate quality tracking results in not knowing about quality problems that affect the schedule until late in the project * Too little formality (lack of adherence to software policies and standards) results in miscommunications, quality problems, and rework * Too much formality (bureaucratic adherence to software policies and standards) results in unnecessary, time-consuming overhead * Management-level progress reporting takes more developer time than expected * Half-hearted risk management fails to detect major project risks * Software project risk management takes more time than expected ------------------------------------------------------------------------ Copyright © 1996-1998 Construx Software Builders, Inc.