Identification of the main problems of change management in software development companies: research in the CEE region Текст научной статьи по специальности «Экономика и бизнес»

Identification of the main problems of change management in software development companies: Research in the CEE region

Denis S. Pashchenko

Independent consultant in software domain

Address: 40/12, Nizhnya Krasnoselskaya Street, Moscow, 105066, Russian Federation E-mail: denpas@rampler.ru

Abstract

Studying the typical problems in the software development process always has two approaches: the strategic view of the team of top managers focused on the IT business and the practical view of software project teammates - engineers, analysts, software quality assurance specialists. This article is dedicated to research of change management in software development processes in Central and Eastern Europe, including Russia, as one of software centers in this region. The research was carried out in the middle of 2014 and covers 78 experienced developers and analysts of the domain from 11 countries. The research has three sections: change planning, change implementation and consolidation of the new practices. The research is focused on key measurements and risks in all stages of change implementation from its planning up to analysis of results.

In the article, we present the project approach to change management with four stages: planning change, preparing the environment, change in details, change implementation. For each stage, we highlighted several typical problems and gave practical recommendations. Special attention was paid to research of long-term problems which cover the whole project of change management. These problems include: organizational resistance, changes goal's management, involvement of teammates and managers in the change management process. Practical recommendations in the final section of the article are focused on change management's best practices in the software domain as regards planning, delivery and consolidation of changes.

Key words: change management, improvement of software production, organizational resistance, software company.

Citation: Pashchenko D.S. (2016) Identification of the main problems of change management in software development companies: Research in the CEE region. Business Informatics, no. 3 (37), pp. 54—61. DOI: 10.17323/1998-0663.2016.3.54.61.

Introduction

The complexity of change management in software production is a well-known problem of the IT branch all over the world. There are a lot of cases when customers, top-managers of IT companies and common engineers have absolutely different points of view on the current level of product quality and process

model of development. Convergence of those views and raising software quality often requires changes in production processes.

In the CEE region (Central & Eastern Europe), part of the evolutionary process of process development, which went on worldwide in commercial software development from the 1970s and 80s, was missed at the end of 90s, when new and progressive ISVs (Independ-

ent Software Vendor) and out-sourcing companies implemented modern models of processes based on the CMM (Capability Maturity Model) and RUP (Rational Unified Process). There also are a lot of IT companies in CEE countries and Russia which built their own process models of software production themselves, basing them on the habits of management, sometimes without taking into account end-customer expectations. On the other hand, during the last 10 years newly appearing software companies have tried to use agile and hybrid methodologies. In the author's research, the overall experience and opinions of 78 engineers from different kinds of software companies have been grouped and identified:

♦ current experience of CEE software industry in production process improvement;

♦ successful approaches in change management;

♦ role of project management and formalization in change management;

♦ key factors of resistance and cooperation of the participants of process improvement.

The view of engineers showed: how change management practices, measurements and results are estimated from production projects level by real participants of software development. Meanwhile, IT companies from the CEE region (and first of all from Russia) are playing an important role in the world market's software development and have a rapidly growing share [1]. This means that success in production and business improvement in these companies has a strong impact on the regional economics.

The IT branch is changing very rapidly in terms of technologies, automation tools, modern methodologies, educational standards and end-customer expectations. This means that production processes should be flexible and be capable of rapid change [2]. Proven approaches and practices in change management give additional chances for successful production, business improvement, and meeting customer requirements.

1. Research method and process

Research was conducted during the period from April to July 2014 by three rounds of Delphi study, which is one of the most relevant methods for long distance expert polling covering a big geographic area [3]. Seventy-eight experts from Central and Eastern Europe (including Russia, Ukraine and Belarus) have taken part in this research. All experts are real teammates in software

delivery projects with a great deal of experience in the industry and almost all of them have a significant career and project history in leading software companies.

It would be correct to assume that the results of research in the middle of 2014 would be relevant for the middle of 2016 because business practices in change management in the software domain in the CEE-region have low volatility. By contrast, in China, India and the USA, we may see another situation: new approaches in software production and technologies are being implemented much faster and drive the business. This means that change management becomes more sophisticated and usual in the operations of IT companies. On the first round, the panelists have sent their opinion and answers on a list of questions with four sections:

common questions about role of process formalization;

planning of changes in production processes; process of implementation; consolidation of the results.

In the second round, the panelists received the leading opinion of the expert panel for all of the questions, thus giving them a chance to correct their opinion or just give a comment.

In the third round, the panelists gave additional information and comments, which helped to improve the Delphi study results and objectiveness.

The following table contains the numbers of active experts for each of the study's rounds (Table 1).

Table 1.

Activity of experts for rounds of the Delphi study

Round 1 Round 2 Round 3

Active experts 78 61 78

Percent of active experts 100% % co 7 100%

In round 2, we faced an obvious decrease of expert activity.

The following bullet points demonstrate different information about experts, their experience and geographical locations. The experience presented is usually most relevant for the same type of IT companies. Types of IT companies were present in Delphi Panel in the following ratio:

• 9% of the experts had experience at non IT companies with in-house development;

♦ 11% of the experts have experience at software system integrators;

♦ 31% of the experts have experience at software vendors (ISV);

♦ 49% of the experts have experience from tailor-made software companies (including the out-sourcing model).

CIS-region geography of the research is as follows:

46% of the experts are from Russia and Belarus;

26% of the experts are from the Balkan region (Serbia, B&H, Moldova, Bulgaria);

15% of the experts are from Central Europe (Czech Republic, Slovakia, Hungary);

13% of the experts are from Poland and Ukraine.

Most of the experts have been working in the software development area for a considerable number of years, so there are not many experts in the panel working in IT sector for less than 5 years:

7 % experts are working in the software development area from 2 to 5 years;

44% experts are working in the software development area from 5 to 10 years;

49% experts are working in the software development area for more than 10 years.

0% experts are working in software development area less than 2 years.

2. Results 2.1. Planning and preparing for change implementation in software production model

In this section we discuss core actions and preparations for change implementation including its initiation, planning, announcement, involvement of management and teammates in the activities.

Experts couldn't define a direct dependency between the whole company efforts, early planning and change management in software production. It seems that the process of innovations in development process model do not have a pre-defined regularity.

Question: Does the process of changes implementation in software production have a regular character?

♦ 23% of experts: Yes, on the level of the whole company;

♦ 36% of experts: Yes, on the level of each project;

♦ 3% of experts: No, changes are implemented spontaneously;

♦ 38% of experts: Partly it has regular character, partly it comes spontaneously.

The panel agreed that a major role is played by the project manager in initiating production process model changes but with some reservations. Firstly, in agile teams, the role of the PM is not so significant and everybody can initiate changes. Secondly, the quality direction in the company could have project managers as persons involved part-time.

Question: Who is the initiator for changes implementation in SW production model in most cases?

54% of experts: Project manager;

21% of experts: Quality / Process development direction;

21% of experts: Members in project teams;

5% of experts: Lead person of the company / software department.

In the experience of almost half of the experts in project teams, changes were announced right before implementation. Also in the practice of 70% of the experts, formal announcement by the Employer was a popular measure, commonly used for staff preparation. About 65% of the experts could remember "Involvement of analysts and engineers in production changes planning" in change management practices in their companies.

Almost 55% of the experts said that from their experience the "buffer period", given for a software engineer's preparation for new production practices is about a few weeks. And only 25% of the experts met cases when preparation for new practices took less than one week. Some experts noticed that each project team should have its own plan of changes implementation even if it was prepared on the "whole company level". Of course, we are discussing only significant changes like implementation of requirements management or the "sprint releases" approach.

Experts defined the most popular measures of change's announcement in production processes as:

• special meetings with line and project managers (in practice of 99% of experts);

• announcement by CEO or CTO (in practice of 30% of experts);

• determination most often of reasons of changes in production processes;

• objective needs of change (in the practice of 64% of experts) in accordance with current economic results in the company or projects;

• following customer or auditor requirements and market's expectations (in the practice of 62% of experts).

Despite different patterns in software development and formal equality in agile project teams, according to the opinion of the panel, exactly the project manager still has the biggest personal responsibility for the success of changes implementation in software production processes.

Question: Who has the biggest personal responsibility for the success of changes implementation in SW production processes?

44% of experts: Each project manager in his production project;

26% of experts: Head of software production department;

26% of experts: All project teammates;

4% of experts: Initiator of changes despite his job title.

2.2. Change implementation in software development processes

In this section, we discussed problems of change implementation, common methods, risks and priorities. The main idea of this section was to define the best approaches in practice to change implementation on the project level.

Experts summarize the most popular methods of practical change management in software companies:

♦ verbal orders and supervision by the project manager (met in the practice of 59% of experts);

♦ publication of orders and instructions, changes in business processes (met in the practice of 57% of experts).

This means that on the project level all changes should be supported by the project manager, but also rebuilt business processes should prevent ignoring the changes.

Of course, automation of production processes in software development is one of the key features [4]. The panel saw a positive and significant role of automation tools in changes management.

Question: How does automation of software delivery processes support change implementation in the production model?

23% of experts: Automation is not connected with changes implementation;

8% of experts: Automation allows ignoring all changes in production processes;

64% of experts: Automation makes teammates follow all changes in production processes;

5% of experts: Automation of processes could be circumvented and changes could be ignored.

Experts identified a list of strong problems, typical for change management and process standardization in IT companies. First of all, "Formal implementation without understanding of its sense and goals" (met in the practice of 77% experts) and "Conflicts between goals of a project and goals of implementing changes" (met in the practice of 54% experts). Experts also found that a "Sharp drop in the quality of software and/or release delivery schedule" is a strong risk in the practice of most IT projects.

There are a lot of organizational measures used to increase effectiveness of change management. But specific features of the IT branch require additional arrangements to overcome organizational resistance. Experts defined a few effecive meatures:

• explanatory work with suppressed elements (met in the practice of 61% of the experts);

• involvement of resisting staff in implementation of changes (met in the practice of 48% of the experts);

• positive motivation for accepting changes.

Motivation of involved staff is a key factor in change

management, but not all measures can be used directly. The panel defined a list of common arrangements:

inspiring and encouraging the use of new practices (met in the practice of 82% of the experts);

public censure for failing to follow the implemented Standards (met in the practice of 31% of the experts).

Change management and production process standardization often meet an interesting contradiction, when changes interferes with current production goals and staff KPI. Experts do not much worry about this issue.

Question: How often are the goals of changes implementation more important than the current activity of producing the product of the project? 3% of experts: Very often; 31% of experts: Often; 59% of experts: Seldom; 7% of experts: Never.

The panel also identified some typical costs for each project during change implementation:

• costs of quality and/or product delivery deadlines (met in the practice of 85% of the experts);

• worsening the internal climate in the project team (met in the practice of 31% of the experts);

• part of staff is leaving the team / company (met in the practice of 27% of the experts).

This means that change implementation on the last stage of product delivery could be a real risk for common project success and on all stages needs a set of corrective actions.

2.3. Changes consolidation and analysis of results

Changes in the production model need a strong consolidation supported by all involved persons. In this section, experts gave their vision of effective measures of changes consolidation and analysis practices of final results in IT companies.

There are a few common and typical arrangements for changes consolidation:

• audit from the project manager's side (met in the practice of 69% of the experts);

• automation processes according implemented standards (met in the practice of 56% of the experts).

• documenting changes in project artifacts (met in the practice of 49% of the experts);

• encourage the use of new practices (met in the practice of 37% of the experts).

New implemented processes also need a regular control of execution by teammates. Experts defined a set of effective arrangements:

audits from the project manager side (met in the practice of 60% of the experts);

analysis of incidents after failures in the software product (met in the practice of 57% of the experts).

The panel shared their experience in change management and its results in their companies.

Question: Usually how successful do you reach the goals of significant change implementation in software delivery?

• 3% of experts: Almost all targets are lost;

• 46% of experts: Part of the goals are lost, details vary;

• 46% of experts: Achieved most of the goals;

• 5% of experts: The goals are achieved, and the results are superior to expectations.

Analysis of results is a crucial activity that helps in change management improvement and allows us to define all key parameters of internal process development in general. Of course, scheduling of this analysis is also important.

Question: When is analysis of changes implementa-

tion in software delivery usually performed?

23% of experts: It may be on any schedule;

59% of experts: The analysis is performed a few months after changes implementation;

8% of experts: The analysis is performed only before planning the next changes;

10% of experts: Nobody cares about such analysis.

As one of the key ideas of research, change management should be convenient for teammates and its negative influence on production goals should be reduced as much as possible. Experts shared a vision of regularity of changes and in common agreed that for projects (or iteration of big projects) it is better to avoid implementing two significant changes in the software development processes.

Question: What time period is considered to be convenient and effective between implementation of two significant changes in the software development processes?

51% of experts: Better to avoid it in one project;

11% of experts: A few months;

15% of experts: A few weeks;

23% of experts: Hard to answer.

Conclusion

This part of the article is focused on an overview of the cycle of change management and results of research, demonstrating different aspects of each stage of cycle. The process of change implementation in the software production process model could be illustrated by the following diagram and was presented by the author from different perspectives [5, 6]. In short, it's a spiral with four main stages:

♦ planning change;

♦ preparing the environment ;

♦ change in detail;

♦ change implementation.

During all stages, the formal team of change management is working on updating and executing the change implementation plan and minimization of special risks, like organizational resistance, maintaining the trust of top and middle management and avoiding contradiction between goals of production and changes.

There is one iteration of the change implementation loop on the level of software production project (Figure 1).

Estimation of level of organizational resistance

Analyze of change implementation

Correction of goals, plans, risk management Implementation plan realization

Change implementation

Overcoming of organizational resistance

Actual Risk Plan

Corrected Working Plan

Fig. 1. Stages of iteration of change implementation cycle

The research sections cover all stages of iteration and are focused on special risks and aspects of each stage and the process as a whole.

In stages of planning and preparing the environment, experts defined a need of change implementation process formalization. The panel recommended using the same sets of documentation for an internal project of process improvement like for most of external software / consulting projects.

Based on the research results, the authors also recommend paying attention to the formal stage of planning, when the manager of this kind of internal project may spend time on risk management and planning important items:

additional time reserves;

involving external consultants in some stages and activities (like training or audits);

all arrangements and actions aimed on the overcoming typical implementation problems;

& working with support and loyalty of the top and middle managers, which may help pass the critical points of the project.

There are two well-known problems in such kind of projects that may be envisaged in the planning stage:

lack of time and lack of resources. Additional time reserves could help to mitigate the first risk, and involving top managers could help with the second. Support of the top managers (like CEO, CTO or COO) could be a strong helping factor, giving an additional chance for the project of software production process improvement to succeed. Involving the top managers in changes management on a high level may be the most valuable resource in this stage.

Experts also found that the project manager is the key person in change management on the project level, and this means that any team of change management should spend some efforts involving and keeping the loyalty of that level of management.

According to the view of the panel, informing staff about changes in the production process early occurs seldom, but is an effective measurement like kick-off meetings or engineer's involvement. Exactly line-managers and the project manager are in charge of these informational activities.

Changes implementation is not only a plan, but a set of documents, actions, reviews, etc. This Delphi study has shown that these arrangements are supported on different levels: in the current project, in software production department, on the level of the whole IT company.

It's absolutely expected by the common engineers if automation of process makes everyone follow changes.

Changes implementation faces with a lot of risks and problems in IT companies. This Delphi study has demonstrated some of these problems, e.g. formal implementation without results and without its understanding by employees, contradiction between project and changes goals and even organizational resistance. Solving these problems requires from the internal project team a lot of effort and attention during all implementation stages.

The experts also defined a set of well-known risks that may be incurred during change implementation:

• sharp drop in the quality of software and/or release delivery schedule;

• drop of team's motivation and rise of conflicts inside project team.

Change implementation also provides a "Costs of quality and/or product delivery deadlines" that requires additional efforts in software quality and project management from the team.

Of course, the team of change management is trying to resolve these issues and research has demonstrated that "soft" methods are more relevant. Perhaps, this is because of the engineer's structure of our expert panel, but the most relevant arrangements looks like:

• explanatory work with suppress elements;

• involvement of resisting staff in implementation of changes;

• inspiring and encouraging the use of new practices.

"Rough" methods like "directive repression" or

"fines" are not expected and are not widespread in IT companies. The author also could advise the use of only "soft" methods and nto be sparing of efforts in explanatory work at all stages of the change management loop.

Consolidation of changes is a crucial point in all kinds of business process reengineering. Experts be-

lieve that exactly the project manager can effectively perform audit execution of new practices, estimate the results, adjust use of new practices in production project. This practically means that efforts of centralized audits should be aligned with needs of the project manager and the loyalty of the project manager should be kept on a high level even after formal change implementation.

From the research results, the author may also recommend formalization and documentation of the results of an internal project no matter what its results. This kind of report may be used in planning the future process improvement, or during the corrective actions in the next stage of changes implementation.

Experts from the engineers' environment are much more optimistic in their estimation of change implementation results from their experience than IT managers as seen in previous research of the author [7]. The expert panel agreed that in change management every subsequent attempt is more successful than the previous one; that is indirectly confirmed by the rationality of the set of cycles in process improvement.

Change management should be comfortable for project teams and not make engineers spend too much attention and time in production projects. The main idea is to reduce stress situations for the team and their needs to spend more efforts overcoming it while keeping high quality and speed of software development.

The research has shown the importance of process improvement and standardization that needs a planned and balanced approach for change implementation at all levels: a project, a software production department and the whole company. The panel responses, especially in consensus opinions, have demonstrated the need to consider all the factors of organizational resistance and teammate's involvement at each stage of a project involving changes implementation. ■

References

1. Software Russia (2G12) Russian Software Industry Overview. Available at: http://www.software-russia.com/why_russia/industry_overview (accessed 25 May 2G16).

2. DeCarlo D. (2GG4) eXtremeproject management: Using leadership and tools to deliver value in the face of volatility. Jossey-Boss: Whiley.

3. Linstone H.A., Turoff M. (1975) The Delphi method: Techniques and applications. Reading: Addison-Wesley.

4. Pomeroy-Huff M., Mullaney J., Cannon R., Sebern M. (2GG9) The Personal Software Process (PSP) Body of Knowledge, ver. 2.0. Special report CMU/SEI.

5. Pashchenko D.S. (2G12) Proektirovanie organizatsionnykh izmeneniy v IT-kompaniyakh s uchetom faktorov protivodeystviya [Design of organizational changes in IT companies taking into consideration resistance factors]. Management and Business Administration, no. 4, pp. 17G—179 (in Russian).

6. Pashchenko D.S. (2G14) Features of change management projects in Russian software development companies. Project and Program Management, no. 1, pp. 22—32.

7. Pashchenko D.S. (2G14) Effektivnye praktiki vnedreniya izmeneniy v protsessakh razrabotki programmnogo obespecheniya na urovne proekta [Efficient practices of changes management in software development processes on project level]. Management and Business Administration, no. 4, pp. 166—174 (in Russian).

ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

Основные проблемы управления изменениями в компаниях, разрабатывающих программное обеспечение: Исследование в Центральной и Восточной Европе

Д.С. Пащенко

кандидат технических наук, MBA

независимый консультант в области разработки программного обеспечения Адрес: 105066, г. Москва, ул. Нижняя Красносельская, д. 40/12 E-mail: denpas@rampler.ru

Аннотация

Статья посвящена проблемам внедрения изменений и улучшений в компаниях, производящих программное обеспечение (ПО). Статья позволяет взглянуть на данный процесс не только на стратегическом уровне, что присуще менеджменту компаний, но и осветить практические проблемы, с которыми сталкиваются рядовые сотрудники проектных команд — разработчики, аналитики, специалисты по качеству ПО. Все выводы и заключения основаны на авторском исследовании, проведенном в 2014 году среди 78 экспертов из 11 стран Центральной и Восточной Европы, включая Россию, как один из центров разработки ПО в данном европейском регионе. Исследование было направлено на поиск решений актуальных проблем управления изменениями от этапа их планирования до анализа результатов.

В статье предложен проектный подход к управлению изменениями, включающий четыре стадии — планирование, подготовка среды к изменениям, детализация изменений, внедрение и закрепление новых практик. Особое внимание уделено проблемам, которые сопровождают все стадии такого проекта: организационному сопротивлению, необходимости управлять целями изменений, вовлечению проектных команд в управление изменениями. Практические рекомендации, представленные в заключительной части статьи, отображают лучшие практики в отрасли разработки ПО на всех стадиях такого проекта.

Ключевые слова: управление изменениями, улучшение производства программного обеспечения, организационное сопротивление, софтверная компания.

Цитирование: Pashchenko D.S. Identification of the main problems of change management in software development companies: Research in the CEE region // Business Informatics. 2016. No. 3 (37). P. 54—61. DOI: 10.17323/1998-0663.2016.3.54.61.

Литература

1. Russian Software Industry Overview. [Электронный ресурс]: http://www.software-russia.com/why_russia/industry_overview (дата обращения 25.05.2016).

2. DeCarlo D. eXtreme project management: Using leadership and tools to deliver value in the face of volatility. Jossey-Boss: Whiley, 2004.

3. Linstone H.A., Turoff M. The Delphi method: Techniques and applications. Reading: Addison-Wesley, 1975.

4. Pomeroy-Huff M., Mullaney J., Cannon R., Sebern M. The Personal Software Process (PSP) Body of Knowledge, ver. 2.0. Special report CMU/SEI, 2009.

5. Пащенко Д.С. Проектирование организационных изменений в IT-компаниях с учетом факторов противодействия // Менеджмент и бизнес-администрирование. 2012. № 4. С. 170—179.

6. Pashchenko D.S. Features of change management projects in Russian software development companies // Project and Program Management. 2014. No. 1. P. 22-32.

7. Пащенко Д.С. Эффективные практики внедрения изменений в процессах разработки программного обеспечения на уровне проекта // Менеджмент и бизнес-администрирование. 2014. № 4. С. 166-174.

БИЗНЕС-ИНФОРМАТИКА № 3(37) - 2016