CC BY-NC-ND
70
STANDARDIZATION IN SOFTWARE PRODUCTION AT THE CORPORATE LEVEL: RESULTS OF RESEARCH IN CIS
Denis PASHCHENKO
Independent consultant in software domain
E-mail: [email protected]
Andrey BLINOV
Professor, Department of General Management, Faculty of Management,
Financial University under the Government of Russian Federation;
Corresponding Member of the Russian Academy of Natural Science
Address: 49, Leningradskiy Prospect, Moscow, 125993, Russian Federation
E-mail: [email protected]
f . \
This paper focuses on challenges associated with modification and enhancement of process models in software production in CIS region, usually accompanied by specific risks and organizational resistance, and aggravated by weakness of formal corporate change management structures. All findings and conclusions are based on authors'survey carried out at the end of2013 that covered 21 managers ofsoftware companies from CIS. The study was aimed to address challenging issues ofsoftware production standardization and certification, organizational resistance and other specifics of change management at the level ofan entire company. This paper highlights relevant institutional interventions to support change management at planning, staff preparation and change implementation phases. The experts have ascertained that the systemic approach to change management is needed, including formal change planning activities and establishment ofa special team change management for an internal project. Also the experts have shared their practical experiences and outputs: typical challenges, change reinforcement techniques and transformation timeframes.
The authors have resumed their research findings by formulating the following recommendations: to use a 4-stage lifecycle change plan, to manage general and specific risks at all stages, to formalize change management and to use change implementation analysis results in future practice.
Key words: changes implementation management, software production improvement, organizational resistance in software company.
Introduction
The complexity of standardization in software development is a well-known problem of the IT industry in all over the world. In CIS (Commonwealth of Independent States) region a part of that evolution process was missed at the end of 1990s, when new and progressive ISVs (Independent Software Ven-
dor) and outsourcing companies implemented advanced process models based on CMM (Capability Maturity Model) and RUP (Rational Unified Process). There are also plenty of IT-companies in CIS countries, which have built their own process models of software production themselves, basing them on habits of management, sometimes without taking into account end-customer
expectations. On the other hand, over the last 10 years software companies - newcomers have tried to use agile and hybrid methodologies. In the authors' survey overall experiences and opinions of 21 experts from different kinds of software companies have been grouped and identified:
♦ effective approaches in process improvement and change management;
♦ key factors of resistance and cooperation of participants in processes improvement;
♦ possible future scenarios of software development improvement.
Meanwhile, IT-companies from CIS (and first of all from Russia) have been playing an increasingly important role in the world market software development and have been enjoying a rapidly growing share. It means that success in production and business improvement at these companies has a strong impact on the regional economy.
The IT industry has been evolving very rapidly thanks to its technologies, automation tools, modern methodologies, educational standards and end-customer expectations. It means that production processes should be flexible and capable to accommodate to rapidly changing environment [1]. Proven approaches and practices in change implementation give additional chances for successful production, business improvement, and meeting customer requirements.
A Russian software production enterprise is an interesting field to observe, how modern approaches in change management and software development process standardization gain new highlights and specific aspects in half-isolated conditions.
1. Research method and process
The survey was conducted in the period since September 9 till December 18, 2013 by a 3 round-Delphi study. Twenty-one Russian speaking experts from CIScountries took part in the survey. All experts were leading managers at their companies: from project managers with team of 15 + people to software quality directors and CEO of software companies with hundreds software engineers.
In the first round the panelists sent their opinion and answers on the list of questions split into 3 sections:
common questions about influence of production processes standardization and company certification on the quality of software products;
special questions about experience and best prac-
tices at the level of production of the whole company;
prognosis and opinions concerning 10 years perspective of software development process models and instruments in CIS countries.
In the second round the panelists received principal opinion of experts' panel for each of the questions. If expert's answer differed from the principal opinion, the expert could correct his answer or just give a comment.
In the third round the panelists gave additional information and comments that helped to improve Delphi study results and objectivity.
The process of gathering experts' opinions is worth being described in more details in this article, as well as generalization of the results in the form of ranked lists and bar/pie charts.
When the responses collected were analyzed during the first round, for each question the dominant (principal) opinion was selected to become the general consensus of the panel. In the 2nd round the responses of each expert were compared with the principal opinion of the panel to provide an expert with an opportunity to change or to comment.
As a result, for every multiple-choice question a ranked list with the dominant response was received at the beginning. If expert's answer was not in the top of answers list, then in the 2nd round comment from his side was requested.
For questions with one possible embodiment of the response charts were built to demonstrate popularity of answers in percents. It helps to receive the whole panel's opinion and to further develop the methods and recommendations.
The following table contains the number of active experts for each of the rounds.
Table 1.
Activity of experts for rounds of the Delphi study
Round 1 Round 2 Round 3
Active experts 21 16 21
Percent of active experts 100% 76% 100%
In round 2 we faced obvious decrease of expert's activity.
The following charts show different information about the experts, their experience and geographical locations.
Presented experience is usually most relevant for the same type of IT-companies [2]. Types of IT-companies were presented in Delphi Panel in the following ratio:
♦ 10% of the experts with experience at non IT-companies with in-house development;
4- 14% of the experts with experience at software vendors (ISV);
4- 29% of the experts with experience at software system integrators;
♦ 48% of the experts with experience at tailor-made software companies (include out-sourcing model).
CIS-region geography of the survey is presented below:
57% of the experts from Moscow and Sankt-Peters-burg (Russia);
19% of the experts from other cities from Russia;
14% of the experts from Ukraine;
10% of the experts from other countries of CIS region.
The experts presented the middle age group, usually considered in the IT area as the apex of creativity and professional activity:
• 5% of the experts at age 20-29;
• 62% of the experts at age 30-39;
• 33% of the experts at age 40-49;
• 0% of the experts at age 50+.
Meanwhile, most of the experts had been working in software development area for considerable number of years, so there were no experts in the panel working in the IT sector for less than 5 years:
♦ 19% experts had been working in the software development area from 5 to 10 years;
♦ 81% experts had been working in software development area for more than 10 years.
2. Results Section 1. Overview of standardization of software production
In this section the experts answered questions relating to importance of software production process standardization and official company's certification. Also in this section detailed perspectives of process model improvement were included.
According to the principal opinion of the panel, there is a strong and visible correlation between software development process standardization and final quality of software products. Most of the experts consider that standardization is a key factor of high quality in software development. On the following diagram and all others
60 50 40 30 20 10 0
54.2
23.8 19
4.8 1 1
1- Always influences 3 - Sometimes influences
2 - Often influences 4 - Almost do not influences
Fig. 1. How often does software development standardization influence the final quality of software product?
numbers mean percent of experts that have chosen the relevant answer (Fig. 1).
Actually it implies that one of approaches of company's management to impact the quality of software production is to establish a quality control department that should work over standardization of process model and improve quality of software products. CIS experts rely on standardization as a key method for product quality improvement with some additional remarks: time schedule and even opportunity of process standardization depends on many factors, such as:
a. Qualification of project office and software production management;
b. Common character of all produced software products.
The principal opinion of the experts about obligatory certification for a company is not so clear. About 25% of the experts have not seen any relation between well-known certifications or appraisal (like ISO, ICAg-ile or CMMI) and high quality of software products. A big share (about 43%) of the experts has considered that official certification could confirm high quality of software only sometimes. Meanwhile, some experts have remarked that even preparation for certification and first audits may temporary increase software quality. But typical opinions were quite different:
«... often company do not support requirements between certifications and do not manage the quality of software...» or «there is a lot of cases then CMMI Appraised software companies do not support their own standards in more than one reviewed project».
Experts' opinions about predominance of any kind of process models in software development in perspective of 10 years were different as well. But a trend of popularity decreasing for classic iterative software development
2
3
4
35 30 25 20 15 10 5 0
28.6 28.6
9.5
33.3-
1
2
3
4
1 - Well-known iterative methods (RUP, MSF 3.0, etc)
2 - Well-known agile practices (Agile, Scrum, etc)
3 - Hybrids methods (OpenUP, MSF for Agile, etc)
4 - In-house distinctive models
Fig. 2. Which methodologies and standards from your point of view are promising in the next 10 years for practical usage in software commercial development?
models (like RUF or MSF) appears in CIS countries, and now much more attention is paid to hybrid and agile methodologies. However, a significant share of market would be taken by companies with their own vision of software production models, including picking elements from iterative, flexible and hybrid models. Certainly, last variant means significant predominance of own distinctive expertise of project teams and specialists, rather than simply adaptation of existing standards to a specific software product or region (Fig. 2).
50 40 30 20 10
42.9
23.8 19
14.3 —
1 - Every 2-4 years 2 - Every 4-7 years
3 - Only in case of deterioration in production 4 - No, never
Fig. 3. Is it necessary to do regular process reengineering in software production?
The experts haven't come to a common opinion about needs of regular reengineering of current production process model. But the majority of experts have found that improvement of software production should have been regular even if it has not been done by drastic reengineering (Fig. 3).
In addition to above mentioned, the panel has found that for the CIS companies there have been a lot of
well-known cases, when standardization driven from the center had led companies back to decentralization in quality management (for example, in program of projects or business division). After such kind of decentralization the improvement of processes had been executing at the level of projects or directions.
It means that only dedicated organization units like SEPG (Software Engineering Process Group) or quality management direction may focus all efforts on continuous process improvement or even just on compliance with accepted production standards. Also such kind of unit may proactively audit the needs of partial or full reengineering of process model in software production.
Section 2.
Changes in processes of software production at the whole company level
In this section the experts shared their opinions and experience concerning practices of changes implementation in software development processes at the level of the whole company — or at a separated division (subsidiary), focused on software development at a company. Of course, this experience related to significant changes that have impacted all stages of processes and all the project team members. For example, this kind of change could be implementation of CMMI principals in production or a new approach in usage of agile practices.
Of course, implementation of any organizational improvements starts from the planning stage and includes estimation of its expected effects [3]. The experts have come to an agreement that for an internal project of software production process improvement it is strictly obligatory to have the full and actual set of project documenta-
60 50 40 30 20 10
52.9 /171
0 0
1 - Very important 2 -Some importance 3 - Unimportant 4 - Changes do not have ny common plan and project
Fig. 4. How important is to have a full and actual set of project documentation in internal process improvementin software production (project plan, risk table, resource map, etc)?
0
2
3
4
0
2
3
4
70 60 50 40 30 20 10
-64.7-
29.4
-5.9-
1 -Very important 3 - Some importance
2 - Important 4 - Unimportant
Fig. 5. How important is to have the formal phase of planning in project schedule of changes implementation in software production at the level of the whole company?
tion (like project manifest, plan, risk table, etc.) (Fig. 4).
It is also important to have a formal phase of planning in such internal project (Fig. 5).
The experts have found the following list of arrangements required to get company's staff ready for future organizational and process changes in software development (given in order of popularity, but all the actions presented in Delphi study are relevant):
♦ Kick-off meetings and detailed explanation for the whole staff;
♦ Personal meetings with line and project managers;
♦ Internal marketing support of future changes;
♦ Announcing of changes by the top management.
Thus kick-off meeting is the most common and popular practice that is used in practice of more than 90% of the experts. Strange as it may seem, the «internal marketing support» was met only in experience of 47% of the
100
80 60 40 20
76.. 5
17.6
5.. 9
i i
1 - Very important 3 - Unimportant
3
2 - Some importance 4 - Damage change management
Fig. 6. How important is to form a separate team for internal project of production processes improvement (with participation of different company's managers)?
experts [4], meanwhile «support of ordinary engineers is a well-known factor of success in change management at IT-companies».
Also the panel was sure that a dedicated team for internal project of process improvement should have been allocated. This team should have been formed from managers and leading specialists for whom this team's activities were not the main job at a company, but would rather have complemented their basic functions (Fig. 6).
The experts have also identified the dominant role of company's first person (CEO) for initiating and implementing changes in production processes at the level of the whole software company: in practice of more than 90% of the experts a top-manager significantly helps to overcome internal project's crises, such as personal conflicts or lack of resources. Only 6% of the experts, however, have met a CEO, who has managed this kind of project in software companies directly.
Involvement of the top management at early stages of internal process improvement gives strong benefits and helps to overcome a lot of regular problems. At a company innovators shouldn't be afraid of high expectations or super extra pushing from the top management side, because they rather prefer to watch process of improvement from a distance and correct it only in special cases.
The panel has agreed that a major and most frequently recurring problem was the problem of formal attitude from the side of process participants. This formal attitude means change implementation without significant results and real understanding of its main goals. More than 80% of the experts have faced such kind of problem in their practice. Meanwhile, more than 50% of the experts have encountered huge resistance of IT-company staff, involved in changes of business processes.
It means that explanation and wide debates about goals and process of changes implementation should be started at early stages and should continue through the whole project. There are lots of practices and approaches supporting involvement of company's staff in Total Quality Management [5] or compliance with the standardized processes. Those of them which are relevant for a case should become regular activities in appropriate internal project plan.
The experts have also identified a problem of serious contradictions between current practices in projects at various stages and new approaches that lead to simultaneous maintenance of several different methodologies at a company; obviously it takes more efforts and frustrates
0
0
2
3
4
0
0
2
4
employees. At the same time «imaginary» interest of the top management declaring the high priority of changes, but at crucial moments not supporting the corresponding project, causes significant difficulties.
Generally, the panel has not defined the vector of current customers' influence on internal projects of changes implementation. A significant part of the experts (around 30%) considered that the current stakeholders, interested in a final software product, had not impacted on such kind of internal activities.
The panel has compiled an agreed list of cardinal methods of overcoming staff resistance at software companies (in order of method's popularity):
Involvement of resisting persons into changes implementation;
Positive motivation of the staff to adopt changes; Advocacy with elements of suppression.
70 60 50 40 30 20 10 0
-64.-7-
"5:9"
23.5
-5.9"
1
2
3
4
1 -Goals are almost lost; 2 - Part of goals are achieved
3 - Goals are achieved, details became better
4 - Nobody cares about comparing planned goals and actual results
Fig. 7. How strong are planned goals of changes implementation usually modified at the end of an internal project?
Meanwhile, only 10% of the experts have admitted direct suppression as a useful method.
It's important to compare planned and actual results of changes implementation. Experience of the panel was quite positive (Fig. 7).
On practice it means, that the original planned goals may be sorted in groups and for each group of the goals a separate project stage in process improvement may be scheduled.
Also the time schedule of internal project at a dynamic IT enterprise is really an important project parameter. Experience of the panel shows, that in most cases the originally planned dates have been usually exceeded
(Fig. 8).
50 45 40 35 30 25 20 15 10 5 0
-47-1-
17.6
23.. 5
II.Ö
1
2
3
4
1 - Final schedule has exceeded the planned one by 50% and more
2 - Final schedule has exceeded the planned one by 20-50%
3 - Final and initial planned schedule have been equal
4 - Nobody has estimated time schedule
Fig. 8. How is final time of changes implementation in the production processes at the level of the whole company comparable with planned schedule of internal project?
Thus the additional risk of the lack of time is relevant for such kind of projects, and monitoring of project schedule should be regular and pro-active. At the planning stage a management team should consider possible time reserves.
The panel has agreed that it was important to arrange a formal assessment of change implementation in software production processes at the company level (Fig. 9).
It means that summarizing at the end of an internal project should be formal and should be scheduled in a project plan. Also such kind of reports may be reviewed from time to time, especially at the beginning of next stages of an internal process improvement project.
70 60 50 40 30 20 10 0
64.. 7
35.3
1 2 3
1 - Very important 2 - Some importance
3 - Only in case of successful implementation
4 - Unimportant
Fig. 9. How important is formal summarizing of results of change implementation in software production processes at the company level?
4
70 60 50 40 30 20 10 0
58.9
41.2
0 0
1 - Important for a whole project
2 - Important at some stages (trainings, audits, etc)
3 - Low importance
4 - Damage to a project
Fig. 10. How important is involvement of external consultants in internal project of change implementation in production at the level of the whole software company?
The experts have defined a set of effective steps to reinforce implemented changes in production practice of a company (in order of answer's popularity):
♦ Additional audit of process execution;
♦ Process documentation respecting corporate standards and instructions;
♦ Attention to process or practice in case of recurring defects and problems;
♦ Internal marketing support of implemented changes.
Also the experts have added some actions into the list
of best practices:
♦ Internal trainings;
♦ Automation tools configured according to the new processes.
The panel has mainly identified the role of external consultants in internal projects of production process improvement at the level of the whole company as «important at some stages» (Fig. 10).
3. Conclusions and recommendations
The experts' panel has recommended to use the same or wider set of documentation for an internal process improvement project, than for external software / consulting projects. For such kind of project dedicated team from leading specialists and managers should be allocated, executing these roles at company in addition to their basic functions.
Based on the survey findings the authors may also recommend to pay attention to the formal stage of planning, when a manager of this kind of internal project may spend time on risks management and planning important items: 4- Additional time reserves;
♦ Involvement of external consultants at some stages and activities (like training or audits);
4- All arrangements and actions aimed to overcome typical implementation problems;
♦ To gain support and loyalty of top managers, who may help passing critical points of a project.
There are two well-known problems in such kind of projects that may be envisaged at 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 to address the second one. Support of top managers (like CEO, CTO or COO) could be a strong helping factor, giving additional chance for success to a software production process improvement project. Involvement of top managers into change management at a high level may be the most valuable resource at this stage [6].
Dividing an internal project into phases at its planning phase could help to prioritize its goals and to get additional chances for successful achieving at least part of them.
At the next formal stage of an internal project — preparation of company's staff for future changes [7] — the panel has recommended to start a set of activities, first of all: kick-off meetings and detailed explaining for all the staff. Well-done preparation of employers for future changes may save a lot of time and efforts for innovators at the next stages of an internal project — a detailed study of changes and changes implementation. Change implementation faces a lot of risks and problems at IT-companies [8]. This Delphi study has shown some of these problems, e.g. formal implementation without results and without its understanding by employees, and even organizational resistance. It requires a lot of efforts and attention during all implementation stages from an internal project team. The experts have recommended:
Involvement of resisting persons into change implementation;
Positive motivation to adopt changes;
Advocacy with elements of suppression.
Based on the survey findings the authors may also recommend formalization and documentation of internal project outputs no matter on its results. Such kind
2
3
4
of report may be used to plan future process improvement or to implement correction activities at next stage of change implementation.
The experts have recommended the set of effective steps to assess implemented changes in production practice of a company, such as:
♦ Additional audit of process execution;
4- Process documentation respecting the corporate standards and instructions;
♦ Attention to process or practice in case of recurring defects and problems;
♦ Internal marketing support of implemented changes. The survey has shown the importance of process im-
provement and standardization that needs planned and balanced approach for change implementation at the level of the whole company. The panel responses, especially in consensus opinions, have demonstrated the necessity of considering all the factors of organizational resistance and analysis at each stage of a change implementation project.
The study performed has revealed that the main ideas and approaches in software production standardization have strong reflection in practice of software companies in CIS region — even respecting such CIS-specific factors as ownership structure, strong language barrier with world's software standards & experts, old-style traditions for information technologies. ■
References
1. Lipaev V. (2008) Ekonomika proizvodstva slognyh programmnyh productov [Economical problems of production of complex software products]. Moscow, SINTEG. (in Russian)
2. Parabelum A., Zapirkin D (2011) Razvitie biznesa [Business Development]. Moscow, Infobusiness. (in Russian)
3. Pomeroy-Huff M., Mullaney J., Cannon R., Sebern M. (2005) The Personal Software Process (PSP) Body of Knowledge, ver. 1.0. Special report CMU/SEI.
4. Tsipes G., Kuzmishchev A. (2014) Proekty organizacionnyh izmeneniy v krypnyh kompaniyah: metody ocenki i prinyatiya resheniy [Organizational change projects in large companies: assessment and decision-making methods]. Project and Program Management, no. 1, pp. 6-21.
5. Fowler P., Rifkin S. (1990) Software Engineering Process Group Guide CMU/SEI-90-TR-024. Pittsburg, Carnegie Mellon University.
6. Pashchenko D. (2013) Rol' rukovoditelya IT-kompanii v processe vnedreniya izmeneniyv proizvodstvennye processy [The principal role of CEO of IT-company in the implementation of changes in the production processes model]. The News of Tula State University, vol. 4, part 1, pp. 164-179.
7. Pashchenko D. (2012) Proektirovanie organizacionnyh izmenenij v IT-kompanijah s uchetom faktorov pro-tivodejstvija [Resistance to organizational changes in software development companies]. Management and Business Administration, no. 4, pp. 170-179.
8. Mosyagin M. (2012) Analis neobhodimosti i tekhnologiya organizacionnyh izmeneniy v IT-kompanii [Analysis and technologies of organizational changes in IT-companies]. Theses of program MBA. IT Management School. Available at: http://journal.itmane.ru/node/638 (accessed 10 June 2014).
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
СТАНДАРТИЗАЦИЯ ПРОИЗВОДСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА КОРПОРАТИВНОМ УРОВНЕ: РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ В СНГ
Д.С. ПАЩЕНКО
кандидат технических наук, MBA, независимый консультант в области разработки программного обеспечения E-mail: [email protected]
А.О. БЛИНОВ
доктор экономических наук, профессор кафедры общего менеджмента, факультет менеджмента, Финансовый университет при Правительстве РФ; член-корреспондент Российской академии естественных наук (РАЕН) Адрес: 125993, г. Москва, Ленинградский проспект, д. 49 E-mail: [email protected]
^Ч\\ШМ1М1М1М1М1М1М1ММ1М1М1М1М1М1М1М1М1ММ1М1М1М11М
I Данная статья посвящена проблемам внедрения изменений и улучшений в процессные модели производства %
1 программного обеспечения (ПО) в регионе СНГ, обычно сопровождаемые специфическими рисками и организационным |
I сопротивлением при слабости формальных корпоративных структур управления изменениями. Все выводы и =
= заключения основаны на авторском исследовании, проведенном в конце 2013 года и охватившем 21 руководителя i
i софтверных компаний из СНГ. Исследование было направлено на решение актуальных проблем стандартизации и i
i сертификации производства ПО, организационное сопротивление и другие особенности внедрения изменений на уровне =
= всей компании. В статье приведены необходимые организационные меры, поддерживающие внедрение изменений =
= на этапах планирования, подготовки коллектива и проведения самих изменений. Эксперты установили важность =
= системного подхода к внедрению изменений, включая активности по формальному планированию изменений и =
= созданию отдельной команды для внутреннего проекта. Также эксперты рассказали о своем практическом опыте и |
I результатах: типичных проблемах, методах закрепления изменений, сроках преобразований. Авторы резюмировали =
= итоги исследования, рекомендовав использовать четырехстадийный жизненный цикл изменений, управление общими i
i и специфическими рисками на всех стадиях, формализацию управления изменениями и использование результатов =
I анализа достигнутых изменений в будущей практике. =
У//птIII И III III III III III III III III III II III III III III III III III III III II III III III III III III III III III II III III III III III III III III III II III III III III III III III III III II III III III III III III III III III II III III III III III III III III III in
Ключевые слова: управление изменениями, улучшение производства ПО, организационное сопротивление в софтверных компаниях.
Литература
1. Липаев В.В. Экономика производства сложных программных продуктов. М: СИНТЕГ, 2008.
2. Парабелум А., Зариркин Д. Развитие бизнеса. M.: Инфобизнес, 2011.
3. Pomeroy-Huff M., Mullaney J., Cannon R., Sebern M. The Personal Software Process (PSP) Body of Knowledge, ver. 1.0. Special report CMU/SEI, 2005.
4. Ципес Г.Л., Кузьмищев А.В. Проекты организационных изменений в крупных компаний: методы оценки и принятия решений // Управление проектами и программами. 2014. №1. С. 6-21
5. Fowler P., Rifkin S. Software Engineering Process Group Guide CMU/SEI-90-TR-024. Pittsburg: Carnegie Mellon University, 1990.
6. Пащенко Д.С. Роль руководителя IT-компании в процессе внедрения изменений в производственные процессы // Известия ТулГУ. Экономические и юридические науки. Вып. 4., Ч. I. — Тула: Изд-во ТулГУ, 2013. C. 164-179.
7. Пащенко Д.С. Проектирование организационных изменений в IT-компаниях с учетом факторов противодействия // Менеджмент и бизнес-администрирование. 2012. №4. С. 170-179.
8. Мосягин М. Анализ необходимости и технология организационных изменений в ИТ-компании // Школа IT-менеджмента [Электронный ресурс]: http://journal.itmane.ru/node/638 (дата обращения 10.06.2014).
