Введение
К читателю
Автор статьи не обладает специализированными знаниями в классическом кризисном менеджменте, единственное что он уже отличает кризисное управление (управление в кризис) от антикризисного управления, что обычно путают. Автор статьи практически всегда был вовлечен в проекты такого рода на «плохой» стадии как управленец. Часть процесса пикирования в кризис им наблюдалась без права решающего голоса. С точки зрения автора статьи чистые методы решения проблем в проектах не могут быть успешно применены в данном типе проектов, что позволяет считать любой кризисный проект проектом с высокой сложностью. Сложность кризисного проекта по мнению автора статьи определяется не стоимостью, не требованиями к качеству, не сроками. Как следствие содержание кризисного проекта зависит от решений спонсора как реагировать на проблему в проекте, которая заставила считать данный проект «особым». Автор статьи не претендует на универсальность примененных проектных решений и универсальность разработанных методов.
Данная статья подготовлена на примере антикризисного управления в проекте разработки и внедрения К(орпоративной) И(нформационной) С(истемы) для IT-дочки крупнейшего холдинга.
Применяемая философия внедрения кризисного управления в проектном опыте автора
Кризис в проектном управлении – это некоторый нонсенс. Поиск нестандартных решений даже в стандартных проектных ситуациях определяет разницу в проектном подходе от подходов операционного менеджмента. Отклонение исполнения проекта от планов, в том числе и базового плана проекта не может являться причиной кризиса. Метрики исполнения проектов такие как индексы выполнения проекта по срокам или стоимости позволяют строго контролировать ход проекта, и принимать на управляющем комитете взвешенные решения о дальнейшей судьбе проекта. Существование органа с полномочиями закрыть проект без удовлетворения целей проекта является нормой в проектном управлении. Конфликтов в целях программы проектов и проекта, как и конфликтов по бюджету между портфелем проектов и проектом не должно быть в управлении проектами. Но к сожалению, согласованность данных параметров не определяется напрямую, и с точки зрения автора статьи также не может быть определена с помощью компетентностей руководителя проекта на данном этапе зрелости проектного управления в целом. Автор статьи в целях лучшего понимания прикладных выводов, изложенных далее в статье предлагает следующие определения:
Пикирование в кризис – потеря информации о текущем ходе проекта в принятых интегральных характеристиках исполнения проекта.
Кризис в проекте – ситуация закрытия проекта, инициированного любым уполномоченным органом неофициально. Отсутствие официального решения по проекту с одновременной эскалацией означает, что фактического управления проектом не осуществлялось и не осуществляется.
Обоснование сложности проекта
Организация-заказчик
Организацией-заказчиком проекта, рассматриваемого в статье, являлось дочернее предприятие крупнейшей корпорации в энергетике - многофункциональный центр обслуживания.
МФЦ создан в 200* году в рамках Программы трансформации информационных технологий (ПТ ИТ).
Целью создания МФЦ являлось выделение второстепенных функций отрасли, не связанных с созданием стоимости продукции, с одновременным повышением качества данных функций за счёт использования единых корпоративных систем и методологий.
Такими функциями являлись бухгалтерский и налоговый учет, управление персоналом и ИТ-поддержка.
Задачами общего центра обслуживания ставились:
обеспечить контролируемость и управляемость непрофильных функций корпорации;
повысить производительность и качество исполнения непрофильных функций корпорации;
сократить затраты на исполнение непрофильных функций.
Ситуация
Заинтересованные стороны
Многофункциональный общий центр обслуживания позиционировался как амбициозный и уникальный для России проект. Причиной данного позиционирования являлся сложный корпоративный ландшафт, в котором реализовалось выделение второстепенных функций отрасли:
предприятия отрасли ведут бизнес в более чем 15 направлениях;
у каждого предприятия отрасли своя специфика;
каждое предприятие отрасли имеет свои системы отчетности и учета;
бизнес предприятия отрасли накладывают свои требования к информационной безопасности.
Рассматриваемая проблема
Главным приоритетом в своей работе МФЦ ставил качество предоставляемых услуг. Клиентоориентированность. Некоторые количественные показатели на тот момент:
Более 2,5 тыс. сотрудников;
Более 200 предприятий на обслуживании;
Более 20 городов присутствия по всей стране;
Более 70 тыс. пользователей корпоративных систем на обслуживании;
Количество предприятий на обслуживании:
По бухгалтерскому и налоговому учету – 89,
По управлению персоналом – 30,
По услугам ИТ – 139.
Улучшение качества обслуживания при оптимизации затрат являлось ключевой задачей в работе организации-заказчика (МФЦ).
Предпосылки возникновения проекта
Проведем анализ исполнимости задачи способом S.M.A.R.T.
S (Specific - конкретный) – лучшие мировые практики оказания услуги являются достаточным основанием для улучшения бизнес-процесса;
M (Measurable - измеримый) – целевые значения показателей качества определены для каждой услуги в разрезе как сроков выполнения запросов и уровня доступности ИТ-сервисов, так и процента отклонений;
A (Achievable - достижимый) – узкая специализация сотрудников при конкретных операциях допускает возможность получения выгоды от унификации процессов;
R (Relevant - актуальный) – автоматизация на основе современных ИТ-технологий уместна для унифицированных процессов;
T (Time-bound - ограниченный во времени) – создание МФЦ выделяется корпорацией как самостоятельный и уникальный для отрасли проект, имеющий обязательное ограничение по времени.
Итак, уникальный для отрасли проект корпорации порождал программу проектов по улучшению качества выделенных функций. Рассматриваемый в статье проект являлся элементом данной программы.
А проект мы рассмотри в разрезе изученных уроков (lessons learned)
Извлечённые уроки
Ситуации кризисного управления
Урок «Признать кризис – это не просто»
Урок «Облегченный сбор требований»
Урок «Адаптация под реалии»
Урок «Вызов ответственности»
Урок «Истерика»
Урок «Альтернативная стоимость»
Урок «Переговоры»
Урок «Brainstorming»
Урок «Неопределенность»
Урок «Потеря фокуса»
Урок «Страх»
Урок «Все не могут быть правы»
Урок «Критический путь»
Урок «Официальная переписка»
Урок «Дружба»
Урок «Доверие»
Ситуации управления проектом изменений
Урок «Принцип аналогий»
Урок «Растущая стоимость»
Урок «Живой регламент»
Ситуации управления проектом в IT-сфере
Урок «Agile-этап»
Урок «Приемочные испытания»
Урок «Гарантийная поддержка»
"Поехали" (c) Юрий Гагарин
Сбор информации
Урок 1. Признать кризис – это не просто
Обычно ситуация обнаружения кризиса в проекте означает одновременное прозрение всех заинтересованных лиц проекта, что проект необходимо закрыть. Это ведет к формальному запуску процедуры завершения проекта и фиксации убытков всех заинтересованных сторон.
Именно одномоментность признания всеми заинтересованными лицами проекта невозможности успешного завершения проекта в заданных ограничениях и является основным реактивным фактором в определении проектов, рассматриваемых автором.
Почему не предупредили подобную ситуацию? Данный вопрос является ключевым. «Вчера» проект был, а «сегодня» не существует мер по его продолжению!
На вопрос необходимо дать ответ. Доверие к отчётности по проекту, доверие к управляющим органам проекта исчезло. См. форк
Урок 2. Облегченный сбор требований
Т.к. в проекте неожиданно исчезает потенция в получении результата, то оснований для продолжения проекта нет. И здесь возникает первый парадокс иерархии проектного управления: хотя проект был согласован и по бюджету в портфеле проектов, и по целям в программах сторон.
Проект вдруг приобретает дополнительный политический вес.
С точки зрения автора и по его опыту – ситуация стандартна в проектном управлении. Данная ситуация возникает всегда в конкурентной среде при отсутствии механизма согласования портфелей и программ проектов между исполнителем и заказчиком.
Возможными источниками неформального согласования подобного рода автор статьи считает правильным пренебречь.
В этот момент необходимо провести анализ внезапно появившегося дополнительного веса проекта. Вопросы, на которые необходимо дать быстрый качественный ответ очевидны:
Насколько велики потери в репутации?
Можно ли окупить дополнительные инвестиции в проект на данной стадии?
Как повлияет исключение проекта из программы?
Перефразируя, получаем «Проект умер. Да здравствует проект!»
Возникает необходимость в сборе требований, требований к проектному решению в режиме организационного коллапса в проекте. По сути требуется повторение обследования в режиме уже случившей неудачи проекта. См. форк.
Урок 3. Адаптация под реалии
Автор статьи не знает иных механизмов «моментального» согласования портфелей и программ проектов кроме концептуального реинжиниринга решения. Здесь и далее под концептуальным реинжинирингом решения автор понимает аналитическую работу над парадигмой признания результатов проекта успешными. Именно разработка понимания приемки результатов проекта, и только оно (понимание) накладывает ограничения на новый проект. Таким образом с точки зрения автора у проектов данного рода смещается акцент с разрабатываемого решения на механизмы его валидации и верификации. Здесь и далее под валидацией решения автор статьи понимает возможность применения решения заказчиком, а под верификацией решения понимается строгое соответствие создания решения требованиям. Только поименованный и описанный в парадигме приемки алгоритм признания успешности проекта может помочь в подобный момент. Это можно поименовать вторым парадоксом проектного управления: нельзя разработать алгоритм признания успешности проекта, если в проекте не случился кризис.
Именно кризис в проекте интенсифицирует процессы сбора требований. Происходящая адаптация всех заинтересованных сторон проекта под текущие реалии форсируется именно потерей эскалационных механизмов в проекте. Эскалационные механизмы исчезли в момент неформального закрытия проекта. Любое изменение в проекте на этой стадии обязано быть согласовано и принято. С этого момента управление изменениями становится строго формализованным на базе парадигмы приёмки.
Пирамида власти
Урок 4. Вызов ответственности
Отсутствие процессов мониторинга и контроля пирамиды ограничений проекта «содержание, качество, сроки, бюджет», разработанной на момент старта проекта органично привело к конфликту. При этом неформальное желание закрыть проект может быть оформлено по-разному, но суть конфликта всегда одна: уточнить ответственных за сложившийся неуспех проекта. Интересно, что заинтересованную сторону, инициировавшую конфликт, завершение проекта уже не интересует. Проработав и изучив варианты для своих портфеля и программ проекта эта заинтересованная сторона оказалась первой, кто признал фатальность успеха именно данного проекта для своей организации в целом. Ее цель в данном конфликте сделать фатальным успех проекта для всех заинтересованных сторон.
Урок 5. Истерика
Важным составляющим конфликта в описанной ситуации является признание всеми заинтересованными сторонами, что это пик возможных эскалаций в проекте. Проект стал системообразующим для заинтересованных сторон. Бюджет, сроки, качество и содержание проекта приносятся в жертву возможности спасти репутацию.
Истеричность решений на данном этапе достигает максимума. Выдавать желаемое за действительное на данной стадии проекта становится парадигмой проекта.
Урок 6. Альтернативная стоимость
По мнению автора, самым важным аспектом при принятии решения о выходе из проекта должна быть альтернативная стоимость. Провести тщательный анализ альтернатив в подобных ситуациях возможно, но лица принимающие решения в организациях участниках проекта находятся в цейтноте. Конфликт не прогнозировался. Конфликт воспринимается как форс-мажор. Стоимостной анализ решений с точки зрения принимающих решения лиц в текущей проектной ситуации невозможен. К альтернативной стоимости заинтересованные лица вернутся позже.
Измена целям
Урок 7. Переговоры
Заинтересованные стороны входят в затяжной цикл переговоров. Цель данных переговоров оценить политический вес проекта. Прямое вычисление данного веса осложненно возможным поведением всех сторон переговоров. С повестки дня в ходе переговоров уходит персональная ответственность членов команды проекта. Стороны приходят к соглашению что проект должен быть продолжен. И здесь можно отметить третий парадокс проектного управления: максимально возможная политическая ангажированность при принятии решения о невозможности закрытии проекта приводит к максимально возможному уменьшению политики в дальнейшем ходе проекта.
Урок 8. Brainstorming
Одного организационного решения продолжать проект мало. Стороны начинают делиться своим проектным багажом. Отличительной особенностью данного мозгового штурма является то, что стороны с удивлением обнаруживают те требования на разрабатываемое проектное решение, которые только подчёркивают бедственную ситуацию в проекте.
Потеря знаний
Урок 9. Неопределенность
В этот момент приходит понимание, что проект закрыт. И открыт новый проект. Проектная неопределенность, как и эскалация достигает своего пика. Проектных материалов может быть накоплено очень много, но к их анализу команда проекта вернется только после успешного завершения нового проекта.
Урок 10. Потеря фокуса
Первым, очевидным и единственным выводом после признания ужасающей проектной неопределенности является факт, что потерян фокус в проекте. Здесь и далее под фокусом проекта автор понимает не только цели проекта, но и бизнес-выгоду владельца продукта. Формирование нового фокуса проекта становится основной целью команды.
Урок 11. Страх
Прошёл эпатаж эскалаций. Ушло дополнительное время на переговоры. Стороны всего лишь договорились о намерениях нового проекта. План отсутствует. Зафиксировано неудачное завершение проекта.
Поиск верного подхода
Урок 12. Все не могут быть правы
С точки зрения автора в этот момент должно прийти признание, что только компромисс может являться методом решения проблемы. Стороны определяют кто чем жертвует при инициации нового проекта. Формируется новые параметры проекта в части сроков, стоимости, качества и содержания. Алгоритм формирования параметров ложится парадигму приемки.
Урок 13. Критический путь
Важным аспектом принимаемой парадигмы приемки результатов проекта является отношение к критическому пути проекта. Для проектов данного рода по мнению автора не план является основой для вычисления критического пути, а критический путь является основой для планов и целей проекта. Существование подобного критического пути сразу не очевидно. Но именно его разработкой и занята команда проекта в переходный период.
Кооперация против конфронтации
Урок 14. Официальная переписка
Отдельным пунктом автор статьи хочет отметить официальную переписку. Несмотря на исчезновение в проекте политических течений эскалация в проекте ещё долго оставляет свой след в официальной переписке по проекту. Автор хочет отметить, что по его экспертному мнению официальная переписка в таких ситуациях не бесполезна. Единственное, что заинтересованные стороны не должны на нее тратить избыточные проектные ресурсы.
Урок 15. Дружба
Разработка парадигмы приёмки начинается, как только очерчены критерии компромисса. Здесь и только здесь конфликт заканчивается. Появляется надежда на возможную успешность нового проекта.
Урок 16. Доверие
Не все договоренности, очерченные в поисках компромисса можно изложить в плане управления проектом. Основная их часть останется в неформальной переписке. Доверие, вернувшееся в проект может быть опять потеряно. Но по мнению автора статьи управлять подобным риском в проектах данного рода избыточно.
Управление проектом бизнес-изменений
От AS IS к TO BE
Урок 17. Принцип аналогий
Управление проектами бизнес-изменений по мнению автора всегда основывается на накопленной исполнителем экспертизе успешных проектов подобного рода. С этой стороны стартующий проект изменения бизнес-процессов организации-заказчика выглядит «легкой прогулкой». Возможные паттерны плохих процессов, паттерны целевых хороших процессов и готовые паттерны изменений в активе организации-исполнителя заставляют относится к подобному роду проектов как проекту внедрения тиражного решения. Основная беда данного подхода неожиданно появляющееся сопротивление ключевых пользователей разработанной конструкции в целом. Проект по изменениям бизнес-процесса начинает тонуть в проектных изменениях. Этот момент знаменует коллапс тиражного подхода. Время на согласование целевой картины устремляется в бесконечность.
Урок 18. Растущая стоимость
Оценка стоимости проекта изменений с учетом небольшого количества итераций на согласование оказывается некорректной. И качественно проведенное обследование, и проверенные практикой готовые предложения по целевой картине основного бизнес-процесса наталкиваются на невозможность выработать общий консенсус по топологии организационных изменений. В этих случаях каждое рабочее совещание оформляется в лучшем случае протоколом разногласий, а нередко и решение о повторе обследования в части процессов.
Урок 19. Живой регламент
Качественно иной подход демонстрируется при наличии ИТ-системы поддержки целевых бизнес-процессов. Каждое предложение по модификации бизнес-процессов становится качественно измеримым в параметрах работы конечных пользователей системы. Целевой бизнес-процесс становится понятным пользователю не на основе нотации блок-схемы, а на основе демонстрируемых примеров работы на системе.
Оставшиеся уроки, извлечённые автором статьи, уже извлечены всем IT-сообществом России, а уж точно хабровчанами, поэтому описывать в данной статье автор посчитал излишним.
Удачи, Хабр, в живых проектах и не доводите их до кризисного сценария!
(с) текст статьи адаптирован мной из собственных записок по изученным урокам проекта начала 2010-х годов в 2018 году. Сейчас же я решил, что статья достойна чтения широкой аудиторией для критики.
