Практика проектной деятельности в области информационных технологий изобилует случаями, когда успешные проекты делались не благодаря, а вопреки многим правильным методологиям. Например, когда в процессе реализации проекта изменяются условия и контракт перестает соответствовать действительности, руководителю приходится «корежить» методологию управления проектом. Зачастую потом оказывается, что именно это и спасло проект от провала.
Попробуем найти закономерность в управлении именно «неправильными» проектами, представляющими собой не лучшую, а реальную практику (на примере проектов внедрения ERP-систем).
Как только мы переходим от рассмотрения лучшей к анализу реальной проектной практики, мы сразу обнаруживаем разнообразие форм организации проектов, дающих вполне удовлетворительные и предсказуемые результаты. Подобные устойчивые формы организации будем называть стилями проектов.
Стиль проекта - это не просто еще один классификационный признак проектов. Он вполне реален и аналогичен живому организму: стиль обладает целостностью и внутренней логикой, оптимальными условиями существования и стратегией адаптации к их изменениям, предсказуемыми результатами, иммунитетом к внутренним изменениям, он даже способен себя воспроизводить в других проектах. Стиль проекта обладает удивительной устойчивостью и закладывается на ранних этапах проекта. Автор неоднократно наблюдал острые конфликты разных стилей, которые исповедовали проектные группы в параллельно идущих и взаимодействующих ИТ проектах. Понятие стиля уже встречается в реальной проектной практике.
Для того, что бы можно было перейти к анализу стилей, необходимо сначала систематизировать описание характеристик объектов автоматизации и реальной практики выполнения проектов. В противном случае все просто сведется к описанию случаев из жизни со счастливым или печальным концом.
Конфигурации бизнеса
Примером удачной систематизации устойчивых форм организации (в бизнесе) является теория конфигураций бизнеса, разработанная Генри Минцбергом [1] и основанная на классификации механизмов координации людей при совместной работе. В современных бизнес-организациях Минцберг выделил пять доминирующих типов таких механизмов: «прямой контроль» ( работа по прямым поручениям, непосредственное управление действиями персонала ), «стандартизация операций» ( работа по инструкциям в рамках бизнес-процессов, управление не людьми, а правилами и процедурами, по которым они работают ), «стандартизация квалификации» ( работа, основанная на профессиональном искусстве специалистов, управление назначением или смещением с должности, контролируется только квалификация персонала ), «взаимное согласование» (коллективная работа, управление в виде уточнения и согласования требований к результатам, условиям или участникам некоего уникального рабочего процесса ), «стандартизация выпуска» ( работа по достижению заданного результата, управление в виде определения и согласования планов выпуска и обеспечения ресурсами ).
Минцберг показал, что доминирующие в бизнесе механизмы координации, фактически, определяют саму форму его организации, которую он назвал конфигурацией бизнеса . Согласно проведённым исследованиям, одни и те же конфигурации могут присутствовать в разных отраслях, так же как и разные конфигурации могут «уживаться» в рамках одной корпорации, и лишь в некоторых случаях границы конфигурации и фирмы совпадают.
Кроме этого, конфигурации бизнеса подвержены жесткому отбору, для каждой из них существует своя зона выживания. Минцбергу удалось найти ключевые характеристики описания этих зон выживания . Оказалось, что выбор конфигурации бизнеса в большей степени определяется не отраслевой направленностью и не персоналиями, а уровнем неопределенности в получении технического (горизонтальная ось) и коммерческого (вертикальная ось) результатов (Рис.1).
Минцберг выделил пять конфигураций [1], описал их и определил условия их выживания. На Рис.1 приведены области устойчивого существования конфигураций бизнеса (в системе координат так называемого квадрата неопределенности ).
Для бизнеса на рынке ИТ можно привести следующие реальные примеры перечисленных конфигураций: «простая конфигурация» - разовые «коробочные» продажи, «механистическая бюрократия» - дистрибуция программного и аппаратного обеспечения, «профессиональная бюрократия» - обучение и техническая поддержка, «адхократия» - заказные уникальные разработки, интеграционные проекты или внедрение больших интегрированных систем, «дивизиональная конфигурация» - комплексные продажи в рамках крупного системного интегратора. Аналогичный полный набор конфигураций можно найти в любой отрасли.
Стили ИТ-проекта
«Проект это временная организация для создания уникального продукта, оказания уникальной услуги или получения другого уникального результата» [3]. Именно эта временность организации принципиально отличает ее от других организационных форм. Тем не менее, в проекте действуют те же люди, что и в регулярном бизнесе и между ними складываются те же механизмы координации, которые описал Минцберг. Из этого следует, что в реальных проектах могут наблюдаться устойчивые формы организации ( стили ), аналогичные конфигурациям бизнеса.
Следуя описанному подходу, проект необходимо рассматривать не только с позиции руководителя проекта, но и позиций других ключевых его участников, требуется также проанализировать внешние условия, в которых зарождался и протекает проект. Выделяя стиль проекта, нужно описать устойчивые связи между ключевыми параметрами и окружением проекта, отражающие внутреннюю логику его организации.
Области управления ИТ-проектом
Большинство стандартов по управлению проектами [3,4] описывают точку зрения на проект только одного из его ключевых участников, а именно руководителя проекта. Однако существуют и другие ключевые участники, предмет деятельности и область ответственности которых выходят за границы реальных полномочий руководителя проекта. К ним относятся архитектор1 ( главный инженер ) и спонсор2( директор ) проекта.
Не претендуя на полноту охвата всех аспектов проекта внедрения ERP-систем, по каждой из областей управления приведем лишь некоторые существенные параметры, отражающие внутреннюю логику стиля.
Областью ответственности архитектора проекта является управление внедрением . На этот процесс влияют: стратегия внедрения системы, уровень неопределенности в требованиях к функциональности решения, характер и объем доработок функциональности, архитектура решения, получающаяся в результате внедрения [6].
Сфера деятельности руководителя проекта - управление проектом . Здесь среди определяющих факторов можно выделить: область лидерства и характер принятия решений, глубину и значимость планирования и контроля проектных работ, характер квалификации, установок и уровень занятости членов проектной группы, а также характер коммуникаций в проектной группе .
Задачей спонсора проекта является управление контрактом . На его эффективность влияют: позиция сторон в переговорном процессе, предмет проектного контракта, характерный тип контракта, характер получения сторонами бизнес-эффекта .
Указанные параметры деятельности ключевых участников проекта и формируют как таковой стиль проекта, определяя форму его организации, которая в значительной степени влияет на коммерческие и технические результаты проекта.
Как это ни парадоксально, но стиль в большей степени может определять архитектуру получаемого итогового решения, чем архитектура составляющих его готовых бизнес-приложений.
Описанные ниже стили могут встречаться при внедрении не только одной и той же ERP-системы, но даже и в проектах одного интегратора.
|
Политический проект | ||
|
Управление внедрением |
Управление проектом |
Управление контрактом |
| Стратегия внедрения - «Натягивание системы на существующий бизнес». | Решения принимаются одним лидером - все остальные работают по его поручениям. Главную роль играет спонсор проекта, руководитель проекта играет техническую роль. | Диктат заказчика выражается формулой «Мы вам платим - вы нам делаете». Статус управления проектом низкий. |
| Требования слабо согласованы и сильно изменчивы. Они в большей степени отражают не стратегию бизнеса, а внутреннюю конъюнктуру отношений подразделений заказчика. | Планирование и контроль сроков и затрат носит обобщенный характер. Главная проблема - удержать границы и статус управления проектом. | Предмет контракта определен в общих чертах. Вся конкретика обязательств содержится в личных договоренностях спонсоров (со стороны подрядчика он, как правило, из числа первых лиц). |
| Большой объем дополнительных разработок, который не редко искажает интеграционную схему приобретенной ERP-системы. Это в свою очередь, иногда приводит к серьезным проблемам с технической поддержкой. | Проектная группа - сплоченная команда хорошо знакомых и лояльных участников (друзей). Все работают с полной загрузкой на проекте. | Формально доминирующим типом контракта является «Фиксированная цена и сроки», но фактическая его реализация в виде дополнительных соглашений, скидок и премий делает его похожим на тип контракта, называемый в мировой практике «оплата фактических затрат + дополнительные расходы». |
| Итоговая архитектура получаемого решения похожа на «лоскутное одеяло», которое является зеркалом конъюнктуры внутренних отношений заказчика. | Доминируют неформальные персонализированные коммуникации, основанные на межличностных отношениях «своих». Слабое документирование проекта. | Подрядчик ориентирован на поддержание непрерывности отношений, которая ему обеспечивает непрерывность денежного потока. Сильная зависимость от личных отношений и слабый контроль затрат и сроков часто выводят проект подрядчика на грань рентабельности. Для заказчика внедрение ERP-системы в этом стиле, как правило, приводит к лишь отдельной локальной оптимизации со слабо выделяемыми бизнес эффектами. |
| Типичным сценарием попадания проекта в такой стиль является такой выбор заказчиком мирового производителя ERP-системы, при котором компания-интегратор является «бедным родственником». В этом случае отчетливо проявляется закон переговоров «Договариваются только равные. Неравные выстраиваются в вертикаль». | ||
|
Типовой проект | ||
|
Управление внедрением |
Управление проектом |
Управление контрактом |
|
Стратегия внедрения - «Конвейер: установка, стандартные настройки, стандартное обучение». |
Вся деятельность регламентирована процедурами. Решения принимаются разными участниками в соответствие с заранее определенными полномочиями. Развита управленческая специализация: спонсоры (заказчик - руководитель функционального подразделения или ИТ службы, подрядчик - менеджер по продажам), руководитель - технический планировщик, координатор и администратор проекта. |
Диктат заказчика выражается формулой «Если что не так, то вон очередь стоит». Проекты легко начинаются и легко останавливаются. Статус управления проектом низкий. |
|
Требования предопределены системой и принимаются заказчиком на этапе ее приобретения. |
Детальное планирование и контроль сроков и затрат. Главная проблема - удержать границы проекта и скоординировать ресурсы. |
Предмет контракта - поставка программного, аппаратного обеспечения и услуг. Контракт - это детальный план поставки. |
|
Детально проработанная технология внедрения. Все дополнительные разработки проводятся вне рамок проекта. |
Проектная группа похожа на механизм с «человеческими ресурсами», для которого характерна узкая специализация. Все участники, в том числе и руководитель проекта, могут быть одновременно задействованы в нескольких аналогичных проектах. |
Доминирующим реальным типом контракта является «Фиксированная цена и сроки». В условиях жесткой конкуренции между производителями и интеграторами типичным механизмом их выбора является тендер. |
|
Итоговая архитектура - стандартное коробочное локальное бизнес приложение. |
Основное значение имеют формально документируемые коммуникации. Документирование представляет собой заполнение шаблонов стандартных документов. |
Высокая предсказуемость проектов и жесткая конкуренция подталкивают интеграторов извлекать прибыль из потока типовых проектов. Заказчик в этом случае внедряет у себя ERP-систему для вполне конкретных локальных целей. |
|
Типичным примером такого стиля можно считать внедрение отдельного модуля ERP-системы в отдельно взятом подразделении с хорошо стандартизованными бизнес процессами. В рамках данного стиля также могут разворачиваться типовые проекты тиражирования в подразделениях крупного предприятия внедренного прототипа большой ERP-системы. | ||
|
Профессиональный проект | ||
|
Управление внедрением |
Управление проектом |
Управление контрактом |
| Стратегия внедрения - «Бизнес заказчика натягивают на систему». | Координация профессионалов с очень высокой квалификацией и опытом. Ключевая роль архитектора. Тот, кто в состоянии удерживать целостную картину бизнеса и интеграции системы, тот реально принимает решения. | Диктат подрядчика (интегратора) выражается формулой «Хотите лучшую практику, стройтесь». Статус управления проектом высокий. Это возможно только при сильном брэнде подрядчика как консультанта. |
| Требования определены моделями «лучшей практики», «зашитыми» в систему. | Детальное планирование и контроль сроков и затрат. | Предмет контракта - найм или сервис команды профессионалов. |
| Детально проработанная технология внедрения, ориентированная на внедрение моделей «лучшей практики». Все дополнительные разработки сводятся к минимуму или проводятся вне рамок проекта. | Проектная группа это команда профессионалов с широкой квалификацией, которая обладает большой экспертной властью. Это создает сильную зависимость от этой группы в ходе проекта, так и в ходе эксплуатации системы заказчиком после проекта. Профессионалам свойственен индивидуализм, что создает проблемы устойчивости проектной группы. Полная занятость всех участников на проекте. Главная проблема заказчика - успеть создать в ходе проекта свою аналогичную команду профессионалов и потом ее удержать. | Доминирующим реальным типом контракта является «Оплата времени по тарифам». Даже тогда, когда контракт формально оказывается другого типа, например, «Фиксированная цена и сроки», реальная практика его исполнения опирается на заранее оговоренные тарифы. Чем сильнее брэнд, тем выше тарифы. |
| Итоговая архитектура - сильно интегрированная корпоративная система управления бизнесом. | В группе между профессионалами непрозрачные межличностные коммуникации. По отношению к внешним участникам проекта коммуникации формализованы и хорошо документируемы. Проекты хорошо документируются. | Подрядчик извлекает прибыль из брэнда и высокой квалификации своих профессионалов. Заказчик получает в своем бизнесе реализацию моделей «лучшей практики», которая при умелом использовании может дать ему конкурентные преимущества. |
| Проекты в этом стиле являются идеалом всех крупных мировых консалтинговых компаний. Все проекты, отклоняющиеся от этого стиля, ими передаются местным партнерам. Данный стиль вполне адекватен для тех заказчиков, бизнес стратегией которых является выход на уровень мировых стандартов с последующим его практическим подтверждением. | ||
|
Инновационный проект | ||
|
Управление внедрением |
Управление проектом |
Управление контрактом |
| Стратегия внедрения - «Внедрение системы - это локомотив преобразований в бизнесе». | Совместное принятие решений в условиях жесткой неопределенности. Разделение ответственности за результаты. | Заказчик и подрядчик - равноправные партнеры. Статус управления проектом максимально высокий. Это возможно только при долгосрочном стратегическом партнерстве между ними. |
| Требования являются компромиссом между возможностями системы и потребностями бизнеса заказчика, определенными в его бизнес стратегии. | Планирование проекта в контексте бизнес стратегии. Главная проблема - удержать стратегические бизнес ориентиры. | Предмет контракта - стратегическое партнерство, альянс |
| Технология внедрения допускает итерационный процесс проб и ошибок. Большое значение имеет технология управления требованиями и тестированием, а также контроль бизнес эффектов. Большой объем дополнительных разработок. | Проектная группа это команда первопроходцев. Универсальность квалификации. Главная компетенция членов проектной группы - командная работа и способность учиться на ошибках. Командный дух с сильной приверженностью стратегическим целям бизнеса. Полная занятость в проекте. | Контракт представляет собой рамочное соглашение, в котором определяются источники формирования бизнес эффектов и принципы разделения рисков, а также принципы организации совместной работы. |
| Итоговая архитектура - инфраструктура для поддержки и преобразований бизнеса. | Большое значение имеют технологии групповой работы, способные одновременно поддерживать неформальные коммуникации и формализованное документирование действий. Единое коммуникационное и информационное пространство проекта является важнейшим активом проекта. | Извлечение прибыли каждым из участников проекта как из совместного предприятия за счет получения своих эффектов. Именно на таких проектах интеграторы вырываются в лидеры, а заказчики реализуют системные инновации. Именно эти проекты с точки зрения регулярного бизнеса являются самыми рискованными. Проект данного стиля порождает проекты в смежных областях, которые, как правило, группируются в единую бизнес программу. |
| Данный стиль вполне адекватен для тех заказчиков, бизнес стратегией которых является лидерство в определенной нише. Основой такого лидерства является уникальность бизнес модели создания добавленной стоимости. Примером такого проекта может быть случай, когда заказчик разработал стратегию лидерства в определенной нише рынка и принял решение, что ERP-система может существенно в этом помочь, инициируя системные изменения бизнеса и фиксируя новую бизнес модель. Тем более что на ERP рынке появился новый модуль, ориентированный именно на эту нишу. С другой стороны, интегратор связал свою бизнес стратегию с этим новым модулем, с которым еще по серьезному никто не работал. Они найдут друг друга как партнеры. К сожалению, примеры реализации таких проектов в российской практике крайне редки. Тем не менее, в западной практике есть не только прецеденты, но и даже школы и методологии [7,8] экстремального управления проектами и экстремального программирования, которые можно с полной уверенностью отнести к этому стилю. | ||
Условия формирования стилей
Помимо внутренней логики организации проекта стиль обладает еще и оптимальными условиями своего существования. Следуя логике Минцберга [1], наиболее важным параметром окружения проекта является неопределенность. При этом большое значение имеет неопределенность в двух аспектах: 1) процесс реализации ИТ-проекта (например, предсказуемость процесса внедрения ERP-системы) и 2) бизнес-отношения, связанные с обязательствами участников (например, контрактные отношения с внешним подрядчиком). В качестве внешней среды проекта выступает внутренняя обстановка бизнеса, как заказчика так и самого подрядчика.
Для описания характеристики внешних условий проекта можно использовать тот же квадрат неопределенности [2], что был нами использован для описания условий бизнеса (Рис.1). Но содержание характеристик неопределенности по его осям будет уже другим (Рис.2).
Горизонтальная ось характеризует неопределенность, связанную с получением результата. Эта неопределенность связана со сложностью решения, а также с предсказуемостью условий процесса внедрения систем и создания решения.
Низкая неопределенность . Надежные коробочные продукты, обладающие средствами дополнительных разработок функциональности на базе существующего продукта. Важной особенностью таких средств дополнительных разработок является наличие «защиты от дурака» или «защиты от умелых ручек». Такая защита гарантирует неизменяемость системного ядра, которое в простой системе полностью обеспечивает надежную работу всего решения.
Высокая неопределенность . Большая сильно интегрированная модульная ERP-система. В такой системе множество связей выходят за рамки системного ядра, и образует сложную сеть, удержать которую в поле зрения способна только узкая группа профессионалов. Чем больше такая система, тем быстрее растет ее сложность и неопределенность ее поведения. В зону высокой неопределенности можно попасть даже с коробочными продуктами. К этому могут подтолкнуть 1) низкая квалификация консультантов и разработчиков или 2) сильная интеграция большого количества стандартных коробочных продуктов (достаточно 5 систем).
Вертикальная ось характеризует неопределенность, связанную с отношениями между участниками проекта. Эта неопределенность может быть связана с нестабильностью состава участников, несогласованностью их ожиданий, намерений и оценок.
Низкая неопределенность . Намерения, ожидания и взаимные оценки, сформированные на предпроектной фазе, остаются стабильными в течение всего проекта.
Высокая неопределенность. Несогласованность и изменчивость намерений, ожиданий и взаимных оценок может быть связана со многими факторами. Среди таких факторов можно выделить: 1) нестабильность состава проектной группы, в том числе и ключевых ее членов (спонсора, руководителя или архитектора), 2) большой масштаб организационных преобразований, 3) изменения бизнес приоритетов участников или 4) банальный дефицит бюджета.
У каждого стиля своя «среда обитания». Каждый стиль имеет свою внутреннюю логику организации, которая порождает свои «врожденные» проблемы (Рис.3.) и имеет свой «врожденный» профиль издержек [2]. Проект подобен организму - если организм жив и действует, то у него всегда что-то болит. Абсолютно без проблем обходится только мертвый или идеальный проекты.
Помимо описанных выше «врожденных» проблем каждого стиля можно отметить, что области профессиональных и инновационных проектов всегда связаны с техническими рисками, а политических и тех же инновационных - с коммерческими. Из Рис.3. видно, что инновационные проекты самые рискованные, для обеих сторон, но именно там могут быть достигнуты наибольшие бизнес-эффекты. Наименее рискованными являются типовые проекты, но именно там оказывается самая жесткая конкуренция среди производителей и интеграторов.
Динамика стилей
Попав в неадекватные для себя условия, в идущем в определенном стиле проекте, помимо «врожденных» начнут появляться и дополнительные проблемы и нарастать издержки. Например, когда в ходе инновационного проекта какой-то из сторон в одностороннем порядке меняются бизнес-приоритеты, возрастает неопределенность статуса управления проектом, то есть разрыв между формальным и фактическим статусами, и начинают расти издержки согласования. В конечном счете, если стороны не согласуют свои бизнес приоритеты или не изменится стиль проекта, проект может быстро остановиться.
Неблагоприятные условия проекта могут создавать и сами участники. Вот пример трех наиболее распространенных сценариев.
- Компания-заказчик хочет проведения глубоких системных изменений бизнеса. При этом подрядчик (интегратор) выбирается в ходе жесткого ценового тендера. Этим самым заказчик формирует идеальные условия для политического проекта. Стратегических партнеров на тендере не выбирают.
- При внедрении коробочной системы в рамках типового проекта в системе «всплыли» недоработки производителя. Обе стороны продолжают проект: подрядчик спешно «как может» исправляет ошибки производителя, а заказчик старается «сохранить лицо». Созданы идеальные условия для превращения типового проекта в инновационный . По крайней мере, интегратор «накувыркавшись» с системой наберется опыта и может стать технологическим лидером среди партнеров этого производителя.
- Проект был начат как внедрение лучшей мировой практики. Но в ходе проекта выяснилось, что у предложенного подрядчика нет консультантов, владеющих этой самой, лучшей практикой. Созданы идеальные условия для превращения профессионального проекта в политический .
В отличие от конфигураций бизнеса стиль проекта более пластичен, он может меняться по ходу проекта. В зависимости от изменений условий руководители проекта и проектная группа могут менять даже механизм координации. Но это «высший пилотаж» управления, который основан на том, что одна из сторон, как правило, подрядчик (интегратор) владеет стилевым разнообразием, которое дает ему большую коммерческую и технологическую гибкость. Стилевым разнообразием управления проектами владеют только лидеры, и это встречается крайне редко.
Выводы
Г.Минцберг обнаружил, что свойства конфигураций бизнеса определяются логикой, задающейся действием механизмов координации и в меньшей степени зависят от отраслевой принадлежности или функциональной специализации бизнеса. Одни и те же конфигурации бизнеса обнаружились во всех отраслях, а крупные бизнес организации предстали как система различных конфигураций. Г.Минцберг также показал, что разнообразие конфигураций не исчерпывается 5 устойчивыми формами. Эти результаты дают право сделать два предположения.
- Разнообразие стилей проектов гораздо больше, чем рассмотрено в данной статье.
- Стили проекта характерны не только для области ИТ, а носят более универсальный характер.
Выделение стиля проекта и контроль его динамики имеет важное практическое значение как для оперативного управления отдельными проектами, так и стратегического управления всей проектной деятельностью.
Понимание сложившегося стиля дает возможность руководителю проекта увидеть связи между проблемами, которые он ранее считал независимыми, и позволяет находить их комплексные решения. Каждый стиль имеет свою внутреннюю логику и предлагает свою систему ранжирования значимости проблем, рисков и требований. Понимание логики стиля проекта позволяет выявить нарождающиеся проблемы по их слабым предвестникам. Использование стиля в проектной практике может дать более тонкие инструменты управления, способные значительно повысить эффективность управления.
Хорошо опробованные существующие проектные методологии и технологии могут оказаться эффективными в одних стилях и не эффективными в других. Использование стиля дает возможность оценки такой эффективности этих методологии и технологии.
Использование стиля позволяет готовить сбалансированные условия проекта уже в ходе переговоров на предконтрактной фазе.
Практически используя понятие стиля, компания-интегратор может провести более тонкую настройку маркетинга и продаж в своем проектном бизнесе.
Литература
1. Г. Минцберг , «Структура в кулаке. Создание эффективной организации», Питер, СПб, 2001.
2. В.И. Ананьин , «Устойчивость управления ИТ проектами в условиях неопределенности», журнал «Управление проектами», 2005, №1,2, Издательский Дом Гребенникова, Москва
3. «A guide to the Project Management Body of Knowledge», 2000 Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
4. IPMA Competence Baseline (ICB), Version 2.0b, Bremen, 1999/2001, International Project Management Association
5. «Federal Acquisition Regulation», General Services Administration Department of Defense National Aeronautics and Space Administration, 2001
6. В.И. Ананьин , «Формирование архитектуры корпоративной информационной системы путем естественного отбора», Intelligent Enterprise № 17 (149) 26 сентября 2006
7. Р. Томсетт , «Радикальное управление ИТ проектами», Лори, Москва, 2005
8. Дуг ДеКарло , «Экстремальное управление проектами», ред. А. Баженов, А. Арефьев, p.m.Office, Москва, 2005
Ананьин Владимир Игоревич, Свободный консультант