EuroSPI99 
Learn from the Past - Experience the Future
European Software Process Improvement
SPI and Assessments
Category Index
Rated Newspaper Supported by EU Project 

SPI Risk Assessment

Allan Baktoft Jakobsen
Delta, Denmark, baktoft@mindmate.com
 

Abstract

Supporting SPI projects successfully requires detailed information about the project, and precise and quick feedback to the project. The TPR-PIF assessment method is designed to be used at a preliminary risk assessment meeting as a basis for further support. It has already been used by several companies participating in the European ESSI program.

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.
 

PIE project and Baseline project

The following model is the frame for the TPR-PIF method.


Figure: Create and control processes in a project.

In most projects, in particularly software projects, two fundamental processes can be recognized:

These two projects are obviously equally important.

For a PIE i.e. a Process Improvement Experiment (an ESSI term for a project working with software process improvements), we have

Thus, the changes initiated in the Improvement project should interact with the Baseline project, and hopefully lead to a better overall project.
 

Assessing the Baseline project using the TPR diagram

The TPR (Task-Process-Resources) model is developed by Allan Baktoft Jakobsen [IEEE Software Jan/Feb 1998] to provide a framework for capturing the various knowledge about a software project.

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.
 

The TPR assessment process

The TPR assessment process is the following:

Input: Documents and people from the project.

Transformation: Questions in the frame of the TPR model. Evaluations of answers.

Output:

Examples of questions are listed below. There are 9 groups of questions corresponding to the 9 areas of the TPR diagram. The list is not complete. It depends on the assessors feelings and knowledge of software development to ask the optimal questions.

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:

Task questions – General Task questions – Input Precision Task questions – Simplicity Task questions – Opportunities for success Process questions – General Process questions – Work break-down Process questions – Coordination Process questions - Transformation Resource questions – General Resource questions – Role precision Resource questions - Motivation Resource questions – Output precision Overall triangle

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?
 

Assessing the Improvement project using the PIF diagram

The PIF (Process Improvement Footprint) model was proposed by Chuck Myers and Suzanne Garcia at the E-SEPG 98 conference in London and slightly restructured by Allan Baktoft Jakobsen.

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.

The PIF assessment process

The PIF assessment process is the following:

Input: Information from the people from the project.

Transformation: Questions in the frame of the PIF diagram. Evaluations of answers.

Output:

When the 9 marks have been plotted into the PIF diagram, they are connected to a polygon. A discussion of the findings can now begin. Again: Below the areas of questions are listed.

Questions on individuals – Management commitment

Questions on individuals – Change Agent skills Questions on individuals – Technical skills in SPI Questions on groups – Resistance Questions on groups – Resources Questions on groups – Change success history Questions on the organization – Organizational push Questions on the organization – Culture Questions on the organization – Opportunities for success Overall triangle

Are the decisions driven by: The individuals, the groups, or the organization? What level of capability maturity do you suspect of the company?
 

Final assessment: TPR and PIF results combined


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 (PIE’s) 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:

  1. Allan Baktoft Jakobsen: Bottom-Up Process Improvement Tricks, IEEE Software, Jan./Feb. 1998, pp. 64-68.
  2. Allan Baktoft Jakobsen: Over My Dead Body, The SPIDER Kourier, October 1999.
  3. Chuck Myers, Suzanne Garcia: SEPG SkillShop: Building Your Process Improvement toolkit. E-SEPG 1998.
  4. Gerald Weinberg: Quality Software Management Vol. 3: Congruent Action. Dorset House 1994.
  5. Gerald Weinberg: Quality Software Management Vol. 4: Anticipating Change. Dorset House 1997.
  6. Watts S. Humphrey: Managing Technical People. Addison-Wesley 1997.
  7. Susanne Kelly: The Complexity Advantage: How the Science of Complexity Can Help Your Business Achieve Peak Performance. McGraw-Hill 1999.
Allan Baktoft Jakobsen has an educational background in mathematics and physics from Copenhagen University and Dartmouth College. He has been working in the software business with maintenance, design, coding, test, quality assurance, and as an SEPG member. He has recently founded his own company, MindMate, counseling best software practices and process improvements. Contact Jakobsen at baktoft@mindmate.dk.


Partners in EuroSPI

Editors
ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland, office@iscn.at, office@iscn.com, office@iscn.ie, Editing Done: 19.7.2002