Most Software Project Managers have to deal with situations, which unless tackled within a specified time have a high probability of leading to disaster. In Software Project Management, disaster can be defined as a failure of Project delivery within the pessimistic deadlines or pessimistic cost limits. Disaster may also be defined as delivery of highly bugged Software to the Client within the pessimistic cost and schedule limits. As the project goes through various phases of the life cycle, the SPM has to decide on a Course of Action (COA) from alternative options, so as to tackle crisis situations. There are many events within the lifecycle, which unless nipped in the bud, may lead to crisis or even disasters. The SPM needs to identify such events and take corrective or even preventive measures to tackle such events.
Crises and Disasters in Software Project Management
Crisis is defined as a crucial stage or turning point, which implies fairly compressed period of time. Although Risk Management is part of project planning and management, it is carried out in an ad hoc manner based on Project Manager’s experience. This experience is usually limited and SPM is generally unaware of dealing with crisis situations. This may lead to pronounced negative effects on the project execution. Risk (R) of an event has been defined as the product of probability of occurrence (p) and consequences (q), i.e.,
R = p x q (1)
High-risk events can lead to crisis situations. Therefore events with high probability of occurrence or with grave consequences or both may be identified as Crisis Events. The idea of crisis management is that when the high-risk event actually occurs or is about to occur, it can be deciphered. However, due to the compressed reaction time available it becomes difficult to respond appropriately to avoid crisis or disaster. In this regard, it is extremely important for the SPM to make decisions, which are not only effective but are taken at a rapid pace under extreme pressure conditions.
We define Crisis Index associated with a risk as
CI = (p/tp) x (q/tq) (2)
Where, tp is the time taken by the crisis conditions to lead to the crisis event and tq is the time taken after the event has occurred and the occurrence of consequences or impact.
From (1) and (2)
CI = R / (tp x tq) (3)
In effect the Crisis Index is inversely proportional to the reaction time available to the respondent. Lesser the value of reaction times higher the value of CI.
Thus while carrying out risk assessment, it is not only important to compute Risk (R), but its imperative to evaluate the Crisis Index (CI) of the events as well. The CI will give a true picture of grave consequences that are possible with occurrence of each event as it incorporates the reaction time. Some of the Risk factors, and Crisis Avoidance and management strategies are listed in the table below.
However, CI’s give only a static indicator of the possible Crises in the SDLC. Various strategies for dealing with the crisis situations should be understood and evaluated in a dynamic situation. The SPM unless put in a dynamic situation wont be able to understand the intricacies involved. To understand the dynamics of crisis situations and to train the SPM to deal with such situations we propose the design of Crisis Games for training SPM.
Why Crisis Gaming?
Penetrating the shadowy and complex intersection between psychology and decision maker remains a key analytic challenge. To address the organizational psychology of crisis management in many socioeconomic, sociopolitical, politico-military and industrial disasters and crisis situations, technique of role-playing simulations have been proposed and used. When properly done, such games offer a close approximation of the stress and flow of events of a real world crisis, saturating the participants – often more than they anticipated or desired – with policy conundrums and quick demands. Games can provide a realistic portrayal of various stumbling blocks in crisis resolution.
The Software Project Manager (SPM) requires a framework on a scientific footing to come up with possible strategies for coping up with various crisis situations. This requires a thorough understanding of possible crisis situations, how these may be avoided and how to manage them.
The Crisis Gaming Methodology provides such a framework for the SPM to explore future situations and to create strategies on a rational basis. Games provide a form of laboratory in which to observe the activities of individuals or groups in simulated crisis. These games use the standard simulation techniques such as Monte Carlo or Discrete Event Simulation for generating virtual crisis situations for creating near real life experience for the SPM.
Crisis Gaming for Software Project Managers
The Game can be designed as a two terminal game – one terminal each for the SPM and expert respectively, or it can be designed as a single terminal game. Although the two- terminal game is easier to design, its usage requires the availability of SPM and trainer at the same time. The single terminal game with automated Trainer may have more value in terms of its usage, but is more difficult to design.
The flowchart shows the sequence of flow in a crisis game. A scenario about the project, client requirements and resources is painted in qualitative terms for the SPM (the trainee). There is usually a library of multiple project scenarios that is kept beforehand. This may contain information of past projects executed by the organization or may have completely new situation described by the expert (the trainer).
Various Risk events possible in the SDLC based on the scenario, project features and SDLC are identified before hand. Their CI’s as described by equation (3) are also computed. Based on the resources available to the SPM and scenario the Performance Indicators are identified. The Performance Indicators (PI) may be qualitative or quantitative as per the preference of trainer. Sometimes the initial values of PI are estimated on a qualitative basis. These are converted to numerical values using a well-established quantitative scale.
The SPM is asked to indicate his Course of Action (COA) along with the effort estimation and effort distribution. The COA is evaluated in terms of impact on PI values. The game structure defines linkages between various Scenarios, Initial PI values, Likely events during the execution of the project, likely events due to chosen COA and certain random events corresponding to the scenario. The CI’s as computed earlier are used to estimate the time and consequences of occurrence of high- risk events.
As the COA is chosen the project execution is simulated. The project goes through various phases and milestones of the chosen SDLC model, which are pre-established. As the project goes through the simulated time, the events linked to chosen COA, linked to the scenario and random events keep on occurring. The occurrence of each event modifies the performance indicator values of the project and SPM. As the event occurs the SPM is given a chance to redistribute his resources and allocation of tasks as per his plan and changing scenario. The time given to the SPM is in accordance with the reaction time estimated for all events, which has been used while calculating CI. This cycle is repeated till the game termination condition occurs which usually is the end of SDLC or pessimistic project deadline estimated by the trainee or stored in the scenario database beforehand by the trainer.
Once the game is over the SPM, the trainer and other experts undergo a post game analysis phase, where all the COAs and Scenarios are evaluated. It is of paramount importance, however, that game post mortem sessions must not become only faultfinding sessions. It should be a group discussion to carve out various lessons from the whole exercise.
Major benefit is that SPM gets trained under simulated pressure conditions rather than learning on live projects where the cost of such learning may be enormous. As the Crisis Gaming Methodology is proliferated throughout the organization, lessons from multiple games may be collected and collated t o establish a process for Software project planning in the long run. This whole procedure is likely to reduce costs and effort compared to the lessons learned on the live projects.