Project Risk Assessment Questionnaire Template Page 13
ADVERTISEMENT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15Put your
Project Risk Assessment Questionnaire Template
Put your
Rev. 2.0, 09/07/2003
logo here
organization
name here
Section II
Typical High-Risk Problems/Response Actions
High-Risk Factors/Potential Problems
Risk Response Actions
H2. The technical requirements are new and complex:
Utilize system and technical design documents to
clearly lay out how the technology fits together
May be difficult to understand the requirements and the
implications of design decisions
Define the overall system technical architecture
and have it approved by knowledgeable people in
May be integration issues between old and new technology
your company
May be difficulty testing the complex technology
Send the architecture proposal to outside
consultants for further feedback and validation
The more complex the technology, the greater the risk that
problems will occur
Create a pilot test or prototype to utilize the new
technology in a small way at first
Problems with incompatible technologies may not be uncovered
until integration or system testing
Try to substitute more proven and familiar
technology in the 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
H3. Subject matter is not well known by the project team:
Take as much training as practical, as early on as
possible
Longer learning curve for project team members
Bring the key customers onto the project team
The project may slip behind in the early portions of the project
Spend extra time understanding and documenting
No sense for whether business requirements make sense
the requirements
Possibility that critical features or functions will be missed
Set up approval process for requirements that
require multiple subject-matter experts
Need to initially rely on customer for all subject-matter expertise
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 the estimates for application
analysis and design activities
I.
Performance
I1.
Performance objectives are unclear or unstated or unrealistic
Make sure that all performance objectives are in
(e.g. everything will be perfect)
writing, agreed to by the project team and
approved by the Sponsor
The project team may be bogged down trying to meet minor
performance objectives while the major ones are slipping away
Insist that any change in expectations regarding
performance objectives be issued as a formal
The team may be subject to imposition of new performance
Change Request
requirements during the project if they are not written down at the
start
This could be a no-win project since it is not possible to meet
unrealistic objectives
Put your organization name here
Page 13
ADVERTISEMENT
0 votes
Related Articles
Related forms
Related Categories
Parent category: Business