Risk management is one of the nine knowledge areas of project management. According to PMBoK, Risk Management has a typical process flow starting from risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. This process flow has clear objectives of decreasing the probability and impact of events that could delay project delivery, and/or create a budget overdue.
Figure 1: Risk Management Process Flow
This is tailored made for traditional software development models (such as Waterfall model). But it wouldn’t sit very well for Agile SDLC if you tried to fit it in “as is”. Let us see why.
Agile methodologies are based on the premise that software development cannot be compared to manufacturing (from where the traditional project management is derived). Agile works on the concept that software development’s configuration is different and therefore, project management and its knowledge areas, such as Risk Management, too are different and should have different process flows.
For example, every software project is “unique” and not “repeatable” to be produced several times. The following table lists a few differences between configuration of software projects and manufacturing:
|Manufacturing Projects||Software Development Projects|
|Well-defined requirement||Evolving, with sketchy initial requirements|
|Production dependent on machine and tools||Development dependent on people; people are required to hard code the development; communication, individual knowledge and experience can bring about a significant difference in output.|
Table 1: Configuration Difference between Manufacturing and Software Development Projects
Agile believes that people communicate better face to face than with written documentation, and therefore stresses more on “people” part of it than on documentation. (Now, that does not mean that there is absolutely no documentation in Agile SDLC). Moreover, Agile believes in responding to change over following a plan and therefore, has a process flow that develops, tests and delivers a project in fragments.
The ideology of accommodating change requirements even at later stages of development causes Agile to rethink risks from different dimensions.
In traditional project management, the resources are spent in risk management planning process flow (refer to Figure 1 above), inferred from the visible variation between any two projects. Most of the unknown “Black Swans” are not accounted for, which may occur due to changing project requirements needed by the stakeholders.
But Risk Management in Agile projects takes a different twist when compared to how it is dealt with in traditional project management. That does not mean that Agile methodologies suggest that you just throw off the bowlines and sail away!
Agile insists on designing and coding first, and deal with risks as they emerge. When the project is delivered in small functionalities, the risks emerge as the development progresses. Often the team members identify the risks and the team as a whole discusses how to deal with it.
It leaves the team with the choice to identify the risky parts first and go for its development first. For example the risk could be in terms of judging the complexity of developing a functionality and to experiment with the estimated development velocity vis-a-vis the complexity.
So, you see there is a risk management plan that goes with Agile but its nature is different. As some experts would call it, it is more “reactive” than “deliberate”.
What is your take?
(Photo credit: www.Office.com)