IT Project Risk Management Checklist Template

Download Free IT Project Risk Management Checklist Template:

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.).
- Re-estimation 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.
- Non-technical 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 of 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 base lined 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 re-implementation.
- 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 do 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 re-implementation.
- Overly complicated design requires unnecessary and unproductive implementation overhead.
- Inappropriate design leads to redesign and re-implementation.
- 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 mis-communications, 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