Роль бизнес-заказчика в ИТ-проекте

Заказчик и проектный менеджер

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

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

Потеряв некоторое количество времени на вдумчивое чтение и перечитывание, можно догадаться, что это всего-навсего описание процесса коммуникации между двумя людьми.

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

Эта фича не входит в скоуп моего проекта, поэтому является риском и должна быть митигирована.

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

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

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

Проблемы ИТ-проектов
и причины их проблем

У каждой аварии есть фамилия, имя и отчество!

Сталинский нарком железных дорог Л. М. Каганович

Существует обширная статистика по неудачам и проблемам ИТ-проектов. Данному предмету посвящено большое количество книг, статей и аналитических исследований. Считается, что только 30 % ИТ-проектов полностью успешны, порядка 50 % сталкиваются с теми или иными сложностями, примерно 20 % проваливаются.

В большинстве исследований проводится анализ причин возникновения проблем на проектах. В таблице 1 приведен список причин из трех исследований:

• обзор Standish Group The Chaos Chronicles;
• исследование по 2200 проектам от консультантов Vital Smarts и Concours Group;
• опрос, проведенный ассоциацией Computing Technology Industry Association (CompTIA).

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

Таблица 1. Причины возникновения проблем на проектах.

Роль заказчика
в «идеальном» мире

Все нужное человеку — просто, все сложное — не нужно.

Лев Толстой

Сначала рассмотрим роль бизнес-заказчика в «идеальном мире». В первом приближении для любого проекта (не обязательно ИТ) ее можно описать пятью основными задачами:

1. провести целеполагание, то есть понять и сформулировать проблему, которую должен решить проект, определить цели, ожидаемые результаты проекта и требования к ним;
2. провести работу с исполнителем: выбрать исполнителя, объяснить ему задачу и проконтролировать, что задача понята адекватно;
3. обеспечить исполнителя: выделить исполнителю ресурсы (если необходимо) и полномочия (если не хватает);
4. принять от исполнителя результаты проекта;
5. использовать полученные результаты в своей деятельности.

Несколько утрируя, можно отразить это в виде схемы, показанной на рис. 1.

Рис. 1. Степени активности заказчика на проекте.

 Например, для проекта внедрения ERP-системы в «идеальном» мире роль заказчика можно описать следующим образом:

1. Проблема — большие остатки на складах. Для решения данной проблемы нужно внедрить модуль учета складских остатков ERP-системы. На основе информации из ERP-системы можно будет провести оптимизацию процессов и уменьшить объем остатков (выгоды).

Цель проекта — внедрение складского модуля2.

Результаты проекта:

• настроен модуль;
• обучены пользователи и администраторы;
• проведена опытная эксплуатация;
• разработана проектная и эксплуатационная документация;
• обновлены регламенты бизнес-процессов.

Требования к данным результатам детализируются в виде «Технического задания» (ТЗ) или «Запроса на предоставление коммерческого предложения» (RFP).

2. Для выбора исполнителя проводится тендер, на который выставляется ТЗ или RFP.

3. Исполнителю выделяются финансовые и человеческие ресурсы (в виде ключевых пользователей).

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

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

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

Роль заказчика
в «реальном» мире

Больше всего в этом нашем мире тревожит не то, что он неразумен, и даже не то, что он разумен. Чаще всего нас тревожит то, что он почти разумен, но не совсем. Жизнь не алогична; однако сама она является ловушкой для логичного человека. Она выглядит немного более логичной и правильной, чем есть на самом деле; ее правильность очевидна, а ее неправильность скрыта; ее хаотичность подстерегает нас…

Гилберт Кит Честертон

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

1. «неидеальность» исполнителя. Этот фактор может проявляться различными способами:

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

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

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

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

• стратегический уровень: акционеры (для крупных проектов) и/или топ-менеджмент;
• тактический уровень: средний менеджмент и ключевые пользователи;
• операционный уровень: конечные пользователи.

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

3. сложность создаваемых и внедряемых ИТ-систем. Это особенность не только «реального мира» вообще, но и предметной области информационных технологий. Данная проблематика подробно освещена во многих статьях и книгах, но раньше всех и, на мой взгляд, лучше всех об этом написано в классической книге Фредерика Брукса «Мифический человеко-месяц»:

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

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

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

Хотя список факторов, приводящих к «неидеальности мира», далеко не полон, подведем некоторые итоги. Обобщить роль заказчика ИТ-проектов в «реальном мире» можно следующим образом. Заказчик должен:

1. понять проблему, определить цель, ожидаемые результаты и выгоды, существующие ограничения (бюджет, сроки и т. д.);
2. разделить роль заказчика (делегировать полномочия) между всеми заинтересованными сторонами и понять, как будут учитываться их интересы;
3. определить требования и приоритеты (срок, функционал, бюджет, качество, важность результатов);
4. определить варианты решений, из которых впоследствии и будет выбран один окончательный вариант;
5. выбрать исполнителя, корректно поставить задачу, официально предоставить полномочия;
6. выделить ресурсы, в том числе время сотрудников заказчика, на каждом уровне;
7. контролировать проект;
8. принимать по его ходу принципиальные решения с учетом целей проекта и требуемых результатов;
9. осуществить приемку результатов;
10. начать использовать результаты и проконтролировать, что результаты приносят заявленные выгоды.

Графически действия заказчика ИТ-проектов в «реальном» мире можно представить как показано на рис. 2.

Рис. 2. Действия заказчика ИТ-проектов в «реальном» мире.

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

Практические рекомендации
заказчику в «реальном» мире

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

Отто фон Бисмарк

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

1. Определите, кому конкретно и зачем нужен проект. Перед запуском проекта зафиксируйте в отдельном документе (его можно назвать «Уставом проекта», «Паспортом проекта» или «Запросом на проект») несколько основных моментов:

• заказчик проекта. А есть ли человек/подразделение, которому действительно нужен этот проект? Готов ли он его отстаивать?
• проблему, которую вы решаете. Зачем мы запускаем проект? Является ли проблема достаточно серьезной, чтобы тратить время и ресурсы на ее решение?
• цели проекта и ожидаемые результаты. Как мы видим себе выход проекта? Что мы получим в результате его выполнения?
• какие выгоды принесут данные результаты. Являются ли данные выгоды решением проблемы? Достаточны ли они?
• важнейшие ограничения (бюджет, сроки, ресурсы);
• каковы приоритеты в проекте.

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

2. Распределите ответственность со стороны заказчика. В рамках проектной команды со стороны заказчика стоит выделить как минимум три роли:

• необходимо определить, кто будет осуществлять стратегическое управление проектом на стороне заказчика: определять цели и приоритеты проекта, обеспечивать проект ресурсами, разрешать конфликтные ситуации и т. д. Это может быть отдельное лицо — спонсор, заказчик, владелец проекта. В ГОСТ 54869 «Требования к управлению проектом» эта роль называется Куратор. Или это может быть коллективный орган («Управляющий комитет», «Управляющий совет»). Тогда Куратор становится председателем этого органа;
• необходимо определить, кто будет осуществлять непосредственное тактическое управление проектом на стороне заказчика: готовить планы, ставить задачи рабочей группе, контролировать подрядчика. Роль может называться ответственный за проект, лидер проекта, менеджер проекта от заказчика. В ГОСТ 54869 «Требования к управлению проектом» эта роль называется Руководитель проекта;
• необходимо определить, кто сформулирует требования к результатам и кто по окончании проекта будет использовать полученные на проекте результаты. В ГОСТ 54869 «Требования к управлению проектом» именно эта роль называется Заказчик.

Принципиально важно, что Куратор проекта не должен быть тем же лицом, что и Руководитель проекта/Заказчик — у них разные роли и разная вовлеченность в проект. Куратор, чтобы выполнять свои функции, должен занимать достаточно высокое положение в иерархии организации. Обычно у таких людей просто физически нет времени ни для непосредственного руководства проектом, ни для детальной работы с требованиями к продуктам. Кроме того, их отстраненность от проектной «текучки» позволяет принимать более взвешенные стратегические решения. Роль же Заказчика и руководителя может быть совмещена, если у Заказчика есть время и компетенции, необходимые для управления проектом.

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

— заранее определите экспертную группу для оценки предложений и роли в ней;

— определите критерии выбора (взаимно не исключающие и не дублирующие друг друга) и процедуру утверждения;

— подготовьте документ RFP (Request for proposal, «запрос на коммерческие предложения»), включающий:

• состав работы подрядчика;
• требования к результатам работы (к внедряемой системе);
• требования по срокам и стоимости проекта;
• требования к ведению проекта;
• предоставляемые подрядчиком на тендер материалы;
• информацию о принципах выбора подрядчика;

— тщательно проанализируйте присланные предложения на предмет соответствия RFP. Подрядчики любят «забывать» неприятные для них вещи. Смотрите на резюме предлагаемых членов проектной команды. Для критичных и сложных проектов имеет смысл предварительно встретиться с предлагаемым менеджером проекта со стороны исполнителя и оценить его адекватность (особенное внимание обратите на резюме проектного менеджера);

— внимательно проработайте договор (обязанности сторон, оплаты, правила приемки работ, штрафные санкции, интеллектуальная собственность).

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

5. Контроль процесса и результатов. Критически важно, чтобы обе стороны придерживались согласованного плана и выполняли взятые на себя обязательства. При этом все неисполнения обязательств должны быстро выявляться и разрешаться. Формулировка «мы им платим деньги, пусть они и работают, у нас другие дела есть» — первый большой шаг к провалу. Внедрение сложной системы требует обязательного плотного взаимодействия между заказчиком и проектным менеджером. Их взаимного терпения, уважения и взаимопонимания. Но при этом и контроля. Обратите внимание: вопрос не в контроле проекта со стороны проектного менеджера (это является составной частью практически всех существующих методологий проектного управления), имеется ввиду контроль за проектом вне самого проекта. Фактически это контроль самого проектного менеджера. О построении системы контроля проекта со стороны заказчика я рассказывал в отдельной статье «Контроль инновационных проектов. Как руководителю контролировать идущие проекты?».

Роль заказчика
в «кризисном» проекте

Кризис — ситуация, при которой совокупность обстоятельств, ранее вполне приемлемая, вдруг, с появлением какого-то нового фактора, становится совершенно неприемлемой

Льюис Борнхайм

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

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

В таком случае можно говорить о том, что проект входит в кризисное состояние:

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

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

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

1. Объединить ответственность со стороны заказчика в одном лице. Несколько ролей со стороны заказчика — это правильный и эффективный подход, но если проект вошел в кризисное состояние, он становится обузой. В кризис надо максимально сосредоточить всю власть по принятию решений в одних руках, объединить стратегический и тактический уровни управления. Это поможет избежать многих согласований и радикально ускорить реакцию системы управления проектом на проблему. При этом, разумеется, тот, в чьих руках сосредотачивается власть, должен выделить достаточно времени для решения всех многочисленных вопросов, с которыми к нему будут обращаться. Более того, очень желательно минимизировать влияние других стейкхолдеров на проект. В идеале основной заказчик проекта должен взять всю ответственность за проект на себя.
2. Пересмотреть и приоритизировать требования к результатам проекта. Исходя из сложившейся ситуации необходимо детально пересмотреть требования к результатам проекта. Надо выделить критичные требования, важные требования, желательные требования. Соответственно, команда проекта в первую очередь должна работать над критическими требованиями, затем важными и уже потом, по возможности, над желательными.
3. Провести мобилизацию команды. Изменить отношение проектной команды и вовлеченных специалистов к проекту. При нормальном течении проекта можно не выполнять те или иные задачи, переносить сроки, принимать неверные решения, потом откатываться назад, принимая другие решения. В кризисной ситуации любое такое действие ведет к провалу проекта. Поэтому в проектной команде необходимо создать ситуацию «отступать некуда — позади Москва». Инструменты для этого могут быть различные: от серьезной материальной мотивации до угрозы очень жестких административных или даже уголовных мер в случае провала, — тут все зависит от конкретной ситуации и компании. В общем, можно сказать, что для таких ситуаций у команды должна быть очень серьезная «морковка спереди и морковка сзади».
4. Изменить систему контроля заказчиком проекта. Выше мы говорили о необходимости создания такой системы. Но та система контроля, которая сформирована в нормальной фазе проекта, не может быть эффективной в кризисной фазе. Необходимо изменить:

• инструменты контроля проекта — отчеты и подходы к совещаниям, контрольные точки и т. д. (изменить ответ на вопрос, какие инструменты использовать3);
• объем и детальность информации, предоставляемой заказчику (изменить ответ на вопрос, как глубоко смотреть);
• частоту предоставления информации.

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

 ***

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

Комментарии 0