Меня зовут Дима Курамшин, более 12 лет я работаю в IT и более 8 лет я управляю IT-проектами в самых разных ролях. Сейчас работаю в AGIMA. Благодаря обширному опыту меня часто подключают либо к ключевым проектам в компании, либо к тем, которые находятся в кризисном состоянии. И здесь я расскажу об одном из самых интересных кейсов в своей практике.
Небольшая ремарка. В этой статье я расскажу о реальном кейсе из своего прошлого, это было задолго до AGIMA. Однако, несмотря на то, что этот проект давно закрыт, из уважения к нашей команде и бывшим партнерам, я всё же не буду указать имен и названий. Скажу лишь, что все данные абсолютно реальны, проект был завершен, а многие участники работают в других командах и даже странах.
Предисловие
Итак, что такое безнадежный проект в нашем с Йордоном представлении?
Под безнадежным проектом мы будем понимать такой проект, параметры которого отклоняются от нормальных значений не менее чем на 50%.
На практике это выглядит примерно так:
1. Сроки проекта сокращены более чем вполовину от нормы.
2. Проектная команда вдвое меньше необходимой.
3. Бюджеты и связанные с ним ресурсы урезаны наполовину.
4. Требования к функционалу (объем работ, scope) вдвое превышает значения, которые они должны были бы иметь при нормальных условиях.
Если хотя бы один из пунктов применим к проекту, значит его можно назвать безнадежным. Далее я буду часто использовать этот термин, поэтому важно с ним разобраться сейчас.
Подключение к проекту
Даже если проект начинается в разумной и спокойной обстановке, все равно велика вероятность, что по мере своего продолжения он выродится в безнадежный
- Моя задача — принять дела у предыдущего руководителя проекта. Но тут выясняется, что я уже 4-й по счету руководитель, все мои предшественники уволились, а последний и вовсе уходит спустя неделю работы. Тревожный звонок.
Итак, у меня примерно 5 дней на то, чтобы принять дела у текущего РП и взять на себя управление проектом. С чего начать?
Анализ, анализ, анализ
Я считаю, что в 80% случаев начинать работу на проекте нужно с изучения текущей документации и только потом переходить к другим шагам. Таким образом, мы сразу обнаружим проблемные места и сделаем встречи с другим РП и командой более предметными. Приемку дел при этом можно сопровождать точечными вопросами.
Изучение документации сразу показало, что у нас проблемы с документооборотом: сроки были сорваны, а новые не зафиксированы. В документах было много пробелов в содержании проекта и обещаний. Но об этом расскажу дальше.
Итак, для быстрого погружения в проект я:
1. изучил проектную и договорную документацию;
2. пообщался с действующим руководителем проекта;
3. пообщался с проектной командой;
4. встретился и переговорил с клиентом.
За отмеченные 5 дней я быстро принял необходимые дела. А вот полноценная интеграция в проект у меня заняла примерно 2 недели. К этому времени я уже точно представлял, что происходит на проекте.
Статус на момент подключения к проекту
1. Срок проекта изначально оценили в 9 месяцев. Когда я подключился, проект уже тянулся 11. Чтобы завершить работы, требовалось еще как минимум 4 месяца. Итого, отставание от первоначального плана составляло полгода.
2. Когда меня назначили руководителем, бюджет проекта был израсходован на 96%. Чтобы успешно его завершить, нужно было превысить бюджет на 58%.
3. Рентабельность проекта изначально закладывалась в 15,5%, но на момент моего подключения составляла 4%. К концу проекта показатель рентабельности ожидался в районе –58%.
Базовый план | Факт (в момент подключения) | Прогноз | Заголовок 5 | Заголовок 6 | Заголовок 7 | Заголовок 8 | Заголовок 9 | |
---|---|---|---|---|---|---|---|---|
Сроки (месяцы) | 9 | 11 | 15 | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
Рентабельность | 31% | 4% | -58% | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
Бюджет | - | 96% | 158% | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
5 «детских» ошибок, погубивших проект
Ошибка №1. Излишняя самоуверенность
Наша компания заключила фиксированный контракт на проект с оценочным сроком работ в 9 месяцев. Но сама ошибка была в том, что фиксированный контракт компания заключила, не имея опыта работы над подобными проектами и опыта решения подобных задач.
Ошибка №2. Пробелы в договоре
В юридических документах было много пробелов: от абстрактного наименования работ до отсутствия зафиксированных результатов. Ограничения и допущения тоже не были зафиксированы, что нанесло непоправимый вред. Не прописали ожидаемые итоговые артефакты по выполняемым работам. Например, было заявлено проведение опытной и промышленной эксплуатаций, но никто не подумал, за счет каких ресурсов мы будем ее проводить. И так далее.
Ошибка №3. Наивность и слепая вера в подрядчика
К сожалению, периодически на рынке встречаются случаи, когда компании заключают контракт на реализацию проекта, но не имеют собственных ресурсов. Такие проекты полностью отдают субподрядчику. В нашем случае была совершена именно такая ошибка.
После заключения сделки начался поиск подрядчика. В итоге выбрали небольшую, малоизвестную студию, которой полностью передали контракт на реализацию проекта. К сожалению, как это часто бывает, на решение о выборе субподрядчика повлияла цена договора.
Итого, мы полностью передаем контракт на реализацию достаточно крупного и интересного проекта неизвестному подрядчику, найденному по выгодной цене.
Проблема с подрядчиком вскрылась на 3-й месяц работ, когда стало очевидно, что сроки срываются, а результатов нет. В этот момент мы решили отказаться от подрядчика и собрать команду из штатных специалистов.
Причем подрядчика «оштрафовали» на 500 тыс. рублей, чему, я думаю, он был рад. Ведь скоро штатная команда занялась переоценкой и поняла, что итоговая стоимость проекта должна была быть в 2–3 раза дороже, чем изначально планировали.
Ошибка №4. Мало внимания проектированию
Важную роль в проекте играет проектирование. От него часто зависит успех или провал. Проектирование позволяет на ранних этапах определить показатели, которые помогут принять решение о будущем проекта. Например, согласиться на его досрочное прекращение, если перспективы реализации выглядят сомнительно.
Чтобы проектирование было качественным, недостаточно одних только опытных аналитиков. У вас должны быть зрелые и отточенные процессы работы, в которых должны быть как минимум стадии ревью и проверки артефактов. Причем заниматься этим должны люди, которые стоят на следующем шаге в жизненном цикле разработки.
В нашем проекте на проектирование выделяли 2 месяца. К сожалению, одной из фатальных ошибок стало то, что проектирование доверили субподрядчику и оставили его полностью без контроля. То есть никто не уделял должного внимания ходу работ, не проверял разрабатываемые артефакты, не запускал процесс согласования, когда это было необходимо, и т. д.
Разумеется, в итоге на выходе мы получили очень слабые артефакты, на которые фактически не могли ориентироваться в работе.
Ошибка №5. Плохое ведения проектной документации
К сожалению, документирование проекта велось плохо. Не буду лукавить, если скажу, что на момент моего подключения это был полный кошмар.
Например:
1. план-график был неактуален и редко обновлялся;
2. почти отсутствовало управлением изменениями;
3. полностью отсутствовало управление рисками;
4. ресурсное планирование было, хотя и поскрипывало;
5. управление бюджетами отсутствовало.
Не люблю придираться, но, по моим меркам, такое документирование проекта было недопустимо. Конечно, проблемы были не со всех сторон. Местами что-то фиксировалось хорошо. Но для серьезных проектов и такого типа контракта, по моему мнению, недостаточно.
Итоги анализа
2. Определил плановые сроки завершения проекта.
3. Составил реестр рисков, определил ключевые, подготовил планы по ним.
4. Актуализировал ресурсный план, чтобы понять, какие люди мне необходимы и в каком количестве.
5. Собрал информацию и проанализировал совершенные ошибки и причины, которые превратили проект в безнадежный.
6. Оценил общее настроение на проекте.
Конечно же, анализ — это не просто разбор текущих проектных данных. За это время я смог подтянуть проектную документацию, собрать актуальную информацию по срокам, бюджетам, остатку работ, ожиданиям и многому другому.
В итоге я получил достаточно информации, чтобы сделать выводы.
Проанализировали. А что дальше?
1. Отказаться от управления безнадежным проектом.
2 .Инициировать досрочное закрытие проекта.
3. Согласиться на эту роль.
Отказываемся от проекта
Тут вы можете возмутиться: «Как же я могу отказаться от него?» Очень просто. Как я писал выше, кризисные проекты отнимают много сил и времени. Большинство таких проектов приводят нас к вынужденным переработкам, работе под постоянным давлением и в состоянии стресса, не исключены и регулярные конфликты на любом уровне. Менеджерам таких проектов (да и другим участникам команды) часто приходится забыть про отпуска, жертвовать свободным временем, личной жизнью, физическим и психическим здоровьем в пользу проекта. И если постоянные переработки в течение 2–3 месяцев можно потерпеть, то жить в таком режиме полгода и больше будет сложно. Я знаю случаи, когда люди на безнадежных проектах подрывали здоровье и рушили свой брак. Нужно ли это вам? Готовы ли вы к такому? Решайте сами.
- Забегая вперед, для меня работа на этом проекте превратилась в ежедневные смены по 11–14 часов в будние дни и по 5–6 часов в выходные. Это продолжалось 5 месяцев. Почти все участники команды работали с большими переработками.
Инициировать досрочное закрытие проекта
К сожалению, многие просто не думают о том, что любой проект можно закрыть досрочно. Да, это может быть не так легко и не так приятно, как довести его до конца. Но всё же это может стать вашим лучшим решением. Подумайте и оцените, во что вам может встать досрочное закрытие проекта и соотнесите с теми затратами, которые повлечет доведение его до финала. Иногда расторгнуть контракт и выплатить штраф выгоднее, чем тянуть такой проект. Помните, что так вы можете не просто избежать дополнительных расходов, но и сберечь репутацию, сохранить команду.
- На основе анализа я поднял вопрос о досрочном закрытии проекта и даже смог убедить многих топ-менеджеров в правильности этого решения. Но главный босс дал приказ «биться до конца». Мне неизвестно, почему решение было таким, но если его приняли, значит на то были причины. Таким образом, на досрочное закрытие проекта можно было не рассчитывать и оставался только один путь.
Вам может показаться, что я считаю, будто безнадежных проектов следует в принципе избегать, но это не так. На самом деле и я, и многие другие соглашаются участвовать в безнадежном проекте, и это объяснимо. Например, Йордон приводит такие причины:
1. Риск высок, но вознаграждение тоже. Если соотношение риска и вознаграждения выглядит привлекательно, то это может стать большим соблазном участвовать в проекте. Речь не только о денежном вознаграждении. Это может быть психологическая награда: создать революционный продукт, помочь человечеству найти лекарство от болезни и так далее. Конечно, это чаще привлекает молодых сотрудников или компании.
2. Синдром покорителей Эвереста. Тут безнадежный проект представляется как возможность испытать себя. Одна только мысль сделать то, чего никто не мог сделать до тебя, заставляет кровь кипеть. Это может быть вызов, и люди соглашаются в надежде завоевать славу и признание.
3. Наивность и оптимизм молодости. Как правило, в IT работают молодые и прогрессивные ребята. У них высокая целеустремленность и уверенность в себе, но и наивность. Многие готовы взяться за такие проекты, просто не понимая, что они за собой скрывают.
4. Альтернатива — безработица. А вот и другая сторона медали. Если наивность — это чаще про молодых специалистов, то мотиватором более зрелых иногда становится страх потерять работу.
5. Возможность будущей карьеры. Безнадежные проекты учат нас многому и взращивают из нас профессионалов быстрее. Наградой тут может быть продвижение по карьерной лестнице или шанс громко заявить о себе на рынке.
6. Альтернатива — банкротство. Сотрудники соглашаются участвовать в безнадежном проекте, если верят, что альтернативой является банкротство или иные страшные последствия.
Я не могу однозначно ответить, почему согласился на этот проект, ведь я знал, на что иду. К тому моменту у меня за плечами уже был не один сложный проект, многие были кризисными. Но всё-таки я сказал да. Скорее всего, я хотел принять вызов, набрать очков в пользу будущей карьеры.Но вместе с тем я еще и проявил наивность. Этот проект казался просто еще одним кейсом в моей копилке, не больше. Казалось, что справиться с ним будет легко. Так или иначе, после отказа от досрочного закрытия проекта я согласился взять на себя ответственность за его реализацию.
Как спасти безнадежный проект
Переговоры — ваше всё
Если вы являетесь менеджером безнадежного проекта, то очень легко предсказать результат переговоров относительно бюджета, сроков и ресурсов: вы проиграете.
Конечно, все зависит от конкретной ситуации, но я бы рекомендовал пойти таким путем:
1. Сначала проводим переговоры внутри своей компании и команды.
2. Потом проводим переговоры с заказчиком.
Внутренние переговоры
Переговоры с руководством важны на начальной стадии. Если уж так получилось, что вы стали менеджером безнадежного проекта, то важно обсудить и договориться о возможных индивидуальных условиях работы на проекте. Например, вы можете договориться об индивидуальном подходе в части управления проектом, избавить вас от бюрократических процессов, мешающих работе, выделить в команду проекта лучших специалистов и так далее. Помните, что если проект кризисный, то не будет лишним создать гораздо лучшие условия работы, ведь работа и так будет не самой простой.
К сожалению, на кризисных проектах часто встречается такой парадокс: проект требует много внимания, и ваше собственное руководство может стать серьезной помехой для успешной работы на проекте.
- Во многих компаниях, где я работал или которые консультировал, я встречал такой сценарий: если проект попадает в категорию «кризисных», то сразу появляется группа людей (как правило, состоящая из руководящего состава), которые назначают регулярные собрания и дополнительные активности по антикризисному управлению. В моей компании существовал антикризисный комитет, который как раз занимался работой с подобными проектами. Правда, работа чаще всего сводилась к тому, чтобы регулярно проводить встречи, на которых менеджер показывает определенные метрики, предоставляет отчетность и докладывает по решениям задач, а также получает новые задачи от участников комитета. Иногда доходило до абсурда, и количество встреч по антикризисным мероприятиям доходило до 4-х в неделю. Не буду лукавить, если скажу, что это явно создавало больше проблем, чем приносило пользы, а еще это приводило к большим переработкам среди менеджеров и тимлидов. Я работал с разными комитетами и в разных ситуациях, но на этом проекте даже мне казалось, что комитет затягивает петлю вокруг моей шеи.
Команда и мотивация
Первая отличительная особенность безнадежного проекта — явно выраженный акцент на правильном формировании проектной команды.
Йордон выделил 4 стратегии формирования команды безнадежного проекта:
Стратегия №1. Команда суперзвезд
Нанимаем суперпрограммистов и предоставляем им полную свободу действий.
Стратегия может быть хорошей, но очень рискованной, так как суперпрограммисты часто бывают суперэгоистами с суперзарплатой. Вполне вероятно, что куча суперзвезд просто не сможет ужиться друг с другом. Да и сама вероятность, что высококвалифицированные специалисты захотят присоединиться к безнадежному проекту, невысока.
Стратегия № 2. Команда «Миссия невыполнима»
Привлекаем команду, готовую к невыполнимой миссии и имеющую опыт совместной работы.
Эта стратегия считается наиболее подходящей. В этом случае команда не состоит только из очень дорогих специалистов, а участники имеют опыт совместной работы. Огромный плюс, если у команды за спиной уже есть подобные проекты.
Стратегия № 3. Команда простых смертных
Формируем команду из самых обычных специалистов, но предупреждаем, куда и на что они идут.
Наиболее распространенный вариант, когда мы сталкиваемся с безнадежными проектами. В команде может не быть суперпрограммистов или тех, кто вместе прошли тернистый путь ранее. Следовательно, это новая команда, собранная на проект, и ваша задача — постараться превратить ее в команду «Миссия невыполнима».
Стратегия № 4. Команда «счастливчиков»
Берем просто всех, кому «посчастливилось» быть назначенными на этот проект, и пытаемся сделать из них команду «Миссия невыполнима».
Самый худший вариант, который можно встретить и которого нужно избегать любыми способами. Такой подход подразумевает, что проект превращается в свалку, куда отправляют сотрудников, которым нет места на других проектах. Почти наверняка это команда превратится в «отряд самоубийц».
Внимание к комплектации команды
А теперь немного мистики. Чтобы команда была эффективной, ее участники должны иметь высокую квалификацию, но еще более важный фактор — психологическая совместимость.
Разумеется, формирование сплоченной команды занимает время. Йордон пишет, что в процессе эволюции команда проходит 4 основные стадии:
1. Формирование: участники команды определяют цели, роли и направления работы.
2. Утряска: команда устанавливает правила и процедуры, пересматривает роли и ответственность.
3. Нормирование: вырабатываются процедуры, стандарты и критерии.
4. Выполнение: команда начинает функционировать как единое целое.
При идеальном стечении обстоятельств команда оказывается сразу на третьей стадии, поскольку участники уже работали вместе. В моем случае я подключился уже к сформированной команде, что немного облегчало задачу. Однако проблема была в самом составе проектной команды, особенно учитывая, что в команде было много новичков.
- Через месяц я заметил, что работа с некоторыми участниками вызывает сложности. Они были сильными специалистами, но не подходили в команду и тянули остальных назад. Я решил провести несколько ротаций и заменить или вовсе убрать некоторых людей с проекта. В обычных условиях я бы вряд ли так сделал. Но условия безнадежного проекта требуют максимальной эффективности, и, к сожалению, иногда приходится принимать непростые решения. Несмотря на частичное сокращение команды, мы не потеряли в скорости, даже наоборот.
К сожалению, многие менеджеры пренебрегают человеческим фактором даже в обычной работе и обесценивают человеческие отношения. И даже если менеджер как-то пытается работать с мотивацией сотрудников на обычных проектах, стоит помнить, что безнадежные проекты требуют более высокой степени, так как участникам придется долгое время выдерживать изнурительную работу, постоянное давление и прочие трудности.
Во-первых, помните, что именно менеджер является основным драйвером настроения в команде и именно он может обеспечить необходимую мотивацию команды. Настроение в команде в первую очередь будет зависеть от того, какое настроение вы транслируете участникам.
Во-вторых, основные факторы, влияющие на мотивацию, сосредоточены вокруг тех процессов, которые происходят в команде.
В-третьих, и это самое главное, будьте внимательны к участникам команды. Ограждайте их от лишних задач и сторонних вопросов, защищайте от вмешательства руководства и других менеджеров. Выгоняйте их с работы в пятницу, запрещайте им работать по выходным, давайте им возможность отдохнуть и выспаться. Как бы ни шла работа, всегда заботьтесь о своих людях. Если вы можете как-то повлиять на их зарплату, сделайте и это. Всё это поможет сохранить команду в целости.
Еще хочется обратить внимание на важность коммуникаций. Я считаю, что на любом проекте важна степень взаимодействия менеджера с командой. В идеале достичь такого состояния, когда у менеджера нет секретов от команда, а у команды — от менеджера. В команде должна быть культура открытости, когда никто не боится сообщать о своих подозрения, подсвечивать риски, говорить о неудачах и обращаться за помощью. Это отлично дополнит полная вовлеченность членов проектной команды в работу на проекте, где каждый участник команды владеет информацией о состоянии проекта, понимает приоритеты, риски и т. д.
На кризисном проекте люди — это ваша самая главная ценность, и нет ничего важнее участников вашей проектной команды.
- Работая над этим текстом, я вспоминал, насколько тяжелым был тот проект, но я уверен, что сделал для своей команды всё возможное. Несмотря на то, что работать было сложно, у нас был крепкий коллектив, хороший боевой дух, доверие друг к другу. Именно такая команда способна творить чудеса, а это именно то, что требуется на безнадежных проектах.
Условия работы
К сожалению, наличие потрясающих специалистов, крепкой команды и отличных условий не гарантирует успех безнадежного проекта. Но их отсутствие почти наверняка будет гарантировать его провал.
Процессы
Если вы запомните хотя бы одно слово из всей книги, то этим словом должно быть «приоритетность» (triage).
Безнадежный проект требует индивидуальных правил игры, и слепое следование стандартным процессам часто заводит такие проекты в тупик. Внедряйте и управляйте процессами осознанно, придерживаясь концепции приоритизации. Находясь в состоянии постоянной нехватки времени и ресурсов, отказывайтесь от тех процессов, которые являются несущественными.
Подведем итоги
2. Объективно оцените свои силы и возможности компании: если проект оказался кризисным, возможно, тратить на него время и ресурсы уже бессмысленно.
3. Договаривайтесь: чтобы вытащить проект из кризиса, вам понадобятся ресурсы — и это нормально. Сделать что-то из ничего невозможно. Поэтому откровенно говорите заказчику и руководителю, как можно выйти из положения и какая помощь вам нужна.
4. Работайте с командой: подберите тех людей, которые помогут вывести проект из кризиса, мотивируйте их, поддерживайте, добивайтесь для них лучших условий — вместе вы решаете непростую задачу.
5. Позаботьтесь об условиях труда: справиться с трудностями можно, только если вам и команде ничего не мешает. Поэтому не стесняйтесь просить особых условий, если это поможет достичь цели.
6. Проявляйте гибкость: процессы должны помогать, а не мешать работе. Поэтому подбирайте такие практики и методы, которые будут всем удобны. И не тревожьтесь, если иногда заведенные обычаи не будут соблюдаться.
- Что касается нашего проекта, то он завершился на этапе ввода системы в опытную эксплуатацию. Конечно, мы оставили небольшую команду для сопровождения, но основной состав был распущен. Это был очень долгий и тяжелый период для всех участников, поэтому многие ушли в отложенные отпуска, кто-то искал спокойствие на более простых проектах и отказывался участвовать в чем-то амбициозном, а кто-то покинул компанию.