Please assess each of the risk factors on a scale from 0 to 10

Corporate Environment
A climate of change in the business and organizational environment that creates instability in the project.
Mismatch between company culture and required business process changes needed for new system. A mismatch between the corporate culture and the changes required by the new system.
Projects that are intended to fail: Projects started for political reasons that carry no clear business value, but serve to divert the organization's focus from actual needed change. Such projects are underfunded, not supported, and are not Intended to succeed. Projects have no business value and are used as diversionary tactics to avoid facing the real change needs.
Unstable corporate environment: Competitive pressures radically alter user requirements, sometimes making the entire project obsolete.
Change in ownership or senior management: New owners and/or managers set new business direction that causes mismatch between corporate needs and project objectives.
Lack of top management commitment to the project. This includes oversight by executives and visibility of their commitment, committing required resources, changing policies as needed.
Lack of client responsibility, ownership, and buy-in of the project and its delivered system(s).
Failure to gain user commitment: Laying blame for "lack of client responsibility" on the project leader rather than on the users.
Conflict between user departments: Serious differences in project goals, deliverables, design, etc., calls into question concept of shared ownership.
Failure to get project plan approval from all parties.
Relationship Management
Failure to manage end-user expectations: Expectations determine the actual success or failure of a project. Expectations mismatched with deliverable—too high or too low—cause problems. Expectations must be correctly identified and constantly reinforced in order to avoid failure.
Lack of adequate user involvement: Functional users must actively participate in the project team, and commit to their deliverables and responsibilities. User time must be dedicated to the goals of the project.
Lack of cooperation from users: Users refuse to provide requirements and/or refuse to do acceptance testing.
Failure to identify all stakeholders’ vision leads project management to ignore some key stakeholders in the project, affecting requirements definition, implementation, etc.
Growing sophistication of users leads to higher expectations: Users are more knowledgeable, have seen sophisticated applications, apply previous observations to existing project.
Managing multiple relationships with stakeholders: Some "clients" are also "partners" in producing deliverables in other projects. Leads to confusion of roles and responsibilities.
Lack of appropriate experience of the user representatives: Users assigned who lack necessary knowledge of the application or the organization.
Project Management
Not managing change properly: Each project needs a process to manage change so that scope and budget are controlled. Scope creep is a function of ineffective change management and of not clearly identifying what equals success.
Lack of effective project management skills: Project teams are formed and the project manager does not have the power or skills to succeed. Project administration must be properly addressed.
Lack of effective project management methodology: The team employs no change control, no project planning or other necessary skills or processes.
Improper definition of roles and responsibilities: Members of the project team and the organization are unclear as to their roles and responsibilities. This includes outsourcers and consultants.
Poor or nonexistent control: No sign-offs, no project tracking methodology, unaware of overall project status, "lost in the woods.
Poor risk management: Countering the wrong risks.
Choosing the wrong development strategy: e.g. waterfall, prototyping, etc.
Unclear/misunderstood scope/objectives. It is impossible to pin down the real scope or objectives due to differences or fuzziness in the user community.
Changing scope/objectives: Business changes or reorganizes part way through the project.
Scope creep: Not thoroughly defining the scope of the new system and the requirements before starting, consequently not understanding the true work effort, skill sets and technology required to complete the project.
Project not based on sound business case: Users and developers ignore business requirements, develop system for sake of technology.
Number of organizational units involved: increased number of lines of communication and conflict potential expands the scope of the system.
Lack of frozen requirements. Because the needs of the users change, the requirements change. Consequently the system will never be moved into production because none of the requirements are ever completed. Alternatively, freezing a subset of the functionality and delivering allows for the completion of the system and update releases as required.
Misunderstanding the requirements. Not thoroughly defining the requirements of the new system before starting, consequently not understanding the true work effort, skill sets and technology required to complete the project.
New and/or unfamiliar subject matter for both users and developers: Lack of domain knowledge leads to poor requirements definition.
Underfunding of development: Setting the budget for a development effort before the scope and requirements are defined or without regard to them (i.e., picking a number out of the air).
Underfunding of maintenance: Support for products in the maintenance phase. If the customer is unprepared or does not budget for this, the project can be judged a failure even if successful in all other aspects.
Bad estimation: Lack of effective tools or structured techniques to properly estimate scope of work. Unrealistic cost estimates cause illogical or suboptimal planning, strategy, and decisions.
All or nothing": Requires budgeting entire project at the outset, leading to underfunding in later years of project.
Artificial deadlines. Presence of unrealistic deadlines or functionality expectations in given time period. "Crash projects" In which test time or training time is reduced— using something other than work effort required to determine when the new system should move into production.
Preemption" of project by higher priority project: Management unable to resolve conflicting schedule demands.
Development Process
Lack of effective development process/methodology: Leading to quality problems—Documentation, Software and Testing—poor estimating—insufficient time for up-front work, for example, design—little flexibility for change—insufficient testing.
Trying new development method/technology during important project.
Lack of required knowledge/skills in the project personnel: for example, technology, business knowledge, and experience.
Lack of "people skills" in project leadership: PM tries to "manage" schedules, technology, requirements, etc., ignoring that management is dealing with people on the team.
Poor team relationships: Strains existing in the team due to such things as burnout or conflicting egos and attitudes.
Insufficient/inappropriate staffing: Not enough people or people with wrong skills/insufficient skills assigned to project, regardless of availability.
Staffing volatility: At some point in the project, losing the key project manager, analysts or technicians (especially in new technology).
Excessive use of outside consultants: Can lead to a conflict of interest, for example, billable hours vs. budget, or resulting in the internal staff not having significant involvement
Lack of available skilled personnel: People with the right skills are not available when you need them.
Introduction of new technology: Using new, or "bleeding edge," technology that has not been used successfully at other companies, or major technological shift occurs during the project.
Stability of technical architecture: Has to be done before comparable applications.
External Dependencies
External dependencies not met: The project's consultants or vendors do not deliver, go out of business, or are unclear as to their roles and responsibilities.
Multi-vendor projects complicate dependencies: Integration of packages from multiple vendors hampered by incompatibilities and lack of cooperation between vendors.
Lack of control over consultants, vendors, and subcontractors: Schedule or quality problems beyond control of project manager. No legal recourse due to poor contract specification.
No planning or inadequate planning: Attitude that planning is unimportant or impractical.