Информация

Последние записи

Теги


Блоги


Записи из всех блогов с тегом: it-система


Моменты в управлении антикризиcными IT-проектами

Прошу прощения у подписчиков, нарыл тут у себя в архиве интересный документ.
Работа над заметками:
  • Авторская теория замены рядового менеджера от Сергея Трушкина (или почему ИИ не быстро идет в гору)
  • Педал-лохус-клан [PL] в QuakeWorld (почему в 90-е уходили из киберспорта)

    продолжается, просто не хочу их дополнять по чуть-чуть.

    Делюсь документом в режиме записи в блоге.

    К читателю
    Автор блога не обладает специализированными знаниями в классическом антикризисном менеджменте. Автор блога практически всегда был вовлечен в проекты такого рода на «плохой» стадии как управленец. Часть процесса пикирования в кризис им наблюдалась интерактивно без права решающего голоса. С точки зрения автора блога чистые методы решения проблем в проектах не могут быть успешно применены в данном типе проектов, что позволяет считать любой антикризисный проект сложным. Сложность антикризисного проекта по мнению автора блога определяется не стоимостью, не требованиями к качеству, не сроками. Как следствие содержание антикризисного проекта зависит от решений спонсора как реагировать на проблему в проекте, которая заставила считать данный проект «особым». Автор блога не претендует на универсальность примененных проектных решений и универсальность разработанных методов.
    Данная заметка подготовлена на примере антикризисного управления в проекте разработки и внедрения одной из IT-систем.

    Применяемая философия внедрения антикризисного управления в проектном опыте автора блога
    Кризис в проектном управлении – это некоторый нонсенс. Поиск нестандартных решений даже в стандартных проектных ситуациях определяет разницу в проектном подходе от подходов операционного менеджмента. Отклонение исполнения проекта от планов, в том числе и базового плана проекта не может являться причиной кризиса. Метрики исполнения проектов такие как индексы выполнения проекта по срокам или стоимости позволяют строго контролировать ход проекта, и принимать на управляющем комитете взвешенные решения о дальнейшей судьбе проекта. Существование органа с полномочиями закрыть проект без удовлетворения целей проекта является нормой, причём катастрофически не хватаемой в IT-отрасли, в проектном управлении.
    Конфликтов в целях программы проектов и проекта, как и конфликтов по бюджету между портфелем проектов и проектом не должно быть в управлении проектами. Но к сожалению, согласованность данных параметров не определяется напрямую, и с точки зрения автора блога также не может быть определена с помощью компетентностей руководителя проекта на данном этапе зрелости проектного управления в целом.
    Автор блога в целях лучшего понимания прикладных выводов, изложенных далее в записи предлагает следующие определения:
    Пикирование в кризис – потеря информации о текущем ходе проекта в принятых интегральных характеристиках исполнения проекта.
    Кризис в проекте – ситуация закрытия проекта, инициированного любым уполномоченным органом неофициально. Отсутствие официального решения по проекту с одновременной эскалацией означает, что фактического управления проектом не осуществлялось и не осуществляется.
    Обоснование сложности IT-проекта-основания.
    Организация-заказчик
    Наименование организации-заказчика
    Организацией-заказчиком проекта, рассматриваемого в записи, являлось дочернее предприятие крупной Госкорпорации.
    Профиль организации-заказчика
    Создано в 90-00-х годах с целью выделения IT-технологического стека в отдельный контур управления.
    Ситуация
    Заинтересованные стороны
  • Госкопорация
  • Заказчик
  • Исполнитель
    Время осуществления проекта: 10-е гды
    Место осуществления проекта: Российская Федерация
    Ситуации антикризисного управления
  • Урок «Признать кризис – это не просто»
  • Урок «Облегченный сбор требований»
  • Урок «Адаптация под реалии»
  • Урок «Вызов ответственности»
  • Урок «Истерика»
  • Урок «Альтернативная стоимость»
  • Урок «Переговоры»
  • Урок «Brainstorming»
  • Урок «Неопределенность»
  • Урок «Потеря фокуса»
  • Урок «Страх»
  • Урок «Все не могут быть правы»
  • Урок «Критический путь»
  • Урок «Официальная переписка»
  • Урок «Дружба»
  • Урок «Доверие»
  • Урок «Принцип аналогий»
  • Урок «Растущая стоимость»
  • Урок «Живой регламент»
  • Урок «Agile-этап»
  • Урок «Приемочные испытания»
  • Урок «Гарантийная поддержка»


    Урок 1. Признать кризис – это не просто
    Обычно ситуация обнаружения кризиса в проекте означает одновременное прозрение всех заинтересованных лиц проекта, что проект необходимо закрыть. Это ведет к формальному запуску процедуры завершения проекта и фиксации убытков всех заинтересованных сторон.
    Именно одномоментность признания всеми заинтересованными лицами проекта невозможности успешного завершения проекта в заданных ограничениях и является основным реактивным фактором в определении проектов, рассматриваемых автором блога.
    Почему не предупредили подобную ситуацию? Данный вопрос является ключевым. «Вчера» проект был, а «сегодня» не существует мер по его продолжению!
    На вопрос необходимо дать ответ. Доверие к отчётности по проекту, доверие к управляющим органам проекта исчезло.
    Урок 2. Облегченный сбор требований
    Т.к. в проекте неожиданно исчезает потенция в получении результата, то оснований для продолжения проекта нет. И здесь возникает первый парадокс иерархии проектного управления: хотя проект был согласован и по бюджету в портфеле проектов, и по целям в программах сторон.
    Проект вдруг приобретает дополнительный политический вес.
    С точки зрения автора блога и по его опыту – ситуация стандартна в проектном управлении. Данная ситуация возникает всегда в конкурентной среде при отсутствии механизма согласования портфелей и программ проектов между исполнителем и заказчиком.
    Возможными источниками неформального согласования подобного рода автор блога считает правильным пренебречь.
    В этот момент необходимо провести анализ внезапно появившегося дополнительного веса проекта. Вопросы, на которые необходимо дать быстрый качественный ответ очевидны:
  • Насколько велики потери в репутации?
  • Можно ли окупить дополнительные инвестиции в проект на данной стадии?
  • Как повлияет исключение проекта из программы?
    Перефразируя, получаем «Проект умер. Да здравствует проект!»
    Возникает необходимость в сборе требований, требований к проектному решению в режиме организационного коллапса в проекте. По сути требуется повторение обследования в режиме уже случившей неудачи проекта.
    Урок 3. Адаптация под реалии
    Автор блога не знает иных механизмов «моментального» согласования портфелей и программ проектов кроме концептуального реинжиниринга решения. Здесь и далее под концептуальным реинжинирингом решения автор понимает аналитическую работу над парадигмой признания результатов проекта успешными. Именно разработка понимания приемки результатов проекта, и только оно (понимание) накладывает ограничения на новый проект. Таким образом с точки зрения автора блога у проектов данного рода смещается акцент с разрабатываемого решения на механизмы его валидации и верификации. Здесь и далее под валидацией решения автор блога понимает функциональность разрабатываемого IT-решения, а под верификацией решения понимается строгое соответствие создания решения требованиям по структуре продукта. Только поименованный и описанный в парадигме приемки алгоритм признания успешности проекта может помочь в подобный момент. Это можно поименовать вторым парадоксом проектного управления: нельзя разработать алгоритм признания успешности проекта, если в проекте не случился кризис.
    Именно кризис в проекте интенсифицирует процессы сбора требований. Происходящая адаптация всех заинтересованных сторон проекта под текущие реалии форсируется именно потерей эскалационных механизмов в проекте. Эскалационные механизмы исчезли в момент неформального закрытия проекта. Любое изменение в проекте на этой стадии обязано быть согласовано и принято. С этого момента управление изменениями становится строго формализованным на базе парадигмы приёмки.
    Урок 4. Вызов ответственности
    Отсутствие процессов мониторинга и контроля пирамиды ограничений проекта «содержание, качество, сроки, бюджет», разработанной на момент старта проекта органично привело к конфликту. При этом неформальное желание закрыть проект может быть оформлено по-разному, но суть конфликта всегда одна: уточнить ответственных за сложившийся неуспех проекта. Интересно, что заинтересованную сторону, инициировавшую конфликт, завершение проекта уже не интересует. Проработав и изучив варианты для своих портфеля и программ проекта эта заинтересованная сторона оказалась первой, кто признал фатальность успеха именно данного проекта для своей организации в целом. Ее цель в данном конфликте сделать фатальным успех проекта для всех заинтересованных сторон.
    Урок 5. Истерика
    Важным составляющим конфликта в описанной ситуации является признание всеми заинтересованными сторонами, что это пик возможных эскалаций в проекте. Проект стал системообразующим для заинтересованных сторон. Бюджет, сроки, качество и содержание проекта приносятся в жертву возможности спасти репутацию.
    Истеричность решений на данном этапе достигает максимума. Выдавать желаемое за действительное на данной стадии проекта становится парадигмой проекта.
    Урок 6. Альтернативная стоимость
    По мнению автора блога, самым важным аспектом при принятии решения о выходе из проекта должна быть альтернативная стоимость. Провести тщательный анализ альтернатив в подобных ситуациях возможно, но лица принимающие решения в организациях участниках проекта находятся в цейтноте. Конфликт не прогнозировался. Конфликт воспринимается как форс-мажор. Стоимостной анализ решений с точки зрения принимающих решения лиц в текущей проектной ситуации невозможен. К альтернативной стоимости заинтересованные лица вернутся позже.
    Урок 7. Переговоры
    Заинтересованные стороны входят в затяжной цикл переговоров. Цель данных переговоров оценить политический вес проекта. Прямое вычисление данного веса осложненно возможным поведением всех сторон переговоров. С повестки дня в ходе переговоров уходит персональная ответственность членов команды проекта. Стороны приходят к соглашению, что проект должен быть продолжен. И здесь можно отметить третий парадокс проектного управления: максимально возможная политическая ангажированность при принятии решения о невозможности закрытии проекта приводит к максимально возможному уменьшению политики в дальнейшем ходе проекта.
    Урок 8. Мозговой штурм
    Одного организационного решения продолжать проект мало. Стороны начинают делиться своим проектным багажом. Отличительной особенностью данного мозгового штурма является то, что стороны с удивлением обнаруживают те требования на разрабатываемое проектное решение, которые только подчёркивают бедственную ситуацию в проекте.
    Урок 9. Неопределенность
    В этот момент приходит понимание, что проект закрыт. И открыт новый проект. Проектная неопределенность, как и эскалация достигает своего пика. Проектных материалов может быть накоплено очень много, но к их анализу команда проекта вернется только после успешного завершения нового проекта.
    Урок 10. Потеря фокуса
    Первым, очевидным и единственным выводом после признания ужасающей проектной неопределенности является факт, что потерян фокус в проекте. Здесь и далее под фокусом проекта автор блога понимает не только цели проекта, но и бизнес-выгоду владельца продукта (решение проблемы Заказчика). Формирование нового фокуса проекта становится основной целью команды.
    Урок 11. Страх
    Прошёл эпатаж эскалаций. Ушло дополнительное время на переговоры. Стороны всего лишь договорились о намерениях нового проекта. План отсутствует. Зафиксировано неудачное завершение проекта.
    Урок 12. Все не могут быть правы
    С точки зрения автора блога в этот момент должно прийти признание, что только компромисс может являться методом решения проблемы. Стороны определяют кто чем жертвует при инициации нового проекта. Формируется новые параметры проекта в части сроков, стоимости, качества и содержания. Алгоритм формирования параметров ложится парадигму приемки.
    Урок 13. Критический путь
    Важным аспектом принимаемой парадигмы приемки результатов проекта является отношение к критическому пути (цепь задач максимальной длительности)проекта. Для проектов данного рода по мнению автора блога не план является основой для вычисления критического пути, а критический путь является основой для планов и целей проекта. Существование подобного критического пути сразу не очевидно. Но именно его разработкой и занята команда проекта в переходный период.
    Урок 14. Официальная переписка
    Отдельным пунктом автор блога хочет отметить официальную переписку. Несмотря на исчезновение в проекте политических течений эскалация в проекте ещё долго оставляет свой след в официальной переписке по проекту. Автор блога хочет отметить, что по его экспертному мнению официальная переписка в таких ситуациях не бесполезна. Единственное, что заинтересованные стороны не должны на нее тратить избыточные проектные ресурсы.
    Урок 15. Дружба
    Разработка парадигмы приёмки начинается, как только очерчены критерии компромисса. Здесь и только здесь конфликт заканчивается. Появляется надежда на возможную успешность нового проекта.
    Урок 16. Доверие
    Не все договоренности, очерченные в поисках компромисса можно изложить в плане управления проектом. Основная их часть останется в неформальной переписке. Доверие, вернувшееся в проект может быть опять потеряно. Но по мнению автора блога управлять подобным риском в проектах данного рода избыточно.
    Урок 17. Принцип аналогий
    Управление проектами бизнес-изменений по мнению автора блога всегда основывается на накопленной Исполнителем экспертизе успешных проектов подобного рода. С этой стороны стартующий проект изменения бизнес-процессов организации-заказчика для внедрения IT-решения выглядит «легкой прогулкой». Возможные паттерны плохих процессов, паттерны целевых хороших процессов и готовые паттерны изменений в активе организации-исполнителя заставляют относится к подобному роду проектов как проекту внедрения тиражного решения. Основная беда данного подхода неожиданно появляющееся сопротивление ключевых пользователей разработанного продукта в целом. Проект по изменению бизнес-процесса начинает тонуть в изменениях проекта создания IT-продукта. Этот момент знаменует коллапс тиражного подхода. Время на согласование целевой картины устремляется в бесконечность.
    Урок 18. Растущая стоимость
    Оценка стоимости проекта изменений с учетом небольшого количества итераций на согласование оказывается некорректной. И качественно проведенное обследование, и проверенные практикой готовые предложения по целевой картине основного бизнес-процесса наталкиваются на невозможность выработать общий консенсус по топологии организационных изменений. В этих случаях каждое рабочее совещание оформляется в лучшем случае протоколом разногласий, а нередко и решение о повторе обследования в части процессов.
    Урок 19. Живой регламент
    Качественно иной подход демонстрируется при наличии ИТ-системы поддержки целевых бизнес-процессов. Каждое предложение по модификации бизнес-процессов становится качественно измеримым в параметрах работы конечных пользователей системы. Целевой бизнес-процесс становится понятным пользователю не на основе нотации блок-схемы, а на основе демонстрируемых примеров работы на системе.
    Урок 20. Agile-этап
    И здесь появляется вся мощность гибких методологий. Быстро создать работающий (!) продукт в части бизнес процессов для демонстрации и тестирвоания конечными пользователями концепта конечного продукта иным образом не решит проблему не вылететь за жесткий дедлайн.
    Урок 21. Приемочные испытания
    Поэтому и получается, что приемочные испытания пройдут в одно касание, Журнал Опытной Эксплуатации будет невелик и в конечном счёт решенная задача позволит окончить проект создания IT-продукта успешно, важным останется формализовать регламенты гарантии и сопровождения.
    Урок 22. Гарантийная поддержка
    И всё же всё не удастся выполнить даже за срок гарантийной поддержки, и конечный продукт не будет иметь две-три фишечки, который хотелось иметь на момент коммерческого предложения, контракта и Agile-этапа


    РЕЗЮМЕ

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

  • Инициация антикризисного проекта
  • Пирамида власти против пирамиды мотивации
  • Измена целям Заказчика в пользу решения его проблемы, инициировавшей изначальный проект
  • Кооперация против конфронтации
  • От AS IS к TO BE или управление подпроектом бизнес-изменений для внедрения версии IT-продукта
  • Гибкие методы и необходимость в WYSIWYG