Success w ith im provem ent - Requires the right roles to be enacted - in symbiosis Jan Pries-Heje IT-University Copenhagen, Denmark Jørn Johansen DELTA, Denmark Abstract This paper focuses on experiences and results from a Danish national research- and collaboration initiative – Talent@IT - on software process improvement (SPI) involving four software organizations and several researchers. The goal for the ini- tiative was to develop a model and a method – ImprovAbility TM - to improve organi- zations ability to improve and innovate. It is a fact that project members, project managers, process owners, project organ- ization, top managers, involved experts and users all have different roles in relation to a main organizational goal: improving and becoming better at improving. A main part of the research in the Talent@IT project has been to identify the kind of success related to improvement based on analysis on several interviews with the identified involved roles in improvement. This paper presents a role model where the roles are grouped in supporters, suppliers and users and roles are linked to success criteria. Finally it elaborates on how the roles better can be coor- dinated and enacted by using the ImprovAbility TM model. Keywords Process Improvement, Organizational Improvement, Roles, Success 1 Introduction Too many software developing organisations fail when they try to improve. They may go through an assessment. They may start one or more improvement initiatives. They may measure what is done. But somehow they never close the “learning cycle” where they continuously measure, improve, evalu- ate and learn. In fact figures from Denmark shows that more than half of the companies that goes through an assessment never manage to improve successfully. To cope with this high “mortality rate” a research project was initiated in January 2003. The name of the research project was Talent@IT where the word “talent” in the title emphasised the role of people and individuals and their abilities and capabilities. In the concrete Talent@IT took place from 2003-06 and involved IT-University at Copenhagen, PBS, Danske Bank, ATP, SimCorp, and DELTA – with support from the Ministry of Science, Technology and Innovation.
Session I : ?? If we look at a software developing organization then we find that a typical employee will “play a role” in improvement. Most organizations will focus on efficiency and the ability of delivering quality results. Often the main problems in relation to this are late results, missing results or results at inadequate quality due to poor requirements. Improvement is needed at all organizational levels. Everyone (near- ly) has an interest in taking part in improving the organization – and have their “fingerprint” on the im- provement result. In the end improvements are meant to help the employees to do a better job. Prior research in process improvement (PI) has revealed that it is very difficult to reach the goals of efficiency and quality for several reasons. Lack of management commitment, submerged in day-to day work (part time is no time), PI workers living in an ivory tower, missing PI strategy, lack of plan and control, PI undermined by bureaucracy, firefighting and resistance against change. These arguments can be used for product improvement just as well. However, some of the reasons can be seen from more than one side. Take for example “management commitment”. Employees may claim that they miss management commitment or they may say that managers are not involved. But if you on the other hand ask the managers, then they may tell you that they are never informed or they may tell you that the employees prefer not to involve management. Thus the same thing can be seen very differently depending on the role you have. This paper therefore looks at process improvement and different roles. The empirical background for doing this is research from the Talent@IT project, especially Pries-Heje et al. (2003), Eichen & Dreyer (2005) and Elisberg et al. (2006). Furthermore this paper builds on personal experience from working with process improvement in several Danish companies as researchers and consultants. 2 Research Method We selected successful and failed projects as an arena of particular interest from the viewpoint of improving the ability to improve. We can highlight two key reasons for this interest. First, we appreci- ate the learning that can be harvested by looking at projects in retrospective. Second, in opposition to many other studies we decided to look at both SPI projects where other software developers are the users and at traditional IT projects in IT organizations. We used an existing research collaboration called Talent@IT to select companies. As mentioned there are four companies that participated in this research collaboration. Each of the companies was asked to appoint two successful and two failed projects. We asked that the companies appointed two SPI projects and two normal innovation projects, preferably a successful and a failed one of each type. Furthermore we asked to have SPI projects that had delivered results that were used in the innovation projects. We then conducted interviews in the projects. We interviewed the project manager and 1-2 project members. We interviewed the sponsor or owner of the project, typically a manager in the organization. We interviewed the users; for an SPI-project that meant other developers, and for innovation projects that typically meant end users. In 16 projects we conducted more than 50 interviews in the period from summer 2003 to summer 2004. Typically every interview was conducted by two people. One interviewing and one taking notes. Sub- sequently all interviews was transcribed and analyzed using Grounded Theory techniques. 3 Definition of roles The first question that comes to mind when one starts to look at process improvement and roles is of course: What roles are there? One answer to this question is that every activity has someone doing it – the “Performer”, responsible for developing and implementing the improvement activities in the or- ganization. Sometimes the result of doing something is a result that the performer will use but more often there is another person using the results of the activity – the “User”. Furthermore the performers
Recommend
More recommend
