(updated 12/15/2013) How to Eliminate Risk from Software Engineering Projects? Uncertainty exists in every project. Where there is uncertainty there is risk. For a project, risk is an event or condition which if occur has an effect, either positive or negative, on at least one of the project dimensions. A risk event can affect scope, schedule, cost and quality of the project. There are two types of risks:
- known risks and
- unknown risks.
For a project to be successful risk management should be done early in the project planning. The plan risk management should identify the risks, perform qualitative risk analysis, perform quantitative risk analysis and plan risk responses. Defining a Risk Breakdown Structure helps to identify project risks. Typical categories where risk might occur in a project are technical, external, organizational and project management.
Shenhar (3) discusses the technological uncertainty for four types of projects: Low-Tech (ex. road building), Medium-Tech (ex. Existing product improvement), High-Tech (ex. New systems) and Super High Tech (ex. the Hubble telescope). Ways to reduce uncertainty involved design cycles and design freeze.
There are mainly three categories of risks relating to software projects:
Project Risks which affect the availability of resources or the time constrains of the project. From experience I know that usually developers are very optimistic when setting deadlines. They do not anticipate difficulties that may occur in the development phase of the project. This easily creates a problem with time and completion of the project. It has also implications with the total cost of the project.
Product Risks which affect the performance, scalability or the quality of the software under development. Again, from experience I know that is totally different a design that supports a few hundred users to one that supports simultaneously thousands of users. Creating multithreaded code and introducing locks into the system to avoid race situations involving shared resources increases the complexity of the code and complicates the testing of software components. I have more than 20 years of programming experience and I have seen good and bad quality code. I have also seen code that was fully commented, not well documented having no bugs but it was unnecessary complicated. This type of code can be spotted only from experience and the cause of it is job protection. Programmers thought that by writing code the way they did they were protecting their jobs because no one else would be able to deeply understand the code. In my opinion quality of the code cannot be counted by bugs and bug fixes as many organizations practice but with internal and external (if possible by an independent consulting firm) code reviews.
Business Risks which affect the business itself. For example a change in technology that a system assumed.
To have a plan ready to respond to risks that might occur, can save the project depending on the severity of the risk. The risks that are worst are the ones that are unknown and have an unknown outcome. There are several strategies available to reduce or control the risks:
- Avoidance. Taking proactive actions to avoid the occurrence of that risk.
- Transference. Insurance or subcontracting.
- Mitigation. Reducing the risk to an acceptable level for the organization
- Acceptance. Identifying the risk but making no plans to mitigate or avoid the risk.
- Contingency planning. Having an alternative plan to follow if a risk occurs.
- Independent verification and validation. A third-party oversees the project.
As a conclusion the most certain thing about projects is that risk factors will occur in one form or the other. Reducing or controlling the risk is a task that is performed by a team.
From experience I know that is also important to take under consideration the external environment when devising risk plans. This post is an introduction to possible risks associated with software development projects. I will continue with more in depth postings on the subject.
- Heldman, Kim (2005). Project Manager’s Spotlight on Risk Management. SYBEX
- PMBOK(2008) A guide to the project management body of knowledge. PMI 4th edition.
- Aaron J. Shenhar (2001) “One Size does not Fit All Projects: Exploring Classical Contingency Domains” Management Science, Vol. 47, No. 3 (Mar., 2001), pp. 394-414 INFORMS
- Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition.