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

Одна из причин особенностей консалтинговых проектов, а именно - наличие большого объема сверхурочной работы, которая учтена в разработанной модели. Результаты анкетирования показали, что большинство респондентов работали сверхурочно чаще трех раз в неделю, и только 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: закон Брукса действителен для консалтинговых проектов - не подтверждена.

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

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

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

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

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

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

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

2.4 Выводы по Главе 2

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

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

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

На основании проведенного исследования также можно заключить, что чем раньше начинает проводиться мониторинг и контроль расписания, тем меньше вероятность отклонения от планового срока завершения.

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

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

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. Процессы управления сроками - входы, выходы, роли

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

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

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

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

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

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

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

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

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

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

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

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

	Организационная модель, дни	Организационная модель, норм.	Организационная модель не применяется (дни)	Организационная модель не применяется. Норм.
Плановая длительность	196	100	196	100
Прирост длительности	Согласование	30	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 Выводы по Главе 3

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. 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.

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

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

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

27. 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

28. 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

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

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

31. 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

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

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

34. 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

36. www.vensim.com

Приложение 1. Анкета для опроса руководителей и участников консалтинговых проектов



Приложение 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. Организационная модель консалтингового проекта с учетом ролей, входов и выходов

Размещено на Allbest.ru