Risk Categories

Risk Categories

The project risk management plan models 12 categories of potential risk to any specific project:

1. Mission and goals. Any project accepted must fit within the organization's mission and goals. Projects accepted that do not fit within the organization create tensions that affect all projects. For instance, suppose an organization exists whose mission is to develop software for internal corporate manufacturing and whose goal it is to produce the most effective, custom software for the organization's factories. If the organization were to accept a project to build a general-purpose software package to be sold commercially, this would be very risky because it goes against their current mission and goals.

2. Organization management. Any project chosen must be buildable within the current or planned organization. A disorganized or non-existent organization cannot succeed in delivering a software project. An example of this risk is a sales organization that closes a development project with no input from the executing organization. The project is "thrown over the wall" to a development organization that has no team available and no process for building the type of system sold.

3. Customer. All projects must have a strong customer commitment to its success. A software development project requires extensive input from the customers and end-users. Without this input, the best development process will only produce a system that works well but may not meet the end-users real needs. The risk here is that it assigns inexperienced people to the development team who do not have adequate problem domain experience to guide the technical trade-offs required for the software developers.

4. Budget/cost. This category is the one that generally gets the most attention and is affected by all other categories. Project managers focus on the budget and cost because these are the most extensively used measurements of a project's success. Understanding project size, having good historic information on similar projects, and completely understanding the external influences, such as technology, are the main ways to reduce this category's risk.

5. Schedule. The greatest risk here is that schedule dates are imposed externally from the development team. If the development team does not have any input into the completion and delivery dates for the project, there is very little chance that the schedule will be met. Software development teams must be a part of developing and modifying the project schedules.

6. Project content. All projects generate artifacts that are in addition to the final and contracted for deliverables. One of the major components is documentation of requirements, design, and the target system in which the software will reside. If this information does not exist, is in error, or is inconsistent the risk is very high that project knowledge will be lost and the schedule or product content will greatly suffer.

7. Performance. These risk factors are related not to particular, delivered system execution times, but to key software development criteria. Some of the major risk areas here are related to performance of the system during testing. The ability to do complete coverage testing of all modules and their interfaces is critical. Inadequate testing is a contributor to project failure.

8. Project management. This category relates to both the management processes for the project and to the project manager. Risk exists not only in the lack of, or inadequacy of, management processes, but in the experience level of the project manager. It is not true that a good project manager can manage any project. Project managers need domain experience and understanding of project management processes.

9. Development process. This category focuses on the processes that reduce overall risk and improve delivered-product quality. Development processes are not concerned with specific tools such as programming languages, tool builders, or code generators. They focus on configuration management processes, quality assurance practices, and analyses of alternatives.

10. Development environment. This category focuses on the physical environment of facilities, hardware platforms, and software development tools. Risk is present in not only the lack of adequate tools, but in inadequate facilities. Not having a colocated team, or not having enough meeting space, customer interviewing space, and workrooms greatly increases risk. Teams need face-to-face contact on a regular basis.

11. Staff. This category is one area where risks can be greatly reduced by having an experienced and proven high-productivity software development team. A highly productive team can be 10 to 25 times more productive than an average team. Not being sure of the abilities of the team or its experience with the problem domain necessitates a very conservative approach to the risk factors in this category.

12. Maintenance. This final category attempts to quantify software risk after the product is delivered. The project development team is often responsible for software maintenance for a period of time after delivery. If this is not the case, project risk increases from having inexperienced people try to fix bugs in the software. Tools used for development need to be available for maintenance. Vendor support after delivery is a risk issue if there has been no plan or budget for continued tool-maintenance support.


software project, development process, project schedules, budget
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus