SPI Risk Assessment
Allan Baktoft Jakobsen Delta, Denmark, baktoft@mindmate.com
The assessment will take 1-2 hours to complete and the aim is to obtain enough information about the project during the meeting to be able to list a few but precise bullets of feedback at the end. It should be emphasized that the assessment is not meant to give an objective or scientific measurement of the risks. The purpose is to facilitate a systematic discussion with the project in order to successfully address the risks and to reduce the resistance against improvements.
Figure: Create and control processes in a project.
In most projects, in particularly software projects, two fundamental processes can be recognized:
For a PIE i.e. a Process Improvement Experiment (an ESSI term for a project working with software process improvements), we have
Examining the following generic process model, three different points of view can be identified:
Figure: Three points of view in the generic project model.
These are:
The Task: This point of view focuses on the concrete inputs and outputs of the project. The ultimate output of the project is usually the product itself, but during the development a lot of sub-inputs and sub-outputs or internal deliveries are present. The Task often have primary interest of the management and sales people since the (external) inputs and outputs usually involves interacting with customers. Questions about the task are usually What-questions.
The Process. This point of view focuses on the transformations of inputs to outputs. If the transformations can be generalized and described in an abstract form independent of the concrete input and output in order to be reused we have the concept of a process. If the task focused on the starting point A and goal B of the projects, the process is about the map of the way from A to B. Questions about the process are usually How-questions.
The Resources: This point of view sees the project in terms of the people of flesh and blood who play the roles defined in the process. Questions about the resources are usually Who-questions.
A baseline project can be systematically examined in the frame of these three points of view.
Input: Documents and people from the project.
Transformation: Questions in the frame of the TPR model. Evaluations of answers.
Output:
When the questions for a given area are asked and discussed, the assessor makes for himself a quick decision regarding the following question:
Figure: TPR diagram for assessing the baseline project.
When the 9 marks have been plotted into the TPR diagram, they are connected to a polygon. A discussion of the findings can now begin:
The faces of the TPR triangle, that is, the relations between T-P, T-R, and R-P, are sometimes called the dimensions of Management, Leadership, and Dedication, respectively. How does the company value these dimensions when decisions are to be made?
Improving processes and changing in general has little to do with technology but a lot to do with human beings. So the PIF diagram is about them. People in relation to change can be assessed from three different points of view: As individuals, as groups, and as organizations. This is the essence of the diagram.
Figure: PIF diagram for assessing the improvement project.
Input: Information from the people from the project.
Transformation: Questions in the frame of the PIF diagram. Evaluations of answers.
Questions on individuals Management commitment
Are the decisions driven by: The individuals, the groups, or the organization? What level of capability maturity do you suspect of the company?
After the meeting with the SPI project the assessors discuss the results of the TPR and PIF diagrams.
An ordinary SWOT (Strengths, Weaknesses, Opportunities, Threats) list with 5-6 bullets is produced and mailed to the project.
Experiences with TPR-PIF
Anyone who has been involved in software process improvements know how difficult it can be. Many times the battle of convincing/persuading the project managers and the developers to go on is not really won. Pressure from top management cannot avoid people resisting the proposed changes.
Resisting change is a key area of SPI work and although the reasons for this phenomenon is fairly well understood, it is seldom systematically counter-measured. In fact, it's all about insecurity and fear of loosing control - in other words, a very human reaction.
The TPR-PIF method has been successfully used by DELTA in Copenhagen, by FZI in Karlsruhe, and on Iceland. These companies are all EspiNodes in the ESSI program. The number of assessed projects (PIEs) is currently about 20. The method is still being refined.
As mentioned earlier, the assessment is not an attempt to measure the risks in any quantitative way. The main purpose as we have seen it in practice is that it opens up for a qualitative yet highly structured discussion of the risks of carrying out improvements. The awareness and overview of the potential risks have a double purpose. First, to reduce the total risk of baseline project failure and second, to reduce the resistance against the improvement project due to insecurity and lack of knowledge
In the interviews we have noticed the effect of discussing the problems of both the baseline project and the improvement project from the various points of view. The frame provided by the TPR-PIF method ensures that most of the important topics are covered. Moreover, the final summery using few very simple kiviat diagrams is an excellent way of sharing the overview of the current situation. If done properly, key insight can be gained here.
Traditionally, risk analysis is hard. Project managers say that this is what they are doing all the time. Developers say that there are two kinds of risks: The ones you can do something about and the ones that are simply out of your sphere of power and control. The first ones occupy most of your time.
Thus, in a hectic software project, all the things to do and to be aware of soon seem overwhelmingly many. Proposing process improvements on top of all that is bound to provoke resistance. The TPR-PIF method helps by bringing in the overview that is blurring the intellectual control of the project. This means reducing the insecurity in the project by increasing the knowledge of the real problems.
References: