Спасти проект: самые важные вопросы

    Так уж получилось, что последние пару лет я много работаю с кризисными проектами. Это проекты, в которых деньги потрачены, цели не достигнуты, все сроки много раз нарушены, менеджера уволили или он сам в ужасе сбежал, а уровень мотивации команды – ниже некуда. В общем, материализовавшийся fuck up. К сожалению, большинство таких проектов нельзя просто закрыть – все они важны для заказчика.

    Есть такой термин – «точка невозврата», часто использующийся в технике, особенно в авиации. Для самолета в полете это точка на трассе, начиная с которой топлива на борту уже не хватит, чтобы вернуться на аэродром вылета или уйти на резервный. Точка невозврата достигается, например, когда самолет долго летит над океаном.
    Такой термин можно применить и к управлению проектами – начиная с какого-то момента проще начать новый проект, чем пытаться спасти старый. Имеющихся ресурсов (времени, людей, денег) – главного проектного «топлива» – на изменение хода проекта уже не хватит. Кризисные проекты, как правило, точку невозврата уже прошли или очень близки к ней.

    image

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

    Чтобы этот процесс имел хоть какие-то шансы на успех, нужно правильно начать. Как говорят по ту сторону океана, a good beginning is half the battle. Помогут правильно начать ответы на следующие вопросы:

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

    Какие бизнес-цели проект преследует, есть ли измеримые показатели этих бизнес-целей? Бизнес-цель должна быть выражена в цифрах, например: «После запуска нового сайта продажи цветных телевизоров в нашем московском магазине вырастут не менее чем на 10% в месяц (в товарных единицах)».

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

    Кто относится к числу стейкхолдеров проекта? Самое время нарисовать матрицу поддержки и влияния. Скорее всего, на проекте уже сложилась ситуация, при которой политика отнимает большую часть сил и времени. Надо изучить карту политических сил и течений и, при необходимости, постараться ее изменить.

    Каковы последствия невыполнения проекта? Бывают ситуации, когда результаты проекта уже просто неактуальны – смело можно его закрывать, деньги целее будут.

    Кто спонсор проекта? С самой важной фигурой проекта нужно наладить тесный контакт и добиться поддержки.

    Кто входит в управляющий комитет проекта, и проводились ли регулярные встречи комитета? Если управляющий комитет не знает ничего о проекте, эту ситуацию надо срочно менять. Проект, о котором никто не знает, никто и не поддерживает, так что неудивительно, что он в такой… Ну, вы поняли.

    Кто входит в проектную команду? Вы будете смеяться, но бывают ситуации, когда люди месяцами работают в проекте и понятия об этом не имеют.

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

    Какова цель проекта, все ли ее понимают? Сформулированы ли критерии достижения цели? Не сформулировали и не донесли цель проекта до команды – попрощайтесь с надеждой на положительный результат.

    Сформулированы ли ограничения проекта? Возможно, от вас ждут совсем не тех результатов, к которым вы идете, ожиданиями заказчика никто не управляет. Итог – разочарованный заказчик, которому невозможно сдать проект.

    Определен ли состав задач проекта, есть ли план-график, достаточно подробный для выполнения этих задач? Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполнения задач? Если плана нет, то вообще непонятно, как проект исполнялся. При аудите плана-графика нужно обращать внимание на следующее:
    • План-график должен быть актуален. Если в мае вы видите план, который не обновлялся с января, что-то тут не так. Частота обновления плана-графика зависит от проекта (или от этапа проекта) и, как правило, варьируется от ежедневного обновления до еженедельного.
    • У каждой задачи в графике есть один и только один исполнитель, причем указана конкретная фамилия. Если фамилии напротив задачи не стоит, задача не будет выполнена никогда, ведь за нее никто не отвечает. Тот же печальный итог будет, если вместо фамилии исполнителя в плане стоит несколько фамилий, «ответственное подразделение» или название компании.
    • В плане-графике не должно быть задач длительностью больше трех дней. Длинные задачи имеют обыкновение не начинаться, их старт всегда откладывается из-за каких-то мелочей. Они тянутся бесконечно и обычно не завершаются. Если что-то пошло не так (вернее, когда все пошло не так), вы просто не успеете отреагировать и вернуть проект в правильное русло. Проект становится неуправляемым, а вы превращаетесь в статиста, который вынужден с тоской смотреть на длинные задачи, до завершения которых еще целый месяц. Так что длинные задачи надо разбивать на подзадачи длительностью не более трех дней.

    Есть ли список рисков и план управления рисками? Вопрос риторический. Понятно, что плана управления рисками нет – иначе проект вряд ли стал бы кризисным. Что ж, пора составить реестр рисков и план управления ими.

    Что у нас с планом (и фактом) бюджета проекта? Хорошо бы его составить, а заодно проконтролировать, что все в порядке с оплатой счетов, расходованием средств и, главное, проект будет финансироваться.

    Собственно говоря, все. Теперь можно заручиться поддержкой влиятельных стейкхолдеров и браться за дело – спасать проект. :-)

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

    Конечно, существуют миллионы проектов, для которых выполнение этих условий необязательно. Возможно, вы вытащите гиблый проект на своей интуиции, опыте и везении. Но зачем рисковать, если можно эти риски снизить?
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +1
      Бра-во! В принципе всем, кто прочитал этот пост, все понял и по каждому пункту смог вспомнить пример из своей реальной практики можно давать сертификат PMP.
        0
        Спасибо. ) Ну, про сертификат не уверен, но обеспечить вхождение в проект помогает, проверено. )
          –1
          PMP даётся не за опыт, а только и исключительно за BOK.
            0
            Что верно, то верно.
          0
          > Определен ли состав задач проекта, есть ли план-график, достаточно подробный для выполнения этих задач?
          > Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполнения задач?

          > В плане-графике не должно быть задач длительностью больше трех дней

          Момент важный, но судя по формулировке вопроса, в кризисные ситуации попадают только waterfall проекты. :) В других полного графика вполне может и не быть.
            +1
            На мой взгляд, даже если методика не waterfall, все равно план нужно иметь, хотя бы план на пару итераций. К сожалению, многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. )) Я лично двумя руками за итерационные методологии, но если уж в них дела зашли в тупик, то дело не в плане, а в коммуникациях, политике или в чем-то еще.
              0
              >многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. ))

              Значит эти «многие» тупо не понимают смысла и принципов agile, только и всего. Планирование — одна из ключевых составляющих любой agile методики.

              Кстати, если говорят «мы применяем agile», то скорее всего это как раз тот случай: ни ухом, ни рылом в том, что такое agile разработка, и ни хрена они на самом деле не применяют и в проекте полная анархия. Ибо нет такого подхода «agile». Agile — это тип подхода к управлению проектом. Группа подходов, если хотите. А дальше уже конретные реализации: XP, Scrum, FDD и так далее.
            +2
            Если мы говорим о кризисных проектах, то я бы ещё поставил пунктом 0 признание действующими лицами того, что проект в кризисе.

            А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
              0
              По идее, это работа менеджера — собрать всех и рассказать горькую правду.
                0
                Так весь Ваш список — это работа менеджера. :)

                Рассказать — это ещё не значит, что все согласны. А несогласные могут оказаться дополнительными трудностями на пути антикризисных действий. А их, трудностей, и так будет не мало.
              0
              Всё понравилось. Реально так, с кризисными проектами. Только вот нету анализа почему он стал кризисным.

              Конечно, если управлять хвостом так, как управлять проектом хорошо — дело выедет на рельсы. Но иногда полезно знать почему проект съехал с рельс, и не всегда дело в менеджере (или даже плане).
                0
                Полностью согласен, дело не обязательно в плане (о чем даже написал выше). Да, написать почему проекты становятся кризисными — хорошая идея, надо будет сделать.
                  0
                  Согласен. Найти причину кризисности надо обязательно. В частности, в веб-проекте: пожирающий время перфекционизм разработчиков и лидера; поток хотелок и отсутствие времени на них, что ведет к костыльным тупиковым решениям; экономия на квалификации разработчиков, дизайнеров или менеджеров в ключевых ролях проекта; недостаточное внимание рекламе и продвижению… Не уничтожив причину, из кризиса не выбраться.
                  0
                  >Какие бизнес-цели проект преследует, есть ли измеримые показатели этих бизнес-целей?
                  В этом случае необходимо составить таблицу (цель) — (существующая ситуация) — (необходимая ситуация) для каждого из «участков проекта». Да, выраженную в четких цифрах (условиях). Но необходимо именно описать «существующую ситуацию». Для приведенного примера — " На данный момент мы продаем 100 телевизоров" — «Надо продавать 110». В большинстве случаев, задача ставится «задача проста, мы должны увеличить продажи».
                    0
                    Согласен. Вообще, это еще хорошо, если пишут «задача проста, мы должны увеличить продажи». Бывает же что пишут «сделайте нам хорошо». )
                      0
                      Ну это равнозначные почти задания) Просто обязательно определять тот уровень с которого надо увеличивать продажи. После этого можно уже анализировать ситуацию, составлять некую воронку «продаж» и искать мешающий, узкий участок. После этого уже составить матрицу влияния на данный участок, ну и вести работу.
                      P.S. «обязательно» = ИМХО
                    0
                    Не хотели это в виде схемки (или таблицы) со стрелочками оформить, и этапы тематически сгруппировать? Это, конечно, не очень просто, но если выйдет, то получилось бы очень наглядное руководство, на мой взгляд.
                      0
                      Хорошая идея, подумаю.
                      0
                      Круто. Очень чётко, конкретно, лаконично и всё по теме.

                      Хотя вопросы и кажутся простыми, но получить на них ответы от новой команды ну очень сложно.
                        0
                        Спасибо. Я думаю, что время от времени надо забывать о сложных современных методах и инструментах управления и вспоминать о банальных вещах. Как сказал Сергей Довлатов, один из моих любимых писателей: «Я понимаю, что все мои рассуждения достаточно тривиальны. Недаром Вайль и Генис прозвали меня «Трубадуром отточенной банальности». Я не обижаюсь. Ведь прописные истины сейчас необычайно дефицитны.» ))
                        +1
                        Осталось задать вопрос нескромный. Сколько вы спасли проектов?
                          0
                          За последние четыре года штук семь, наверное.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              +4
                              1 — проект создания системы обработки статистических данных (для нероссийской госструктуры)
                              2 — проект создания сети платежных терминалов (для нероссийского розничного банка)
                              3 — проект развития сервисов банкомата (для нероссийского розничного банка)
                              4 — проект модификации штрафной политики (для розничного банка)
                              5 — проект по созданию виртуальных карточных сервисов для банкомата (для нероссийского розничного банка)
                              6 — проект создания DWH на технологиях Sybase (для крупного российского банка)
                              7 — партнерский проект банка с сотовым оператором

                              На самом деле даже побольше семи будет, если еще мелочь учитывать. ))

                          0
                          «Способна ли команда справиться с задачей, можете ли вы повлиять на ее состав?»
                          Ответ — нет. Ваши действия?
                            +2
                            Если руководителю проекта не дали полномочий на подбор и расширение команды — это не руководитель проекта, пусть не льстит себе.
                              +2
                              Должно быть, вы никогда не работали в матричных структурах. ))
                              habrahabr.ru/blogs/pm/121828/
                                0
                                Я работаю руководителем отдела, в моём подчинении руководители проектов. Структура матричная. Разработчики не подчиняются непосредственно РП-шникам.
                                При матричной структуре проблема с ресурсами еще проще, РП ставит задачу начальнику разработчиков с указанием сроков. Если сроки не выполняются — это проблема начальника отдела разработки.
                                  0
                                  Все абсолютно верно, так и есть. А теперь представьте, как в таких ситуациях чувствует себя менеджер проекта. )
                                    0
                                    Тяжело, но никто не говорил, что управлять проектами легко, это только в глазах разработчиков РП-шники выглядят лентяями, которые только и могут, что письма писать, да деньги получать.
                                    Реальный пример — руководитель проекта по внедрению крупной ИТ-системы (не мой подчиненный, там проект покрупней на порядок, и проектная группа вообще выведена из ИТ-департамента) свалился с приступом. Я прекрасно понимаю причину.
                                  0
                                  Плюс при отсутствии матричной структуры у тебя в команде при крупном ИТ-проекте должны быть свои сисадмины, поддержка, разработчики по всем системам, по которым идёт разработка в не зависимости от того, что по проекту может быть требуется на С библиотеку за пару дней написать.
                                0
                                Менять scope, например. До тех пор, пока хотелки и возможности хоть как-то не совпадут.
                                  0
                                  Нельзя. Но проект должен быть сдан
                                  ?
                                +1
                                Не бывает в проектах, в которых нельзя поменять scope.
                                  0
                                  Не совсем понимаю: вот мы задались вопросами. А дальше-то что?
                                  Требую продолжения статьи, как вытаскивать проект за уши из навоза
                                    0
                                    А дальше как раз начинается искусство воплощения в жизнь ответов на вышеописанные вопросы. )
                                      +2
                                      Набора ответов на указанные вопросы обычно достаточно, чтобы либо соскочить с предложения спасать, либо чтобы затребовать сумму и при этом аргументированно не обещать результата. Чисто венчурная математика: «пан или пропал».
                                      0
                                      Жалко мысли в голове не выделяются жирным если они важные…
                                        +3
                                        Длинные задачи имеют обыкновение не начинаться, их старт всегда откладывается из-за каких-то мелочей.

                                        Очень хорошее замечание! Особенно, если эти длинные задачи сформулированы в 2-3 строки, представляющие собой мысль в виде — «У нас есть проблема поддержки нашего приложения на 10 разных СУБД. С этим надо срочно что-то делать!»

                                        Еще я бы добавил такой пункт сюда. Боритесь с упадническими настрояниями в проекте, и боритесь за мотивацию. Если проект в такой ситуации, у половины разработчиков будет убеждение — «какой смысл тут упираться, если все равно эта херня будет тянуться, пока бюджет не кончится, или у кастомера терпение не лопнет, так смысл тут стараться?»

                                        По поводу мотивации — большинство нормальных прагматичных программистов терпеть не может две вещи.

                                        1) Писать фичи, по поводу которых никто не может толком объяснить, зачем они вообще нужны и кто и как их использует, и почему это должно работать именно так. Например — сказано, добавить поддержку для СУБД FoxPro. Зачем? Кому это надо? Не проще мигрировать на что-то другое?

                                        2) Делать фичи, по котором нет четкого и понятного требования и критерия выполнения, на уровне фичи, не на уровне успеха проекта.
                                          0
                                          Респект Вам, мне кажется ценность Вашего коммента выше ценности всей статьи. Сразу видно, что Вы прошли долгий последовательный путь программера, прежде чем стать менеджером :) Может напишете отдельную статью, например о том, чего не любят программеры? С удовольствием бы почитал!
                                            0
                                            Или статью, или подкаст — посмотрим :) Вообще надо, надо бы.
                                              0
                                              Один момент — я не перестал быть программером ;) Например, месяц назад я провел 3-4 восхитительных дня, портирую старую одну библиотеку на С++ с Win dll на unix .so, и это все под соусом JNI.
                                            0
                                            Мне что-то подсказывает, что если хотя бы на половину этих вопросов можно дать ответ, то проект очень даже позитивный и совсем не гиблый.
                                              0
                                              Это смотря какие ответы на эти вопросы можно дать. Никто не сказал, что ответы позитивные. )
                                                0
                                                Вот-вот. Главное, чтобы ответы были реальные
                                              0
                                              > Как говорят по ту сторону океана, a good beginning is half the battle.

                                              А по эту сторону говорят «доброе начало — полдела откачало».
                                              Терминов-англицизмов и без того целая куча, давайте хоть фольклор русским оставим…
                                                0
                                                Очень понравилось, спасибо большое за статью!
                                                  0
                                                  Спасибо )

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое