Исследование влияния команды проекта на величину отклонения по срокам

Введение

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

Консалтинговый проект - это поэтапно выстроенная партнерская деятельность Консультанта и Заказчика, решающая комплекс задач по оптимизации и развитию бизнеса.

В рамках проекта Консультант и Заказчик работают совместно, выявляя проблемные моменты в работе компании клиента и разрабатывая план по разрешению этих сложностей и достижению поставленных целей.

Чаще всего целью консалтингового проекта является повышение качества управления, оптимизация бизнес-процессов, управление человеческими ресурсами. «Грамотно спроектированный и реализованный консалтинговый проект способствует повышению производительности труда и эффективности работы систем клиентов» [№, с. 120]

Отличительной чертой консалтинговых проектов является то, что в них, как нигде более, важен человеческий фактор, и человеческие ресурсы являются основным видом ресурсов и статьей затрат в данных проектах. То, насколько руководитель проекта и команда исполнителей профессиональны, насколько большой опыт имеют в исполнении подобных проектов, насколько хорошо разбираются в специфике бизнеса компании-заказчика, значительно влияет на качество конечного результата проекта.

Существует множество видов консалтинговых проектов. Каждый отдельный проект специфичен, решает уникальную задачу, и поэтому этапы жизненного цикла в разных консалтинговых проектах могут различаться. Проект может включать или не включать в себя IT-составляющую, быть направлен на операционную деятельность или же на стратегическое управление компанией, иметь большой или малый масштаб.

В качестве инструмента сокращения отставания по срокам менеджер проекта может использовать увеличение численности персонала, работающего в проекте. Однако, действенность данного метода может быть оспорена, так как существует немало кейсов, в которых, несмотря на многократное увеличение команды проекта, отставание по срокам сократить не удалось. Данное явление зачастую можно наблюдать в проектах, связанных с IT. В случае превышения сроков распространенной практикой является увеличение команды разработчиков, однако, сроки выполнения проекта не только не сокращаются, а наоборот - отставание становится еще больше. Данное явление было впервые описано Ф. Бруксом в книге «Мифический человеко-месяц, или как создаются программные системы», основным выводом которой являлось то, что если проект не укладывается в сроки, то добавление новой рабочей силы задержит его еще больше.

ИТ-проекты и консалтинговые проекты имеют ряд общих характеристик. Во-первых, к ним можно отнести высокую значимость человеческого фактора в их исполнении, широкую распространенность практики усиления команды на промежуточных этапах проекта, а также то, что чаще всего с самым сильным отставанием по срокам проект сталкивается ближе к окончанию. действует не только в ИТ-проектах, но и в других проектах, где большая роль в их исполнении принадлежит человеческому фактору. Примером таких проектов как раз и являются консалтинговые проекты. Таким образом, можно предположить, что закон Брукса актуален также и для консалтинговых проектов, и именно вследствие данного явления проекты сталкиваются с отставанием от первоначального графика, несмотря на предпринятое усиление команды.

Сделать вывод о том, действует ли закон Брукса в консалтинговых проектах, допустимо путем комплексного представления о ходе исполнения консалтингового проекта и влиянии на него команды и ее численности. Для ответа на данный вопрос применим такой инструмент, как системная динамика. Задача такого направления, как системная динамика - описать поведение систем во времени. Это дает возможность анализировать различные сценарии поведения системы, отвечать на вопросы «Что было бы если». Таким образом было бы возможно снизить неопределенность в поведении системы, и, следовательно, сделать ее более управляемой. Также стоит отметить, что системы могут рассматриваться в рамках разных масштабов и границ, и только от этого зависит, что будет рассмотрено в качестве отдельного элемента модели. В основном, каждый элемент может также быть разделен на подэлементы и образовывать подсистемы, причем цели подсистем могут быть различны. Основная задача в том, чтобы они в совокупности способствовали достижению общей цели. В вопросе построения модели важно определить эту границу. Д. Медоуз в своей книге «Азбука системного мышления» приводит следующий пример. Общество является системой, элементами которой являются люди, а каждый отдельный человек, в свою очередь, также является системой, цель которой - функционирование организма (Медоуз, 2011).

Стоит отметить, что каждый проект является системой. Согласно институту управления проектами PMI, проект - временное начинание, предназначенное для создания уникального товара, услуги или получения уникального результата (PMBoK: пятое издание). Также проект всегда выполняется в условиях ограниченных сроков и ресурсов, и множество участников способствуют доведению его до стадии завершения. Таким образом, проект обладает основными характеристиками системы. Во-первых, у каждого проекта есть уникальная, строго определенная цель. Во-вторых, к признакам можно отнести наличие множества функционально независимых подсистем - элементов модели. Причем, цели данных подсистем различаются. В проекте все подсистемы четко взаимосвязаны. Наконец, как и в каждой системе, в проекте присутствуют входы - ресурсы, требования к конечному результату, стандарты и методологии, и выходы - конечный продукт, услуга либо цель.

Следовательно, с помощью системной динамики представляется возможность описать поведение любого проекта, проанализировать ключевые факторы его успеха, снижая риск и неопределенность, а также повысить качество принимаемых управленческих решений, сделав их более эффективными.

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

Таким образом, целью данной работы является исследование влияния размера команды проекта на величину отклонения по срокам при помощи системно-динамического моделирования, выявление причин задержки сроков и эффективных мер по ее минимизации, разработка оптимальных процессов консалтинговых проектов.

Объектом исследования являются консалтинговые проекты. Предмет исследования - отклонение от базовых параметров в консалтинговых проектах и эффективность их исполнения.

Соответственно, рабочей гипотезой данного исследования является то, что закон Брукса действителен для консалтинговых проектов, то есть, добавление новых членов в команду способствует большей задержке сроков завершения консалтингового проекта.

Основные задачи, требующие решения в рамках проверки рабочей гипотезы.

·        Проанализировать специфику процессов консалтинговых проектов

·        Проанализировать различные системно-динамические модели, применяемые к управлению проектами

·        Разработать системно-динамическую модель сроков консалтингового проекта, включающую закон Брукса

·        Оценить на основе анкетных опросов менеджеров консалтинговых проектов силу взаимного влияния различных факторов количественной модели

·        При помощи имитационного моделирования выявить наличие или отсутствие действия закона Брукса при исполнении консалтинговых проектов, а также его силу и факторы, оказывающие основное влияние на его возникновение и усиление.

·        Разработка организационной модели консалтингового проекта, включающей процессы управления сроками и командой проекта, а также разработка рекомендаций для ее применения.

В рамках Главы 1 будет произведен обзор и анализ научных исследований в области консалтинговых проектов и системно-динамического моделирования, рассмотрены теоретические основы закона Брукса. В рамках Главы 2 будет разработана системно-динамическая модель, описывающая процесс исполнения консалтингового проекта, включающая в себя аспект усиления команды. Далее будет проведено анкетирование руководителей и участников команд консалтинговых проектов, в которых имело место отставание по срокам, после чего будет проведено имитационное моделирование с помощью программы Vensim, основанное на числовых параметрах, оцененных по результатам анкетирования. В рамках Главы 3 будет разработана организационная модель, основанная на выводах, полученных по результатам имитационного моделирования и проверки гипотезы, нацеленная на повышение эффективности консалтинговых проектов, а также оценен эффект от ее применения.

Глава 1. Теоретические основы и исследования в области консалтинговых проектов и системно-динамического моделирования

1.1     Исследования в области консалтинговых проектов

Рисунок 1.Количество работ, посвященных исследованию консалтинговых проектов (запрос «consulting projects»)

Количество исследовательских работ, посвященных теме консалтинговых проектов по запросу «consulting projects», опубликованных с 1971 по 2014 год согласно базе данных Scopus, указано на рисунке 1. Исходя из данной динамики можно заключить, интерес к исследованию в области проектов, связанных с консалтингом, начал расти, начиная с 2005 года, ранее оставаясь на достаточно низком уровне. Однако, в данной динамике не учитывается растущее внимание отечественных исследователей к данному вопросу. Рост количества исследований на данную тему можно связать с тем, что все большее число компаний стало пользоваться услугами консультантов для различных целей, и аутсорсинг стал более распространен. Причиной тому является тот факт, что процесс глобализации усиливается, и повышение конкурентоспособности, увеличение собственной гибкости становится все более актуальным вопросом для компаний. И задача консалтинга - предоставлять решения по оптимизации и решать практические задачи данного характера. Г. Ципес и Д. Садков отмечают, что в России на настоящий момент рынок консалтинговых услуг только начинает развиваться, что выражается в появлении все большего разнообразия предлагаемых продуктов и росте платежеспособного спроса (Ципес, Садков, 2008).

Рисунок 2. Ципес Г.Л., Садков Д.В. Проектно ориентированный подход к построению консалтингового бизнеса. Объем выручки на рынке консалтинговых услуг в России

Статья Innovation in Emerging Markets: The Role of Management Consulting Firms опубликованная И. Бэком, K. П. Проботиахом и Д. Намом в 2014 году в журнале Journal of International Management. Авторами статьи поставлены гипотезы о том, что использование услуг консалтинговых фирм положительно влияет на инновационную деятельность компаний в условиях развивающихся рынков. Задано предположение, что, прибегая к помощи консалтинга, компания положительно влияет как на развитие своей RND функции, так и на экономическую выгоду, полученную в результате создания инновационных продуктов. Исследование проведено на выборке из 1133 компаний, чья деятельность осуществляется в странах с развивающейся и развитой экономикой. По результатам статистического анализа была выявлена положительная взаимосвязь между интенсивностью обращений к консалтинговым фирмам и объемом средств, вложенным в RND, и сделан вывод о том, что обращение к консультантам действительно способствует развитию функции RND и процессов в компании, которые способствуют росту инновационной деятельности, однако влияние на эффективность данной деятельности отсутствует. Это объясняется тем, что на развивающихся рынках в целом зрелость компаний на более низком уровне, что негативно влияет на возврат инвестиций в инновации (Back, Praboteeah, Nam, 2014). Также было выявлено, что чем выше уровень институционной поддержки инноваций, которая описана уровнем поддержки авторских прав в стране, тем больше эффективность инновационной деятельности компании, и, таким образом, данный фактор отрицательно влияет на частоту обращений в консалтинговые фирмы.

Авторы в своем исследовании делают упор на взаимосвязь эффективности инновационной деятельности компаний, которые обращаются к услугам консультантов, исключительно с точки зрения данных компаний, однако, в расчет не берутся характеристики фирм, предоставляющих консалтинговые услуги. Дело в том, что от опыта и компетенций компании-консультанта во многом зависит эффективность разработанного решения и его влияние на бизнес заказчика.

Что касается исследований, посвященных эффективности консалтинговых проектов, в статье Factors influencing the success of management consulting projects, написанной Я. Джангом и Д. Ли в 1998 году в журнале International Journal of Project Management построена трехфакторная модель влияния различных характеристик как компании-заказчика, так и консалтинговой компании, представленная на рисунке 3. К первой группе факторов авторами отнесены компетенции и роли, которыми располагают участники команды консалтингового проекта, вторая группа включает в себя аспекты, которые необходимо соблюдать непосредственно в процессе исполнения проекта, и к последней группе относятся качества, которыми располагает компания-заказчик (Jang, Lee, 1998).

Рисунок 3. Jang, Lee, 1998. Трехфакторная модель консалтингового проекта.

Можно отметить, что теоретически основанная модель, предложенная авторами может быть и по сей день применима для того, чтобы оценить и предсказать возможность успешной реализации того или иного консалтингового проекта. Из года в год вовлечение клиента в процесс реализации, условия, обеспечивающие эффективные коммуникации между компанией-заказчиком и консультантом, что, согласно авторам, является следствием совокупности данных в модели факторов, остаются актуальными для эффективного исполнения проекта в области консалтинга. Модель также могла бы быть дополнена количественными и весовыми оценками данных факторов, чтобы она могла унифицированно применяться для измерения эффективности различных проектов.

В статье «Классификационные признаки консалтинговых» услуг, опубликованной О. Нестеренковой в отечественном журнале «Маркетинг и финансы», проводится обзор рынка консалтинговых услуг, из которого можно сделать вывод, что самым распространенным видом консалтинга, в котором испытывают потребность компании, является стратегический и маркетинговый консалтинг согласно темпам роста выручки в данном сегменте (рисунок 4). Автор отмечает, что в России деятельность компаний, предоставляющих консалтинговые услуги, в первую очередь сконцентрирована на финансовых аудиторских услугах, и за счет них получается 60% выручки компаний (Нестеренкова, 2014).

Рисунок 4. Нестеренкова О. Классификационные признаки консалтинговых услуг (2014) // Маркетинг и финансы. Темпы роста выручки компаний по видам консалтинга

Стоит отметить, что абсолютное большинство исследований, посвященных теме консалтинговых проектов, было сделано в области маркетинга. С точки зрения маркетинга, консалтинг можно определить, как «процесс взаимодействия субъектов рынка с целью создания дополнительной потребительской ценности посредством использования научно-технических и организационно-экономических инноваций» [Лобода, с 10]. При этом тема консалтинга, как проектной деятельности, в исследованиях на сегодняшний день остается нераскрытой: в малой степени исследованы консалтинговые проекты с точки зрения проектного управления, подходов к их реализации, существенных специфичных рисков для данных проектов и их заинтересованных сторон, жизненного цикла.

1.2     Теоретические основы системной динамики

В данном разделе будут рассмотрены теоретические основы инструмента, который будет применен в данной работе - системной динамики.

Донелла Медоуз дает определение системы как набора элементов, связанных друг с другом таким образом, что их взаимодействие определяет поведение самой системы (Медоуз, 2011). В каждой системе есть элементы и наличие связей между этими элементами. Обязательное условие функционирования системы - наличие общей цели, смысла ее существования. Согласно Д. Шервуду, зная отдельных игроков, вы все-таки не можете предсказать поведение команды (Шервуд, 2012). Система и все ее компоненты подвержены изменению во времени, так как система динамична.

Основателем системной динамики является Джей Форрестер из Массачусетского Технологического Института (MIT) в середине 1950-х годов. Первоначально его целью являлось применение инженерного и научного опыта к тому, чтобы выявить ключевые причины провала и успеха корпораций. В течение 1950-х Форрестер начал сотрудничать с компанией GE (General Electrics), и именно тогда у него возникли идеи, которые в будущем привели к созданию системной динамики. Менеджеры General Electrics недоумевали по поводу одного завода в Кентуки, на котором имели место колебания в численности рабочих длительностью в три года. Объяснение причин бизнес-циклами недостаточно удовлетворяло менеджмент компании. Тогда Форрестер занялся ручным построением сложной структурной модели завода, включавшую в себя модель принятия решений об увольнении и найме работников в организации. И было выявлено, что бизнес циклы и вообще любые внешние факторы не имели никакого отношения к проблеме, а реальная причина заключалась в структуре завода (Форрестер, 2003).

Затем Форрестер стал работать над возможностью компьютерного моделирования системной динамики. Сначала была написана программа SIMPLE, затем была создана ее улучшенная версия - DYNAMO. Именно эта программа на следующие тридцать лет задала стандарты языка системной динамики.

Первой книгой, написанной Форрестером, стала «Индустриальная динамика» в 1961 году. После он написал книгу «Динамика города» о применении системной динамики для моделирования города, который также является динамической системой. Наконец, в 1970 году была выпущена «Мировая динамика», в которой описывалась динамическая система мира и человеческой цивилизации.

В книге Форрестер описывает основные компоненты системно-динамической модели, к которым относятся потоки и запасы. Запасом считается текущее состояние чего-либо, которое может быть измерено в текущий момент времени. Примером запаса может являться сумма денежных средств на балансе фирмы. Потоковые переменные являются приростом, производной запаса, и отвечают за его увеличение или уменьшение. Например, выручка компании за период является потоком. Также в моделях системной динамики присутствуют внешние переменные, которые могут оказывать влияние на потоки, запасы или друг на друга.

В моделях могут присутствовать циклы обратной связи, которые бывают балансирующими и усиливающими. Усиливающие циклы отвечают за рост в модели, а балансирующие делают рост переменных невозможным до бесконечности. В реально существующих системах обязательно присутствуют циклы обоих видов. Форрестер в «Мировой динамике» приводит пример таких циклов в случае с приростом и убылью населения. Население в этом случае является запасом, а его прирост и убыль - потоком. Чем больше людей живет в мире, тем больше рождаемость, чем больше рождаемость, тем больше население. Имеет место усиливающий цикл обратной связи. Однако, население не может расти до бесконечности за счет наличия также балансирующего цикла смертности. Чем больше население, тем больше людей умирает, чем больше смертность, тем меньше население.

Можно заключить, что Форрестер составил действительно наиболее полную модель мировой динамики, которая с высокой точностью и степенью логичности отражает поведение системы. Как отмечали О’Коннор и Макдермотт, «Называя что-либо сложным, мы, как правило, представляем себе очень много различных частей. Это сложность, вызванная детализацией, количеством рассматриваемых элементов. Когда перед нами мозаика, составленная из тысячи кусочков, мы имеем дело со сложностью детализации. Сложность другого типа - динамическая. Она возникает в тех случаях, когда элементы могут вступать между собой в самые разнообразные отношения.» [7, с 2.]

1.3     Исследования в области системной динамики в управления проектами.

В данном разделе алее будет произведен анализ исследований в области управления проектами, в рамках которых было успешно использовано системно-динамическое моделирование.

 

Рисунок 5. Количество работ, посвященных применению системной динамики в управлении проектами (запрос «system dynamics» и «project management»)

С помощью базы данных Scopus было выявлено количество работ в области системной динамики по запросу «system dynamics» и «project management», связанных с темой управления проектами, которое можно увидеть на рисунке 5. Из данной схемы можно сделать вывод о том, что исследование применения системной динамики в области именно управления проектами являлось намного менее популярным, чем в области менеджмента в целом. Первая работа была опубликована в 1996 году, и при этом годовое количество опубликованных работ не превышало три работы в год. Данная база данных не учитывает отечественные исследования, однако, их совокупное количество стремится к нулю.

Первая научная статья, посвященная данной теме, рассматриваемая в рамках данной работы -Dynamic modelling of labor productivity in construction projects, опубликованная в журнале International Journal of Project Management в 2013 году авторами Ф. Насирзаде и П. Ноджедехи. В статье была представлена системно-динамическая модель производительности труда в строительных проектах, подразумевающая комплексную взаимосвязанную структуру различных факторов, влияющих на продуктивность. Предложенная модель отражала высокую динамичность этих факторов в течение жизненного цикла проекта, связанную с многочисленными процессами обратной связи. Авторы построили качественную модель с помощью диаграммы casual-loop.

Рисунок 6. Nasirzadeh, Nojedehi., 2013. Диаграмма casual-loo[, описывающая взаимосвязь факторов, влияющих на производительность труда в строительных проектах.

С помощью формул были описаны отношения производительности труда и других факторов, а также отношения прочих факторов друг с другом, и была построена количественная модель, выраженная в виде диаграммы потоков и запасов, состоящая из нескольких частей.

Рисунок 7. Nasirzadeh, Nojedehi, 2013 Диаграмма потоков и запасов.

Можно отметить, что низкая производительность труда вызывает превышение бюджета проекта и увеличивает срок его выполнения, тогда как эти факторы сказываются на мотивации персонала, в свою очередь. Образуются циклы обратной связи, уменьшить влияние которых возможно только с помощью создания в участниках проекта уверенности и мотивированности на начальном этапе (Nasirzadeh, Nojedehi, 2013). Далее модель была применена на реальном проекте строительства блоков апартаментов в США, были изучены прямые и непрямые эффекты, влияющие на производительность труда участников проекта, а проведенный анализ чувствительности измерил степень влияния разных факторов.

Можно считать, что модель, предложенная авторами, является гибким инструментом, позволяющим не только симулировать производительность труда в проектах, связанных со строительством, но и может способствовать нахождению ключевых причин в уменьшении продуктивности, с которой столкнулся проект. Это позволит сгенерировать необходимые управленческие решения, применение которых заставит производительность труда персонала проекта расти.

Статья «Using system dynamics to analyze disruption and delay in complex projects for litigation: can modelling purposes be met?», опубликованная в журнале Journal of Operational Research Society С. Хоуиком, посвящена теме применения системной динамики для анализа расписания проекта, в частности, сбоям в расписании и задержкам. Цель данной работы заключалась в том, чтобы ответить на вопрос, является ли системно-динамическое моделирование хорошим инструментом для оценки задержек в расписании и может ли быть более эффективным, чем традиционный инструмент - метод критического пути. Автор разделил причины задержек в расписании на три типа. Во-первых, некие нарушения, которые прерывают ход работы, во-вторых, возникающие дополнительные работы, добавление которых увеличивает время выполнения проекта, а также задержка во времени выполнения существующих работ. Была построена качественная модель в виде диаграммы casual-loop, изображенная на рисунке 8. В нее были включены основные переменные, оказывающие влияние на задержки, среди которых также присутствуют действия менеджмента в отношении принятия решений о расписании.

Рисунок 8. Howick, 2003. Диаграмма casual-loop для моделирования эффектов воздействия различных факторов задержки расписания.

Автор статьи делает вывод, что системная динамика может быть подходящим инструментом для моделирования задержек в расписании, однако, это зависит от целей моделирования. Системная динамика может позволить смоделировать внешние эффекты и их влияние, и это говорит о том, что данный инструмент может помочь выявить причинно-следственные связи. Однако, автор отмечает, что системно-динамическое моделирование не подходит для анализа более детальных вопросов в управлении расписанием (Howick, 2003). Данный инструментарий может применяться в совокупности с другими инструментами управления.

К недочетам данной статьи можно отнести отсутствие количественной модели, которая могла бы быть протестирована на реальном проекте, в котором имели место задержки в расписании. Системная динамика действительно, в отличие от метода критического пути и его производных, не позволяет решить вопрос планирования времени выполнения конкретных работ, однако, она могла бы применяться для того, чтобы снизить степень задержек во всей совокупности проектов фирмы, выявив их корни и особенности. Также системная динамика может быть применима в части планирования длительности работ.

Статься «System Dynamics (SD) based concession pricing model for PPP highway projects», опубликованная в журнале International Journal of Project Management, написанная Ч. Суном, М. Скибневским, А. Чаном и Дж. Юингом в 2012 году посвящена построению системно-динамической модели для управления стоимостью проекта.

Рисунок 9. Yelin Xu a, b,⁎, Chengshuang Sun c, d, Miroslaw J. Skibniewski c, Albert P.C. Chan e, John F.Y. Yeung f, Hu Cheng. 2012. Диаграмма casual-loop для моделирования стоимости проекта.

Сначала авторами была построена качественная модель, включающая в себя различные переменные, отвечающие за ценообразование проекта, а также взаимосвязи между ними. Далее была построена количественная модель в виде диаграммы потоков и запасов, отражающая динамику затрат и выручки проекта, и влияние различных факторов на них. Автор отмечает, что использование данной модели могло бы способствовать определению цены, при которой частные инвесторы согласились бы вложиться в проект при определенной IRR (Сун, Скибневский, Чанг, Юинг, 2012).

Стоит отметить, что управление стоимостью - одна из областей УП, в которой применение системной динамики могло бы быть наиболее актуальным. Это объясняется относительной простотой определения переменных модели и известностью связей между переменными, которые были выявлены задолго до построения модели. Например, не нужно изобретать формулу NPV, и все переменные, влияющие на нее, известны.

Рисунок 10. Yelin Xu a, b,⁎, Chengshuang Sun c, d, Miroslaw J. Skibniewski c, Albert P.C. Chan e, John F.Y. Yeung f, Hu Cheng. , 2012. Диаграмма потоков и запасов для моделирования стоимости проекта

1.4     Моделирование закона Брукса

В данном разделе будут рассмотрены теоретические основы такого явления, как закон Брукса, а также системно-динамическая модель, направленная на имитацию проявления закона Брукса в ИТ-проектах, то есть, задержки сроков проекта в связи с увеличением проектной команды.

Ф. Брукс в своей книге «Мифический человеко-месяц, или как создаются программные системы», написанной в 1975 году, сформулировал закон: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Имея немалый опыт в работе в проектах, связанных с разработкой ПО, например, ОС360, автор сделал вывод, что отставание по срокам - самая распространенная причина, по которой могут провалиться ИТ-проекты. Основываясь на собственных наблюдениях, им были сформулированы предпосылки, фасилитирующие отставание по срокам в проектах по разработке ПО. Брукс утверждает, что такая единица измерения, как человеко-месяц, является крайне неподходящей для оценки сроков проекта по разработке системы, так как в его основе лежит предположение о допустимости менять местами людей и часы, однако, выполнение работы происходит нелинейно. Кроме того, не существует объективного научного метода оценки времени, за которое можно завершить работу над проектом, и в качестве базового ориентира при планировании лежит время, желаемое для заказчика или руководства, однако, некоторые вещи невозможно завершить быстрее, не испортив результат. Излишний оптимизм при планировании также способствует неточности в определении базового плана-графика (Брукс, 1995). Предполагается, что при отставании от расписания принимается решение о наборе новых членов в команду разработчиков ПО с целью уменьшить это отставание. Чем больше людей в команде, тем больший объем работ команда способна выполнить. Однако, новые члены команды еще не знакомы со спецификой работы, и надо вводить их в курс дела. Таким образом, старым членам команды приходится тратить время на обучение новичков, уделяя меньше времени непосредственно работе. Кроме того, новички совершают больше ошибок, чем бывалые члены команды, из-за чего возникает больше переработки, на которую требуется дополнительное время. Далее, план изначально составляется с учетом только первоначальной численности команды, и если эта численность увеличивается, возникает необходимость в перекраивании задач и повторном разделении их между участниками. Перекраивание задач - трудоемкий вопрос, и также требует дополнительного времени. И, наконец, чем больше человек в команде, тем больше времени они тратят на коммуникации: договориться друг с другом, донести информацию от одного человека до другого. Факт в том, что группе, состоящей из 5 человек, проще договориться друг с другом, чем той, которая состоит из 10 человек. И, таким образом, время, потраченное на обучение, коммуникации и исправление ошибок, перекраивание задач внутри проекта вызывают еще большее отставание по срокам.

Одним из наиболее известных исследований на данную тему является работа Абдель-Хамида, работа которого посвящена исследованию явлений, описанных в «Мифическом человеко-месяц, или как создаются программные системы» (Abdel-Hamid, 1984). В модель Абдель-Хамида включены следующие основные переменные.

·        Объем работ. Те работы, которые еще не выполнены, находятся в резервуаре «Требования», а выполненные работы - в резервуаре «Продукт». Поток «Выполнение работ» опустошает «Требования» и наполняет «Продукт»

·        Члены команды. Новые члены команды находятся в резервуаре «Новички», бывалые члены команды - в резервуаре «Старожилы». Резервуар «Новички» наполняется потоком «Найм персонала» и опустошается потоком «Обучение», который наполяет резервуар «Старожилы».

·        Внешние переменные. Касаются времени на обучение и на коммуникации. Время на коммуникации Абдель-Хамид описал формулой 0,06n^2, где n - общее число членов команды.

Время на коммуникации и на обучение влияет на скорость выполнения работ.

Таким образом для проверки действительности закона Брукса для консалтинговых проектов разработана и отражена в Главе 2 системно-динамическая модель, основой которой являются заключения Абдель-Хамида, отражающая специфические черты и особенности консалтинговых проектов.

 

.5 Выводы по Главе 1

Несмотря на обилие исследований в области маркетинга, посвященных консалтингу, очень мало научных работ посвящено исследованию консалтинговой деятельности как проекта.

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

Закон Брукса, по сути, также является одним из проектных рисков, осуществление которого неизбежно при использовании неуместного способа сократить отставание по срокам и непринятии во внимание ряда предпосылок, сформулированных автором данного закона. Внесенный исследованием Абдель-Хамида вклад в понимание взаимосвязи человеко-месяцев и ходом реализации проектов по разработке позволил определить, что именно фасилитирует возникновение закона Брукса в процессе их исполнения, что могло бы способствовать повышению эффективности управления и принятых в рамках проекта решений, более качественному планированию расписания и контролю рисков.

Глава 2. Разработка системно-динамической модели и проверка рабочей гипотезы.

2.1. Разработка системно-динамической модели сроков консалтингового проекта, включающей закон Брукса.

В данном разделе будет разработана системно-динамическая модель консалтингового проекта, которая далее будет использована для проверки актуальности действия закона Брукса в консалтинговых проектах.

Будучи основанной на модели, разработанной Абдель-Хамидом, она также включает в себя ряд переменных, используемой его в модели, описанной в Главе 1. К ним относятся переменные потоков и запасов работ проекта и членов команды. При этом, с целью возможности моделирования исполнения консалтинговых проектов разного масштаба задачи в рамках данной потоково-запасной диаграммы заменены этапами проекта, которые были типизированы ниже.

Если унифицировать этапы консалтингового проекта, то можно выделить четыре основных этапа, которые есть в каждом проекте, за исключением предпроектной и постпроектной стадии:

·        Анализ бизнес-кейса.

·        Разработка проектного решения

·        Реализация проектного решения

·        Завершение

После окончания этапа завершения при наличии необходимости в этом начинается постпроектная стадия, включающая в себя поддержку внедренного решения и постпроектный мониторинг, однако, данная стадия не рассматривается в данном исследовании

Описанные выше этапы будут использованы в системно-динамической модели в качестве базовых.

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

Модель, разработанная в рамках данного исследования, построена с учетом специфики консалтинговых проектов. Например, в отличие от строительства или разработки ПО, сложно оценить продуктивность одного отдельного члена команды, ибо результата может достигнуть только команда целиком. Можно оценить, сколько кирпичей в день способен уложить один рабочий или сколько кодов способен написать один программист в среднем, но один член команды консалтингового проекта просто не способен выполнить проект в одиночку, а продуктивность команды, в отличие от строительства, не имеет более-менее линейной зависимости от размера команды. Таким образом, в модель включена переменная, описывающая продуктивность команды в зависимости от числа ее членов.

Далее, модель учитывает сверхурочные, которые имеют место в абсолютном большинстве консалтинговых проектов.

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

Помимо того, в модель добавлена часть, посвященная методу освоенного объема. Как отмечалось выше, отставание по срокам зачастую может коррелировать с превышением бюджета, и показатели EV могут наглядно это отобразить.

Ниже приведена диаграмма потоков и запасов данной модели, построенная с помощью программы Vensim.

 

Рисунок 11. Разработанная модель: диаграмма потоков и запасов

Описание переменных модели

Переменная	Тип	Описание
Плановая длительность	Внеш.	Изначальная плановая длительность проекта в днях.

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

·        1 этап: 15% от общей длительности

·        2 этап: 30% от общей длительности

·        3 этап: 40% от общей длительности

·        4 этап: 5% от общей длительности

Таким образом, в модели предполагается, что 1 этап длится 15 дней, 2 этап - 30 дней, и т.д.

Переменная	Тип	Описание
Осталось выполнить	Запас	Объем работы, которую осталось выполнить
Выполнено	Запас	Объем сделанной работы по проекту

За одну работу в данной модели принимается один этап проекта, то есть, проект состоит из 4 работ. Таким образом, изначальное значение переменной «Осталось выполнить» равняется 4, и этому числу равняется значение «Выполнено» тогда, когда проект полностью выполнен.

ПеременнаяТипОписание
Выполнение работ	Поток	Объем работы, выполняемый за день

Предполагается, что в условиях отсутствия сверхурочных, а также необходимости обучать и тратить время на коммуникации, команда способна выполнить определенный объем работы в день в зависимости от количества новичков и старожилов в ней. Базовые значения производительности участников команды на четырех разных этапах проекта вычислены на основании результатов анкетирования (переменные ПНУ i этап и ПУ i этап, i = 1,…, 4). Индивидуальная производительность участников умножается на так называемый «эффект команды» - степень того, насколько большее количество людей в команде быстрее выполняет работу (переменная «Эффект команды», имеет логарифмическую зависимость от числа участников команды). Однако для расчета реальной скорости выполнения работ из общего рабочего времени за день (равняется 1) вычитается % времени в день, потраченного на коммуникации (t ком., обучение (t обучение), и прибавляется время сверхурочных (рассчитанное на основании результатов анкетирования с учетом частоты и количества переработанного времени). Таким образом, скорость выполнения работ проекта меняется в зависимости от появления новичков в команде.

Переменная	Тип	Описание
Новые участники	Запас	Количество новичков в команде
Участники	Запас	Количество старожилов в команде

Предполагается, что первоначальный состав проектной команды весь является старожилами с самого начала. Согласно результатам анкетирования среднее значение первоначального состава команды равно 5 участникам, что было взято за первоначальное значение запаса «Участники».

Переменная	Тип
Обучение	Поток	Скорость обучения новичков

Согласно мнению людей, имеющих опыт работы в консалтинге, новых участников команды в консалтинговых проектах не надо обучать. Если новички имеют опыт работы в аналогичных проектах и являются профессионалами, то их не нужно обучать специфике работы в проекте. Единственное, к чему сводится обучение - это то, что новому участнику требуется время, чтобы ознакомиться с проектной документацией, и, исходя из результатов анкетирования, среднее время на это составляет примерно 6 дней.

Переменная	Тип	Описание
Найм	Поток	Прием новичков в команду

В данной модели зависит от того, сколько новых участников требуется («Требуемое число новых участников») и того, было ли принято решение о наборе новичков («Решение об усилении команды»). Ведь в реальности новые участники принимаются в команду не каждый день, когда проект отстает от расписания, а после принятия соответствующего решения, которое происходит с определенной периодичностью (значение которой взято из результатов анкетирования).

Переменная	Тип	Описание
«Требуемое число новых участников»	Внеш.	Сколько новых участников требуется команде
«Решение об усилении команды»	Внеш.	Принимаются ли фактически новые участники в команду в этот день. Бинарная (1 - принимаются, 0 - не принимаются).

Необходимость усиления команды новыми участниками определяется тем, отстает ли проект от расписания, или превышают ли ожидаемые сроки выполнения проекта плановые. Число новых членов, необходимых команде, рассчитано на основании результатов анкетирования, и различается для разных этапов выполнения проекта. Считается, что между пониманием необходимости принятия новичков и их фактическим принятием проходит какое-то время, и на основании результатов анкетирования вычислено, что это время в среднем равняется 5,3 дня.

Переменная	Тип	Описание
Ожидаемое отставание	Внеш.	Превышение ожидаемого срока окончания над плановым

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

Переменная	Тип	Описание
ПНУ i этап ПУ i этап	Внеш.	Сколько работы за день способен в одиночку выполнить один новичок (ПНУ i этап) или старожил (ПУ i этап) в период i (i = 1, 2, 3, 4).

Базовые значения производительности рассчитаны на основании результатов анкетирования с учетом длительности этапов и командного эффекта

Переменная	Тип	Описание
Эффект команды	Внеш.	Коэффициент, увеличивающий продуктивность команды в зависимости от числа ее участников

В отличие от работы, например, строительной бригады, продуктивность работы команды консалтингового проекта не зависит линейно от числа ее участников. Предполагается, данная зависимость - логарифмическая (основание логарифма примерно равно 2). Также может иметь место степенная (гиперболическая) зависимость.

Переменная	Тип	Описание
t ком.	Внеш.	Время, которое тратится на обучение
	Внеш.	Время, которое тратится на коммуникации

Время на обучение рассчитано на основании результатов анкетирования. Время на коммуникации зависит от числа участников команды (а время на обучение - нет, о чем стало известно из интервью с участником команды консалтингового проекта).

Переменная	Тип	Описание
PV	Запас	Плановая стоимость работ
Накопление PV	Поток	Накопление плановой стоимости
AC	Запас	Фактически понесенные затраты
Накопление AC	Поток	Накопление фактически понесенных затрат
EV	Запас	Освоенный объем бюджета
Накопление EV	Накопление освоенного объема бюджета
SPI	Внеш.	Индекс выполнения расписания
CPI	Внеш.	Индекс выполнения стоимости
CR	Внеш.	Индекс критичности

Модель предполагает, что плановый бюджет проекта равен 1000 у.е. на основании интервью с участниками команды консалтингового проекта, бюджет по этапам распределяется примерно следующим образом:

·        1 этап: 15% бюджета

·        2 этап: 50% бюджета

·        3 этап: 30% бюджета

·        4 этап: 5% бюджета

PV накапливается равномерно в зависимости от бюджета и длительности этапа. AC, в свою очередь, накапливается с учетом объема выполненной работы и реальной стоимости каждого этапа (отклонения по стоимости на каждом этапе рассчитаны исходя из результатов анкетирования). EV накапливается исходя из объема выполненной работы и плановой стоимости данного объема.

 

.2 Анализ результатов анкетирования и проведение имитационного моделирования

Прежде, чем проводить имитационное моделирование на разработанной модели, необходимо провести статистический анализ для предварительной проверки гипотезы о законе Брукса в консалтинговых проектах и определения значений числовых параметров модели.

В анкетировании принял участие 21 респондент, 33% из которых, являлись менеджерами консалтинговых проектов, остальные - участниками команды консалтинговых проектов. 95% респондентов когда-либо сталкивались с проектом, в котором имело место отставание по срокам, и в среднем отклонение от планового срока завершения составляет 36,9%. При этом в 76% проектов действительно привлекался новый персонал с целью сокращения отставания от расписания. Частота привлечения новичков в команду выше всего на этапе диагностики и анализа бизнес-кейса. Многие проектные команды были усилены исключительно на этом этапе, и в дальнейшем новые люди не принимались в команду. Однако, если на данном этапе и привлекались новички, то, как правило, в количестве не более 1, максимум двух людей. Что касается количества, то на этапах разработки решения и его внедрения могло привлекаться до 5 новых участников, однако, в меньшем числе проектов на данных этапах были усилены команды. Максимальное количество новых членов, добавленных в команды проектов респондентов, составило 12, среднее значение примерно равняется 3.

Рисунок 12. Результаты анкетирования - величина отклонения по срокам.

Как видно из рисунка 12, при очень малых отставаниях от расписания решение об усилении команды не принимается, и необходимость в новых участниках команды может появиться в случае, когда проект отстает на 20 - 30% и более. Средний процент отклонения составляет примерно 21% (только среди тех респондентов, которые признали необходимость усиления команды при отставании от сроков).

Рисунок 13. Результаты анкетирования - продуктивность работы новых участников в команде

Из рисунка 13 можно заключить, что большая часть респондентов не согласна с тем, что новые участники команды работают менее продуктивно, чем бывалые, лишь 8 человек из 21 хотя бы частично могут с этим согласиться. Это является первой предпосылкой того, что закон Брукса может не действовать в консалтинговых проектах.

Вычислив на основании результатов анкетирования значение числовых параметров модели, проведено имитационное моделирование, и выявлены следующие результаты.

Рисунок 14. Результаты базового моделирования.

На рисунке 15 можно увидеть, что индекс критичности проекта имел значение меньше 1 на протяжении всей длительности (96 дней, далее программа продолжает моделировать его значения, но проект уже закончен). Это связано с низкими значениями индекса SPI из-за опережения сроков.

Если числовые параметры модели соответствуют результатам анкетирования и предпосылкам модели, то проект должен быть закончен даже раньше запланированного срока (100 дней). При этом в команду проекта принято 10 человек к моменту его завершения.

Рисунок 15. Динамика индекса критичности при базовом моделировании.

Рисунок 16. Динамика переменной "Ожидаемое отставание (базовые числовые параметры)

Динамика переменной «Ожидаемое отставание» говорит о том, что моделируемый проект сталкивался с ожидаемым отставанием по срокам, и при этом, исходя из рисунка 14, в проект принимались новые участники. Можно предположить, что положительный эффект командной работы в данном случае превалировал над издержками большой команды - необходимостью обучать и тратить больше времени на коммуникации. То есть, переменная «Эффект команды» оказывала положительный эффект на переменную “Выполнение работ». Данное предположение можно проверить с помощью регрессионного анализа, взяв в качестве зависимой переменной значения «Выполнение работ» по дням, а в качестве независимой - значения «Эффект команды». Регрессия построена для 2 и 3 этапа проекта, во время которых, согласно моделированию, были приняты новички.

R-квадрат регрессии составляет 20% для 2 этапа и 99% для третьего. При этом переменная «Эффект команды» в обоих случаях является значимой (P-значение = 0,0 при уровне значимости 95%) и оказывает положительное влияние на скорость выполнения работ. Коэффициент при переменной «Эффект команды» на 2 этапе равняется 0,003, а на 3 этапе - 0,01.

Низкое значение R-квадрат на 2 этапе может говорить о том, что на данном этапе командный эффект имел меньший вес при расчете скорости исполнения, и на нее другие переменные, от которых она зависит, влияли значительнее. На 3 этапе командный эффект действительно стал превалировать над негативными сторонами наличия большего числа участников - совместная продуктивная работа стоила времени на обучение и большее время на коммуникации.

Во время интервью с участником команды консалтингового проекта стало известно, что в данных проектах обучение новичков не требуется. Единственное, в чем состоит их обучение - это в первые несколько дней ознакомление с проектной документацией и деталями конкретного проекта, и бывалые не тратят на это много времени. В некоторых случаях, не тратят его вообще. В зависимости от того, какого рода работу привлечен выполнять новый участник, можно вообще не вводить его в детали проекта.

К другим причинам, почему время на обучение новичков в консалтинговом проекте незначительно, можно отнести то, что качество работы новичка определяется не тем, насколько долго он работает именно в данном проекте, а тем, насколько большой опыт работы в аналогичных проектах он имеет, насколько профессионален в принципе. Значительно хуже, чем бывалые члены, могут работать те новички, которые не имеют достаточно опыта, например, те, кто только начинает свою карьеру в консалтинге. Именно этой категории новичков требуется уделять много внимания и обучать, остальным же этого не требуется. Кроме того, как правило, в консалтинге новички принимаются в команду в тех случаях, когда в команде не хватает человека с определенными компетенциями, и нанимают людей под выполнение какой-то конкретной работы, а не для участия в работе коллектива в целом, как, например, в случае с разработкой ПО. Таким образом, остальной коллектив, выполняя свою работу, не может обучать человека с другими компетенциями.

Однако, консалтинговые проекты, тем не менее, сталкиваются с отставанием по срокам. Из интервью со специалистами выяснилось, что отношения с заказчиком играют значительную роль в том, насколько проект отклоняется по срокам. Часто имеет место плохое качество коммуникаций с заказчиком, возникает проблема на этапе приемки результатов заказчиком, в том числе, саботаж приемки. Может быть неудовлетворительной работа менеджера проекта со стороны заказчика, и это все отодвигает срок завершения проекта. Часто пересматривается состав работ заказчиком после инициации проекта, что является следствием вышеперечисленных факторов, в особенности, плохого качества коммуникаций между сторонами. Иногда состав работ просто дополняется в связи с возникновением дополнительных требований со стороны заказчика, которые не были обозначены ранее. А в некоторых случаях результат оказывается не тем, что в действительности было нужно, и возникает дополнительный объем работ из-за необходимости разработки нового решения, исправления ошибок, переработки. Это является частой практикой в российской действительности консалтинга.

Одна из причин особенностей консалтинговых проектов, а именно - наличие большого объема сверхурочной работы, которая учтена в разработанной модели. Результаты анкетирования показали, что большинство респондентов работали сверхурочно чаще трех раз в неделю, и только 2 человека не работали сверхурочно вообще (рисунок 17).

Рисунок 17. Результаты анкетирования - сверхурочная работа

Сверхурочная работа возникает не только в случае отставания по срокам одного конкретного проекта, но и в связи с тем, что иногда консультанты работают на нескольких проектах одновременно, из-за чего сильно перегружены. Но в данном исследовании учитывается только сверхурочная работа на конкретном проекте.

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

Таким образом, можно смоделировать ситуацию, когда переменная «Ожидаемое отставание» начинает приниматься во внимание на поздних этапах, например, после того, как прошло 70 дней с момента старта проекта.

Рисунок 18. Результаты моделирования - отсутствие контроля сроков на ранних этапах

Из рисунка 18 можно сделать вывод, что если не уделять контролю сроков внимание до определенного момента, проект будет отставать по срокам на 10% от первоначально запланированных.

При этом ожидаемое отклонение к моменту начала контроля сроков будет больше (синяя линия на рисунке 19).

Рисунок 19. Ожидаемое отставание при условии постоянного мониторинга сроков только в конце проекта

Можно сделать вывод, что постоянный мониторинг сроков положительно влияет на то, что проект уложится в плановый срок.

Как было сказано выше, командный эффект превышал негативные факторы большой команды на 3 этапе, но не на втором. На 3 этапе команда была достаточно большой. В случае же последнего моделирования в команду было принято меньше членов и только на 3 этапе. Можно предположить, что в данном случае, командный эффект не будет настолько большим, чтобы повысить значительно скорость выполнения работ, а вот время на коммуникации будет ее сокращать. Проведем регрессионный анализ, чтобы проверить это. В качестве зависимой переменной взята скорость выполнения работ («Выполнение работ»), а независимая - время на коммуникации (t ком.).

Можно предположить, что, изменив формулу переменной «Эффект команды» так, чтобы полезность каждого нового члена была меньше, возможность возникновения закона Брукса все же есть. Изменив основание логарифма в формуле с 2 на 3, получаем результат, показанный на рисунке 20.

Рисунок 20. Динамика выполнения работ с учетом меньшей полезности каждого нового участника

В данном случае проект значительно отклоняется от планового срока завершения, и в команду принято значительно больше новых участников. Для проверки того, оказывает ли влияние уменьшение полезности каждого нового участника на возникновение закона Брукса, проведем регрессионный анализ. Для начала проведем 7 испытаний модели в Vensim при разных формулах переменной «Эффект команды» - изменяя основание логарифма в пределах от 2 до 3.2. в качестве зависимой переменной возьмем значения скорости выполнения работ при разных значениях основания логарифма, а в качестве независимой - время на коммуникации при соответствующих значениях.

Значение R-квадрат равно 80%. При уровне значимости 95% коэффициент при «t ком.» значим (Р-значение равно 0,01) и равен -4,21. То есть, время на коммуникации действительно отрицательно влияет на время выполнение работы, и чем меньше предельная полезность каждого нового участника («Эффект команды»), тем больше негативные стороны большой команды превалируют над ее достоинствами и задерживают сроки исполнения работ. То есть, закон Брукса действительно имеет место, но при условии, что предельная полезность каждого нового участника, или эффект команды, меньше определенного значения. При условии логарифмической зависимости «Эффект команды» от размера команды, после проведения серии испытаний модели с разными значениями оснований логарифма, закон Брукса начинает действовать при таковом значении больше 2,2. Однако то, является ли такая зависимость близкой к реальности, спорный вопрос, реальность скорее говорит об обратном. Следовательно, закон Брукса не действителен для консалтинговых проектов.

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

Н1: закон Брукса действителен для консалтинговых проектов - не подтверждена.

Его возникновение возможно лишь при соблюдении некоторых условий, которые не являются близкими к реальности.

 

.3 Сравнительный анализ специфики ИТ и консалтинговых проектов

Несмотря на ряд сходств между консалтинговыми и ИТ-проектами, описанными в начале исследования, закон Брукса актуален только для ИТ-проектов. Это может быть связано с тем, что вопреки сходствам существуют некоторые принципиальные различия в исполнении и управлении проектами данных видов, влияющие на возникновение данного эффекта.

Во-первых, средний размер команды консалтингового проекта меньше, чем в ИТ-проекте. Численность команды консалтингового проекта, согласно опросу, редко превышает 15 человек. Конечно, нередки случаи, когда над разработкой программ и систем работает маленькая активная команда, состоящая не более, чем из 10 человек, но работа настолько малочисленной команды невозможна, если говорить о крупных проектах. Ф. Бруксом в «Мифическом человеко-месяц, или как создаются программные системые» было выявлено, что несмотря на предельно малое количество коммуникаций, отсутствие необходимости в обучении новичков и перекраивании задач, маленькая команда выполнила бы проект за время, в десять раз большее, чем большая команда. В ИТ-проектах по разработке программного обеспечения может быть занято более 1000 человек. Кроме того, на сегодняшний день остается актуальной проблема того, что проектирование архитектуры системы и разработка не всегда отделены друг от друга и выполняются одними и теми же людьми, и слишком большое количестве людей участвует в разработке спецификаций системы, что негативно сказывается на ее концептуальной целостности и увеличивает время отладки и интеграции. Данное затруднение не актуально для консалтинговых проектов.

Во-вторых, как было сказано выше, в консалтинговых проектах новые участники, как правило, нанимаются строго под определенные задачи. Команде может потребоваться человек, либо обладающий некоторыми компетенциями, которыми действующие участники располагают в недостаточной степени, либо человек, способный взять на себя выполнение некоторых задач в том случае, если ожидается ощутимое отставание от графика, но действующие участники команды загружены достаточно сильно. Данная ситуация может возникнуть, в том числе, вследствие недостаточно качественного планирования ресурсов в самом начале проекта. При этом дробления задач не происходит - выполнение задачи целиком отдается новичку. В ИТ-проектах при добавлении новых участников происходит перекраивание задач - части одной задачи, распределенные между прежним составом, требуется перераспределить заново с учетом новичков. Значительные временные затраты требуются только для того, чтобы должным образом осуществить данное перераспределение.

В-третьих, существует разница в методологии, применяемой к управлению данными типами проектов. В ИТ-проектах применяется управление по итерациям - Agile-методологии (Мартин, Ньюкирк, Косс, 2004). Задолго до окончания проекта появляется готовый к использованию продукт, который от итерации к итерации претерпевает изменения и улучшения, и не один раз проходит этапы разработки спецификаций, проектирования, реализации и тестирования (Кон, 2015). В консалтинговых проектах более применим принцип Waterfall. Первоначально допускалась применимость данного принципа также и к ИТ-проектам (Royce, 1970), однако, позже была доказана его абсолютная неэффективность к данному типу проектов. Действительно, в консалтинговых проектах зачастую не может быть промежуточного результата, какими спецификами ни обладал бы данный проект: не может быть «пробных» и промежуточных версий бизнес-процессов и функций, пользователи не могут быть переобучены много раз подряд, Primavera не может быть внедрена частично. Решение чаще всего не может начать внедряться, прежде, чем оно полностью разработано, пользователи не могут быть обучены прежде, чем разработан план по обучению их работе в новой программе. Итоговый результат консалтингового проекта, пригодный к использованию, которым может воспользоваться компания заказчик и ее пользователи, появляется к завершению проекта. В случае, если проект крупный и комплексный, нацеленный на всю организацию, например, внедрение ERP, невозможно выполнение проекта, в некотором роде, по итерациям, например, после проведения опытно-промышленной эксплуатации системы у компании заказчика может возникнуть ряд вопросов и требований, связанных с необходимостью доработки системы и доведения ее до состояния, позволяющего конечным пользователям продуктивно работать с ней. Таким образом, начинается снова разработка элементов, необходимых компании, с их последующим внедрением. Однако, в случае грамотного планирования проектов данного типа этап опытно промышленной эксплуатации и этап реализации запросов на изменения от пользователей выделяются отдельно и стоят последовательно в рамках реализации проекта. Так как модель Waterfall предполагает, что требования к конечному продукту определяются в начале проекта и с тех пор не претерпевают изменения, в консалтинговых проектах данные требования фиксируются на этапе анализа бизнес-кейса. Таким образом, переработки, исправление ошибок и переделывание части работ на заключительных этапах в консалтинговых проектах возникает только в случае зафиксированного изменения периметра, и их объем значительно меньше, чем в ИТ-проектах. Данный аспект отрицательно влияет на возможность действия закона Брукса. Модель, разработанная в рамках главы 2, также предполагает применение Waterfall - этапы проекта выполняются последовательно.

Далее, исходя из информации, полученной от экспертов, в связи с необходимостью выбора подрядчика консалтинговых услуг посредством тендера и острой конкуренцией на данном рынке, консалтинговым компаниям свойственно выбирать наиболее оптимистичный срок исполнения проекта в качестве планового. Вследствие данного оптимизма при инициации проекта ресурсы зачастую оказываются перегружены, и в некоторых случаях под выполнение отдельных задач выделяются дополнительные люди в команду, так как завершить проект в срок - критичный вопрос.

 

.4 Выводы по Главе 2

На основе исследования, посвященному моделированию закона Брукса в IT-проектах, а также анализа специфики консалтинговых проектов на основании интервью с участниками команд, была разработана количественная системно-динамическая модель в виде диаграммы потоков и запасов, моделирующая динамику выполнения работ и членов команды в консалтинговых проектах.

Проведено анкетирование, на основании результатов которого модели заданы числовые параметры, и проведено имитационное моделирование с учетом различных предпосылок. Для подтверждения результатов моделирования был проведен регрессионный анализ.

Результаты моделирования показали, что усиление команды является действенным инструментом для сокращения ожидаемого отставания по срокам в консалтинговых проектах. Следовательно, гипотеза об актуальности действия закона Брукса в консалтинговых проектах не подтверждена. Причина данного результата заключается в ряде различий между спецификой реализации и управления ИТ и консалтинговыми проектами, такими, как жизненный цикл, постановка и разделение задач, планировании и другими.

Интервьюирование экспертов, имеющих опыт работы в консалтинговых проектах, показало, что одним из ключевых факторов успешной реализации консалтингового проекта являются эффективные и своевременные коммуникации с заказчиком и вовлечение его в процесс управления проектом. Кроме того, в консалтинговых проектах зачастую имеет место излишне оптимистичное планирование расписания, из-за чего ресурсы проекта зачастую перегружены.

Глава 3. Построение организационной модели консалтингового проекта и разработка рекомендаций к ее практическому применению

 

.1 Построение организационной модели

На основании проведенного исследования можно заключить, что управленческие решения, связанные с усилением команды, являются действенным инструментом для решения проблемы отставания по срокам в консалтинговых проектах. Одной из самых распространенных причин отставания по срокам в консалтинговых проектах является низкое качество взаимодействия с заказчиком. Чем хуже в проекте выстроены коммуникации с его заказчиками, тем больше вероятность выявления несоответствий проектного решения ожиданиям заказчика и возникновения с его стороны дополнительных требований, выраженных в качестве изменения периметра и необходимости реализации запросов на изменения. Это является причиной возникновения дополнительных работ, которые требуют времени на то, чтобы быть выполненными. Таким образом, срок вехи завершения проекта сдвигается.

Для того, чтобы снизить вероятность неудовлетворенности заказчиком внедренным решением, необходимо не только регулярное информирование заказчика о ходе проекта, но и вовлекать его в управление проектом в той мере, в которой это требуется для контроля качества реализации проекта. Например, на начальном этапе консалтингового проекта руководителю и проектной команде необходимо добиться понимания требований и ожиданий заказчика, а ему, в свою очередь, важно быть осведомленным о возможных вариантах решения, которое может быть реализовано в рамках проекта. Поэтому на этапе анализа кейса требуется не просто информировать заказчика о ходе работы, но и вовлекать его в работу проектной команды. А на этапе проектирования настолько интенсивное взаимодействие может не иметь смысла и являться непродуктивным расходованием времени.

Коммуникации требуют дополнительных временных затрат, и в том случае, если они будут в избыточном количестве, проектная команда рискует не улучшить, а снизить эффективность своей работы из-за того, что негативный эффект от непродуктивного расходования времени будет превалировать над положительным эффектом от коммуникаций. Это может быть причиной еще большего отклонения от планового срока. Следовательно, важно найти баланс и выявить оптимальную частоту взаимодействий с заказчиком.

Таким образом, вышеперечисленные факторы отражены в организационной модели консалтингового проекта, включающей его ключевые бизнес-процессы, описывающей жизненный цикл, взаимодействие с заказчиком и контроль сроков проекта (рис. 21). Первой предпосылкой данной модели является то, что на каждом этапе имеют место процессы согласования с заказчиком текущих результатов. Следовательно, длительность каждого отдельного этапа проекта может увеличиться в результате того, что заказчик посчитает результат, выполненный к текущему сроку, неудовлетворительным, и потребуется выполнение дополнительных работ по его корректировке. Вторая предпосылка модели - непрерывный контроль сроков проекта, начиная с этапа разработки решения, который. Исходя из результатов системно-динамического моделирования, при раннем начале контроля сроков больше вероятность выполнить проект согласно первоначальному плану за счет своевременного принятия решения об усилении проектной команды. В отличие от стандартной модели контроля сроков по вехам, свойственной методологии Waterfall или же, в некоторых случаях, отсутствию контроля план-графика на ранних этапах, данная концепция предполагает непрерывный расчет ожидаемого отклонения и постоянную актуализацию плана-графика без привязывания данного управленческого решения к вехам.

Рисунок 21. Бизнес-процессы консалтингового проекта

Для каждого процесса необходимо определить ответственных за его реализацию, то есть, назначить роли. В зависимости от характеристик компании-заказчика консалтингового проекта, в разных проектах может быть разное количество ролей его участников. Это, зависит, например, от наличия проектного офиса в компании, к обязанностям которого относится также взаимодействие с подрядчиками, от количества подразделений, которые будут пользоваться результатами проекта, от наличия или отсутствия в проекте ИТ-составляющей. Однако, следует выделить следующие роли участников, которые должны быть актуальны для всех консалтинговых проектов:

·        Руководитель консалтингового проекта (на смехе в Приложении 3 - Руководитель проекта - К)

·        Команда консалтингового проекта (на смехе в Приложении 3 - Проектная команда - К)

·        Руководитель проекта от заказчика (на смехе в Приложении 3 - Руководитель проекта - З)

·        Функциональный заказчик (на смехе в Приложении 3 - Функциональный заказчик)

Во-первых, руководитель консалтингового проекта - ответственный за выполнение мероприятий по проекту в срок и в рамках существующего бюджета, а также за достижение результатов проекта. Проектная команда является исполнителем мероприятий. Как правило, в компании, с которой имеют дело консультанты, решение по проекту требуется в рамках какого-либо внутреннего проекта компании, для которого в ней также назначен руководитель и команда. Таким образом, образуется роль руководителя проекта от заказчика, заинтересованного в успешной реализации проекта. С ним необходимы коммуникации не только по части содержания проекта, но и его базовых параметров и хода реализации. Отдельно следует выделить роль функционального заказчика (ФЗ) - руководителя подразделения компании, которое принимает решение проекта по его завершению. Именно функциональный заказчик изначально имеет требования и ожидания относительно данного решения, которым оно должно соответствовать, и которые руководитель проекта, как от заказчика, так и от консультанта, должны учитывать. Следовательно, обязательны коммуникации с функциональным заказчиком в части содержания проекта.

Каждый процесс имеет свои входы и выходы, и в данном случае ими являются документы и информация на момент начала и по завершению процесса. Документ, полученный по окончании процесса, является формальным основанием для его завершения и начала следующего процесса.

Начиная с этапа анализа бизнес-кейса, который начинается после завершения процесса инициации, целью которого является формальное открытие проекта (ГОСТ Р 54869―2011 «Требования к управлению проектами»), можно выделить следующие характеристики процессов.

Рисунок 22. Этап 1 "Анализ бизнес-кейса" - роли, входы и выходы

Цель данного этапа - зафиксировать ожидания заказчика относительно решения, которое нужно разработать в рамках проекта, и выбрать тот вариант, который был бы оптимален с точки зрения соответствия требованиям и потребностей для его реализации. Первым шагом является анализ текущей ситуации «как есть», разбор бизнес-кейса, актуального на данный момент. На данном шаге важно обсудить с функциональным заказчиком специфику работы компании в части его подразделения, совместно проанализировать слабые стороны актуальных бизнес-процессов и причины потребности в их изменении, обеспечить руководителю проекта и команде понимание того, что именно заказчик ожидает от решения, которое предоставит проект. Предполагается, что на данном этапе проектная команда и функциональный заказчик работают совместно. Чем более тесно проходит работа с ФЗ на данном шаге, тем меньше вероятность получения на следующих шагах результата, не удовлетворяющего его требованиям.

По завершении процесса проектная команда формирует документ, фиксирующий требования ФЗ к решению (ТкР). ТкР могут быть представлены в виде документа MS Word, в котором описан функциональный периметр проекта с допущениями и исключениями. Также формируется презентация, включающая сравнительный анализ вариантов решения с точки зрения их стоимости, возможного срока реализации, эффекта от реализации. Кроме того, на данном шаге необходимо сформировать Устав проекта.

После ТкР необходимо согласовать с ФЗ и руководителем проекта от заказчика, а также выбрать совместно с ними оптимальный вариант решения. Если ФЗ или руководитель проекта от заказчика считают, что их требования к решению некорректно зафиксированы, проектная команда продолжает взаимодействие с ФЗ с целью того, чтобы повысить понимание их ожиданий и скорректировать ТкР.

После того, как требования ФЗ и руководителя проекта зафиксированы, и выбрано одно из решений проекта, которое будет реализовано, команда составляет базовый план-график, который руководителю консалтингового проекта необходимо согласовать с руководителем проекта от заказчика. В данном случае для согласования не критично привлекать ФЗ и организовывать отдельное мероприятие в виде встречи, поэтому нет необходимости выделять его в отдельный процесс. Завершение данного процесса обозначается вехой окончания Этапа 1 «Анализ бизнес-кейса» и начала Этапа 2 «Разработка проектного решения», описанный на рисунке 22.

Рисунок 23. Этап 2 "Разработка решения" - входы, выходы, роли

Проектная команда совместно с руководителем проекта приступает к проектированию решения согласно тому, что было выбрано ФЗ и руководителем проекта от заказчика на предыдущем этапе с учетом согласованных ТкР. Результатом шага является детальное описание целевых бизнес-процессов, а также документы, фиксирующие план мероприятий по внедрению. План представляется в виде документа MS Word, содержащего перечень мероприятий и результатов, которые должны быть достигнуты по результатам каждого мероприятия и срок их достижения для дальнейшего мониторинга исполнения плана. Пример шаблона плана приведен в таблице Ж:

Мероприятие	Результаты	Срок выполнения
Миграция исторических данных в систему	- данные по свободному денежному потоку за 1 кв. 2015 года мигрированы в систему	14.09.2015
…	…	…

Кроме того, если в рамках проекта, например, планируется внедрение новой ИТ-системы, с которой будущие пользователи еще не знакомы, требуется организация их обучения в рамках проекта, и на данном шаге необходимо разработать план мероприятий по обучению.

По окончании этапа разработанные целевые процессы и планы по внедрению и обучению согласуются руководителем консалтингового проекта с ФЗ и руководителем проекта от заказчика, и если у последних не имеется возражений, данный этап может считаться завершенный, и начинается Этап 3 «Реализация проектного решения» (рисунок 23). В противном случае фиксируются дополнительные требования ФЗ и руководителя проекта от заказчика, после чего разработанное проектное решение корректируется командой и снова подлежит согласованию.

Этап «Реализация проектного решения» - самый длительный относительно общего срока выполнения в абсолютном большинстве консалтинговых проектов. На данном этапе проектная команда выполняет мероприятия по внедрению и обучению согласно утвержденным ранее планам, а руководитель проекта регулярно отчитывается руководителю проекта от заказчика о проделанных мероприятиях, при необходимости привлекая также функционального заказчика. Отчет о ходе реализации представляет собой документ MS Power Point, содержащий таблицу с перечнем мероприятий, результатов каждого мероприятия и статусов достижения каждого результата («выполнено» - зеленый индикатор статуса, «не выполнено, ожидается выполнение в срок» - желтый индикатор статуса, «Не выполнено, ожидается отклонение от планового срока/невозможно выполнить» - красный индикатор). По мероприятиям, по которым имеются результаты с красным индикатором статуса, требуется дать комментарии в отчете и предложить меры по устранению существующей проблемы.

Рисунок 24. Этап 3 "Реализация проектного решения" - входы, выходы, роли

Регулярность данных отчетов может быть разной в зависимости от длительности этапа и масштаба проекта, и цель данного процесса - информирование и оперативное разрешение возможных спорных вопросов, в результате чего проектная команда имеет возможность сразу параллельно вносить корректировки в работу с учетом замечаний заказчика, что снижает вероятность возникновения переработки в конце этапа. В том случае, если все-таки возникла необходимость в этом, и руководитель проекта от заказчика и ФЗ посчитали мероприятия по проекту невыполненными по их завершению в силу каких-либо причин, проектная команда реализует их дополнительные требования и снова согласует результаты выполнения мероприятий. Реализация дополнительных требований не обязательно может возникнуть в результате некачественной проработке требований заказчика. Зачастую возможны случаи, когда со стороны заказчика принимается решение о расширении периметра проекта, например, как функционального, так и организационного. То есть, либо в рамках проекта необходимо внедрить какой-либо дополнительный функционал, либо подразумевается, что решение нужно внедрить в большем числе подразделений компании-заказчика. В этом случае с руководителем проекта от заказчика могут быть согласованы и новые базовые параметры проекта (план-график и бюджет).

Рисунок 25. Этап 4 "Завершение" - входы, выходы, роли

После того, как завершение всех плановых мероприятий и результатов согласовано ФЗ и руководителем проекта от заказчика, реализацию проектного решения можно считать завершенной, а также выделить начало Этапа 4 «Завершение» (рисунок 24).

На последнем, самом коротком этапе, внедренное решение передается руководителю проекта от заказчика и его проектной команде. Результатом этапа является отчет о завершении реализации мероприятий по проекту, включающий в себя перечень выполненных перечень мероприятий согласно плану, результаты каждого мероприятия и статус их достижения (статус каждого мероприятия должен быть «выполнено»).

Как было сказано при описании организационной модели, с момента старта Этапа 2 «Разработка проектного решения» начинается непрерывный контроль сроков проекта, отраженный на рисунке Е. Проектная команда занимается расчетом ожидаемого отставания, принцип расчета которого был описан в главе 2 в описании переменных системно-динамической модели. Данные для расчета команда получает на основании утвержденного плана-графика, информации о реализованных мероприятиях и информации о расширении периметра проекта, если оно имело место. Исходя из плана-графика команда знает дату планового срока завершения проекта, также команде известно, какой объем мероприятий осталось выполнить на текущую дату. Для определения значения скорости исполнения работ команда может опираться на статистические данные, либо на его расчет согласно текущей дате и выполненному объему работ.

Таким образом, если значение показателя ожидаемого отставания превышает 1, делается вывод о том, что проект может столкнуться с отклонением от планового срока завершения в будущем и рассматривается возможность усиления проектной команды совместно с руководителем консалтингового проекта. В том случае, если принято решение об усилении команды, и в нее принят новый участник, расчет ожидаемого отклонения возобновляется с учетом данного факта.

Рисунок 26. Процессы управления сроками - входы, выходы, роли

Решение о продлении сроков может быть принято с высокой вероятностью, однако, предусматривая, что руководитель проекта от заказчика может предъявлять к команде консалтингового проекта завышенные требования и отказать в этом, то в данном случае руководитель консалтингового проекта может вынужденно принять решение об усилении команды.

Руководитель проекта может принять решение о том, что нет необходимости добавлять в команду новых участников, если причиной ожидаемого отставания является, например, расширение периметра проекта или необходимость реализовать некоторый объем дополнительных требований от заказчика. В этом случае необходимо совместно с руководителем проекта от заказчика утвердить новый срок завершения и актуализировать базовый план-график с учетом плана мероприятий по внедрению, обучению и расширении периметра и актуального отчета о ходе реализации. На выходе процесса сформирован обновленный план-график проекта.

 

.2 Эффект от применения организационной модели

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

Во-первых, любые согласования требуют дополнительных временных затрат. Согласно экспертам, имеющим опыт работы в качестве участников команд консалтинговых проектов, время, которое требуется для согласования того или иного промежуточного результата, зависит от ряда факторов. К ним, например, относится количество людей, с которыми необходимо согласования сделанной работы на данной шаге. Если результат проекта затрагивает деятельность нескольких функциональных подразделений компании-заказчика, соответственно, с большим числом руководителей данных подразделений необходимо их согласовать. Процесс согласования может затягиваться также по причине зачастую возникающих «испорченных телефонов» между функциональными подразделениями и проектной командой заказчика. В некоторых случаях к согласованию необходимо привлекать также ключевых пользователей конечного результата проекта. Иногда именно та информация, которая получена от пользователей, может являться весомой причиной того, чтобы считать этап проекта незавершенный, например, когда речь идет о реализации запросов на изменения. В качестве примера можно привести проект внедрения ERP-системы, охватывающей работу всей компании целиком. В данном случае согласование может затягиваться не на один месяц, а на реализацию дополнительных требований заранее предусматриваться несколько кварталов в базовом плане-графике.

К другим факторам, влияющим на длительность процесса согласования, является масштаб проекта и значимость его для компании в целом. Если проект является стратегически очень значимым, и его результат, полученный в полном объеме и в срок критичен для компании, обычно обеспечивается в различных аспектах поддержка данного проекта высшим руководством. Топ менеджеры компании-заказчика имеют полномочия в случае необходимости ускорить процесс согласования и скоординировать действия руководителей функциональных подразделений.

Ускорить время согласования возможно, в качестве одного из вариантов, обозначив временные рамки, в которые нужно уложиться при выполнении данной процедуры. Если данные временные рамки не прописаны в стандартах по управлению проектами и других нормативных документах в компании заказчика, их необходимо обозначить руководителю консалтингового проекта при составлении плана коммуникаций при инициации проекта. При установке четкого количества дней, за которые необходимо согласовать результат, снимается неопределенность по срокам исполнения. В данном случае можно заложить некоторое количество дней в качестве буфера и учесть их в базовом пане-графике. В некоторых случаях компаниями применяется такая практика, при которой результат считается автоматически согласованным, если в течение времени более установленного допустимого срока не от руководителя проекта заказчика не поступает обратной связи, однако, это может быть чревато возникновением большего объема корректировок на следующих этапах.

Экспертами были даны некоторые количественные оценки времени на согласование по вехам в конце каждого этапа. Если учесть разницу в специфике разных проектов, в их масштабе и других аспектах, среднее время на согласование составляет около 5 - 10 дней. За это время информация о статусе проекта и промежуточном результате должна быть донесена до руководителя проекта заказчика, функциональных заказчиков и других заинтересованных сторон, если в этом есть необходимость, и получена обратная связь от них, в том числе, требования по корректировкам, если в них возникает необходимость. По окончании этапа анализа бизнес-кейса после формирования требований к решению объем необходимых корректировок обычно не превышает 20-30% по отношению к первоначальному объему. На следующих этапах при условии постоянного вовлечения заказчика в работу над проектом объем корректировок не превышает 5-10%. Однако, в том случае, когда после фиксации требований к решению заказчика не информируют о текущей работе до конца разработки решения, объем может быть больше. На этапе реализации при условии подготовки еженедельных отчетов о статусе проекта объем корректировок минимален, однако, запросы на изменения от пользователей и функциональных заказчиков все равно могут иметь место. Таким образом, усредненный объем корректировок составляет примерно 10-20% от первоначального объема.

Описанная в данной главе организационная модель предполагает также постоянный контроль расписания, начиная с этапа разработки решения. Данный процесс идет параллельно, не увеличивая потенциальное отставание проекта, однако, необходимо выделить ресурсы в виде одного дополнительного члена команды, который занимался бы данный направлением. От него требуется заниматься своевременной экспертной оценкой объема выполненных работ путем взаимодействия со всеми участниками проектной команды и получения от них информации касательно выполняемых ими задач. Стоит отметить, что данный участник команды должен обладать достаточно развитыми поведенческими компетенциями, такими, лидерство, уверенность и убедительность, снятие напряженности, открытость, ориентированность на результат, умение вести переговоры. Согласно экспертному мнению, подобный контроль может негативно восприниматься людьми, и человек, ответственный за это может быть некой назойливой мухой в глазах других сотрудников, он, очевидно, должен уметь находить правильный подход к коммуникациям. Также, если руководитель проекта может грамотно донести до своей команды все издержки и преимущества контроля и привести доходчивое обоснование его необходимости, то в этом случае команда способна его принять.

Согласно результатам моделирования, описанным в главе 2, при более позднем начале контроля сроков (после завершения 70% от планового срока проекта) проект может выполняться на 10% дольше, чем в случае постоянного контроля сроков с самого начала.

Основываясь на результатах анкетирования, среднее отклонение по срокам среди проектов респондентов составило около 38% от первоначального. Таким образом, данное отклонение будет считаться базовым, при расчете эффекта применения вышеописанной организационной модели. Основываясь на данных о плановой длительности проектов, в которых участвовали респонденты, определена средняя плановая продолжительность проектов.

Таблица 1. Расчет дельты нормированной длительности проекта с учетом применения организационной модели

		Организационная модель, дни	Организационная модель, норм.	Организационная модель не применяется (дни)	Организационная модель не применяется. Норм.
Плановая длительность		196	100	196	100
Прирост длительности	Согласование	15	76	38
	Корректировки: Этап Анализа кейса	3	1,5
	Корректировки: Этап разработки решения	6	3
	Корректировки Этап реализации	8	4
Фактическая длительность		243	123,5	272	138
Эффект от раннего контроля отклонений (10%)		24	13
Фактическая длительность с учетом контроля отклонений			110,5
Дельта нормированной длительности (дни)		-27,5

Можно сделать вывод о том, что при условии плановой длительности проекта в 100 дней при регулярных коммуникациях с руководителем внутреннего проекта компании и функциональными заказчиками, вовлечении их в процесс управления проектом, а также при условии начала активного контроля возможного отклонения от планового срока сразу после утверждения базового плана-графика возможно минимизировать итоговое отклонение по срокам примерно на 20%, снизив его примерно до 10,5 дней. Стоит отметить, что кроме данной экономии времени имеет место также прирост в виде одного человеческого ресурса в первоначальном составе команды, который необходим для параллельного контроля выполнения работ и ожидаемого отставания.

Таким образом, эффект от применения описанной в данной главе организационной модели заключается в следующем. Во-первых, ожидается снижение общего объема дополнительных требований, которые необходимо реализовать в течение проекта. Это влечет за собой улучшение показателя отклонения по срокам - ожидается снижение отклонения от плановой даты завершения за счет своевременных и качественных коммуникаций с заказчиками, а также своевременного усиления команды. Качество коммуникаций должно быть повышено за счет включения в управление проектом взаимодействия как с руководителем проекта от компании-заказчика, так и функционального заказчика, располагающего информацией о потребностях и ожиданиях конечных пользователей проектного решения. Вследствие начала контроля возможных отклонений в начале проекта снижается вероятность отклонения от плана на заключительных этапах за счет своевременного усиления проектной команды, либо согласования измененных базовых параметров.

 

.3 Выводы по Главе 3

В данной главе разработана организационная модель консалтинговых проектов с учетом выводов, полученных во второй главе, включающую в себя процессы взаимодействия с заказчиком и управления сроками. Каждому процессу модели присвоены роли, входы и выходы. Были даны рекомендации применительно к процессам на каждом этапе жизненного цикла консалтингового проекта.

Данный подход к управлению сроками консалтинговых проектов включает в себя контроль по вехам, ориентированный на поэтапное согласование и выполнение работ, а также постоянное вовлечение заказчика в проект. Подход сопряжен с увеличением временных затрат и трудозатрат на первых этапах, однако, положительный эффект от применения данной организационной модели превалирует над указанными дополнительными затратами за счет снижения ожидаемого объема корректировок и минимизации отклонения длительности проекта от плановой, а также минимизации риска столкнуться с отставанием, связанным с чрезмерной перегруженностью ресурсов.

Из вышесказанного можно заключить, что применение данной организационной схемы влияет положительно не только на то, насколько проект способен уложиться в плановые сроки, но и непосредственно на качество конечного результата. Каждый консалтинговый проект уникален, так же, как уникален клиент и результат, который он ожидает получить, и чем более минимизирован разрыв между данными ожиданиями и результатом, тем большую пользу он представляет для заказчика в конечном итоге.

Заключение

Цель данной работы заключалась в исследовании влияния команды проекта на величину отклонения по срокам при помощи системно-динамического моделирования, выявление причин задержки сроков и эффективным мер по ее минимизации, разработка оптимальных процессов управления сроками в консалтинговых проектах.

Рабочая гипотеза Н1: закон Брукса действителен для консалтинговых проектов, то есть, добавление новых членов в команду способствует большей задержке сроков завершения консалтингового проекта - не подтверждена.

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

Таким образом, оптимизация процессов управления сроками и улучшение качества взаимодействия с заказчиком способны обеспечить более эффективную реализацию консалтинговых проектов, развивая потенциал по оптимизации экономических показателей деятельности компании в будущем, а также потенциально оказывая положительное влияние на репутацию консалтинговой компании, что является одним из важнейших активов для игроков данной отрасли.

Список использованной литературы

консалтинговый проект управление срок

1.     Багратиони К.А., Алешин А.В., Аньшин В.М. Управление проектами: фундаментальный курс; под ред. Аньшина В.М., Ильиной О.Н., М: Национальный исследовательский университет - Высшая школа экономики. 2013. 624 с.

2.       Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. Чапелл-Хилл: Forbidden reality. 1995. 171 с.

.        Грей К.Ф, Ларсон Э.У. Управление проектами. М:Дело и сервис. 2007. 608 с.

.        Кон М. Scrum: Гибкая разработка ПО. М.: Вильямс. 2015. 576 с.

.        Мартин Р.К., Ньюкирк Д.В., Косс, Р.С. Быстрая разработка программ: принципы примеры, практика. М.: Вильямс. 2004. 752 с.

.        Медоуз Д. Азбука системного мышления. М: БИНОМ. Лаборатория знаний. 2011. 170 с.

.        О’Коннор Д., Макдермотт И. Искусство системного мышления. М: Альпина Бизес Букс. 2008. 256 с.

.        Сенге П. Пятая дисциплина: Искусство и практика самообучающейся организации. М.: Олимп-Бизнес. 2003. 408 с.

.        Форрестер Д. Мировая динамика. М: Terra Fantastica. 2003. 379 с.

.        Шервуд. Д. Видеть лес за деревьями: Системный подход для совершенствования бизнес-модели. М.: Альпина Паблишер. 2012. 341 с.

.        Ципес Г.Л., Товб А.С. Проекты и управление проектами в современной компании. М.: Олимп-Бизнес. 2009. 480 с.

.        Лобода Л.Н. Создание стратегических конкурентных преимуществ на рынке консалтинга // Маркетинг и маркетинговые исследования. 2006. №1. С. 10 - 20)

.        Нестеренкова О.А. Классификационные признаки консалтинговых услуг // Маркетинг и финансы. 2014. №2. С. 110 - 114)

.        Савушкин Э.Ю. Основные аспекты реализации консалтингового проекта // Маркетинг услуг. 2007. №2. С. 108 - 121

.        Ципес Г.Л., Садков Д.В. Проектно ориентированный подход к построению консалтингового бизнеса // Управление проектами и программами. 2008. №4. С. 288 - 299

.        ГОСТ Р 54869―2011 «Требования к управлению проектами»

.        Руководство к своду знаний по управлению проектами (руководство PMBoK). Пятое издание

18.     Forrester J. Industrial dynamics. MIT Press, Cambridge, MA (1961)

.        Royce W.W. Managing the Develoment of Large Software systems. Proceedings of IEEE Wescon, 1970

.        Abdel-Hamid T. B. The dynamics of software development project management: an integrated perspective. 1984

.        Back Y., Praveen Parboteeah K., Nama D. Innovation in Emerging Markets: The Role of Management Consulting Firms // Journal of International Management/ 20 (2014)

.        Bessant J., Rush H. Building bridges for innovation: the role of consultants in technology transfer // Res. Policy 24 (1995) 97 - 114

23.     Creplet F., DuPouet O., Kern F., Mehmanpazir B., Munier F. Consultants and experts in management consulting firms. Res. Policy 30 (2001) 1517-1535.

.        Czernawska F. What sets excellent consulting apart // Consulting Management 15 (2004). 47 - 49

.        Grant P. Chapter 4. The Consulting Project lifecycle // Business Psychology in Practice. № 5. 2008. 22 - 35

.        Highsmith J.A. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002

.        Howick. S. Using system dynamics to analyze disruption and delay in complex projects for litigation: can modelling purposes be met?// Journal of Operational Research Society (2003) 54, 222-229

.        Howick S., Eden C.I. On the nature of discontinuities in system dynamic modelling of disripped projects // Journal of the Operational Research Society (2004) 598 - 605

.        Jacobson N., Butterill D., Goering P. Consilting as a strategy for knowledge transfer // Milbank Q. 83 (2005) 199 - 321

.        Jang Y., Lee J.. Factors influencing the success of management consulting projects // International Journal of Project Management (1998)

.        Nam-Hong Yim, Soung-Hie Kim, Hee-Wong Kim, Kee-Young Kwahk. Knowledge based decision making on higher level strategic concerns: system dynamics approach // Expert Systems with Application. 27 (2004) 143-158

.        Nasirzadeh F., Nojedehi P.. Dynamic modelling of labor productivity in construction projects, // International Journal of Project Management (2013) 903-911

.        Pidd M. Tools for thinking: Modelling in Management Science. 3rd ed. Aptara Inc., 2003.

.        Yelin Xu a, b,⁎, Chengshuang Sun c, d, Miroslaw J. Skibniewski c, Albert P.C. Chan e, John F.Y. Yeung f, Hu Cheng. System Dynamics (SD) -based concession pricing model for PPP highway projects // International Journal of Project Management 30 (2012) 240-251

35.     www.pmi.com <#"908009.files/image029.gif">

Приложение 2. Формулы расчета переменных разработанной системно-динамической модели

Переменная	Формула
Ожидаемое отставание	(Time+Осталось выполнить/(Выполнение работ+0.001))/Плановая длительность
Выполнение работ	IF THEN ELSE(Осталось выполнить<=0, 0 , IF THEN ELSE(Осталось выполнить<=1,(0.19*(1-"t ком."-t обучение)+0.57*((1+0.3*0.8)-"t ком."-t обучение)+0.24*((1+0.4*0.3)-"t ком."-t обучение))*Эффект команды*(ПУ 4 этап+ПНУ 4 этап)/2 , IF THEN ELSE(Осталось выполнить<=2, (0.19*(1-"t ком."-t обучение)+0.57*((1+0.3*0.8)-"t ком."-t обучение)+0.24*((1+0.4*0.3)-"t ком."-t обучение))*Эффект команды*(ПНУ 3 этап+ПУ 3 этап)/2 , IF THEN ELSE(Осталось выполнить<=3, (0.19*(1-"t ком."-t обучение)+0.57*((1+0.3*0.8)-"t ком."-t обучение)+0.24*((1+0.4*0.3)-"t ком."-t обучение))*Эффект команды*(ПУ 2 этап+ПНУ 2 этап)/2 , (0.19*(1-"t ком."-t обучение)+0.57*((1+0.3*0.8)-"t ком."-t обучение)+0.24*((1+0.4*0.3)-"t ком."-t обучение))*Эффект команды*(ПУ 1 этап+ПНУ 1 этап)/2 ) ) ) )
Требуемое число новых участников	IF THEN ELSE(Ожидаемое отставание<=1, 0 ,IF THEN ELSE(Осталось выполнить<=1, 1 , IF THEN ELSE(Осталось выполнить<=2, 2 ,IF THEN ELSE(Осталось выполнить<=3,2 ,1 ) ) ) )
Решение об усилении команды	IF THEN ELSE(Time/5.5=INTEGER(Time/5.5), 1 , 0 )
Наем	IF THEN ELSE(Выполнено>=4, 0, Требуемое число новых участников*Решение об усилении команды )
Новые участники	Новые участники(i-1) + Наем - Обучение, Initial Value = 0
Обучение	0.17*Новые участники
Участники	Участники(i-1) + Обучение, Initial Value = 0
t ком.	IF THEN ELSE((Участники+Новые участники)>15, 0.15 , IF THEN ELSE((Участники+Новые участники)>10, 0.12 , IF THEN ELSE((Участники+Новые участники)>5, 0.1 , 0.05 ) ) )
Эффект команды	LOG((Участники+Новые участники), 2 )
Осталось выполнить	Осталось выполнить(i-1) - Выполнение работ, Initial Value = 4
Выполнено	Выполнено (i-1) + Выполнение работ, Initial Value = 0
PV	PV(i-1) + Накопление PV, Initial Value = 0
Накопление PV	IF THEN ELSE(Выполнено<=1, 10 , IF THEN ELSE(Выполнено<=2, 16.67 , IF THEN ELSE(Выполнено<=3, 6 , 10 ) ) )
EV	EV(i-1) + Накопление EV, Initial Value = 0
Накопление EV	IF THEN ELSE(Выполнено<=1, Выполнение работ*150 , IF THEN ELSE(Выполнено<=2, Выполнение работ*500 ,IF THEN ELSE(Выполнено<=3, Выполнение работ*300 , Выполнение работ*50 ) ) )
AC	AC(i-1) + Накопление AC, Initial Value = 0
Накопление AC	IF THEN ELSE(Выполнено<=1, Выполнение работ*150*1.13 , IF THEN ELSE(Выполнено<=2, Выполнение работ*500*1.11 ,IF THEN ELSE(Выполнено<=3, Выполнение работ*300*1.15 , Выполнение работ*50*1.05 ) ) )
SPI	EV/PV
CPI	EV/AC
CR	CPI*SPI

Приложение 3. Организационная модель консалтингового проекта с учетом ролей, входов и выходов