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

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

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

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

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

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

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

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

• · Руководитель консалтингового проекта (на смехе в Приложении 3 — Руководитель проекта — К)
• · Команда консалтингового проекта (на смехе в Приложении 3 — Проектная команда — К)
• · Руководитель проекта от заказчика (на смехе в Приложении 3 — Руководитель проекта — З)
• · Функциональный заказчик (на смехе в Приложении 3 — Функциональный заказчик)

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

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

Начиная с этапа анализа бизнес-кейса, который начинается после завершения процесса инициации, целью которого является формальное открытие проекта (ГОСТ Р 54 869Ї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. Процессы управления сроками — входы, выходы, роли.

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

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