EuroSPI 2000 
Practical and innovation based software process improvement to prepare for the new millenium.
European Software Process Improvement
SPI implementation
Category Index
Rated Newspaper Supported by EU Project 

 
 
 
 
 

Avoiding Failure in SPI Initiation
 

Pouya Pourkomeylian
AstraZeneca R&D Mölndal, S-431 83 Mölndal, Sweden
Tel: +46 31 776 17 96, Fax +46 31 776 37 30
Viktoria Institute, Box 620, 495 30 Göteborg, Sweden
Pouya.pourkomeylian@astrazeneca.com

Abstract
Software Process Improvement (SPI) is a recognised systematic approach for improving the capability of software organisations. Such initiatives have however proven to meet with a number of difficulties such as: scaling the SPI initiatives, setting realistic goals, the complexity of organisational changes, and the organisational culture. For organisations with no earlier experience with SPI, the first initiative might therefore run the risk of being the last.
This paper shows the results of a case study in which the first SPI initiative in an organisation was analysed according to two frameworks: first a framework that maps the characteristics features of SPI and second a framework that describes SPI as a knowledge creation process. On the basis of our findings we argue that the first SPI initiative: 1) should be a learning process focusing on learning SPI practice, 2) should satisfy organisational goals rather than routinely follow a normative model for reaching any maturity level, and 3) should be organised as a project aiming to improve a few software processes based on practitioners’ ideas. These insights are compared and contrasted with the established knowledge on how to initiate SPI activities.

Keywords: SPI Initiation, Knowledge Creation.
 
 

1. Introduction

Software Process Improvement (SPI) is a systematic approach to improve software processes in organisations. This approach was developed by the Software Engineering Institute (SEI) inspired by the work of Watts Humphrey [1]. The basic idea of SPI is to focus on software processes as social institutions with a complex interplay of people, methods, tools, and products [2], figure 1.
SPI initiatives start with an assessment to identify organisations’ current software process problems. The improvement activities should then be planned and performed on the basis of the assessment’s findings and other goals of the organisation. The improved new software processes should then be institutionalised in the whole organisation to become a part of the practitioners’ daily work. Many organisations have been inspired by the concept of SPI and started SPI initiatives. However achieving success with SPI has been shown to be a difficult challenge for many organisations. Many organisations do not succeed in performing their improvement activities, others have difficulties with implementation of new processes in the organisation [3]. Different factors such as scaling the SPI initiative, setting realistic goals, the complexity of organisational changes, and the organisational culture have made it difficult to achieve success in SPI initiatives [4], [5], [6], and [7]. For an organisation with no earlier experience in SPI (a novice organisation), the first initiative might therefore run the risk of being the last. Therefore, it should be crucial for such an organisation to find answers to some key questions before starting an SPI initiative: What are the most characteristic features of the first SPI initiative? How should a novice organisation organise, plan, and conduct an SPI initiative? Does a novice organisation have a fair chance of succeeding in its first SPI initiative?

Figure 1: A complex interplay of people, methods, tools, and products.

According to Aaen et al. [8], organisations that start SPI efforts should find inspiration and guidance in the literature. They argue that these organisations should avoid the pitfalls that have led to failure in other organisations and should learn from successful initiatives that have bearing on their own situation. However, following this advice is not easy: the SPI literature is extensive and is growing and there are no authoritative sources outlining the underlying rationale of the SPI [8]. A large body of knowledge about SPI has become available during the last years, including specific models [9], [10], concepts to support practical use of the models [11], [12], experience reports [4], [7], and critical evaluations [13]. A survey of SPI literature and a MAP of the key ideas in SPI are presented by Aaen et al [2]. They provide a conceptual MAP of software process improvement which describes three fundamental concepts of SPI approach including nine ideas, i.e. the management of SPI activities, the approach taken to guide the SPI initiatives, and the perspective used to focus attention on the SPI goals. The MAP also addresses the following questions: 1) What are the characteristic features of SPI initiatives? How do SPI initiatives compare with other improvement approaches? 3) What are the key benefits and risks related to SPI initiatives?
Using the MAP, this study tries to analyse one SPI project done as the first SPI initiative in a novice organisation. The main question in this paper is: Which were the crucial features in successfully initiating this SPI project? It is hoped that this analysis will help other novice organisations to find ways to increase their chances of success and minimise the risks of failure.
 
 

2. Research Approach

This study uses a case study approach to analyse and map an SPI project performed as the first initiative in a novice organisation. Case studies are particularly useful for an understanding of some special subject in great depth and where one can identify cases rich in information, rich in the sense that a great deal can be learned from a few examples of the phenomenon in question [14]. This approach was chosen for this study because of its strength in focusing on the case and its ability to provide techniques to structure the research process and its findings.
The SPI initiative was carried out from April 1999 to May 2000 and aimed to improve the software organisation’s software processes. This paper does not include the activities related to the implementation of new processes within the software organisation. The author has been the driving force behind the SPI initiative and has actively participated in activities to initiate, organise, plan, and conduct the SPI initiative during the one-year period. In this study the author reflects on the SPI initiative and tries to make conclusion about, lessons useful for understanding the field of SPI and support the practice of the first SPI initiative in novice organisations.
The next section discusses the knowledge creation and learning concepts and SPI’s characteristic features. Section 4 presents the case. Section 5 presents the results of the SPI initiative analysed and discusses the findings according to the research question stated above and section 6 concludes the paper by presenting the lessons learned and pointing out areas for further research.
 
 

3. A Theoretical Framework

This section presents a brief description of the two frameworks used to analyse the SPI initiative.
 

3.1 Knowledge Creation and Learning

Nonaka and Takeuchi [15] use two dimensions of knowledge creation to explain the process of organisational knowledge creation: 1) the ontological and 2) the epistemological. The ontological dimension focuses on individual knowledge creation. The organisation supports creative individuals or provides a context for them to create knowledge. Organisational knowledge creation is therefore understood as a process that “organisationally” amplifies the knowledge created by individuals and crystallises it as a part of the knowledge network of the organisation. This process takes place within an expanding “community of interaction”, which crosses intra- and inter-organisational levels and boundaries. For the epistemological dimension Nonaka and Takeuchi [15] draw on Michael Polanyi’s [16] distinction between explicit knowledge and tacit knowledge. Explicit knowledge refers to knowledge that is transmittable in formal, systematic languages. It can be articulated in formal languages including grammatical statements, mathematical expressions, specifications, manuals and so forth. It can be transmitted across individuals formally and easily. Tacit knowledge is personal and context-specific and therefore difficult to formalise and communicate. It is personal knowledge embedded in individual experience and involves intangible factors such as personal belief, perspective, and the value system. Tacit knowledge is difficult to communicate and share within the organisation and must thus be converted into words or numbers that everyone can understand.
Nonaka and Konno [17] describe two dimensions to tacit knowledge. The first is the technical dimension, which encompasses the kind of informal personal skills or crafts often referred to as “know-how”. The second dimension is the cognitive dimension, which consists of beliefs, values, ideals and mental models that are deeply ingrained in us and that we often take for granted. They argue further that this cognitive dimension of tacit knowledge shapes the way we perceive the world and creates our understanding of it. According to Nonaka and Takeuchi [15] the organisational knowledge is created during the time the “conversion” takes place, i.e. from tacit to explicit and back again into tacit. The interaction between these two forms of knowledge is the key dynamic of the knowledge creation in the organisation.

3.1.1 Knowledge Conversion

Knowledge conversion is a “social” process between individuals and not confined within an individual. Assuming that knowledge is created through the interaction between tacit and explicit knowledge, four different modes of knowledge conversion are possible (Figure 2). The contents of the knowledge created by each mode of knowledge conversion is naturally difficult, which create different contents of knowledge [15]:

Figure 2: Contents of knowledge created by the four modes [15].

1. From tacit knowledge to tacit knowledge (socialisation which creates sympathised knowledge). The socialisation mode usually starts with building a “field” of interaction. This field facilitates the sharing of members’ experiences and mental models. Socialisation involves the sharing of tacit knowledge between individuals.
2. From tacit knowledge to explicit knowledge (externalisation which creates conceptual knowledge). The externalisation mode is triggered by meaningful “dialogue or collective reflection,” in which using appropriate metaphor or analogy helps team members to articulate hidden tacit knowledge that is otherwise difficult to communicate. Externalisation requires the expression of tacit knowledge and its translation into comprehensible forms that can be understood by others.
3. From explicit knowledge to explicit knowledge (combination which creates systematic knowledge). The combination mode is triggered by “networking” newly created knowledge and existing knowledge from other groups in the organisation, thereby crystallising them into a new product or service.
4. From explicit knowledge to tacit knowledge (internalisation which creates operational knowledge). “Learning by doing” triggers internalisation. The internalisation of newly created knowledge is the conversion of explicit knowledge into the organisation’s tacit knowledge. In practice, internalisation relies on two dimensions. First, explicit knowledge must be embodied in action and practice. Second, there is a process of embodying the explicit knowledge by using simulations or experiments to trigger learning by doing processes.

3.2 The most characteristic features of SPI

To have a better chance of succeeding with SPI efforts an organisation must understand the most important key ideas in SPI. Understanding SPI includes knowing: 1) what elements affect the SPI initiative, 2) how to organise, plan, and take action to make SPI happen and 3) how to institutionalise the new processes within the organisation.
Aaen et al. [2] present a map structured mainly on the basis of theoretical insight in the SPI literature and experience in practising SPI in close collaboration with software organisations and describe the characteristic features of SPI initiatives. According to these authors SPI is based on a number of ideas that offer specific answers to specific concerns. SPI has three fundamental concerns: the management of SPI, the approach taken to guide the SPI initiatives and the perspective used to focus attention on the SPI goals. Table 1 contains a survey of the MAP described by Aaen et al. [8] and provides an overview of the key ideas involved in SPI. The table gives information about alternatives, opportunities, and risks related to SPI initiatives.
 
Concern Idea Aspiration Pitfalls
Management of SPI  Organisation Dedicated and adapted effort Inadequate resources, emphasis and co-ordination
Plan Plan goals, activities, responsibilities and co-ordination  Loss of motivation. Diversity or deadlock
Feedback Measure and assess benefits Opportunism, and loss of relevance
Approach to SPI Evolution Experiential learning and stepwise improvement Wearing and inertia
Norm Seek dedication and legitimacy Hastiness and fundamentalism
Commitment Ensure dedication and legitimacy  Goal deflection and gold plating
Perspective in SPI Process Integrate people, management and technology Disinterested customers
Competence Empowerment through competence building Turf guarding
Context Establish sustainable effort Machine bureaucracy

Table 1 : The SPI MAP with aspiration and pitfalls [8], p 2.

Based on their concept the management of SPI initiatives builds on three ideas: 1) the SPI activities are organised, 2) all improvement efforts are carefully planned and 3) feed-back on effects on software engineering practices are ensured. The approach to SPI initiatives is guided by three additional ideas: 1) SPI is evolutionary in nature, 2) SPI is based on idealised, normative models of software engineering and 3) SPI is based on a careful creation and development of commitments between the actors involved. Finally, the perspective on the SPI goal is dominated by three ideas: 1) SPI is focused on software processes, 2) the practitioners’ competencies are seen as the key resources and 3) SPI aims to change the context of the software operation to create sustainable support for involved actors.
 
 

4. The Case

This study was conducted at AstraZeneca, one of the world’s leading pharmaceutical companies. AstraZeneca is a research-driven organisation with a formidable range of products designed to fight disease in important areas of medical need. The company was formed in April 1999 by the merger of Astra AB and Zeneca Group PLC. AstraZeneca has a strong research base and powerful product portfolio, designed in seven areas of real medical need – cancer, cardiovascular, central nervous system, gastrointestinal, infection, pain control and anesthesia, and respiratory. AstraZeneca is world number three (1999) in ethical pharmaceuticals and has more than 50,000 employees world-wide. There are research and development (R&D) centers of excellence in Sweden, UK and the USA and R&D headquarters in Södertalje, Sweden. The company has some 10,000 R&D personnel and a US $2 billion R&D investment in 1999, extensive global sales and marketing network, employing over 25,000 people, and 12,000 people employed in production in 20 countries.
 

4.1 The Software Organization

AstraZeneca has four departments that supply global IT services to the whole company: one in the UK, one in the USA, one in Sweden and one to provide IT support for research and development for the whole organisation. In addition to this, there are five global supplier managers who have the responsibility of controlling the needs of IT services in the business functions in the company. Furthermore, there is a company staff with central IT departments for solving problems related to technology adoptions, infrastructure, security, integration, and strategies. Beyond all this, there are IT functions that support the local marketing company in the respective countries. There are in total 2,500 persons working with IT-related questions in AstraZeneca.
This research started before the merger between the two companies in an IS organisation called Clinical Research and Information Management (CRIM) at the former Astra Hässle in Sweden and continued later in the new IS organisation, which then changed its name to Development IS (DevIS). DevIS supports clinical and pharmaceutical projects, Regulatory Affairs and Product Strategy and Licenses at AstraZeneca R&D Mölndal. DevIS is also responsible for influencing the development of the global clinical research processes and IS/IT tools in AstraZeneca. DevIS comprises 90 people including contractors, most of whom have backgrounds in IS/IT.
Many regulatory authorities require that pharmaceutical companies and their software organisations comply with GXP (Good Manufacturing Practice, Good Clinical Practice, and Good Laboratory Practice) rules. GXP rules are the authorities’ quality requirements to pharmaceutical companies for ensuring patient health, the quality of processes (e.g. clinical studies or software development) and the quality of products (e.g. tablets or software). As a software organisation in the pharmaceutical business, DevIS must address many quality requirements. One fundamental requirement is that DevIS must be able to show the authorities, by documented evidence, that software development activities (e.g. software change control, software validation, and data processing and storage) are being performed in compliance with quality requirements. Therefore every software project regulated by GXP requirements should carefully apply all quality rules and be able to show by documented evidence that the software is compliant with the related GXP requirements. The company long ago adopted standard operation procedures that explicitly describe the company’s software quality rules. These standard operation procedures should be applied for all information systems regulated by GXP requirements.
Employees of DevIS are basically engaged with software development, software maintenance and software operation activities. The software development activities occur in two forms: 1) development of totally new software products (software development) and 2) developing or changing existing software products (software maintenance). A typical software development project at DevIS is scheduled to take between six months and one year and includes analysis, design, construction, testing, and validation. Software maintenance activities can consist of changes in the code or developing a completely new application for existing software products. Software products in DevIS include the software and all related documentation (e.g. user requirement specification, test plan, validation plan, validation report, user manuals etc.).

4.1.1 The Problem Area

The results of a problem analysis performed in early 1999 in one of CRIM’s largest software development groups showed a need for improving software project disciplines and providing guidelines to understand the standard operation procedures and GXP rules. The director of DevIS initiated an improvement project called Software Process Improvement at CRIM (SPIC) (whose name was changed to SPID after the merger (Software Process Improvement at DevIS)) to understand the existing problems and improve the organisation’s software processes. The following figure illustrates a rich picture of the SPID project.

Figure 3 : The rich picture of SPID [18].

The SPID project was initiated, organised, planned, and performed during the period of April 1999 to May 2000 aiming to improve DevIS’s software processes. A maturity assessment using a modified CMM-based (Capability Maturity Model) assessment method, QBA (see [19]), showed that DevIS was by then a level one organisation and addressed improvement possibilities in all analysed KPAs (Key Practice Areas). An improvement report based on the assessment’s findings and other findings from earlier improvement initiatives at DevIS addressed six improvement activities. The steering committee of SPID gave priority to the following improvement activities (improvement decision) from the improvement report:

1. To establish a minimum documentation level for documenting the results of software projects and create the software documentation process.
2. To improve processes for software validation, software change management, and document version control.
3. To create a template library including templates for documentation of software development activities, such as: user requirement specification, design specification, test plan, and validation plan.
An improvement plan was created and the SPI group (including the author, two SPI consultants and five software engineers) started planning and performing improvement activities over a period of four months, which resulted in creation of new software process guidelines. An implementation plan was then created and presented for the steering committee. The steering committee of the project accepted the new software processes and decided to implement the newly created processes throughout all of DevIS. The implementation activities are scheduled to be arrayed out between August 2000 and June 2001. The implementation activities include among others a trainee program for all practitioners at DevIS and aim to change the context in which the new software processes will work. The implementation phase also includes further improvement activities in which the created processes will be improved on the basis of experiences of using them in practice. This phase will result in a new version of the software process guidelines in June 2001.
 
 

5. The Findings

In this section we discuss the knowledge creation and the learning process that took place during the creation of new software processes in SPID. Further we discuss the most characteristic features of SPI affecting the SPID project.
 

5.1 The learning process in SPID

According to Pourkomeylian [20] it is useful to view an SPI project as an organisational knowledge creation process in which certain type of created knowledge deals with the fundamentals of SPI (SPI-knowledge) such as: management of SPI initiatives, issues related to how an SPI initiative should be guided, and issues related to SPI’s focus on target(s) (see [2]). Others deal with issues related to Software Engineering practice (SE-knowledge) such as: project planning, quality assurance, change control, and configuration management (see [21]).
In SPID the created SPI-knowledge was such that it was able to be put into practice during the project, while the created SE-knowledge could only be practised in a testing phase in which the new or modified software processes could be verified. This means that the learning process for the SPI-knowledge in SPID started when the project manager created tacit SPI-knowledge at the individual level in the socialisation phase to gain management and practitioner’s commitment to the project. At that time the level of SPI-knowledge in the organisation was very low and the management was not able to see the organisational benefits of an SPI project. Thus the project manager arranged meetings with both management and the SPI-group to explain the concept of SPI and the benefits that an SPI project might give to the organisation. The created SPI-knowledge transformed afterwards very slowly via other practitioners in the organisation in one on one talks during coffee breaks as well as formal and informal presentations by the project manager in different meetings. The created tacit SPI-knowledge then becomes explicit SPI-knowledge through dialogue in the externalisation phase in which conceptualised SPI-knowledge was created primarily by the project manager and the steering committee. This knowledge was in the form of project specifications including plans, schedules, roles, and responsibilities. The created explicit SPI-knowledge was then combined with other knowledge or experience of improving software processes or other improvement models and/or methods in the combination phase in which systematic knowledge was then created. In this phase, knowledge was created mostly at the individual and group levels and all actors were involved in the knowledge creation process. The created explicit SPI-knowledge was then put into practice by all actors involved in the SPID to make SPI happen in the project. Operational knowledge about the SPI was created by practising SPI activities in the project. We learn about the SPI approach by doing it in practice. In this phase, the created explicit SPI-knowledge became tacit SPI-knowledge through practice. This means that the learning process in SPID took place almost through all OKC phases involving all actors in individual and group levels and led to creation of SPI-knowledge.
 

5.2 The management of SPID

SPID was organised as a project with specific budget and resources. The initial improvement infrastructure of the project was established early in the project, and the roles and responsibilities in the infrastructure were described. The organisation of SPID consisted of: one project manager (the author of this paper): responsible for co-ordinating, planning and performing the project; a steering committee: including the software managers and the director of DevIS responsible for allocating resources to the project and deciding on the acceptance of the results of the project; a reference group: including software engineers and project managers responsible for giving input to the software improvement activities for creating the new software processes; and a working group: including the SPI consultants responsible for documenting the newly created software processes. An SPI plan was created to define the deliverables, milestones, schedules, and goals of the project. Feedback on improvements was not defined explicitly. It was simply mentioned in the SPI plan that the results of the project (the new software processes) should be tested in two software projects before implementation in the whole organisation.
Organising the SPID as a project gave us the possibility to allocate resources to the project as with any other project at DevIS. This helped to gain the management’s commitment to the project during the project’s entire life span. It further helped us to structure the project’s organisation and the responsibilities. Organising SPI initiatives as regular software projects has been supported in earlier work by [7], [2], and [22]. Organising SPID as a project brought risks as well. People working in the reference group were very busy with other projects at the same time and this sometimes meant that someone could not deliver what he/she was supposed to deliver at a meeting. However this was a minor problem. Co-ordinating the resources and the meetings, both with the management and the improvement team, demanded a grate deal of planning time. On the other hand, planning the project helped us to understand: what to do, when to perform which activity, and who should do what in the project. This helped us to focus on our schedule and the deliverables. This sometimes caused stress, especially for the project manager. Another risk of detailed planning was that we sometimes felt that we were prisoners in the schedules and deliverables, although we did not let our thoughts and ideas be stopped or disturbed by the depth of the plans. We tried to “reflect-in-our-actions” all the time and changed some plans and some deliverables a couple of times. These changes were either necessitated by other ongoing improvement activities in the company which had effects on our project or because we felt that some changes in a specific plan and its deliverables would provide better results for the project in the end. Not defining the feedback on the improvements in detail actually did not affect the initiation of the SPID, but we missed some feedback during the improvement activities in terms of knowing whether we were on the right path.
 

5.3 Approaches to the SPID

In SPID we decided to improve a few software processes in an evolutionary way by taking one step at a time. The goals were neither to reach any maturity level in the CMM nor to improve several software processes. To understand the current level of software process problems we adopt and performed a modified CMM-based assessment, which helped us to identify our software process problems in a structured way. Because the goal of SPID was not to reach any maturity level in the CMM we decided not to follow the CMM recommendations in our improvement activities. We rather let ourselves get inspiration from the concept of SPI, i.e. improving software processes in a systematic way, than tried to fulfil the CMM’s requirements. We based our improvement strategy on the assessment’s findings, other quality goals within the organisation, and practitioners’ and management’s commitment to the project. Without the management’s commitment we could neither start the SPI initiatives nor get the necessary resources for the project and without the practitioners’ commitment to the project we could never have constructed a creative forum for discussion and improvement of the new software processes.
Having an evolutionary approach in SPID helped us to concentrate on a few software processes. We could see the whole picture and did not get lost in the complexity of having several software processes to improve. We could manage the situations well and had time to reflect in our actions to improve our SPI practice. The problem with focusing on a few software processes was rather that the software processes focused on were related to other software processes and software development models. This caused many hours of discussion to separate other issues from our main scope. We still however needed to remind each other of the scope of the software processes several times during our project. Not aiming to reach a maturity level in the CMM led to a positive reaction among both the management and the practitioners. Because the goal was not just to reach an “abstract” target (reaching a “level” in a model, for management and practitioners at that time) but, solving the organisation’s problems by being inspired by a well-known model, which was modified to suit the organisation’s situation. This created more motivation and enthusiasm among practitioners and management and strengthened their commitment to the project. Being dependent on both management and practitioners’ commitment was one of the most vulnerable key issues of the SPID. This meant that, before starting the project, the project manager had to carry out many marketing activities for the project to gain both the management’s and the practitioners’ commitment and this was a time demanding activity. One key factor in succeeding in creating new processes was that the practitioners believed in SPID and were considered about the results of the project. Practitioners working with SPID were almost all persons with in-depth experience in leading software projects and wrestling with software process problems. They knew the importance of solving the software process problems, and this made them very committed to the project and involved in working hard to create processes that could function in practice.
 

5.4 Perspectives in SPID

At that time DevIS did not have a detailed description of all software processes. This meant different interpretations of any given simple software process activity in the software projects. For instance, the practitioners knew that a software product should be validated before being put into operation, but the interpretation of the software validation process was different in different projects. We knew from earlier improvement activities that a description of the software documentation process was missing in the organisation. Knowing which documents should be created as products of the software projects could help us to identify the activities needed to perform for creating them. It could further help us to identify the main processes needed for supporting these activities. We therefore adopted a product perspective in the beginning of the project and focused on identifying the documents needed as the results of a software project. On the basis of this, we identified actors and activities needed for creating each document. After defining the software documentation process we changed our focus and concentrated on processes that should be improved (software validation and software change control). During the improvement process the practitioners’ competencies, ideas and experiences were the main input to the improvement work. Because the improvement phase of the project ended before the implementation phase we did not need to change the context in which the software processes should be operated.
The problem in focusing on software processes was that these processes were related to the other processes, the software development models, and the software project management models. It required many hours of discussions to separate different issues from the project’s main target and focus on the defined goals. The benefit of focusing on documents as software product was that we agreed upon the documentation as one type of software products. This helped us later to identify the activities and processes needed to be in place to support the creation of these documents. All the improvement activities in SPID were based on the practitioners’ ideas and experiences. One problem of focusing on practitioners’ competencies for improving software processes was that the whole project was dependent on their input. If a majority of practitioners was not able to join a meeting we cancelled the meeting and had to wait until the next time. This problem has been identified by Johansen and Mathiassen [7]. Another problem was that the practitioners had different experience from different software projects. This caused variations in interpretation of any specific software process activity. Much time was needed to discuss different views and experiences related to one specific software activity or process. However the benefit was that we knew that all the different issues discussed had already been put into practice and shown some degree of usability. Table 2 illustrates the SPID activities based on the MAP described by Aaen et.al [2], *: Total, ~: Partly, -: Nothing.
 
Concern  Idea Performed Description Aspiration Pitfalls
Management of SPI  Organisation * The SPID was organised as a project like all other software projects within DevIS having specific budget, and resources. The organisation of SPID consisted of a reference group, a steering committee, a working group, and a project manager. Allocated resources.
Gaining management’s support.
Structuring a formal organisation for the project.		 Inadequate resources.
Difficulties co-ordination.
Plan * An SPI plan was created to identify the millstones, deliverables, responsibilities, and activities needed to be performed within the project. Knowing what to do, when to perform which activity, and who does what. Stress feelings.
Bounded in plans and deliverables.
Feedback - The SPID didn’t defined in detail how feed back on improvements should be measured. Saving time. Could not measure quality during the project.
Approach to SPI Evolution * SPID aimed to learn from the SPI concept and improve a few software processes in an evolutionary way by:
Identifying the current level of the software process problems
Identifying the minimum documentation level
Creating processes for:
Change management, and
Software validation		 Learning by doing.
Stepwise improvement.
Adapting the concept of SPI by reflecting-in-action.
Not getting lost.
Could see the whole picture.		 Not having the whole picture.
Time demanding.
  Norm ~ Using a modified CMM-based model only for the assessment to identify the current maturity level of the software organisation. Not aiming to reach any maturity level in CMM. Basing the improvement strategy on the assessment findings and earlier improvement findings. Identifying the software process problems in a structured way.
Using a modified version of a well-known model.
Gaining management and practitioners’ commitment to the project. 		 Took a long time to understand that we still can learn and use the concept of SPI without blindly following the CMM.
Commitment * One important factor in getting succeed with SPID was both practitioners’ and management’s commitment to the project. During the whole project we had the management’s support and practitioners’ commitment to collaborate in creation of new software processes. Ensured the resources for the project.
Ensured dedication		 To be dependent on management and practitioners in two different ways.
Time demanding marketing activities.
Perspective in SPI  Process * In the beginning SPID was focused on the products (documents) of the software projects. This focus changed later on in the project to the processes. Two targets with one shot, i.e. defining processes by identifying products. Having the scope in focus all the time.
Competence * The main input to SPID was practitioners’ ideas, and experiences about the software processes. The practitioners’ ideas and experiences were tested in the reality. Being dependent.
Different views.
  Context - During the SPID the context in which software processes operated was not changed.

Table 2: SPID activities based on the MAP see [2].


6. Lessons Learned

We have analysed an SPI project based on the most characteristic features of SPI (see [2]) and an OKC perspective using a framework based on Nonaka and Takeuchi [15] of the organisational knowledge creation process. From the perspective of this framework we believe that: a novice organisation has a chance to succeed with its first SPI initiation if the organisation maximises its ability to learn from the concept of SPI, and minimises the amount of software processes to be improved. This study suggests a number of lessons relevant for future SPI projects and the SPI practice.

Lesson one: The first SPI initiative should  aim to learn the concept of SPI and the software process problems. An SPI initiative is a complex effort in which people, methods, tools, and products interact with each other. The first SPI initiative in a novice organisation should therefore be a learning process in which the organisation learns about the concept of SPI and the current software process problems while improving software processes.

Lesson two: A novice organisation should focus more on the SPI concept than the CMM recommendations. The first SPI initiative should start by diagnosing the current maturity level of the organisation. The CMM can offer much help in doing this. However for improving the software processes, it is better to rely on the organisation’s goals and focus on the SPI activities and learn to improve a few software processes based on the organisational goals rather than just following the CMM as a model.

Lesson three: The first SPI initiative should be organised as a project, with specific goals, deliverables, and recourses aiming to improve a few software processes in an evolutionary way, on the basis of the organisation’s ideals and practitioners’ ideas. Organising the SPI initiative as a project and planning the activities are essential for managing improvement activities in an SPI initiative. For guiding the SPI improvements it is much more important to focus on stepwise improvement and satisfy the organisation’s goals than to follow an abstract goal. This supports gaining the management and practitioners’ commitment to the project. An SPI initiation should be focused on the practitioners’ ideas and experiences for improving the software processes.
These lessons correspond with [2], [7], and [22]. However, SPID did not adopt the whole MAP in detail. But as the first SPI initiative it is most essential to be focused on delivering results that are visible to the management in the scheduled time. This will ensure dedication and legitimacy for the continuous SPI efforts in the organisation. As a success criterion it should be mentioned that the steering committee of SPID accepted the new created software processes and decided to implement these processes in the whole organisation. The implementation phase in SPID starts in August 2000.
As mentioned before one great challenge for DevIS is to find a way to implement the newly software processes in the organisation. A key factor in helping the implementation of the created new software processes is training. According to the implementation suggestion report presented to the steering committee of SPID all practitioners working with software development and maintenance should have training in the new processes. This means that, based on the trainee program, each practitioner will create his/her own understanding of the newly created software processes. These understandings may not be the same because of the differences in practitioners’ experiences and backgrounds. Because of this, as well as other factors that might cause variation-in-action, DevIS should expect variations-in-action (see [23]) when these new processes are put into practice. Questions for further research might then be: 1) Does variation-in-action happen in DevIS using the new software processes? 2) How does it happen? 3) Which factors are involved in affecting variations-in-action? 4) What does it mean for DevIS? 5) How does variation-in-action affect the institutionalisation of the new software processes at DevIS?
 
 

7. Acknowledgement

This research was sponsored by AstraZeneca R&D Mölndal in Sweden in collaboration with the Viktoria Institute and the Institute of Computer Science in Aalborg, Denmark.
 
 

8. References

[1] Humphrey, Watts S.: Managing the Software Processes, Addison-Wesley Publishing Company, USA. 1989.

[2] Aaen I., Arent J., Mathiassen L., Ngwenyama O.: A Conceptual MAP of Software Process Improvement. Artikelsamling, Center for Softwareprocesforbedring. Dansk Elektronik, Lys & Akustik. 2000.

[3] Tryde, S., A.-D. Nielsen & J. Pries-Heje 82000). A Framework for Organizational Implementation of SPI in Practice. In: L. Mathiassen et al. (Editors): Learning to Improve.

[4] Goldenson, D. R., and J. D. Herbsleb.: After the Appraisal: A Systematic Survay of Process Improvement, its benefits, and Factors that Influence Success. CMU/SEI-95-TR-009, SEI, Pittsburgh. 1995.

[5] Herbsleb, J., et al.: Software Quality and the Capability Maturity Model. Communications of the ACM, 40(6), 30-40. 1997.

[6] Mashiko, Y., and V.R. Basiili: Using the GQM Paradigm to Investigate Influential Factors for Software Process Improvement. Journal of Systems and Software, 36. 17-32. 1997.

[7] Johansen, J., and L.: Mathiassen. Lessons learned in a National SPI Effort. EuroSPI 98 Göteborg. 1998.

[8] Aaen I., Arent J., Mathiassen L., and Ngwenyama O., Mapping SPI Ideas and Practices. 2000, TBD

[9] Paulk Mark C., et al.: The Capability Maturity Model for software Version 1.1, Carnegie Mellon University, Software Engineering Institute. 1993.

[10] Kuvaja Pasi, Bicego: BOOTSTRAP - a European assessment methodology, Software Quality Journal 3, 117-127. 1994.

[11] McFeeley Bob: IDEAL: A User’s Guide for Software Process Improvement, Software Engineering Institue, Cornegie Mellon University. 1996.

[12] Zahran Sami, Software Process Improvement, Software Engineering Institute, SEI Series in Software Engineering, Addison Wesley Longman 1998

[13] Curtis, B., A Mature View of the CMM. American Programmer, 7, 9, 19-27. 1994.

[14] Patton M., Q., Qualitative Evaluation and Research Methods. SAGE Publications. 1990.

[15] Nonak, I., and Takeuchi H.: The Knowledge-Creating Company, Oxford University Press, Inc. 1995.

[16] Polanyi, M., : The Tacit Dimension. London: Routledge & Kegan Paul. 1966.

[17] Nonaka I. And Konno N.: The Concept of “Ba”: Building a Foundation for Knowledge Creation, California Management Review Vol 40, No.3, Spring 1998

[18] Checkland Peter, Scholes Jim: Soft System Methodology in Action, John Wiley & Sons LTD. England. 1990.

[19] Arent J., Iversen J., Development of a Method for Maturity Assessments in Software Organizations based on the Capability Maturity Model, in Department of
Computer Science. Aalborg: Aalborg University, 1996.

[20] Pourkomeylian P., Knowledge Creation in Improving a Software Organization. IRIS 2000.

[21] Pressman Roger S.: Software Engineering, a practitioner’s approach, fourth edition, International editions. 1997.

[22] Aren J. and Norbjerg J: SPI as Organizational Knowledge Creation: A Multiple Case Analysis. Proceedings Conference Proceedings at Maui Hawaii, January 2000.

[23] Schön Donald A., Educating the Reflective Practitioner. Jossey-Bass Publishers . San Francisco. 1987.
 


 
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