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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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