How Is Risk Evaluated in a Project?
18 Apr 2017
18 Apr, 2017

The objective of risk management in web and software development, according to the Carnegie Mellon Software Engineering Institute (SEI), is to change the way of thinking of the IT department from "putting out fires" and "managing crisis" to actively staying away from problems. To make that change, IT pioneers need to incorporate risk assessment into their everyday work. 

 

As indicated by Peter Faletti, a CFO-turned-specialist, a good framework for risk evaluation involves three variables: 

 

  • - Business requirements
  • - Technology lifecycle 
  • - Project management capabilities

 

Faletti has come up with this approach based on his C-level experience in three financial institutions and saw a way to apply it in the IT sector. 

 

Business requirements risk

 

Faletti traced the failure of numerous IT projects to poorly defined requirements from the start. But the projects can steer away from business requirements even after the requirements have been identified and documented.

 

One of the common errors is the absence of the business side people in the software development just because it's an "IT project". IT leaders must fight that attitude and get business representatives involved in the project in order to reduce the risk of failure.  

 

Reports from reputable companies such as Gartner concluded that in the majority of the cases when the developers' team make corrections on the project without notifying stakeholders, the consequences lead to higher costs and, in some cases, project failure. 

 

Technology lifecycle risk

 

Faletti said that the fundamental question IT teams need to ask to make a risk assessment is - "How long will this [technology] be an effective way to solve these issues?" His recommendation is to get experts who can make an assessment of the situation in the market and calculate the likelihood that the chosen technology will become a solid base for future tweaks. Those tweaks could be as simple as adding a field to the database, or as complex as working on a merger or acquisition. 

 

When trying to assess the technology risk, try to get at least three-year outlook on the tech lifecycle. By doing this, you'll ensure the technology can be used for at least a few years after the project is completed. 

 

When trying to quantify risk, Faletti utilizes two methodologies. First one involves low-medium-high positioning to sort the scope of project risks quickly, and afterward, the high risks are deep analyzed and sorted. 

 

Project management risk

 

As a rule, the responsibility of notifying the business unit of the project problems falls on the project manager. Quite often, the team leaders choose project managers who don't have the skills or experience required for the job.

 

Make sure that the project manager is completely capable of doing the job. Sometimes a person who can oversee two small teams can't make the jump to the project that requires handling seven or eight teams. Managers with the lack of experience are more liable to make serious errors, which can range from agreeing to unrealistic commitments to neglecting to address personality conflicts. 

 

The mix of four skills is the key:
 

  • - 20 percent business knowledge
  • - 20 percent technical knowledge
  • - 30 percent communication skills
  • - 30 percent project management skills 

 

Some CEOs try to reduce the risk for big projects by choosing managers with different skills and areas of expertise to work in pair. 

 

Conclusion

 

Much of the project risk centers on communication. When the project starts, the IT team needs to form an alliance with the business team and align technical solutions with business requirements. Good communication will prevent minor errors from turning into a project failure. And that's the key to managing risk in IT projects.
 

Ready to get Started?