success with improvement — requires the right roles to be enacted — in symbiosis

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2007; 12: 529–539

Published online 25 July 2007 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/spip.348

Success withImprovement – Requiresthe Right Roles to beEnacted – in Symbiosis

Practice SectionJørn Johansen1*,† and Jan Pries-Heje2

1 DELTA, Denmark2 Roskilde University, Denmark

Success in process improvement (PI) depends on the viewpoint and the observer. The sameprocess can be seen as a success from one viewpoint and an utter failure from another. In thisarticle, we report the results of a large Danish research project that set out to study success andfailure in product innovation and PI projects, using a large interview study and grounded theoryanalysis as the research approach. One main outcome of the research project was a model and amethod – called ImprovAbility – that can be used to increase an organization’s ability to succeed.Another outcome was detailed findings about the different roles in PI. The roles we identify arethat of project members, project managers, process owners, project organization, top managers,involved experts and users. They all have different roles in relation to the organizational goal:improving and becoming better at improving. They are also involved in defining requirementsand providing and obtaining knowledge in different ways, and they focus on different things,face different problems, and are happy about different solutions. The core of the article reportsthese findings and discusses how one can use diversity to increase the chance of success in PI.Copyright 2007 John Wiley & Sons, Ltd.

KEY WORDS: process improvement; success; roles; ability to improve

1. INTRODUCTION

Many IT organizations have expended considerableresources on process improvement (PI). However,investments in PI often have not led to the changesand expected improvements. In a study of a largenumber of organizations that had invested in SPI(Software Process Improvement), Goldenson andHersleb (1995) found that 26% of the organizationsconcluded that ‘nothing much (had) changed’, and

∗ Correspondence to: Jørn Johansen, DELTA Software Engineer-ing, Venlighedsvej 4, Denmark†E-mail: [email protected]

Copyright 2007 John Wiley & Sons, Ltd.

that 49% declared themselves discouraged by thelack of improvement. This study is not unique.Several others have examined the many ways inwhich SPI initiatives can fail (cf Blanco et al. 2001,El-Emam 2001, and Rainer and Hall 2002).

Unsuccessful PI initiatives led to growing inter-est in the necessary components of a successfulPI implementation (cf Grady 1997, Zahran 1998,Stelzer and Mellis 1999, and Dyba 2000). Grady(1997) directed attention to the fact that an organi-zation must be ready for PI. If that is not the case, thePI initiative can be very costly and may fail. Zahran(1998) pointed out the importance of understandingthe business and organizational context before car-rying out an assessment of the organization for the

Practice Section J. Johansen and J. Pries-Heje

purpose of initiating PI. Zahran called this activity apreassessment phase, and recommended that it becarried out before any decisions about initiating PI.

In Denmark, it was not until the mid-90s thatthe wave of PI hit. A few companies may havedone something before that, especially if they werepart of an American or international companyundertaking a PI effort. But in Denmark, the mostpopular improvement model, even for software-developing companies, was ISO 9000. Then, around1995, many companies suddenly became interestedin PI. The technology-transfer organization, vizDELTA Danish Electronics, Light and Acoustics(DELTA) setup a department to help companiesto improve. It adopted the European maturitymodel BOOTSTRAP (Kuvaja et al. 1994) to assessorganizations, and within a few years more than50 Danish organizations were assessed (Pries-Hejeet al. 2001).

Two years later, as we were filing the applicationfor the research project, (called Talent@IT, reportedin this article), one author, who chaired the assess-ment effort at DELTA, discovered that of all Danishorganizations that had undertaken an assessment,approximately 50% had not improved at all. Thatis a disheartening statistic. Something had to bedone; we promised to develop a model that Dan-ish companies could use to improve their ability toimprove.

If we now turn towards the different rolesinvolved in PI and look at a software-developingorganization, then we find that a typical employeewants to ‘play a role’ in improvement. Most orga-nizations will focus on efficiency and the ability todeliver quality results. Often, the main problems inrelation to this are late results, missing results orresults of inadequate quality due to poor require-ments. Improvement is needed at all organizationallevels. Everyone (nearly) has an interest in takingpart in improving the organization – and have their‘fingerprint’ on the improvement result. In the end,improvements are meant to help the employees todo a better job.

Prior research in PI has revealed that it is verydifficult to reach the goals of efficiency and quality,for several reasons. We just mention below ten ofthese reasons that are often observed:

• Lack of management commitment• Developers submerged in day-to-day work

• Developers allocated to many activities in par-allel (part time is as good as ‘no time’)

• PI workers living in an ivory tower• Missing PI strategy• PI not aligned with business strategy• Lack of planning and control• PI undermined by bureaucracy• Daily fire fighting• Resistance to change.

These arguments are applicable for productimprovement as well (cf McConnell 1996).

However, some of the reasons can be seen frommore than one side. Take for example ‘managementcommitment’. Employees may claim that they missmanagement commitment or they may say thatmanagers are not involved. But on the other hand,if you ask the managers, they may tell you that theyare never informed or that the employees prefer notto involve the management. Thus, the same thingcan be seen very differently, depending on one’srole.

This article therefore looks at PI and differentroles. The empirical background for doing thisis research from the Talent@IT project. Thus, theremainder of the article unfolds in the followingway. First, we report our research method andthe main result, which we call ImprovAbility. Then,we focus on the different roles played whilecommunicating about requiremets and obtainingknowledge. Then we focus on the motivation, focusand problems of the different roles as well as whatkind of solutions they are after. Finally, we discusshow one can use the diversity to increase the changetoward success in PI.

2. RESEARCH METHODS

The Talent@IT project was initiated in January2003 and ended in January 2006. Partners inthe project were DELTA, the IT University ofCopenhagen and four large organizations in thefinancial sector – ATP-huset, Danske Bank, PBS,and SimCorp. The two authors of this article actedas project managers and were responsible for theresearch in the project.

We focused on both successful and failed IT-improvement projects, from the viewpoint of‘improving the ability to improve’. We agree thatlearning can be harvested by looking at projectsin retrospect, but unlike other studies ours studied

Copyright 2007 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2007; 12: 529–539

530 DOI: 10.1002/spip

Practice Section Success with Improvement Requires Right Roles to Be Enacted in Symbiosis

both the PI projects in which other software devel-opers are the users and traditional IT projects inIT-developing organizations.

We asked each of the four participating com-panies in Talent@IT to nominate projects for study:two PI projects and two general-innovation projects,preferably a success and a failure for each type. Wealso asked for PI projects that had delivered resultswhich had subsequently been used in innovationprojects.

We conducted interviews on the projects withthe following key project participants: project man-ager and one or two project members; the sponsoror owner of the project, typically a manager in theorganization; and users (i.e. other developers for SPIprojects and end users for innovation projects). Thisensured that many diverse perspectives were repre-sented in our data – exactly what we had reportedearlier in this chapter on the data warehouse exam-ple.

In the period from summer 2003 to summer 2004,we interviewed more than 50 people, representing14 different projects. Interviews were conducted bytwo persons: one conducting the interviews andanother person taking notes. More details can befound in Hansen (2006).

Interviews were transcribed and analyzed usingtechniques from grounded theory (GT). GT is aqualitative research methodology that takes itsname from the practice of discovering theory thatis grounded in data. GT is best used for researching‘uncharted territory’, such as the concept of Internetspeed. GTs are inductively discovered by meansof a careful collection and analysis of qualitativeempirical data. That is, this method does not beginwith a theory and then seek proof. Instead, it beginswith an area of study and allows the relevant theoryto emerge from the data collected (Strauss andCorbin 1990).

We applied GT coding procedures to our inter-view data. According to Strauss and Corbin (1998),analysis in a GT approach is composed of threegroups of procedures: open, axial, and selectivecoding. These procedures do not entirely occur as asequence, but each overlaps the others and iteratesthroughout the research project.

The goal of open coding is to reveal the fun-damental ideas found in the data. Open codinginvolves two essential tasks. The first is the labelingof phenomena, and involves decomposing an obser-vation into discrete incidents or ideas. The second

essential open-coding task is the discovery of cate-gories. Categorizing is the process of finding relatedphenomena or common concepts and themes in theaccumulated data and grouping them under jointheadings. We uncovered 54 categories of factorsthat contributed to the success or failure of projects.

Developing a better and deeper understandingof how the identified categories are related is thepurpose of axial coding. It involves two tasksthat further develop the categories and properties.First, categories and relationships were identified,discussed, corrected, and changed, until a commonunderstanding of the categories, subcategories,and their relationships was reached. Actually, weended up with 20 categories. Finally, selectivecoding involves integrating the categories into atheoretical framework often called the story line.The story line we ended up with was that anorganization’s capacity for achieving success andavoiding failure – its ability to improve – dependedon its ability to cope with four groups of parameters:

• Parameters related to initiation of projects, typi-cally, ideas for new PI or innovation projects

• Parameters related to projects, from the very firsthour and until a result is taken into use

• Parameters related to results in use, from the firstuser using the new process or product for thefirst time and until full deployment

• Parameters related to the enterprise foundation

3. THE IMPROVABILITY MODEL

After having identified the story line and theparameters, we decided to build a model out ofit. This model is shown in Figure 1. As you can see,the four groups of parameters form the core of themodel and the 20 categories are distributed amongthe four groups.

The ImprovAbility model was tested in thefour companies that participated in the Talent@ITproject. We found that the concept is unique. Itfunctions very well, it is very useful as a commu-nication framework, the result of the appraisal inrelation to the model parameters is very useful, andthe scope and change strategy identification gives anew insight for the organization. More informationon use of the ImprovAbililty model and method canbe found in Pries-Heje (2007).

ImprovAbility is not a maturity model likeCMMI (Chrissis et al. 2003) and SPICE (ISO/IEC


DOI: 10.1002/spip 531


Figure 1. The ImprovAbility model with the four cate-gories of parameters

TR 15504–2003, 2004 and 2006). Maturity modelsappraise the quality of development processes andtheir institutionalization. ImprovAbility appraisesthe ability to improve them. ImprovAbility also goesbeyond development. It includes the ability to initi-ate and use innovations and improvements – foundin the organization’s strategy, culture, management,and learning. ImprovAbility furthermore extendsthe scope of maturity models by proposing concreterecommendations, which are relevant in the specificcontext of the organization.

4. DEFINITION OF ROLES

The first question that naturally comes to mind,when one starts to look at PI and roles is: What rolesare there? One answer to this question is that everyactivity has someone doing it – the ‘Performer’,responsible for developing and implementing theimprovement activities in the organization. Some-times the result of doing something is what theperformer will use but more often there is anotherperson using the results of the activity – the ‘User’.Furthermore, the performers very often do not actalone. There will be a sponsor supplying money,a champion helping with technology transfer, an

owner who owns the benefit coming out of using theresult, or a manager making sure that a performeris allocated to this specific activity and not threeothers. In general, we can say that we have a ‘Sup-plier’ role, characterized by distributing resources,knowledge and power.

If we now look at these three roles, we canhave them at different levels of the organization.If we look at the organization as a whole, we willtypically find something like a PI department or asoftware engineering process group (SEPG) that isresponsible for performing the PI. The user of PIwill typically be a customer, and the supplier willbe someone from top management enacting the roleof sponsor.

In the individual projects also, one can find thesame three roles but enacted differently at theindividual level. In Table 1 (inspired by Hansenet al. 2004), we have given an overview of the rolesat the three different levels mentioned. We havegiven below an account of how each role presentedin the table is enacted in the PI arena.

4.1. Management/Sponsor

The sponsor has the overall responsibility for align-ing the improvement program according to theactual business needs. The responsibility for initi-ating and supporting the improvement activities inthe organization lies with the sponsor. The spon-sor – typically a person from top management – isa person (or a group of persons) who endorses theimprovement programs or projects and demandsthe results. This type of role is found among thetop managers, who are responsible for business,product and process development. Only at thatlevel of the organization is there enough power andinfluence.

Table 1. Process improvement role matrix

Organization Project Individual

Supplier Management/Sponsor ProjectOrganization

Expert

Performer PI Unit PI ProjectManager

PI Developer

User Customer ProjectManager

Productdeveloper


532 DOI: 10.1002/spip


4.2. Project Organization

The project organization (or steering committee) isthe official body responsible for defining, scopingand controlling projects in the organization. It hasto follow the project closely and if unexpected prob-lems or necessary changes occur, it has to makedecisions on the basis of the changes or the direc-tion of the project. An important task is to ensureresults – which often require continued contact andongoing involvement of different groups of stake-holders. Normally, this group is a group selectedfrom management. Depending on the situation, thisgroup of people could be supported by externalexperts.

4.3. Experts

There can be internal or external experts or con-sultants, with the necessary competence to supportmanagement or the project manager.

4.4. Process Improvement Unit (Process Owners)

This is normally a visual part of an organizationaldiagram. It could be the department for qualityassurance, a department for methods or a lesssubstantial part of the organization such as theSEPG. This Unit is the owner of the processes in theorganization. They have the responsibility – oftennot clearly defined – to maintain the formal setupof the processes in the organization, to develop newprocesses, and to diffuse and ensure adoption ofprocesses. This role is often played by employeeswith strong interests in quality, efficiency andongoing PI.

4.5. PI Project Manager

The project manager is the person (or persons) whoin practice prepares and carries out the project, andalso often includes the diffusion and adoption ofthe changes in the organization. He or she mustperform within the chartered course set by the PItop manager and is the facilitator for the PI effort.An important task is to run the project, includingall normal project activities and disciplines suchas planning, teaming, managing, monitoring andcontrolling the project and its risks. This role is oftentaken by an influential, high-status project managerwith a solid inside knowledge of the organization.

4.6. PI Developer

PI developer is a person, or normally a group(or groups) of persons, working together with theproject manager. Depending on the project goals,the project is manned with persons holding thenecessary competencies. This group includes everynecessary part of the organization – if the personshave the right qualifications.

4.7. User

When it comes to change in an organization, the user(of the change) can be everyone in the organization(customer, project manager, product developers,suppliers and performers). Only the experts are nottaken as users. So in this context, the users includethose who perform the improvement work.

In an organization, it is necessary that all theseroles are successful. They have to work closelytogether to ‘push’ the change through, which isillustrated in Figure 2.

The seven different roles (management, projectorganization, project manager, developers, processowners, users and experts) that we have definedare shown in Figure 2 as part of an improvementproject, as part of the organization, or as outsider tothe organization. Suppliers are located in the upperpart of the figure, performers in the lower left part,and users in the lower right part.

The PI process (sic!) can develop in the followingway. (i) Management initiates a project and (ii) setsup a project team together with project organization(could include the development, method depart-ment and human resource management), which (iii)in collaboration with the project manager and theprocess owners (could be PI unit) forms a project.(iv) The project is managed by a project managerand the work is performed by developers withhelp from the process owners. (v) Experts can benecessary to support the management or projectmanagers with external knowledge or to avoid roles,which can be accused of riding their own hobby-horses. The change – e.g. a new process – ends atthe users.

On looking at Figure 2, it becomes clear thatmanagement, project organization and the projectmanager (and ofcourse the project as a whole) arethe key roles to ensure successful change through-out the organization – ending with a diffused andadopted change. Each of these roles has three or


DOI: 10.1002/spip 533


Figure 2. A role model for Organizational Change. Project (big arrow) produces change for user group. Small arrowsindicate communication requirements

more starting arrows indicating that they have theprimary keys to the process. All the requirements(the push for change) end at the user’s ‘doorstep’.

Success demands activities addressing diffusionand adoption – an often forgotten or neglected ‘partof the play’. It also requires a recognized need fromthe user – which is much easier if the users havebeen involved as stakeholders before and duringthe project.

The arrows indicate the communication of allkinds of needs and requirements during theproject – pull of needs. The large arrow indicatesthe project, and the change the project will realize.The users are here indicated to be located insidethe organization, which is the typical situation in PIprojects. Experts can be both internal and external.

To ensure the best possible setup of a PI project, allstakeholders have to be activated – eliciting infor-mation from different sources in the organizationto be able to define the requirements, scope andbenefits for the project. This is illustrated in Figure 3.

From the illustration in Figure 3, it is clear thatusers, process owners and management are the keyroles. It is also clear that the project manager is themost important person in that he or she controlsthe communication path – this role has the broadestorganizational contact.

5. SUCCESS

The quest for defining success in IS has beenon the agenda in the IS community for overtwo decades, since Peter Keen in 1980 at the 1stInternational Conference on Information Systems(ICIS) identified it as one of five issues in need ofbeing resolved (DeLone and McLean 1992).

A lot of effort has been put in since then todiscuss what constitutes a success. In our studieson interviews (see details under Research Method)we found different and sometimes opposing view-points for the same projects and for the sameprocesses. Thus, what is considered a success fromone point of view is not a success from anotherpoint of view. We analyzed the results and cameup with the ImprovAbility model as one conflationof our findings. However, we also kept track of thedistinct viewpoints of each role (or stakeholder). Ananalysis of these separate observations for each rolerevealed the following results.

5.1. Management/Sponsor

Management is mainly concerned with the success-ful implementation of PI in the sense that it provesuseful to the organization. It is also interested inwhether the new processes are in fact used homo-geneously across the business unit. Managementfocuses on the strategic benefits gained from PI.


534 DOI: 10.1002/spip


Figure 3. Role model showing the pull of knowledge. Small arrows indicate communicated need and user requirements

Success is equal to the achievement of the formalobjectives – including a focus on cost.

5.2. Project Organization

The project organization role focuses on qualityand productivity as a success criterion. The qualityis linked to the final product in terms of classicproject management goals: time, quality, costsand functionality. The project organization alsopoints to the success criterion that is linked tothe dissemination of knowledge across projects. Bysupporting the PI, the project organization expectsto be less dependent on the individual, achieving amore flexible organization.

5.3. Experts

By getting personally involved in the designprocess, the experts acquaint themselves with theconsequences of PI in the organization. Success forthis role is constituted by the influence on the designof processes through active involvement.

5.4. PI Unit (Process Owners)

The PI Unit’s role is not concerned with the addedvalue of PI as opposed to management. The PI Unitis concerned with the organizational capability todeliver stable processes based on the best practicethat increases the productivity of employees in the

organization. The PI Unit takes the responsibility forseriously demonstrating the value of improvementinitiatives, both to the management and employeesin general.

5.5. PI Project Manager

The PI Project Manager emphasizes that it isimportant that the organization accepts the newprocesses. It is evident that the PI Project Managermust take into consideration many stakeholderexpectations that sometimes contradict each other.They must perform within the charted course setby management and the project organization andat the same time deal with the acceptance at theindividual level. On the basis of the analysis, PIManagers can be characterized as a facilitator for PIeffort.

5.6. PI Developer

Besides being in control of the PI work, the datareveals that PI developers regard their effort as asuccess if it enhances the organizational effective-ness. But they are also driven by the anticipationof the entire organization benefiting from theircontribution and continuous effort to consolidateprocesses. PI developers are therefore concernedwith designing processes that are practicable forusers. People who enact the role of process develop-ers find it satisfying to contribute to the organization


DOI: 10.1002/spip 535


Figure 4. Roles with success criteria. Italicized text is directly grounded in specific research interviews. Normal text isinterpreted through the knowledge and experience of the authors

and have influence on the structural design of theorganization.

5.7. User

Users, in general, demand that the result of PImust back up daily work activities, if they aregoing to regard it as a successful improvement.If this requirement is not met, chances are that theywill find alternative ways of bypassing the definedprocesses. Users also require wide organizationalsupport to consider PI successful.

In Figure 4, this ‘landscape’ of roles and successcriteria is unfolded. The success criteria in relationto a PI project are listed for each role. In the figure,we have distinguished between the findings thatspecifically can be traced back to the interviews inthe Talent@IT project and findings that can be tracedback to one or more of the many PI assessments, wehave performed (cf Pries-Heje et al. 2001).

The rational goals for a project are normallyagreed as success factors by all roles in theorganization – such as the requirements for theproject. The expected goals in relation to thestakeholders are normally related to specific roles.

From Figure 4 it can be seen that the view ofsuccess is different from role to role, and seendifferently from a project perspective and from auser perspective. From the project point of view,the suppliers relate success more to the fulfilmentof organizational benefits (rational goals), whereasthe performers relate success more to the perceptionof the end users (expected goals). Seen from a userpoint of view, success is role specific.

6. DIFFERENT NEEDS AND PERSPECTIVESIN RELATION TO ROLES

To obtain a more detailed view, we decided to carryout another round of analysis focusing on the needsof the different roles. Again, we used interview datafrom the Talent@IT project coupled with experiencedata from numerous PI assessments. We decidedto group our findings into four categories thatwe called Horizon, Focus, Problems and Solutions.Horizon is everything that a player in the role isinterested in. Focus is what they focus on withintheir horizon. Problems are the obstacles typicallyencountered, and Solutions are how the problemswere solved in the many projects and organizations


536 DOI: 10.1002/spip


Figure 5. Roles with different perspectives - focus, problems and solutions

we have engaged. The outcome is shown in Figure 5,which clearly illustrates the distinct differencesbetween the roles.

The relation between problems, solutions andsuccess criteria is obvious – and also natural. Theperformers are more focused on running the projecteffectively and maturely, minimizing related prob-lems, increasing quality and improving qualifica-tions. The suppliers on the other hand are morefocused on structure and control, overall pro-ductivity and quality – a broader organizationalview.

The characteristics of the perceived problems arevery different. One of the keys to a more successfulimprovement initiative in an organization is to focuson this difference. If you have one role – for exampleas performer – then the less you focus on your ‘own’problems the more frequent will be the conflicts. Onthe other hand, it is clear that solved problems forone role can contribute to the problem solution forother roles.

Let us take an example. The management prob-lem ‘Missing basis for decision making’ can besolved or minimized by providing more insight:Right information, data and dialogue. This problemis strongly correlated with improved predictability

and improved processes and therefore will con-tribute to a solution for both Project Organizationand for PI Unit (process owners). The key forincreasing the possibility for success is selectionof solutions which address as many problems foras many roles as possible - and use their point ofviews and perspectives on problems, solutions andsuccesses.

Thus, the conclusion arrived after this detailedanalysis of roles is that insight into other roles, theirproblems and potential solutions are very importantfor success. It is also clear that the solutions inFigure 5 are linked directly to the correspondingrole’s perception of success.

7. DISCUSSION

As reported, we used the interview data to build theImprovAbility model. After having built the model,we tested it in the four organizations participatingin the Talent@IT project as well as many otherorganizations.

The core assumption behind the ImprovAbilitymodel is that the parameters identified in theinterviews on the success and failure of projectscan be used to identify an organization’s ability


DOI: 10.1002/spip 537


Figure 6. The ImprovAbility model, including main roles

to improve, by encouraging activity that has beenshown to be related to success and avoidingactivities that have been shown to lead to failure.

The ability of an organization to produce successand avoid failure – the ability to improve - dependson the organization’s ability to cope with thefour groups of parameters related to Foundation,Initiation, Projects and In Use.

If we now take the roles that we have identifiedand map them to the place where in the ImprovAbil-ity model they have their main importance or aremost powerful, the result is as shown in Figure 6.

From Figure 6 we can see that the suppliersare located primarily in the Initiation and nearthe In Use categories. The performers are tightlycoupled to the Project category. The specifics of theidentified roles are easy to explain in relation to themodel categories, which also give the link to theparameters in the model – which parameters are ofmost interest for the specific roles.

8. CONCLUSIONS

This article has identified three major roles in threedifferent organizational settings. Analysis revealedthat the view on success, even in the same projectsand about the same things, was quite different.

For each role, we have identified key foci,problems and solutions and we have discussedhow they were related. We have also hypothesizedthat if you enact one role but show empathy for theproblems related to other roles, you can increase thechance of success.

Finally, we have shown how the ImprovAbilitymodel may be a concrete way to identify the roles,problems and solutions leading to success in aconcrete organizational setting.

REFERENCES

Blanco M, Gutierrez P, Satriani G. 2001. SPI patterns:learning from experience. IEEE Software 18(3): 28–35.

Chrises MB, Konrad M, Shrum S. 2003. CMMI: Guidelinesfor Process Integration and Product Improvement. Addison-Wesley: Boston.

DeLone WH, McLean ER. 1992. Information systemssuccess: the quest for the dependent variable. InformationSystems Research 3(1): 60–95.

Dyba T. 2000. An instrument for measuring the key factorsof success in software process improvement. EmpiricalSoftware Engineering 5(4): 357–390.

El-Emam K. 2001. Modelling the likelihood of softwareprocess improvement: an exploratory study. EmpiricalSoftware Engineering 6(3): 207–229.


538 DOI: 10.1002/spip


Goldenson DR, Hersleb JD. 1995. After the appraisal: asystematic survey of process improvement, its benefits,and factors that influence success. Technical ReportCMU/SEI-95-TR-009. Software Engineering Institute,Carnegie Mellon University: Pittsburgh, PA.

Grady R. 1997. Successful Software Process Improvement.Prentice-Hall: Upple Saddle River, NJ, 336.

Hansen N. 2006. What really constitutes project success?A study of success, failure, evaluation criteria andinfluencing factors in the context of IT-supported process-innovation projects. PhD Dissertation, The IT Universityof Copenhagen, Copenhagen, Denmark.

Hansen NG, Hansen G, Elisberg T. 2004. A key tosuccess in SPI – mapping stakeholders’ success criteria.Proceedings of the 27th Information Systems Research Seminarin Scandinavia (IRIS 27), Falkenberg, Sweden, 14–17August, 2004.

Kuvaja S, Koch P, Mila L, Krzanik A, Bicego S,Saukkonen G. 1994. Software Process Assessment andImprovement: The BOOTSTRAP Approach. BlackwellPublishers: Oxford, 149.

McConnell S. 1996. Rapid Development. Taming WildSoftware Schedules. Microsoft Press: Remond, WA.

Pries-Heje J, Johansen J, (eds). 2007. Improve: IT: A book forimproving software projects. DELTA, Hørsholm, DK.

Pries-Heje J, Jonassen-Hass A-M, Johansen J. 2001. Takingthe temperature on Danish software quality. In SoftwareQuality: State of the Art in Management, Testing, and Tools,Wiezorek M, Meyerhoff D (eds). Springer-Verlag: Berlin,46–60.

Rainer A, Hall T. 2002. Key success factors forimplementing software process improvement: amaturity-based analysis. Journal of Systems and Software62(2): 71–84.

Stelzer D, Mellis W. 1999. Success factors oforganisational change in software process improvement.Software Process Improvement and Practice 4(4): 227–250.

Strauss A, Corbin J. 1990. Basics of Qualitative Research:Techniques and Procedures for Developing Grounded Theory.Sage Publications: Beverly Hills, CA, 240.

Strauss A, Corbin J. 1998. Basics of Qualitative Research:Techniques and Procedures for Developing Grounded Theory,2nd edn. Sage Publications: Beverly Hills, CA, 288.

Zahran S. 1998. Software Process Improvement: PracticalGuidelines for Business Success. Addison-Wesley: UpperSaddle River, NJ, 480.


DOI: 10.1002/spip 539

success with improvement — requires the right roles to be enacted — in symbiosis

Documents