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:


Characteristics

Low risk

Medium  risk

High risk
The business benefit of project is:
-Well defined
-
--Poorly defined
The scope of project is:
-Well defined
-
--Poorly defined
The project sponsor is:
-Identified, committed, and enthusiastic
-
-- identified or enthusiastic
The business customer level is:
-Passionate and enthusiastic
-
--Passive and hard to engage
The project manager has:
-Similar experience on multiple projects
-
--Little experience on similar projects
The project team is:
-Located together
-
--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
-
--New complex
requirements are:
--Simple
-
--Complex
The of locations deploy to is:
--One
-
-- than four
The number of system interfaces are:
--One or none
-
--More than five
The number of organizations this will affect is:
--One or two
-
--More five
total estimated effort are:
--Less 1,000
-
--Greater 5,000
The total estimated project duration is:
-- Less three months
-
-- Longer than one year
The subject matter 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:
--Little or no change
-
-- Substantial change



















































































Guidelines for Project Risk Management
SW/G09/1.0.0 Internal Page 3 of 12

  Uncontrolled copied/ printed
Changes to the organizational structure require:
-- or no change
-
-- Substantial change
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