risk

Project Management and the Risk Factor

Any software development and implementation project comprises of risks. The visible risks are easy to handle or manage. Invisible risks are more vulnerable. Invisible risks are like volcanoes that can erupt without any warning and can cause more harm. More harm because we never know how severe will be the intensity of the eruption.

The same happens in software also. Risks can come from any corner during the complete project lifecycle. Developers, testers, documents, process, methodology, customer, requirement – anyone or anything can generate a risk. During a project the project manager’s critical role is to be ready for a risk and manage it without hampering the project development. Like the variance in planning of tasks and their actual occurrence decides the timely or delayed completion of project. Higher the variance, more chances are for a project getting delayed.

A similar variance is the difference between perceived risks and actual risks. All perceived risks may not happen. All actual risks may not be perceived well in advance.

10 stages of Risk in software application development and testing

A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.

Let us understand the different stages of risk in software application development and testing phase:

10. Risk Closure

Different Software Applications have different set of Risks involved

Any activity is never without risk involved in it. Risk could be classified in different categories like - low, medium or high depending on its impact, software’s requirements and purpose, software usage, and software user volume. Accordingly the risks are identified or rather perceived. Their impact is measured or assessed, and based in the category in which it falls into – its countermeasures are designed or defined. The right identification of risk is as important as its classification or category.

A classic example could be a bank application being used by all its customers for their account maintenance, for transactions and for various other purposes. The risks involved in this sort of application could be: availability of application to all its users all the time, the speed of the application, the security of transactions, the ease and comfort of usage, the user account vulnerability of hacking and so on.

Some applications required all time availability whereas other demand high performance and high availability at peak time. Say, for example there is a website of a university where the peak usage is only at the time of admission or enrollment, at the time of fee payments, and at the time of release of results. At these times the volume of this site usage will be extremely high. So not only it demands availability of application at critical or peak times but also to be ensured is that it does not crash down due to high volume of use.

So it is very important to identify the right risks, to understand the right impact size, and to derive at a right countermeasure.