Содержание к диссертации
Введение
Глава 1. Теоретико-методологические основы управления организационными ИТ-проектами 14
1.1. Проблемы планирования реализации ценности в организационных ИТ-проектах 14
1.2. Управление изменениями в организационных ИТ-проектах 27
1.3. Подход к обеспечению устойчивости систем управления проектами, основанный на построении устойчивого расписания 36
1.4. Моделирование обратных связей в системах управления проектами методом системной динамики 39
Выводы по первой главе 49
Глава 2. Развитие методологии и методов управления организационными ИТ проектами 52
2.1. Подход к реализации мониторинга ценности в организационных ИТ-проектах 52
2.2. Развитие метода освоенного объема для мониторинга реализации ценности в проекте 64
2.3. Разработка определения устойчивости системы управления организационным ИТ-проектом 72
2.4. Обоснование характера возрастания трудозатрат на изменения в течение жизненного цикла проекта 80
2.5. Прогнозирование результатов проекта на основе оценки запаса устойчивости 88
Выводы по второй главе 95
Глава 3. Исследование практики управления созданием ценности в организационном ИТ-проекте 97
3.1. Анализ устойчивости системы управления организационным ИТ-проектом 97
3.2. Метрики ценности организационного ИТ-проекта на примере проекта автоматизации бизнес-процессов 103
3.3. Реализация организационной структуры системы управления организационным ИТ-проектом 107
3.4. Управление проектом автоматизации бизнес-процессов с использованием метода реализованной ценности 109
3.5. Верификация закономерностей изменения трудозатрат на изменения в течение жизненного цикла проекта 118
Выводы по третьей главе 124
Заключение 126
Список литературы 129
Приложение 1. Анкета опроса о трудозатратах на изменения в проектах 145
- Управление изменениями в организационных ИТ-проектах
- Развитие метода освоенного объема для мониторинга реализации ценности в проекте
- Анализ устойчивости системы управления организационным ИТ-проектом
- Верификация закономерностей изменения трудозатрат на изменения в течение жизненного цикла проекта
Управление изменениями в организационных ИТ-проектах
В диссертации рассматриваются изменения двух видов: организационные изменения, для осуществления которых предпринимаются исследуемые в работе ИТ-проекты, а также изменения в содержании этих проектов, рассматриваемые как инструмент управления процессом создания ценности. Контекст рассмотрения однозначно определяет и вид исследуемых изменений. Организационные изменения рассматриваются в контексте определения бизнес-целей проекта и мониторинга метрик ценности, а изменения в содержании проекта – в контексте планирования задач проекта и технических свойств ИТ-продукта. При этом в разработанном в диссертации подходе изменения в содержании проекта зависят от данных мониторинга создаваемой ценности и, таким образом, сильно связаны с видением и ходом выполнения организационного изменения, выполняемого на базе выполняемого ИТ-проекта.
В настоящем исследовании не ставится задача развития моделей организационных изменений. Вместе с тем обзор существующих моделей изменений помогает осознать и сформулировать место разработанных в диссертации моделей и методов в методологии управления организационными изменениями на основе проектов. Из использующихся в настоящее время моделей организационных выделим несколько наиболее цитируемых.
Модель Курта Левина [Lewin, 2008] описывает основные этапы изменения: размораживание системы, включающее подэтапы признания проблемы, диагностики проблемы и выбора решения, выполнение изменения, состоящее во внедрении решения и замораживание системы, включающее подэтапы фиксации изменений и обучения. Методы, рассматриваемые в настоящей диссертации, относятся ко всем этапам организационного изменения модели Левина. При этом, поскольку они основываются на мониторинге реализации ценности и на использовании инкрементного жизненного цикла ИТ-проекта [PMI, 2013b], то подэтапы диагностики проблемы, выбора решения и обучения частично отнесены к этапу выполнения изменения.
Модель Коттера [Коттер, 2011] описывает основные ошибки, совершаемые менеджментом при выполнении организационных изменений, а также формулирует восемь шагов, которые необходимо выполнить для того, чтобы успешно осуществить изменение: создание ощущения срочности перемен, создание команды реформаторов, постановка целей и разработка стратегии перемен, пропаганда видения будущего, делегирование полномочий, получение быстрых первых результатов, закрепление достигнутых успехов, укоренение изменений в корпоративной культуре. Коттер уделяет большое внимание созданию видения организационного изменения и его пропаганде, а также получению быстрых результатов и их развитию на последующих этапах проекта организационного изменения. Методы, разработанные в настоящей диссертации, соответствуют данному подходу, поскольку позволяют непрерывно уточнять видение выполняемого в рамках проекта организационного изменения на основе мониторинга создания ценности и анализа полученных на начальных этапах результатов.
Модель Бекхарда и Харриса [Beckhard, Harris, 1987] служит для оценки возможности осуществления изменений в организации. Модель основывается на сравнении произведения факторов сопротивления изменениям с численным выражением факторов преодоления сопротивления. К факторам преодоления Бекхард и Харрис относят неудовлетворенность текущей ситуацией, оценку видения выгод от изменения и удовлетворенность результатами выполнения первых шагов. Подход к управлению созданием ценности, разработанный в настоящей диссертации, оказывает влияние на оценку видения и получение ранних результатов от первых шагов (что оказывает влияние на удовлетворенность заинтересованных сторон), благодаря чему повышается потенциал преодоления сопротивления изменениям в организации и, таким образом, вероятность успеха самих изменений.
Управление изменениями содержания является одной из ключевых областей знания в управлении организационными ИТ-проектами в силу уже упомянутой выше невозможности согласования полной спецификации требований к продукту на ранних этапах выполнения проекта, в связи с которой возникает необходимость внесения изменений в требования к продукту и в содержание проекта по данным мониторинга внедрения организационно-технического решения. Как отмечают Ципес и Кузьмищев, «цели проектов организационных изменений, как правило, не являются четко определенными и могут изменяться. С другой стороны, методы реализации проекта часто либо изначально не определены, либо нуждаются в постоянном уточнении по ходу выполнения работ» [Ципес, Кузьмищев, 2014].
В настоящее время управление многие стандарты управления проектами затрагивают вопрос управления изменениями. Так стандарты международной ассоциации управления проектами IPMA выделяют управление изменениями в качестве одной из технических компетенций менеджера проекта [Андреев и др., 2010; Hermarij, 2013]. IPMA дает общие рекомендации по организации процесса управления изменениями в проектах, которое включает в себя стадии концепции (инициации) управления изменениями в проекте, прогнозирование и планирование изменений, организации и контроля изменений в проекте, анализа и регулирования изменений, закрытия управления изменениями в проекте.
Стандарт PMBoK [PMI, 2013a] выделяет относящийся к группе процессов мониторинга и упраелния процесс «Интегрированный контроль изменений», основная выгода которого состоит в том, что он позволяет организовать рассмотрение запросов на изменения, их документирование и внесение изменений в проект централизованным способом, благодаря чему снижаются риски, обусловленные изменениями, которые вносятся в содержание проекта без рассмотрения.
Стандарт PRINCE2 [OGC, 2009] рассматривает процесс управления изменениями в составе более широкого процесса управления событиями (issues), которые наряду с изменениями содержания включают отклонения от плана, а также проблемы и вопросы.
Брем и Маркус организационно разделяют ИТ-проект на часть, выполняющуюся на стороне заказчика и часть, выполняющуюся на стороне подрядчика [Brehm, Markus, 2000]. Жизненный цикл подпроекта, выполняемого на стороне подрядчика [PMI, 2013b], включает в себя, как правило, следующие этапы: Анализ, Архитектура, Дизайн, Конструирование, Интеграция, Тестирование.
Данные этапы являются перекрывающимися, в зависимости от подхода к поставке продукта проекта могут быть итерационными, инкрементными, а также предполагать различный хронологический порядок этапов жизненного цикла.
Подпроект, выполняющийся на стороне заказчика, включает следующие этапы жизненного цикла, подробно описанные в литературе, посвященной автоматизации бизнес-процессов [Portougal, Sundaram, 2006]: Концептуализация (бизнес-кейс), Конфигурация (подробное описание состава продукта), Развертывание, Передача в операционную деятельность. Также к области ответственности заказчика относится в проектной деятельности извлечение выгод от использования результатов проекта в соответствии со стратегией организации [ГОСТ ИСО 21500-2014, 2015].
Рассмотрим обобщенный жизненный цикл ИТ-проекта с выделением этапов, выполняемых на стороне заказчика и подрядчика (Рисунок 4). Представленная на рисунке последовательность этапов является условной: как будет продемонстрировано в работе далее, зачастую интеграцию и тестирование эффективно начинать непосредственно после разработки архитектуры и выполнять непрерывно до приемки разработанного продукта. Расположение этапов жизненного цикла в последовательности на представленном рисунке в чем-то аналогично связи «окончание-окончание», применяемой при построении сетевых диаграмм, то есть, последующий этап не может закончиться ранее, чем завершится предыдущий. Этап развертывания в различных проектах может выполняться командой подрядчика или командой заказчика. Более того, программный продукт может развертываться и на вычислительных мощностях, предоставляемых заказчику подрядчиком. Это не оказывает существенного влияния на управление изменениями в проекте, поэтому в данной работе на этом внимание не акцентируется.
Также возможны варианты использования итеративного, либо инкрементального или адаптивного жизненного цикла, в которых указанные этапы повторяются в циклах разработки и внедрения разработанной информационной системы.
Развитие метода освоенного объема для мониторинга реализации ценности в проекте
Анализ существующих подходов к управлению организационными ИТ-проектами, проведенный в первой главе, показал, что в силу существования разрыва между техническими свойствами решения, создаваемого в проекте и результатами деятельности организации, определяющими ценность проекта, для успешной реализации проекта усилия менеджмента должны быть направлены не столько на тщательную проработку плана на начальных стадиях жизненного цикла проекта, сколько на построение системы управления, устойчивой к изменениям. Существенную роль в обеспечении устойчивости системы управления ИТ-проектами играет мониторинг и процесс принятия решений о внесении корректирующих действий. Мониторинг включает в себя как контроль процесса разработки, так и контроль реализации ценности продукта. Управление изменениями в проекте осуществляется по данным мониторинга. Ответственным за организацию мониторинга и поддерживающей его системы коммуникаций является руководитель организационного ИТ-проекта.
В данной работе разработан «метод реализованной ценности» (Released Value Management, RVM), представляющий собой модификацию метода освоенного объема, дополненную возможностью мониторинга метрик продукта в их привязке к выполнению работ проекта. Это дополнение позволяет реализовать отрицательную обратную связь в системе управления проектом, что является необходимым условием обеспечения устойчивости системы управления, так как способствует устранению дестабилизирующего влияния расползания требований.
Идея модифицировать метод освоенного объема таким образом, чтобы с его помощью иметь возможность также контролировать реализацию выгод, на получение которых направлен проект или программа, не нова (управление выгодами относится к вопросам программного управления, но в организационных ИТ-проектах той же цели служит управление реализацией ценности, которому и посвящена настоящая диссертация). В 2012 году в США был зарегистрирован патент [Hersch, 2012], который наряду с традиционными индексами продуктивности по срокам и затратам SPI и CPI предлагал ввести в метод освоенного объема индекс продуктивности по реализации выгод BPI
Действительно, такой коэффициент был бы чрезвычайно полезен и позволил бы решить проблему, обусловленную тем, что выполнение всех работ проекта или всех задач программы не гарантирует получение планируемых выгод. Вместе с тем, в версии, зафиксированной в данном патенте, предложен способ определения коэффициента, использование которого ведет к другой проблеме, а именно: BPI, рассчитанный таким способом, не дает возможности дифференцировать ситуации, когда выгоды не получены вследствие того, что не выполнены запланированные работы и задачи, и когда выгоды не получены в условиях выполнения проекта в соответствии с планом, что может быть вызвано тем, что продукт проекта определен неверно и его получение не ведет к реализации планируемых выгод.
Основным отличием разработанного в диссертации метода является привязка плана поставки ценности к плану выполнения работ проекта. Это позволяет в алгоритме управления изменениями различать разные виды отклонений и, таким образом, вводить корректирующие действия, основываясь на фактах.
Коэффициент реализации ценности организационного ИТ-проекта обозначим как PPI. Это вектор, включающий в качестве компонент коэффициенты реализации ценности по конкретным метрикам. Размерность его совпадает с размерностью вектора метрик ценности. Плановое значение метрик ценности в зависимости от освоенного объема - PP(EV). Фактическое значение метрики в данный момент времени -АР. Зависимость от освоенного объема означает, что сопоставление плановых и фактических значений будет осуществляться не на данный момент времени вне зависимости от объема выполненных работ, а по значениям соответствующим освоенному объему. Таким образом, метод позволяет рассчитать эффективность выполненных задач проекта с точки зрения их вклада в реализацию ценности проекта. Это важно для различения причин отклонения от плана проекта, так как, в соответствии со схемой создания ценности, нельзя ожидать реализации запланированной ценности до того, как выполнены соответствующие работы по разработке и внедрению организационно-технического решения.
Освоенный объем для целей метода рассчитывается путем суммирования плановых затрат на выполнение завершенных к настоящему моменту работ. Метод начисления затрат - фиксированная формула [PMI, 2011] с распределением 0 - 100%, что значит, что все затраты начисляются только после выполнения работы. Это связано с тем, что в методе реализованной ценности никакая работа, реализованная не полностью не может создавать бизнес-ценности, а значит, учет таких работ мог бы привести к искажению коэффициентов эффективности управления процессом создания ценности.
Для удобства использования дадим названия вводимым переменным: РР -плановая ценность, АР - реализованная ценность.
Интерес представляют не только значения коэффициентов реализации ценности, но и их связь с коэффициентом эффективности управления по временным параметрам метода освоенного объема SPI. В диссертации рассмотрены различные сочетания PPIt и SPI в контрольной точке.
SPI 1, РРІІ 1. Имеет место отставание от плана в выполнении работ проекта, требуются корректирующие действия для повышения производительности. При этом реализация ценности происходит в соответствии с планом. При этом может наблюдаться и отставание от плана реализации ценности в привязке ко времени. Метод реализованной ценности в отличие от метода освоенного объема в такой ситуации позволяет сделать вывод о том, что вмешательство в процессы реализации ценности не требуется.
SPI 1, РРІІ 1. Имеет место отставание от плана как по временным параметрам, так и по реализации ценности по соответствующему каналу. Метод реализованной ценности позволяет точно установить факт отставания в реализации ценности и запланировать изменения в содержании проекта на более ранних этапах выполнения проекта, когда их стоимость ниже.
SPI = 1, РРІІ 1. Нормальная ситуация. Коррекция не требуется.
SPI 1, РРІІ 1. Выполнение проекта опережает график, при этом ценность создается в соответствии с планом. Есть вероятность того, что выполняются работы из следующего этапа. Если это подтверждается, требуется перепланирование.
SPI = 1, РРІІ 1. Проект выполняется по графику, но имеет место в отставании от плана реализации ценности по одному из каналов. Такое сочетание коэффициентов эффективности является индикатором того, что в содержание проекта включены работы, не создающие ценность, существует потребность в изменениях.
SPI 1, РРІІ 1. Имеет место опережение графика выполнения проекта, но отставание от плана реализации ценности по одному из каналов. Такое сочетание коэффициентов эффективности является индикатором того, что в действительности проект отстает от графика, и из-за проблем в проекте выполняются не те работы, которые должны выполняться в текущих итерациях поставки продукта, а работы из будущих итераций, которые в данный момент не могут создавать ценность.
Последние две ситуации не могут быть определены в случае мониторинга проекта по методу освоенного объема без учета данных мониторинга ценности.
Далее приводится разработанный в диссертации алгоритм выполнения корректирующих действий на основе мониторинга, построенного по методу реализованной ценности (Рисунок 8).
Анализ устойчивости системы управления организационным ИТ-проектом
Опробование разработанных в диссертации методов (метод реализованной ценности и анализ устойчивости) осуществлено в проекте автоматизации бизнес-процессов в ОАО «Московский завод тепловой автоматики» на базе ERP-системы «1С Управление производственным предприятием». ОАО «Московский завод тепловой автоматики» осуществляет процессное производство приборов для автоматизации технологических процессов (преимущественно для отраслей ЖКХ и малой энергетики). Проект автоматизации соответствует определению организационного ИТ-проекта, используемого в данной диссертации.
Выбор кейса для исследования обусловлен его типичностью. Объем рынка систем ERP по данным аналитического центра TAdviser составил в 2015 году 108 млрд. руб., продемонстрировав рост на 9% [Системы управления предприятием (ERP) рынок России [сайт], 2016]. В структуре проектов автоматизации, выполненных с 2005 по сентябрь 2016 года, суммарная доля проектов автоматизации процессного производства составляет не менее 20%. Это число включает автоматизацию производственных процессов в машиностроении, пищевой и химической промышленности и неопределенную часть проектов из категории «Другие» [Отраслевая специфика проектов ERP в России [сайт], 2016]. Лидерами рынка ERP систем по оценке аналитического центра IDC в 2015 году являлись компании SAP (48,9% в денежном выражении) и 1C (32,7%) [Попсулин, 2016]. Таким образом, выбранный проект аналогичен существенной доле проектов внедрения ERP-систем, и поэтому полученные для него результаты могут быть распространены и на другие проекты этого класса.
Тестирование выводов о характере закономерностей изменения трудозатрат на изменения и запаса устойчивости в течение жизненного цикла проекта осуществляется на основе кейс-метода (case study) [Johansson, 2003]. Принцип триангуляции кейс-метода реализуется вследствие использования данных о проекте, полученных тремя принципиально различными способами: на основании отчетности по проекту (объем изменений оценивался относительно первоначального объема проекта по процедурам заказчика, затраты – на основании дополнительных соглашений к договору об оказании услуг и оплаченных счетов), на основании проведенного анкетирования сотрудников организации, задействованных в проектной деятельности, а также интервьюирования представителей высшего руководства компании (генеральный директор, технический директор, директор по производству) для объяснения выявленных закономерностей, относящихся к трудозатратам на изменения в проекте и объему изменений на разных этапах жизненного цикла.
Ниже приводится краткая характеристика проекта, содержащая необходимую информацию для применения разработанных в диссертации методов и оценки их вклада в реализацию запланированной бизнес-ценности.
Цель проекта – автоматизировать бизнес-процессы предприятия (включая бизнес-процессы снабжения, управления продажами, запасами, планирования и управления сборочным производством).
Бюджет проекта – 12 млн. руб.
План реализации проекта по вехам представлен в таблице 3 (разработан в соответствии с жизненным циклом проекта разработки программного обеспечения).
Исполнение проекта происходило по следующему сценарию (контрольные точки соответствуют плановым датам наступления вех проекта):
Контрольная точка 1 (0,5 месяца).
Проведен анализ текущего состояния бизнес-процессов и видения проекта. Начат сбор требований к программному продукту. Выяснено, что бизнес-цель проекта состоит в решении следующих проблем бизнеса:
Сроки поставки продукции превышают средние по рынку, что является существенным для отрасли, так как сроки выполнения проектов автоматизации технологических процессов, выполняемых с использованием продукции компании, зачастую не превышают 1 месяца, и потребность в оборудовании возникает на ранних этапах проекта. Вследствие этого клиенты выбирают продукцию конкурентов, предлагающих поставку продукции в короткие и предсказуемые сроки;
По той же причине важной является безотказная работа оборудования (краткие сроки реализации проектов автоматизации не позволяют тратить время на гарантийную замену оборудования). Одной из бизнес-целей проекта является повышение надежности (безотказности) производимых приборов;
Вследствие долгосрочного планирования производства в условиях неопределенности спроса компания имеет большие запасы как комплектующих, так и готовой продукции. Внедрение информационной системы должно улучшить как точность прогнозирования спроса, так и процессы закупки и выдачи заявок на производство для уменьшения сроков хранения закупленных комплектующих и произведенной продукции.
В соответствии с видением заказчика желаемые улучшения в бизнес-процессах компании с получением ожидаемых выгод от внедрения должны произойти в течение года после передачи продукта проекта в операционную деятельность (через два года после начала проекта).
Контрольная точка 2 (1,5 месяца).
Проведено моделировании бизнес-процессов. Начата разработка спецификации требований. Также начата разработка доработок к информационной системе по уже утвержденной части требований. Выявлены новые требования, оценочный объем которых составляет 17% от объема исходных требований к продукту.
Выполнено 5% от общего объема требований к доработке информационной системы.
Контрольная точка 3 (2 месяца).
Определены основные роли пользователей. Разработка спецификации требований и сценариев использования завершена на 70% (с учетом внесенных изменений). Выявлены новые требования, оценочный объем которых составляет 15,5% от объема исходных требований к продукту.
Выполнено 6% от общего объема требований к доработке информационной системы (с учетом утвержденных изменений).
Контрольная точка 4 (2,5 месяца).
Утверждена архитектура решения. Разработка спецификации требований и сценариев использования завершена на 80% (с учетом внесенных изменений). Выявлены новые требования, оценочный объем которых составляет 14,5% от объема исходных требований к продукту. Осуществлена закупка лицензионных ключей 1С УПП. Проведена установка ядра ИС и первичная настройка.
Выполнено 7,5% от общего объема требований к доработке информационной системы (с учетом утвержденных изменений).
Контрольная точка 5 (3,5 месяца).
В данной контрольной точке было принято решение о перезапуске проекта, так как полученные результаты по доработке ИС (выполнено 8,5% вместо запланированных 40% от общего объема разработки) заказчик нашел неудовлетворительными. Потребность в изменениях и их стоимость была оценена для расчета запаса устойчивости в данной точке.
Данные об исполнении проекта по контрольным точкам сведены в таблицу 4. Объем изменений выражен в функциональных единицах (ф.е.), рассчитываемых из первоначально утвержденного объема требований к продукту (первоначальный объем принят за 100 функциональных единиц). Реализованные требования включают также утвержденные изменения, чем и объясняется расхождение в столбцах учета реализованных требований в процентах и функциональных единицах.
Верификация закономерностей изменения трудозатрат на изменения в течение жизненного цикла проекта
В рассмотренном кейсе подтверждается наличие закономерности экспоненциального возрастания трудозатрат на изменения в зависимости от времени их внесения, а также снижения объема изменений с течением времени вследствие лучшего понимания требований заказчиком (конус Боэма).
Было также проведено анкетирование сотрудников компании, задействованных в проектной деятельности, для выяснения, распространяются ли данные закономерности на другие проекты организации, а также интервьюирование высшего руководства компании для объяснения найденных закономерностей.
Анкета и распределение полученных ответов приведены в Приложении 1. В опросе приняли участие 24 сотрудника компании, роли которых распределены следующим образом:
– Член управляющего совета / спонсор проекта – 3;
– Технический лидер – 5;
– Руководитель проекта – 5;
– Исполнитель / Разработчик – 11.
По итогам опроса были сделаны следующие выводы.
Вопрос 2 анкеты направлен на выявление отношения респондентов к проблеме невыполнения сроков проектов. Проблема является значимой для организации: по оценкам 16 респондентов (67% опрошенных) доля проектов, выполняемых с неприемлемым для заказчика превышением сроков, составляет 50% и более.
Оценки причин, вызвавших значительные задержки сроков проектов (ответы на вопрос 3), отличаются в группе респондентов, выполняющих роли по управлению или руководству проектом (спонсоры проектов, руководители проектов) и в группе респондентов, выполняющих роли по поставке продукта (технические лидеры и разработчики). Первая группа условна названа «Руководители», вторая – «Исполнители».
В группе «Руководители» были выделены следующие наиболее значимые факторы:
1. Изменения в требованиях / содержании работ (29% полученных ответов);
2. Ошибки в декомпозиции задач (21% полученных ответов);
3. Недостаточная вовлеченность команды (21% полученных ответов).
Во группе «Исполнители» наиболее значимыми названы факторы:
1. Изменения в требованиях / содержании работ (31% полученных ответов);
2. Нечеткие требования (22% полученных ответов);
3. Отсутствие у команды информации о целях проекта (11% полученных ответов).
Таким образом, в обеих группах респондентов наиболее значимым назван фактор изменений в требованиях или содержании работ. Можно также видеть, что два других наиболее популярных ответа в обеих группах – различное восприятие одних и тех же проблем, рассматриваемых с разных точек зрения: нечеткие требования делают невозможной качественную декомпозицию задач, а отсутствие у команды информации о целях проекта негативно сказывается на вовлеченности исполнителей.
В соответствии с ответами, полученными на вопрос 4, объем изменений в содержании проектов также оценивается сотрудниками, задействованными в проектной деятельности, как значительный: 58% процентов (14 респондентов) считают, что доля проектов, в которых объем изменений превышает половину изначально запланированного объема, составляет более 50% всех проектов, выполняемых организацией.
Вопрос 5 предназначен для того, чтобы прояснять факторы, влияющие на количество изменений и обусловленные политикой организации в области управления изменениями в содержании проектов. Полученные ответы позволили выявить следующие особенности. Только в 5 (11%) полученных ответов указывалось на то, что при внесении изменений в проект учитываются трудозатраты на связанные изменения в бизнес-процессах. 7 респондентов (16% полученных ответов) в ответе указали на то, что при внесении изменений учитывается влияние связей в архитектуре на трудозатраты. Это говорит о том, что данные практики не являются стандартными в организации. Как было показано во второй главе, связи в архитектуре решения (включая не только архитектуру программного модуля, но и связь с автоматизируемыми бизнес-процессами) являются причиной экспоненциального роста трудозатрат на изменения на поздних стадиях проекта и при их игнорировании в оценках сроков и затрат приводят к расползанию требований.
Вопросы 6 и 7 уточняют влияние того, вносятся ли изменения на ранних или поздних сроках проекта, на превышение трудозатрат на их реализацию по сравнению с планируемыми. С учетом того, что учет связей в архитектуру решения не является общей практикой в организации, можно предположить, что изменения, вносимые на ранних стадиях (когда связей не так много), будут чаще выполняться без существенных превышений трудозатрат, чем изменения, вносимые на поздних стадиях (когда большая часть планируемых связей в архитектуре решения уже реализована). Данное предположение подтверждается ответами респондентов. В ответах на вопрос 6 (об изменениях на ранних стадиях проекта) 14 респондентов (58%) оценили объем изменений, выполняемых с превышением трудозатрат более чем на 50%, как не превышающий 25% от общего числа изменений. В ответах же на вопрос 7 (об изменениях на поздних стадиях проекта) таких оценок было всего две (8%), в то время как 17 респондентов (71%) оценили долю таких изменений как превышающую 50% от их общего числа. Это подтверждает вывод о том, что трудозатраты на изменения возрастают в зависимости от срока проекта, так как с течением времени возрастает число зависимостей модулей архитектуры, и поскольку в компании не стандартизована практика учета архитектурных зависимостей при расчете трудозатрат, это приводит к значительным превышениям затрат на изменения по сравнению с планом.
Отдельного внимания заслуживает факт, что введение в стандарты организации по управлению изменениями в проектах обязательную оценку трудозатрат, обусловленных архитектурными зависимостями изменяемого модуля, хотя и позволит более точно планировать трудозатраты на изменения, но не приведет к их снижению, так как экспоненциальный характер их возрастания в течение жизненного цикла проекта обусловлен тем, что с возрастанием числа модулей решения возрастает также число связей, то есть это системная особенность ИТ-проектов. Снизить зависимость трудозатрат на изменения от времени возможно путем уменьшения связности архитектуры решения, но данный вопрос не относится к компетенции проектного менеджмента.
Вопросы 8 и 9 предназначены для выяснения, оценивают ли сотрудники организации, вовлеченные в проектную деятельность, как существенное, действие закономерности, известной в отрасли как «конус Боэма», то есть снижение неопределенности требований в процессе выполнения проекта. Из ответов на вопрос 8 выяснилось, что 23 респондента (96%) считают, что в течение первой четверти длительности проекта вносится более четверти изменений, а 13 из них (54%), что в течение это времени вносится более половины всего объема изменений. В отношении изменений в течение последней четверти длительности проекта 16 респондентов (67%) считают, что в этот период вносится меньше четверти всего объема изменений. Таким образом, действие «конуса Боэма» в организации подтверждается.
В вопросе 10 выяснялись причины, которые по оценкам сотрудников, задействованных в проектной деятельности, чаще всего приводят к внесению изменений в содержание проектов. Ответы в группах «Руководителей» и «Исполнителей» рассматривались отдельно. В группе «Руководители» наиболее часто назывались следующие факторы: «Ненадлежащее исполнение требований к продукту» (25% ответов), «Жалобы пользователей программного продукта» (21% ответов), «Реализация рисков» и «Лучшее понимание заказчиком требований» (по 17% ответов). В группе «Исполнители» наиболее популярными были ответы «Ошибки в требованиях к программному продукту» (30% ответов), «Жалобы пользователей программного продукта» (22% ответов) и «Лучшее понимание заказчиком требований» (17% ответов). Полученные ответы свидетельствуют о том, что основной проблемой, вызывающей изменения в проектах, является ненадлежащее качество изначальных требований к продукту. А значительное число ответов, указывающих на жалобы пользователей в качестве причины изменений, в обеих группах свидетельствует о том, что вовлечение пользователей в разработку существенно меняет представления требованиях к продукту.