Guidelines Project Risk Management
SW/G09/1.0.0 Internal Page 1 of 12
Uncontrolled copied/ printed
Project Risk Checklist
Instructions for using this document
Section I of this template is used to determine whether there are inherent risks to your project. The results should be used as guidelines, since there will be other factors that may lower or raise the risk level. For instance, you may have a large project, which implies higher risk. This risk could be reduced if you also have an experienced project manager. Depending on where your project characteristics fall, you can evaluate whether your risk is high, medium, or low. (Medium risks fall in between the extremes.) If your project has many high-risk characteristics, it does not mean you will not be successful. However, it does mean that you should put a plan place to manage the risk.
This checklist can be especially valuable if your organization customizes the specific risk characteristics and risk criteria that apply to your company. For instance, you may find that in your organization, a project of less than 5,000 hours is considered low-risk, while one that is 20,000 hours more is high-risk.
When you have completed the checklist, look at all of the high-risk items and refer to Section II of this template. In this section, you will see each high-risk factor and examples of problems you may encounter. For each high-risk factor, create a plan to ensure that the risk is mitigated and does not occur. The second column of Section II shows examples of activities that can be added to the risk plan to help mitigate the risk.
After the high-risk factors have been evaluated, look at the medium-level risks to determine if the impact is severe enough that they should have a risk mitigation plan created for them as well. If so, create a risk plan for them. Then look at any low-risk items and see whether they should be listed as assumptions. In this way, you recognize that there is a potential for problems, but because the risk is low, you are “assuming” that the condition will not occur. The activities associated with managing the various risks should then be moved to your project work plan.
This shall be used the planning stage of project i.e. of Project management plan. The risks the project shall identified and the appropriate mitigation and contingency plans identified under the sec 13 of PMP.
Guidelines Project Risk Management
SW/G09/1.0.0 Internal Page 2 of 12
Uncontrolled if copied/ printed
Section I - Project Risk factors:
The business benefit of project is:
-Identified, committed, and enthusiastic
-- identified or enthusiastic
The business customer level is:
-Passionate and enthusiastic
--Passive and hard to engage
-Similar experience on multiple projects
--Little experience on similar projects
--Dispersed at multiple sites
Project management processes and procedures are:
--Familiar will be utilized
--Not familiar will not be utilized
business requirements of the project are:
--Understood and straightforward
--Very vague or very complex
The system availability requirements include:
-- Windows of availability and downtime
-- Availability on a 24/7 basis
The technical requirements are:
--Similar to others in the company
The of locations deploy to is:
The number of system interfaces are:
The number of organizations this will affect is:
total estimated effort are:
The total estimated project duration is:
-- Well known by the project team
-- well known by the project team
The project is dependent on:
--Zero or one outside project or team
-- or more outside teams or projects
Business processes, procedures, policies require:
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 3 of 12
Uncontrolled copied/ printed
Changes to the organizational structure require:
The technology being utilized consists of:
-- Existing software, hardware, languages, databases, and tools
-- New software, hardware, languages, databases, or tools (or new releases)
The quality of current data is:
-- Well defined and simple to convert
--Poor or complex to convert
If a package implementation:
-- No (or minimal) is needed
-- The or release is stable
--The vendor is familiar in this market
-- Heavy customization is needed
--The product or release new to the market
-- The vendor is new to this market
Section II—Risk management strategy tables
High-risk factors/
Potential problems
Risk management activities
business benefit of the project is defined
• Project is in jeopardy of being placed on hold or cancelled if higher value work is identified
• to get resources required
• Hard to evaluate the value of the project to the organization
• Hard define scope changes in terms of cost/benefit
• Hard to know if business value was achieved when project is complete
• Try to get business customer to quantify the overall business value of the project
• Look at the major requirements try to quantify the value of the various deliverables
• Document the intangible benefit that the project will achieve
• Review prior similar projects see how the benefits were quantified
• Don’t start the project while business is undefined
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal 4 of 12
Uncontrolled if copied/ printed
scope of the project poorly defined
• Hard provide sound estimates
• May spend time and cost on areas out of scope
• Hard to gather concise requirement
• Difficult to write project definition and work plan
• Hard to invoke scope-change procedures
• Project deliverables are defined
• Focus on firming up scope in the planning process
• Define various components of scope, such as what organizations are affected, what deliverables are expected, what type of information is required
• Clearly is out scope for the project
• Begin to define business requirements at a high level and then work upward to define scope
• Ask project sponsor to decision on conflicting scope statements
• Document all scope assumptions providing of work, cost, or duration
• Use pictures or diagrams to communicate and options
• Establish firm scope-change procedures up front
• Ensure the project definition and business requirements are formally approved and signed off on
• Distribute statements all stakeholders confirmation
• Do not begin project until scope is clear
The sponsor is not identified or not enthusiastic
• Project may not the resources it needs
• Project may not have the long-term commitment needed
• Political battles may delay the project
• Issues and change requests may not be resolved in a timely manner
• Establish a strong steering to help guide the project
• Establish a process for resolving disputes between organizations
• Try to identify a different sponsor
• Ask the sponsor delegate full authority to another person who can act on behalf
• Don’t start the project
Customer level is passive/hard engage
• May point out low confidence in the business value
• Harder to get customer time and resources needed
• Harder to gather business requirements
• Customers may undermine or work against the project
• Create an aggressive communication plan to keep customers engaged and communicate the business benefit
• Create user group to surface concerns and enthusiasm
• Ask for customer participation in planning and requirements gathering
• Ask for help from the sponsor to generate excitement
• Look for to project fun settings and contexts
• Be proactive in gaining commitments for customer resources when you need them
• Don’t project
Project management experience light
• May take longer define the project and work plan
• May make more mistakes in judgment, causing rework and project delays
• More difficulty organizing and managing a complex project
• May not be familiar with sound project management practices
• May not know when to call for help
• Provide up-front project management training
• Designate a more senior to coach and mentor the project manager
• Break the project into smaller pieces that are to manage
• Put a strong quality-assurance process in place ensure the is on the right track
• Make sure the major deliverables are approved
• Utilize strong team leaders and team members to bring additional experience bear
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal 5 of 12
Uncontrolled if copied/ printed
Project is in locations
• Harder communicate effectively
• Less interaction and cohesion
• Harder to build relationship with the entire team
• Some members may feel isolated and not a part of the team
• Technology problems may result in productivity decrease
• Try to get the team one location, at least for the length of the project
• an aggressive communication plan to ensure the team communicates effectively
• Hold regular meetings where the entire team meets face-to-face
• team- activities the entire team meets face-to-face
• Have backup methods to if the primary technology fails
• Maintain contact by phone with remote team members
• Create a central repository to hold the project documentation that all team members can access
Project management processes are unfamiliar or will not be used
• Team may have a difficult time understanding how to raise issues, scope changes, and risks
• Project may get out of control as the internal processes become more complex and harder to manage
• Communication will tend to poorer
• Project deliverables might be completed in different formats
• Issues may not be addressed in a timely manner, scope changes may be adopted without thought of impact to the project, risks may be ignored, and quality may be compromised
• Chance that the project may be in trouble before it is recognized
• Provide training to the project manager and project team on sound project management processes and procedures
• Assign an experienced project management coach or mentor to the project
• Break the project into smaller pieces that can be managed with less-rigorous project management
• Define and gain approval for a set of project management procedures before the project starts, including issues management, change management, risk management, and quality management
• Create a solid communication plan to ensure everyone knows what’s going on and can provide feedback
• Solicit input on issues, risk, scope change, and quality concerns on basis
The business requirements of the project are vague or complex
• Difficult to document the requirement properly
• Difficult to use to document the requirements
• Difficult to understand what the expectations of the project are
• Chance that the resulting solution will not meet business need
• May be a sign of a lack of focus the customer
• Use joint application design (JAD) session to gather requirements from all stakeholders together
• Utilize prototyping and iterative development techniques to assist users in discovering the requirements of the new system
• Get access to the sponsor senior management to provide overall guidance
• Provide training to customers on how to think about and express business requirements
• Ensure that the final business requirements are approved in writing and that a change- management procedure is enforced after that
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 6 of 12
Uncontrolled if copied/ printed
The system availability requirements 24/7
• Downtime problems may result in productivity decreases or of revenue
• Redundancy may be needed, which increases system complexities
• Newer advanced technology may be required
• More procedures and processes are needed to maintain the system environment
• more time to analysis, design, testing, and overall quality assurance activities
• Focus extra time and energy on technology architecture
• Focus more time and energy on design
• Use industry best practices all technology and process components
• Provide appropriate training to the team so they understand the 24/7 implications on the project
• Determine exactly what portions of the system have a 24/7 requirement
• Look internal experts to overall technical design and architecture
• solid disaster procedures
• Develop a strong partnership with the hardware and software vendors
The technical requirements are new and complex
• May be difficult to understand the requirements and the implications of design decisions
• integration issues between and new technology
• May be difficulty testing the complex technology
• The more complex the technology, the greater the risk that problems will occur
• Problems with incompatible technologies may not be uncovered until integration or system testing
• Utilize system and technical design documents to clearly lay out how the technology fits together
• Define the overall system technical architecture and have it approved by knowledgeable in your company
• Send the architecture proposal to outside consultants for further feedback and validation
• Create a pilot test or utilize the new technology in a way at first
• Try to substitute more proven and familiar technology in architecture
• Utilize multiple products from the same vendor to ease integration complexities
• Use products that utilize open standards and architectures to reduce the risk of integration problems
The project data requirements complex
• Hard understand the implications of data relates
• Hard to know if and when all data elements have been captured
• More likely that some data elements will be discovered missing until system construction
• Solution may have more limited value if all required data is not present
• Solution will take longer to analyze, design, construct, and test
• Utilize an automated tool to capture data elements and the relationships
• Gain agreement on logical design before databases are built
• Gather customer approval for once they are completed
• Utilize trained data architects to help collect the data and design what the data structures should look like
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 7 12
Uncontrolled if copied/ printed
Many locations to deploy to
• May be different requirements from the different locations
• May be different procedures, processes, or technology
• May be technology problems with tying all the pieces at each location
• Technology infrastructure may be different at different locations
• Gather requirements all locations deploy to
• Make sure the sponsor agrees with any customization of process or system based on locations
• Implement at a simple site first to gain experience and modify implementation process before proceeding with all sites
• Make sure an overall architecture is in place that will flexibly accommodate all locations and any communication that take place
• sure the technical infrastructure understood at each location
Many system interfaces
• Increased of testing
• More reliance other projects or systems
• More chance for incompatibility
• Harder to down problems, errors, and bugs
• Reduce need interfaces when possible
• the of information being passed when possible
• Use as flexible a technology for the interface as (i.e., XML)
• Break the project into smaller subprojects with fewer interfaces to manage
• Work early to set expectations regarding the need for knowledgeable resources from the other systems
• Test the interfaces as early in the project as possible
• Add extra analysis to ensure the needs of the interfaces are well understood
• Include the people that support the interfaces in the official communication and status reporting
High number of organizations are affected
• Coordination more complex
• Approvals be more and lengthy
• difficult to reach consensus
• More people and groups to involve in planning and requirements
• Harder to know the major stakeholders of the various organizations
• Implementation harder and more complex
• Establish a approval process
• Create a steering committee to represent the entire stakeholder community
• Keep the sponsor engaged and ready to intervene in the organizations
• Include representative from each organization in requirements, quality assurance, and testing
• Include opportunities for people from the various organizations to meet and interact
• Work with the team on adherence to overall project objectives and priorities
• Use consensus-building techniques at all possible
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 8 of 12
Uncontrolled if copied/ printed
High number of estimated effort hours
• Implication of a high number of effort hours is that there are many people and more complexity
• Harder to communicate effectively with the team
• Bottlenecks occur when decisions are needed quickly
• More chance of people problems
• Increased of turnover
• More to train
• Use a project management tool to utilization
• Have team members utilize weekly status reports to report on progress against their assigned workplan activities
• Utilize team leaders manage sub teams
• Organize team-building activities build cohesion
• Schedule status meetings keep people of project status
• Utilize structured internal procedures scope, issue, quality, and risk management
• the project into smaller, shorter subprojects
• Reduce available project work time per person, per day to recognize additional people and team- activities
Long estimated project duration
• to manage schedule
• Easier team and the customer to drift or lose focus
• More chance that project will lose organizational commitment
• More chance business requirements will change
• More of change in software or hardware versions
• Difficult to instill sense of urgency at the beginning of project
• More chance of team and customer turnover
• Break the project into smaller, shorter subprojects
• Identify milestones to check that the project is on schedule
• Be diligent formal management procedures
• Rotate team members into different roles to keep up the interest level
• Strive to get ahead of schedule as early as possible.
• Instill a sense of urgency from the start of the project
• Organize team-building activities to cohesion friction
• Ensure all major deliverables are formally approved, so that change management can be invoked afterward
• Make technical design and architecture decisions as flexible as possible to account for potential changes
Subject matter is well by the project team
• Longer learning curve for project team members
• The project may slip behind in the early portions of the project
• sense for whether requirements sense
• Possibility that critical features or functions will be missed
• Need to initially rely on customer for all subject-matter expertise
• Take as much training as practical, as early on as possible
• Bring the key customers onto the project team
• Spend extra time understanding and documenting the requirements
• Set approval process for requirements that require multiple subject-matter experts
• Use joint application design (JAD) session to gather requirements from all stakeholders together
• Utilize more frequent walkthroughs and include the users
• Build extra time into estimates for application analysis and design activities
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal 9 of 12
Uncontrolled if copied/ printed
High on outside projects or teams
• in the other projects/teams could delay your project
• Changes to deliverable from other projects/teams could force your project make changes
• More complexity involved in requirements, design, testing, etc.
• More chance of incompatible standards, processes, technology
• More people and groups to with
• Harder to build consensus, longer time for decisions that affect multiple groups
• Be very specific defining how other projects/teams affect your project
• Be very specific on the timing for when deliverables are from other projects/teams
• Establish central contacts as the focal points of communication between the projects/teams
• Include the dependent projects/ in reports and meetings
• communicate expectations from the other projects/teams
Business processes and policies require substantial change
• Policy changes could the project
• People will be confused with new processes, which will affect their ability to utilize solution
• Possibility that new processes will not be fully integrated at first
• Possible void if new processes don’t fully cover all contingencies
• System functions may not be used if not supported by correct procedures
• Substantial change in processes may result in destructive behavior
• Document all current policies and processes ensure that they are correct
• Communicate precisely how the new processes differ from the old ones
• Communicate potential changes as far in advance as possible
• Ensure the customers defining the policy changes
• Have one person responsible for all and policy changes
• Create an aggressive communication plan to keep customers engaged and informed
• Use the new processes in a pilot test or prototype first to ensure they are workable and correct
• Include the successful implementation of new policies and processes as part of the performance criteria for managers
• Be open to customer input on process changes—for better ideas and to allow them to feel they have impact
Changes to organization structure are substantial
• Organizational uncertainty can cause fear in the organization
• People may not focus on project if they have organizational concerns
• People may fear loss of in a new organization
• People may not use the system if they are unhappy with the organizational change
• Uncertainty may cause decisions to be delayed
• Organizational change may result in decisions made for political purposes
• Document the concerns that come out of a new organization and look for ways to mitigate the concerns
• Communicate early and often about the potential for change and the business reasons for it
• Involve from all stakeholder areas in the organizational design and options
• human resources involved to deal with potential people issues
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 10 of 12
Uncontrolled copied/ printed
The project technology is new and unfamiliar (or new releases)
• Learning curve may result lower initial productivity
• May be integration problems between old and new technology
• Resistance to technology changes may cause the project to be delayed
• May be difficulty testing the new technology
• Technology may not be installed or configured correctly, which will lead project delays
• New tools can lead to longer delivery times
• New technology may substantial efforts
• System performance may be poor while expertise is gained in optimizing and the technology
• Provide much training on the new technology as practical, as as possible
• Train everyone who needs to install, use, or support the new technology
• Make arrangements to rely vendor technical specialists, when needed
• Use who familiar with the technology
• Make sure there is an adequate test environment where the technology can be utilized without affecting production
• Ensure that solid analysis is completed regarding the new technology functions, features, capabilities
• Create procedures and standards for the new technology should be utilized
• Create a test or prototype to utilize new technology in a small way at first
The quality of current data is poor and difficult to convert
• More work to the data to the new system
• Scrubbed may cause problems in the new system
• Data conversion problems can cause significant project delays
• Make sure that all the old data elements are correctly mapped to the new system
• Test the conversion process rigorously before with conversion
• Determine if the cost and trouble associated with the converted data is worth the value. Ask whether the new system start with new data only.
• the old system around for some period to the old data
• the effort to manually clean up old data as much as possible before conversion
Package implementation requires heavy customization
• Customization added to the project
• Making modifications may result in something else breaking
• Customization can lead to poor performance
• Customization can complicate migrating to newer releases
• Heavy customization may mean that the wrong package was selected
• Package will probably take longer to implement
• will more reliance on vendor
• Consider packages
• Consider custom development
• Cut on the business requirements so that customizations are not required
• Get a firm estimate of the cost and duration of the modifications from the vendor and build into your overall workplan
• Manage the vendor relationship to ensure all needed work is completed on schedule
• sure the sponsor approved the customizations being proposed
• Thoroughly test the modified package for functionality and performance
• a vendor log to track issues and milestones
Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 11 of 12
Uncontrolled if copied/ printed
Package implementation is a new product or release
• Greater of problems surfacing
• More reliance on the vendor to ensure problems are corrected quickly
• Installation, testing, and deployment will take longer
• Hard to know up front whether the package meets all the requirements
• Schedule training on the package early the project as possible
• an internal resource, or a consultant, with product experience onto the project
• Schedule a pilot test or a prototype to gain familiarity with the package before full implementation
• Establish agreements with the vendor stipulating support level and problem resolution times
• See if the project can be delayed until other companies have the product
• Seek out other companies have used the product for their feedback and key learning’s
Package implementation is from a vendor
• Possibility that vendor may not survive and leave you with no support
• Upgrades may be in jeopardy if there are not enough sales in the marketplace
• No prior relationships from which to build a quick partnership
• Legal and financial concerns may delay contracts and the project
• Make sure that agreements with the vendor be in writing
• Insist that source code be placed escrow case does not survive
• the vendor to be a part of the project team
• Maintain a vendor log to track problems with the package
• Make sure the vendor financially sound
• Establish agreements with the vendor stipulating support level and problem resolution times
Pls. refer to the guideline for preparation of PMP guideline for risk tracking.
< End of Document >
Project Risk Management
SW/G09/1.0.0 Internal Page 12 of 12
Uncontrolled if copied/ printed
