вторник, 10 апреля 2018 г.

Модель жизненного цикла магазина торговой сети

При рассказе об орг.возможностях (capabilities, TOGAF capability based planning) всегда встает вопрос рассказать про конкретный пример жизненного цикла, без упрощенных "колбасок" и V-диаграмм. Сделал пример, по которому можно разбираться:


Упрощенный и обобщенный жизненный цикл магазина розничной торговли
Для чего используются модели жизненного цикла?

  1. Планирование программы проектов (переход из AS IS в TO BE)
  2. Определение целей и содержания отдельных проектов
  3. Технологическое планирование предприятия (какое ИТ и другое технологическое решений подойдет и почему)
  4. Управление человеческим капиталом (какие компетенции есть и будут нужны для реализации стратегии)

вторник, 3 апреля 2018 г.

PDCA и онтологика

Когда говоришь “PDCA”, все кивают головами, всем все понятно, только почему-то почти ни у кого этот цикл не работает, а значит, почти никто его не понимает, просто не признается себе в этом. Проблем в его применении несколько, и все они приводят к практической невозможности перехода на проектное управление в российской компании, а решение этих проблем дает гипотезу, объясняющую успех своеобразного понимания Agile в России.


Особенности мышления в сравнении с деятельностью
Работаем мы с индивидами (4Д объектами), а планируем в концептах (в абстрактных объектах). Другими словами, мы думаем “молоток”, видим любую штуку, подходящую под этот концепт, хватаем ее и колотим куда надо. Индивиды реальны, концепты в голове. Т.е., мы всегда концептуализируем деятельность, потому что деятельность происходит в реальном мире, а планирование происходит в голове. Какой-то однородный кусок реального мира называется доменом - домен строительства, домен управления финансами, домен домохозяйства. В доменах происходит разделение труда, есть специализации.


Цикл PDCA подразумевает, что вам нужно концептуализировать:
  1. Свою деятельность, моделирование вашего кусочка предметного домена.
  2. Деятельность других людей в вашей команде, моделирование целикового предметного домена.
  3. Деятельность вашего заказчика (Сюрприз! Потому что если у вас нет концептов деятельности заказчика, то как вы проверите качество вашей работы на уровне планов? Так и происходит проверка качества с помощью фактической передачи результата работ заказчику в отсутствии моделей деятельности). Моделирование домена заказчика.
  4. Деятельность по изменению деятельности. Организационное моделирование.

Т.е. за кажущейся простотой аббревиатуры стоят 4 навыка только планирования. А ведь эти планы еще надо прочесть, понять и исполнить, не говоря уже о том, что проконтролировать. Тем, кому кажется, что я переусложняю, предлагаю еще раз честно ответить на вопрос “а у вас PDCA работает”?


План нужен для одной вещи - для предсказания состояния реального мира, домена. Мы строим план из точки прошлого и затем видим факт, который можем сравнить с планом. Если расхождение между планом и фактом для нас приемлемое, то план (предсказание модели) был хорошим, если расхождение было значительным и мы делали что-то неправильное, то план был плохим*. Чем меньше у нас знаний о домене (т.е. чем хуже концептуализация домена), тем слабее ваша предсказательная сила, тем меньше и хуже вы можете планировать, тем больше вам надо договариваться по поводу фактов, доказывать, что результат работ и есть то, что хотели сделать.
https://en.wikipedia.org/wiki/Cynefin_framework объясняет различие между уровнями концептуализации домена. Если модели, позволяющие качественно планировать, доступны почти всем, совместная деятельность простая, например, все водят автомобиль в городе. А если деятельность часто меняющаяся, сложная, либо команда не может договориться по поводу моделей планирования (обращаю внимание на этот момент), то концептуализация хаотическая. Всяческие канбан доски как раз позволяют сделать общую для команды концептуализацию проекта.
Практическая рекомендация - когда общаетесь с другими, разделяйте в своей речи, ведете ли вы речь о концептах или об индивидах, другими словами, обсуждаете ли вы фактическое исполнение работы или планируете деятельность. При этом свои убеждения об устройстве мире, ваши модели мира, стоит формулировать в виде проверяемых предсказаний, фактов, не “Вася любит молоко”, а “если дать молоко Васе, то он скорее всего возьмет”, не “люди несправедливы”, а “если я сейчас сделаю ему одолжение, о котором он просит, то на мое ответное одолжение завтра он ответит отказом”. Общайтесь по поводу фактов, а не мнений, это намного продуктивнее. *Хороший план означает, что вы можете договориться с другими по поводу фактов, т.е., есть соглашение, что факт соответствует плану, плохой план означает, что такого соглашения нет.


Что такое прагматика?
“Лучше ударить кривой палкой, чем потратить полжизни на ее исправление”.


История из жизни. Менеджер и инженер обсуждают сроки реализации задачи.
  • Когда закончишь?
  • Не знаю, надо подумать.
  • Мне ответ нужен прямо сейчас, надо идти на совещание, там будет принято решение делать это вообще или нет.
  • Не могу я сейчас ответить, это же считать надо. Я сейчас скажу, а потом с меня же эти сроки и спросят.
  •  Т.е., не дашь сейчас сроки?
  • Не дам, и не проси.
  • Хорошо, к следующему году сделаешь?
  • К следующему точно сделаю.
  • К сентябрю?
  • Да, к сентябрю смогу.
  • За 3 недели?
  • Думает несколько секунд, кивает головой.
  • За неделю?
Резко мотает головой, перекрещивает руки, говоря всем видом, что “вот, я же говорил”!
  • Другими словами, твоя оценка сроков от 2 до 3 недель?
  • Да, где-то в этих пределах.
  • Спасибо, этого достаточно.


Основной принцип моделирования и планирования. “Нет моделей точных, есть модели более полезные для чего-то или менее полезные для чего-то”. Не обязательно иметь посчитанные с высокой степенью точности и достоверности прогнозы, чтобы принять решение, надо каждый раз думать, в какой части спектра мышления вы хотите принимать решение по поводу ситуации. Другой принцип: “Все знания вероятностны, но это неточно”. Мы ничего не знаем с абсолютной точностью, мы всегда должны думать в терминах вероятностей и менять свои модели в цикле PDCA постепенно сдвигая их при получении свидетельств об их точности-неточности, а не отказываться от них сразу и полностью после какой-то ошибки планирования, как это часто бывает. “А, этот ваш проектный менеджмент не работает, мы один раз пробовали, ничего не дало”.


В домене управления проектами, например, лучше иметь не очень проработанные планы по всем областям проекта, т.е., планы по содержанию, срокам, стоимости, качеству, рискам, персоналу, команде, стейкхолдерам, закупкам, коммуникациям и прочему, чем иметь проработанный график работ и бюджет, и полный ноль по всем остальным пунктам. Да, прорабатывая план по срокам и бюджет проекта, вы уменьшаете степень неопределенности по ним, но оставляете критический уровень неопределенности в других областях проекта, откуда могут прийти совершенно неожиданные для вашего проекта изменения, которые опрокинут точность планирования. Например, если вы не учли в плане коммуникации особенности общения с госорганами, то есть риск, вероятность того, что ваше расписание будет сорвано из-за согласований и других моментов, связанных с тем, что это общение не было нормально концептуализировано, планы вашего проекта просто не включают в себя концепты государственных чиновников.


Сравните, например, с тем, что пишет Nick Lavingia в статье “How to create world-class project management organization?” Шаг 1 “Создайте общий язык”, другими словами, узнайте и согласуйте между собой концепты домена. На всякий случай о том, кто такой автор.


Другими словами, помимо того, что надо уметь строить 4 вида моделей (Plan-Do-Check-Act), надо уметь еще и делать по модели (Plan-Do-Check-Act), уметь контролировать (Plan-Do-Check-Act) факт того, что люди действуют в соответствии с моделью, а там могут быть отклонения в действиях, отклонения в результатах (ошибки в навыках, ошибки в знаниях, ошибки в правилах). И метод “5 почему” имеет свои особенности исполнения в отношении каждого из вариантов использования, так, “5 почему” может касаться исследования того, что работа проводилась не в соответствии с утвержденными моделями, а может в отношении того, что модели разрабатываются неправильно. И перескакивать между этими линейками вопросов нельзя, хотя и случается при каждом удобном случае, когда начинают расспрашивать про модели, а завершают расспросы доменом.


И, наконец, act. Вы можете откорректировать модель, способ прогрузки этой модели в головы людей, их обучение, или способ контроля.


Еще раз, основная мысль, в виде истории, которую рассказал биржевой трейдер: “Если ты можешь предсказывать с точностью 51%, иди на ФОРЕКС, станешь миллионером”. Не всегда нужна точная модель, иногда нужно уметь строить прогноз чуть-чуть лучше других, этого будет достаточно. Будьте прагматиками.


Это именно то, о чем говорит PMBOK, когда пишет, что команда проекта должна адаптировать предлагаемые практики к требованиям конкретного проекта.


Как пример, разберу карту процессов Риты Малкахи в аспекте
Какие есть модели в управлении проектами?
  1. Устав
  2. Матрица анализа стейхолдеров
  3. Реестр стейкхолдеров
  4. Список и атрибуты операций
  5. Требования к ресурсам
  6. План управления изменениями
  7. План управления коммуникациями
  8. Базис по стоимости
  9. План управления стоимостью
  10. План управления человеческими ресурсами
  11. Матрица прослеживаемости требований
  12. Список контрольных точек
  13. Сетевая модель расписания
  14. Матрица вероятности и рисков
  15. План улучшения процессов
  16. План управления проектом
  17. Расписание
  18. Описание содержания
  19. План управления качеством
  20. Спецификация требований
  21. План управления рисками
  22. Роли и ответственность команды
  23. План управления расписанием
  24. План управления содержанием
  25. План управления стейкхолдерами
  26. Словарь ИСР
  27. ИСР
  28. Журнал изменений
  29. Запрос на изменения
  30. Журнал решений
  31. Журнал проблем
  32. Аудит качества
  33. Реестр команды
  34. Оценка эффективности члена команды
  35. Оценка эффективности команды
  36. Отчет по статусу проекта члена команды
  37. Операционное соглашение команды
  38. Отчет по статусу от подрядчика
  39. Отчет по освоенному объему
  40. Акт сдачи-приемки
  41. Отчет о ходе проекта
  42. Анализ рисков
  43. Анализ отклонений
  44. Закрытие проекта
  45. Накопленный опыт
  46. Анализ закупок
  47. Закрытие контракта

Модели нужны нам для предсказаний. Что же они предсказывают?
  1. Устав - даты начала и завершения, какие ресурсы будут выделены на проект и кто какую ответственность несет. Можно еще предсказать карьеры участников в случае успеха либо неудачи.
  2. Матрица анализа стейхолдеров - на какие темы надо будет много общаться в проекте
  3. Реестр стейкхолдеров - с кем надо будет много общаться на проекте и на какие темы, какая будет динамика и особенности этого общения
  4. Список и атрибуты операций - что понадобится для выполнения работ проекта, что важное в этих работах, а что нет
  5. Требования к ресурсам - как и где искать людей для выполнения проекта, как будет устроен маркетинг вакансий и найм
  6. План управления изменениями - с какой скоростью будут реализовываться изменения, сколько денег на это будет тратиться, насколько фактический результат будет соответствовать формальному описанию
  7. План управления коммуникациями - кто будет активно включен в работу над проектом, кто будет находится в неведении, где будут циркулировать слухи, где будут возникать непонимания
  8. Базис по стоимости - сколько потратят денег на проект, насколько сложным будет согласование бюджета, какая будет нагрузка на проектную команду перед бюджетным циклом
  9. План управления стоимостью - какие будут перерасходы и нецелевое использование бюджета, сколько будет нарушений в части стоимости, в каких областях эти нарушения будут возникать
  10. План управления человеческими ресурсами - какая будет культура в проекте, сильно ли повлияет человеческий фактор, где будут очаги недовольства и как будет циркулировать информация между группами влияния
  11. Матрица прослеживаемости требований - какие требования будут реализованы качественно, а какие нет, кто из стейкхолдеров будет больше удовлетворен проектом, кто будет менее доволен и будет мешать проекту
  12. Список контрольных точек - где возникнут неожиданные проблемы в проекте
  13. Сетевая модель расписания - какие будут сроки окончания и бюджет проекта по мере появления новой информации о скорости выполнения работ (отчетов по ходу работ)
  14. Матрица вероятности и рисков - соответствие текущих знаний команды домена проекта задаче, объем дополнительных работ и необходимости контроля в проекте по ряду задач
  15. План улучшения процессов - что будет часто повторяться и на что будут потрачены основные деньги и усилия, где будет больше внимания операционного руководства проектом
  16. План управления проектом - на что будет направлено внимание руководства, за что будут спрашивать и за что платить деньги и награждать
  17. Расписание - когда будут начинаться и завершаться работы, кто чем когда будет занят
  18. Описание содержания - что будет сделано в проекте, сколько это будет стоить и сколько времени займет, кто из людей потребуется, где были сделаны аналогичные проекты и где есть подобная экспертиза
  19. План управления качеством - что мы передадим заказчику, зачем ему нужен такой результат, как он его будет использовать, на чем построен его бизнес
  20. Спецификация требований - как будет вести себя изделие
  21. План управления рисками - где возникнут проблемы, что станет их причиной, что мы будем делать, чтобы этого не случилось
  22. Роли и ответственность команды - кто чем будет заниматься, где возникнут проблемы с исполнением и почему
  23. План управления расписанием - как часто и насколько мы сможем менять сроки исполнения работ, количество авралов, сверхурочных, ошибок
  24. План управления содержанием - насколько сложно и долго будет урезать и наращивать содержание проекта, кто будет принимать такие решения и кто на них сможет влиять
  25. План управления стейкхолдерами - успешность влияния команды управления на проект, возможные конфликты и предмет конфликтов, способы решения конфликтов
  26. Словарь ИСР - успешность коммуникации в команде, количество неправильно сделанной работы
  27. ИСР - распределение полномочий, ответственности, объем работ проекта, нагрузка на команду управления и другое руководство
  28. Журнал изменений - количество проблем с исполнением, качество работы команды и подрядчиков ,качество планирования и проектирования
  29. Запрос на изменения - степень зрелости команды планирования, проработанность предметной области, квалификацию исполнителей
  30. Журнал решений - потенциальные проблемы с долгосрочными следствиями принятых решений, возможность успешного расследования инцидентов и разбора действий руководства
  31. Журнал проблем - открытость коммуникаций в проекте, доверие, командный дух, стремление к результату, квалификация команды
  32. Аудит качества - умение работать со спецификациями, экспертиза в измерениях и организации рабочего процесса
  33. Реестр команды - культура команды, динамика общения внутри команды, потенциальные конфликты, зоны ответственности и полномочия людей
  34. Оценка эффективности члена команды - отношения между членами команды, эффективность и результативность внутри команды, срывы сроков и возможность решения проблем
  35. Оценка эффективности команды - отношения между членами команды, эффективность и результативность команды, срывы сроков и возможность решения проблем, удовлетворенность команды и заказчика результатами проекта
  36. Отчет по статусу проекта члена команды - когда будет выполнена работа, насколько хорошо он оценивает сроки и трудоемкость задач, достаточность квалификации работника для назначенных задач, способность решать проблемы, взаимоотношения в команде
  37. Операционное соглашение команды - как будет вести себя команда, как будут решаться проблемы
  38. Отчет по статусу от подрядчика - когда будет выполнена работа, насколько хорошо он оценивает трудоемкость и решает проблемы, будут ли выполнены контрактные обязательства
  39. Отчет по освоенному объему - во сколько обойдется проект, сколько на нем можно будет заработать
  40. Акт сдачи-приемки - вероятность успешного выполнения работы, вероятность возникновения проблем с результатом, вероятность юридических разбирательств, вероятность получения повторного контракта
  41. Отчет о ходе проекта - возможные управляющие действия со стороны руководства, карьерные последствия для членов команды, изменения в проекте по срокам-бюджетам-содержанию
  42. Анализ рисков - квалификацию команды в домене проекта, успешность завершения проекта, работы по устранению риска
  43. Анализ отклонений - необходимость переработок, переноса сроков, изменения содержания, перебросок ресурсов между задачами
  44. Закрытие проекта - объем работ, доступность ресурсов, вероятность получения прибыли, премий, наград
  45. Накопленный опыт - количество ошибок в подобных проектах, сроки и стоимость исполнения таких проектов, вероятность получения бизнеса по таким проектам
  46. Анализ закупок - точность бюджетов по аналогичным закупкам, содержание будущих договоров на поставку и отношения с подрядчиками и поставщиками
  47. Закрытие контракта - удовлетворенность сторон договора, вероятность возникновения проблем по предмету договора, сроки и бюджеты аналогичных договоров

Именно прогнозы и модели, по которым формируются эти прогнозы и являются основным содержанием бесед по методике Тулгана “Все начальники делают это”. И на тренинге по онтологике как раз и учат методикам правильного общения в команде. А т.к. руководители проектов 90% времени общаются с другими, в этом заключается их работа, то надо уметь это делать лучше других. Этому учат здесь:


суббота, 24 марта 2018 г.

Управление кризисными проектами, пошаговое руководство для профессионалов


Часть 1. Стоит оно того?

На определенном этапе большинство руководителей проектов получают предложение войти в кризисный проект. Вас попросят спасти провальный проект или восстановить проект, столкнувшийся с серьезными проблемами. Ваша роль может заключаться в диагностике здоровья проекта, но вы можете и возглавить попытку спасения. Эта статья состоит из трех частей и в ней обсуждаются некоторые вопросы, подлежащие рассмотрению перед стартом, порядок проведения диагностики и мероприятия по восстановлению.
Перед началом необходимо выяснить, какие у вас полномочия. Они могут варьироваться от ревизии и отчета до "разобраться с проблемой, пленных не брать".
Множество попыток спасения оканчивается неудачей из-за того, что в начале нет четкого понимания ожиданий. И даже хуже того - ожидания смешаны. Чтобы проиллюстрировать данный пункт, давайте рассмотрим более конкретный пример. Помощь при стихийных бедствиях может быть совершенно неэффективна, когда несколько организаций и служб пытаются делать одни и те же вещи, либо не четко определены зоны ответственности. Образцом для организации помощи при стихийных бедствиях является центральная европейская служба, объединяющая различные агентства, в обязанности которой входит определение плана действий и назначения ответственных агентств, наилучшим образом оснащенных для выполнения поставленных задач.
Если вас попросили войти в проект, вам должно быть понятно, чего от вас ждут. Эти ожидания должны быть документированы и согласованы со спонсором или другим ответственным лицом. Этот документ должен быть доступен всем заинтересованным лицам, чтобы все понимали вашу роль и что вы собираетесь делать.
Содержание мандата (документа описывающего полномочия)
Мандат должен описывать следующие моменты:
Ваши полномочия по доступу к информации. Например, должны ли вы иметь доступ к конфиденциальной и всей финансовой информации?
Конфиденциальность информаторов. Обязаны ли вы передавать всю собранную информацию руководству или она может предоставляться на условиях анонимности?
Уровень кооперации, который ожидается от участников. Например, обязаны ли участники оперативно принимать приглашение на встречу для обсуждения состояния проекта с вами? Вполне возможно, что в интересах определенных людей быть слишком занятыми для разговоров с вами месяц-другой.
Какая поддержка будет оказана. Кто поможет вам собрать информацию и выполнять административную работу?
Ожидаемый результат. От вас требуется отчет по состоянию проекта, рекомендации, решения и т.д.
Какой у вас контроль над результатами работы. Я видел, как множество ревизионных отчетов переписывались для покрытия виновных. Я всегда настаиваю на том, чтобы мой отчет оставался таким ,каким я его написал. Обычно это означает, что отчет идет к спонсору, и уже он решает, насколько широко этот отчет распространяется. Если подготавливается еще и отредактированная версия, я настаиваю, чтобы из такой версии была удалена закрытая информация (финансовые показатели, условия контрактов). Я не участвую в подмене фактов, отраженных в отчете для защиты определенных людей. Если организация настаивает на переписывании отчета, я требую удаления своего имени из документа.
Ограничения. Например, можно ли менять персонал? Можно ли изменить содержание? Может ли проект быть прекращен?
Сроки. Какие будут контрольные точки проведения ревизии и разработки плана мероприятий?
Промежуточные задачи. Редко получается получить представление о проекте за несколько часов и даже за несколько дней. Для завершения отчета может потребоваться несколько недель. Что происходит в это время в проекте? Продолжается ли работа, должны ли люди быть перекинуты на другие работы, пока отчет не будет подготовлен?

Следующие шаги
Один мой коллега, которого часто просят провести диагностику проекта, сказал, что обычно после того, как он указывает на проблему, его обычно просят исправить ее. У меня был такой же опыт, несмотря на то, что изначально мы договаривались только на подготовку отчета. Ответьте себе и заказчику на вопрос, готовы ли вы или нет возглавить спасательную операцию. Четко обозначьте свою позицию спонсору в самом начале, особенно если вы не заинтересованы. Самый худший вариант, по которому могут пойти события - это предложение вам огромной компенсации за "передумать", в случае, если заказчик будет впечатлен вашей работой.
Влияние на карьеру
Проведение такой ревизии может иметь цену - как эмоциональную, так и для карьеры. Несколько лет назад ко мне обратился клиент, с которым у меня был бизнес ранее, меня попросили провести ревизию одного проекта. Вскрывшиеся факты были были очень критичными по многим аспектам деятельности компании, включая руководителя проекта и поддержки, которую он получал от топ-менеджмента. Результаты ревизии никто не оспаривал, но они, тем не менее, были болезненными для множества людей, которые надеялись на то, что факты будут заметены под ковер. К их сожалению, я не прислушался. Результат - они ко мне больше не звонили.
Сожалею ли я об этом? Не особо. Я начинал ревизию с пониманием того, что результат может быть нелицеприятным и что есть риск быть гонцом с плохими новостями с очевидными последствиями. По крайней мере я могу сказать, что этот отчет - это мое честное мнение о данной организации. В частности, я не хочу писать отчет, перемещающий вину с неспособности участников управлять проектом на мою неспособность анализировать ситуацию. Подлоги имеют тенденцию возвращаться к вам бумерангом по прошествии времени.
Часто организации ищут козла отпущения. Минимум. на который они рассчитывают, это найти человека, которого можно обвинить в текущих проблемах и зачастую это стрелочник, а не истинный виновник.
Эмоциональный ущерб
Я упомянул эмоциональный ущерб. Если ваши близкие друзья связаны с проектом, и окажется, что они виноваты в какой-либо оплошности? Готовы ли вы рискнуть вашей дружбой ради правды? В самом начале моей карьеры я работал в одной организации, и там проходила ревизия работы подразделения. В отчете на десятки страниц была одна строка, которая стала точкой в карьере одного руководителя. Проводивший ревизию человек был близким другом руководителя подразделения. Он, наверное, боролся с собой оставить или нет эту строку в отчете на протяжении нескольких дней. Фраза была примерно такой: "Реализованные мероприятия не соответствовали утвержденному годовому плану из-за недостаточного управленческого надзора за деятельностью отдела".
Руководитель подразделения был перемещен на должность с примерно таким же названием, но по значимости даже близко не стоящей к предыдущей. Это было во времена, когда увольнения по сокращению штатов было последней мерой, а не частью нормального бизнес-цикла. С точки зрения корпорации это, возможно, было правильным решением, но эти двое никогда больше не разговаривали.
Стиль управления
Спасательная операция не обязательно сопровождается демократическим стилем принятия решений. Когда корабль тонет, никто не собирает комитет по распределению спасательных шлюпок и определению способов латания пробоин. Человек, который призывнее всех кричит "За мной!" скорее всего и будет лидером. Кто-нибудь, кто берет командование на себя и возглавляет передний край борьбы является идеальным кандидатом в большинстве ситуаций.
Но есть и исключения. Если проблемы возникли из-за разрушенных отношений и нарушенной коммуникации, подход, основанный на совместном принятии решений может оказаться наиболее эффективным. Перед стартом вы должны понимать, хотя бы на самом высоком уровне, в чем корень проблемы.
Необходимые навыки
Для проведения диагностики требуются более выраженные по сравнению с обычными руководителями проектов навыки. Вы должны спросить себя, а достаточно ли у вас способностей для того, чтобы согласиться на эту работу. Как кто-то сказал мне однажды: "Достаточно сложно даже просто собрать команду проекта, но намного хуже комплектовать команду для проведения ревизии . Если они потерялись, у них все еще есть шанс найти дорогу домой, но если ты укажешь им дорогу в неправильном направлении, то они точно потеряны навсегда".
Навыки управления проектами
Вряд ли есть необходимость указывать, что человек, который проводит ревизию скорее всего должен быть очень опытным руководителем проектов. Он должен обладать как теоретическими знаниями, так и практическими навыками, чтобы понимать, куда и на что смотреть в проекте. Он должен иметь четкое представление об инфраструктуре проекта. Инфраструктура проекта - это все поддерживающие организацию инструменты, процессы и шаблоны.
Навыки проведения интервью
Если что-то пошло не так, то скорее всего, кто-то захочет это скрыть. Еще более вероятно, что некоторые вопросы люди захотят пропустить мимо ушей и уж тем более не захотят на них отвечать. Ревизор должен быть искусен в извлечении информации и уметь проводить перекрестные проверки. Вот некоторые примеры вопросов, которые вы, возможно, захотите добавить в свой репертуар.
Это мнение или факт?
Как это можно подтвердить?
Какая документация необходима для понимания проекта?
Кто хорошо работал в проекте? Вы ничего не сказали про Х?
Когда вы впервые подумали, что проект срывается?
Какие значительные трудности были между проектом и бизнесом?
Насколько заинтересован был Х в проекте в самом его начале?
Сильно ли менялся результат/содержание/сроки?
Что надо было бы делать по другому?
Что нужно сделать для воскрешения проекта?
Уверен ли спонсор/управляющий комитет/руководитель проекта в большинстве людей?
Что изменилось в окружении с начала проекта?
Нужно ли прекратить проект?
Навыки ведения бизнеса
Множество проектов ломаются из-за несоответствия целей между проектной командой и бизнесом. Если это ИТ проект, и ревизор смотрит на него со стороны ИТ, ревизия может не получить поддержку со стороны бизнеса. Ревизор должен быть отстранен от обоих лагерей, и зачастую именно поэтому этим человеком чаще всего является консультант.
Навыки письменной речи
Критичным является навык четкого и сжатого изложения информации в письменном виде. Отчеты такого рода - основные кандидаты на творческое переосмысление и неверную интерпретацию. Автор обязан однозначно указать на факты и не оставлять никакой возможности для неверной интерпретации.
Смелость
Смотреть на проект в кризисе - занятие не для слабохарактерных. Спросите себя перед тем, как согласиться: "Если я решу, что проект должен быть остановлен, хватит ли мне смелости донести эту точку зрения до спонсора или того, кто будет принимать решение?"
Вы скорее всего столкнетесь со всеми видами противостояния людей, у которых есть интересы в проекте либо просто по причине личной привязанности и высоких вложений своих сил в проект. Возможно, вам потребуется твердо выстаивать против нажима различных сил. Если вы не верите, что сможете это сделать, лучше откажитесь от возглавления попытки восстановления, а возможно и от проведения ревизии.
Заключение
Может показаться, что слишком много внимания уделено подготовке к спасательной операции, но я надеюсь, что вы увидите, что такого рода предприятия не стоит воспринимать беззаботно. Для определения того, можно ли спасти проект, требуются определенный набор навыков. В следующей части статьи будет описание того, что же на самом деле надо сделать.
Часть 2. Подготовка
Обзор
Это вторая статья по управлению кризисными проектами. В ней описано, как проводить диагностику проекта для определения, что же конкретно произошло в проблемном проекте. Также приведен чек-лист, на что нужно смотреть в ходе обычной диагностики или пересмотра проекта.
Структура
Меньше всего при проведении диагностики вы захотите ходить вокруг да около и тыкаться куда попало. Это завершится примерно с тем же успехом, как покупка первого попавшегося подержанного автомобиля. Если вы просто попинаете шины и посмотрите уровень масла, заглянете под капот, то вряд ли при покупке у вас будет полная уверенность в том, что автомобиль стоит своих денег. А если вы проведете профессиональную проверку - подвеску, тормоза, двигатель, коробку передач, чехлы, покраску и т.д. - вы скорее всего определите неисправности, которые надо будет устранить.
Для того, чтобы провести оценку статуса проекта, вам нужна определенная структура работы. PMBOK дает неплохую основу для подхода. Есть еще и другие аспекты, требующие рассмотрения, но приведенный здесь чек-лист обеспечит вам основными вопросами и укажет на области обследования для того, чтобы понять, что же нужно исправить.
Вопросы, приведенные ниже, логически сгруппированы по областям обследования. У всех организаций будет своя специфика, и вопросы, посвященные ей, добавятся в этот список.
Содержание
Содержание было хорошо определено на старте проекта?
Есть ли процесс по изменению содержания?
Есть ли отклонения, не прошедшие через этот процесс?
Может ли команда определить суммарное влияние на сроки и стоимость по всем таким отклонениям?
Отслеживается ли факт против плана/оценок для отклонений?
Был ли план проекта изменен, чтобы снабдить проект необходимыми ресурсами для реализации изменений?
Стоимость
Есть ли система отслеживания затрат?
Отслеживаются ли затраты?
Есть ли затраты, которые отслеживаются неправильно?
Вовремя ли отслеживаются затраты?
Сверяются ли затраты с корпоративным планом счетов?
Есть ли прогнозы по стоимости проекта на момент его завершения?
Все отклонения по стоимости одобрены в письменном виде?
Сроки
Есть ли достаточно подробное расписание проекта?
Оно актуальное?
Оно соответствует текущему содержанию проекта?
Используются ли контрольные точки для отслеживания хода реализации?
Достаточное ли количество контрольных точек по ходу проекта для отслеживания проекта или в расписании есть недели, когда контроль отсутствует?
Отслеживаются ли трудозатраты через систему табелирования и учета рабочего времени?
Существует ли устойчивый и реалистичный план для оставшейся работы?
Качество
Есть ли план управления качеством?
Предметы поставки принимаются согласно плану по качеству?
Какие действия происходят после аудита качества и отслеживается ли их выполнение?
План проекта предусматривает время на переработку и устранение дефектов по результатам аудита качества?
План приемки и тестирования реалистичен (есть стратегия тестирования, план и тест-кейсы)?
Правильные ли люди выделены для проведения тестирования и приемки?
Тестирование и приемка включает в себя систему, ее характеристики и интерфейсы?
Ресурсы
Ресурсов достаточно?
Они правильные?
Они в состоянии работать над проектом достаточное время?
Есть ли чувство хорошего взаимодействия в проекте?
Команда управляется хорошо?
Ресурсы используются эффективно?
Хороший ли рабочий настрой в команде проекта?
Коммуникация
Есть ли план по коммуникациям?
Он реализуется?
Как определялись ключевые стейкхолдеры?
Все ли ключевые стейкхолдеры определены?
Чувствуют ли стейкхолдеры, что их держат в курсе?
Есть ли общие области в коммуникации, которые вызывают опасения?
Приведет ли проект к изменениям в организации и есть ли план по управлению ожиданиями?
План реализуется и ожидания отслеживаются?
Закупки
Используются ли внешние ресурсы?
Есть ли актуальные договоры, по которым работают внешние ресурсы, до завершения проекта?
Есть ли план по использованию этих ресурсов после окончания плановой длительности проекта, в случае необходимости?
Требует ли проект закупки оборудования, установок, программного обеспечения, и если да, то есть ли план по проведению переговоров по договору?
Уровни и полномочия по согласованию договоров и сроки подписания понятны и включены в план проекта?
Риски
Есть ли актуальный план по управлению рисками?
Стейкхолдеры были привлечены к разработке плана?
Стратегии уклонения существуют и отслеживаются?
Проводится ли регулярный аудит рисков?
Есть ли журнал проблем?
Решение проблем отслеживается до полного разрешения?
Процесс эскалации проблем существует? Он работает?
Мероприятия по сдерживанию
Есть ли план по сдерживанию последствий, если реализация не укладывается в сроки?
План сдерживания подписан всеми заинтересованными сторонами?
План испытан?
Последствия реализации сдерживающих мероприятий понятны руководству?
Какие сроки по реализации плана сдерживающих мероприятий?
В течение какого срока будет действовать план сдерживания? Что случится потом?
Эффекты
Какие эффекты были определены на старте проекта?
Они пересматривались недавно?
Они все еще актуальны?
Были ли идентифицированы новые эффекты и включены ли они в результат проекта?
Измеряются ли и будут ли измеряться эффекты?
Определены ли ответственные за реализацию и использование эффектов?
Бизнес-процессы
Повлияет ли проект на бизнес-процессы?
Рассчитывает ли на них бизнес?
Когда и как они будут изменены?
Мы знаем, что они заработают?
Какое влияние они окажут за пределами компании?
Эти изменения запланированы?
Обучение
Есть ли план обучения?
Заложено ли время на производство обучающих материалов?
Тренеры определены?
Персонал будет доступен для обучения?
Есть ли план проведения пилотного обучения?
Реализация
Есть ли план реализации проекта по месту (предполагая, что проект идет по плану)?
Поддержка будет оказываться во время и после запуска?
Кто даст разрешение на ‘go live’?
Есть ли критерии ‘go live’?
Если реализация подразумевает преобразование данных, известно ли состояние этих данных?
Требуют ли данные работы с ними и был ли этот процесс протестирован?
Подотчетность
Определены контрольные точки, в которых управляющая группа определит, соответствует ли проект корпоративным стандартам? Конечно, диагностика является такой точкой, но обычно проект должен пройти один или несколько гейтов, в которых должны быть выполнены определенные критерии.
У команды проекта есть все необходимые инструменты, навыки и процессы для успешной реализации проекта?
Кто отслеживает комплаенс (соответствие внутренним корпоративным нормам, регламентам, этике и т.п.)?
Если у компании есть методология, придерживается ли ее команда проекта?
Роли и ответственность
Четко ли обозначены зоны ответственности?
Достаточно ли точно они отражают то, что происходит по факту?
Бизнес обеспечивает необходимый уровень поддержки?
Достаточный ли уровень поддержки оказывает руководство?
Есть ли какие-то участки работы, которые не описаны в ролях и ответственности?
Документация

Хранится ли вся документация по проекту в централизованном хранилище?
Хорошо ли организовано хранилище и легко ли найти необходимый документ?
Наличествует ли корректная система контроля версий?
Основные документы обычно хорошо составлены?
Повестка и протоколы ключевых собраний ведутся и хранятся?
Ключевые решения подписаны уполномоченными лицами?
Есть ли словарь/глоссарий проекта?
Есть ли реестр принятых решений?
Требования
Требования хорошо документированы?
Есть ли система отслеживания требований и их изменений?
Предметы поставки соответствуют документации по требованиям или преображаются в ходе разработки?
Документируются ли причины и утверждающие лица при изменении требований?
Проведение очных встреч
1. Кто был на вашем последнем собрании? Когда вы в последний раз общались со стейкхолдерами из подготовленного на старте проекта короткого списка?
2. Как вы управляете собой? Сколько времени в неделю выделено на управление собой? Опишите свою систему управления задачами.
3. Какой план коммуникаций в проекте? С какими участниками есть регулярные очные
встречи? С какими далекими от вас участниками и заинтересованными сторонами вы регулярно списываетесь в чате или разговариваете по телефону? Повестка ваших встреч и обсуждений?
4. Когда в последний раз с ними общались? Сколько баллов по 10-балльной шкале вы поставите себе за содержательность и структурированность последней беседы? Что можно улучшить?
5. Посвящена ли каждая встреча только одной теме? Не размыта ли повестка? Достаточно ли все концентрируются на предмете, чтобы достичь понимания и найти устраивающее всех решение?
6. Какие интересы у участников? Какие у них KPI? Какие рычаги влияния на их поведение есть у вас или спонсора проекта?
7. Ведете ли вы личные дела сотрудников? Фиксируете ли вы их характеры, особенности поведения, сильные и слабые стороны? Ведете ли вы список задач, которые можно и нельзя им доверять? Можете ли вы ответить на вопрос, почему надо управлять этим сотрудником? О чем с ним говорить? Как с ним надо говорить? Где с ним говорить? Подстраиваете ли вы график встреч и бесед с ним, так, чтобы ему было удобно и он не торопился домой или по другим делам?
8. Какие темы для еженедельного разговора у вас есть? Какие проблемы (расхождения между желательным и действительным) есть? Что мешает решить проблемы?
9. Общение с кем вы уделяете больше времени и почему? Подсказка – чем более способный и талантливый человек, тем больше ему надо уделять внимания.
10. Следуете ли вы при общении схеме «Мои ожидания от вас-Вот какие результаты я ожидаю-Вот что будет считаться успехом-Вот что будет считаться неудачей-Вот какие будут последствия плохо сделанной работы-Обратная связь по выполненной работе».
11. Понимают и осознают ли сотрудники последствия плохо выполненной работы для проекта и для них лично? Предоставил ли спонсор проекта вам право на письменную оценку эффективности работы персонала, выделенного на проект? Вы внесли задачу по проведению этой оценки в список задач по проекту? Знают ли участники проекта о том, что эта оценка будет проведена? Оценка будет направлена линейному руководителю, директору по персоналу и спонсору проекта?
12. Регулярно ли вы обсуждаете общий план-график и расписание проекта с ключевыми участниками? Понимают ли они последствия сдвига сроков по выполнению задач на общие сроки проекта? На все ли ближайшие задачи по плану-графику выделены и подтверждены ресурсы?
13. Какие ресурсы нужны для выполнения задач? Используете ли вы при обсуждении стандартный список ресурсов:
a. Рабочее пространство
b. Снабжение
c. Материалы
d. Оборудование
e. Транспортировка
f. Информация
g. Производственный процесс
h. Техническое обслуживание
i. Персонал
j. Таланты/Компетенции, м.б. внешние
k. Тренинги
l. Коммуникации
m. Конкретный сотрудник
14. Кто может сказать, есть ли в наличии нужный ресурс? С помощью какого процесса можно получить этот ресурс? Ожидаемое время поставки ресурса. Что вы должны сделать, если столкнетесь с проблемами при получении ресурса? Все ли участники проекта знают про процесс запроса и получения ресурса? Знакомы ли они с ключевыми людьми, отвечающими за процесс предоставления ресурса?
15. Содержит ли запрос на получение ресурса следующие пункты?
a. Что я заказываю?
b. Для кого и зачем я это заказываю? В чем польза?
c. Какие затраты на выполнение заявки? Деньги, время. Чьи это затраты, когда они будут?
d. График выполнения заявки. Дедлайн, основные этапы обработки выполнения, ресурсы на обработку заявки.
e. Есть ли План Б, если ресурс не будет получен? Какие есть альтернативные источники поставки ресурса? Какие есть возможности по возможностям замены ресурса? Есть ли способ выполнить работу без этого ресурса? Можно ли увеличить сроки и стоимость выполнения работ, если ресурс не будет получен?
16. Есть ли повторяющиеся проблемы? Если они есть, то есть ли процедура, политика, стандарт или регламент, описывающий процесс решения проблемы? Какие необходимые ресурсы для решения проблемы есть у подчиненного? Границы импровизации при решении проблемы. Как принять наилучшее решение? Есть ли детальный пошаговый план решения проблемы? Прослеживается ли исполнение плана решения проблемы совместно с командой?
В заключение
Есть и другие области, которые необходимо будет рассматривать, и этот список, в большинстве случаев, покрывает, наверное, от 70 до 80%.
Часть 3. Спасти рядового Райана
В первой части обсуждалась личность человека, спасающего проект. Во второй был приведен список тем, которые необходимо отработать. В этой третьей и заключительной части, посвященной конкретно самой операции мы рассмотрим, что же на самом деле необходимо сделать.

Кто тут главный?
Первая вещь, с которой необходимо разобраться, это то, кто руководит проектом. Мы не ищем менеджера проекта, а скорее спонсора. Человека, который подписывает договора. Человека, который может остановить проект, если это потребуется.
Как-то я разговаривал с консультантом, который выполнял работу для большой политической партии и разрабатывал рекомендации по тому, как ее лучше организовать. Большое количество финансовых доноров были обеспокоены тем, что текущая организационная структура является причиной потери популярности. Он ответил донорам, что приняться за работу только в том случае, если это будет с согласия первого лица партии. И он говорил не про человек с должностью, наиболее близкой к этому описанию, а о том, кто реально держал бразды правления.
На эту роль подходило несколько кандидатов. Одним из них был премьер-министр. Глава партии был другим. Была еще пара очень влиятельных спонсоров, которых тоже стоило рассматривать. Как и в большинстве партий, в этой были и финансисты, которые обладали невероятным влиянием на то, как партия управлялась. Они знали, в каких шкафах лежали скелеты и разные деликатные подробности того, как они там очутились.
Он искал, кто же, по общему мнению, был тем, кто рулил и жал на газ. Он летал по всей стране на партийные собрания с функционерами и со всеми перечисленными выше лицами и пытался достичь соглашения. После двух лет поисков он так и не приблизился к пониманию и отказался от предложения. Он сказал: "Если мы не можем договориться, кто же ведет это представление, как вообще можно задумываться о его реорганизации?"
Вам нужно определить, кто в проекте дергает за веревочки, даже если некоторые из них и обветшали. Обычная тактика в таких случаях - показать на комиссию. Мой ответ в таких случаях - а кто отвечает за комиссию? Кто председатель? Кто утверждает решения? Кто может отменить решение большинства? Вы должны найти этого человека.
Содержание проекта
Следующий шаг - это определение содержания. Обычно состоит из двух частей:
Какое было содержание, когда проект начинался
Какое представление о содержании проекта сейчас
Очень часто здесь кроется корень всех проблем. На самом деле совершенно типично, когда по поводу того, что же входит в содержание, согласия нет и в помине. В ряде наших других статей эти проблемы подробно описаны, так что мы не будем останавливаться на том, как надо определять содержание. Если по поводу содержания есть различные точки зрения, выпишите их все и найдите различия.
Решение проблем с содрежанием
Если есть неразрешенные проблемы с содержанием, сейчас самое время их решить. Это может проходить через переговоры с ключевыми стейкхолдерами либо можно просто спросить человека, отвечающего за проект. Пока вы не решите, что же вы хотите сделать в проекте, остальной анализ бесполезен.
Я всегда устанавливаю ожидания в этом месте, описывая документ как "рабочее содержание". Другими словами, это не окончательно согласованное содержание проекта, а скорее текущая оценка того, что будет получено в этом проекте. Содержание может значительно меняться по мере определения дополнительных факторов. Например, уровень усилий, необходимый для реализации содержания полностью, может быть неприемлем для организации. Содержание может быть урезано. Проект может быть разбит на подпроекты. Если вы хотите двигаться вперед, по поводу содержания необходимо делать предположения. Эти предположения надо проверять или изменять, и развивать предложение по дальнейшим шагам.
Ожидания и реальность
В то же самое время вы можете начать записывать что люди ожидают и какова реальность. Цель этого упражнения - это определение различий в восприятии различных людей, попадающих в сферу влияния проекта.
Вот пример:
Кто владелец: Клиентский отдел
Ожидание: Проект завершится к Августу
Реальность: Проект будет идти до конца года
"Д. Смит.; система будет обрабатывать возвраты; будут обрабатываться возвраты только для клиентов категории А"
"Команда проекта; бизнес-пользователи будут доступны минимум 3 дня в неделю; бизнес-пользователи доступны крайне редко"
Цель создания этого списка - свести вместе все невыполненные ожидания, которые и создали ощущение, что проект находится в кризисе. Возможно, проект и не в кризисе. При правильном управлении ожиданиями люди могут быть удовлетворены направлением движения и результатом.
Решение проблем
Есть искушение решать проблемы по мере их выявления. Это скользкая дорожка, ведущая к зыбучим пескам. Даже спасательные миссии могут провалиться, если их затянуть. Определите проблемы, но тратьте времени на их решение. Очевидные пути решения часто слишком примитивные и никогда не работают. Как только вы начнете реализовывать простые решения, вы погрязнете в технических деталях, которые окажутся под водой.
Во время одной спасательной операции с самого начала было понятно, что наибольшей проблемой было то, что не были приняты 15-20 основных решений. Значительное количество работ по проекту стояли в ожидании принятия этих решений. Большинство из них касалось достаточно сложных проблем и ситуаций, но все-таки некоторые из них стали жертвой неправильной расстановки приоритетов. Люди тратили все свое время на решение сложных и больших проблем, не уделяя малым никакого внимания. Было искушение выделить время на решение этих малых проблем проблем во время ревизии. К счастью, я устоял против этого искушения и быстро завершил анализ.
Моя рекомендация была остановить проект на неделю-другую и провести серию рабочих совещаний, на которых бы присутствовали главные лица, принимающие решения, и где были бы решены все найденные на данный момент вопросы. Рабочие совещания проводились по принципу суда присяжных - никто не имел права выйти с совещания, пока решение не было принято. Конечно, это привело к тому, что топ-менеджмент посвятил проекту все свое время на несколько дней. Это имело свое воздействие на скорость принятия решений.
Для принятия некоторых решений потребовалось менее часа, но одно заняло более двух дней. Никто не покидал совещания по распоряжению генерального директора, который сказал сидеть до последнего. Внедрение ERP зачастую требует такого от компании. Смысл моего рассказа в том, что не пытайтесь решить все проблемы с первого раза. Соберите факты как можно скорее, затем ищите решения. Помните, что люди ждут, пока вы не построите им курс. Чем дольше они ждут, тем больше вероятность, что они откажутся следовать вашим рекомендациям.
При поиске проблем используйте чек-листы и вопросы из первых двух частей статьи. Аспекты бизнеса и технические моменты будут различаться от проекта к проекту. Например, при ремонте здания, вопросы будут касаться строительных материалов, доступа в здание, архитектурных чертежей, одобрений юристов и т.п. При производстве программного обеспечения, вопросы бизнеса могут касаться юридических моментов, бизнес-процессов, маркетинга, а технические аспекты относиться к безопасности, хранению данных и апгрейду оборудования. Вам нужно создать свой чек-лист для каждого из проектов.
Игра "Кто сидеть будет?"
Неизбежна ситуация, при которой одни люди будут обвинять других за то, что проект дошел до точки. Такие обвинения редко приводят к разрешению кризиса. Цель этой техники - замутить воду и перенести внимание из будущего в прошлое. Избегайте обсуждений кто в чем виноват, но используйте эту информацию как фильтр для интерпретации получаемой информации.
Я интервьюировал двух людей при аудите реализации проекта. Их обоих я видел в первый раз в роли независимого аудитора. Было трудно поверить, что они описывают один и тот же проект. Они оба обвиняли друг-друга за то, что проект превысил бюджет и сорвал сроки. Каждый представил набор фактов (и немного выдумки) таким образом, что вы бы уволили второго за некомпетентность, если бы имели только свидетельство одной стороны. Истины находилась посредине, или немного в сторону от центра. И потребовалось несколько других интервью для определения, что же произошло на самом деле.
Всегда помните, что все, что вы слышите, искажено чувством самозащиты и веры людей в то, что их способ выполнять работу является самым верным. Каждый будет видеть ситуацию несколько односторонне. Слушайте, что вам говорят, но спрашивайте себя, почему они это говорят.
И последнее, что я хочу сказать на тему вины. Ищите исходную причину. Кто-то назначил некомпетентного менеджера проекта. Почему его назначили? В приведенном выше примере, менеджер проекта не имел достаточно опыта для управления крупным сложным проектом. И хотя он допустил множество ошибок, исходная причина была в том, что менеджер по реализации проекта организации не обладал достаточным количеством квалифицированных ресурсов для проекта. Все это явилось следствием того, что компания имела политику не нанимать менеджеров проекта по контракту и не позволяла тратить достаточное количество денег на найм квалифицированного постоянного штата. Поверх этого наложилась проблема с недостаточным бюджетом на обучение. Мои рекомендации не включали в себя увольнение менеджера проекта, они заключались в следующем: увеличить бюджет на обучение, платить менеджерам проектов рыночные ставки и нанять пару опытных менеджеров проектов, которые могли бы обучать текущих менеджеров проектов.
Для определения проблем необходимо понять, что пошло не так. Как только вы определили причины, по которым проект оказался в кризисной ситуации, вы можете добавить эти причины в список проблем.
После определения содержания
После того, как вы определили содержание, нужно обратить свое внимание на план и ресурсы. Какие ресурсы есть в наличии, и на какие ресурсы еще надо получить одобрение? На этой стадии полезно сделать несколько сценариев. Например, с двумя людьми, которые есть сейчас, работа будет завершена за три месяца, если добавить еще один ресурс, можно справиться за два.
Как только план готов, можно оценить его стоимость. Если было разработано несколько планов, надо обсчитать их все. Вернитесь к начальному бюджету и проанализируйте расхождения по статьям расходов. На этом шаге более вероятно, что вы сможете протолкнуть идею управленческих резервов. Например, предположим, что в проекте было изначально заложено 20 тыс. долларов на тестирование программного обеспечения, но оно оказалось намного сложнее, чем ожидали, и тестирование вызвало задержку. Вы можете заложить в бюджет 25 тыс. и добавить 10 тыс. управленческого резерва, т.к. у вас нет понимания сложности задачи. И до тех пор, пока вы не поймете задачу полностью, вы не сможете оценить затраты на нее. Обжегшись один раз, организации обычно более консервативной подходят к оценке предстоящих затрат.
Другой важный момент – это пересмотр ролей и ответственности при планировании. Мало сказать, что вы хотите тестировщика, если вы под ним подразумеваете человека с определенным набором навыков, а лицо, принимающее решения, считает, что для того, чтобы проводить тестирование, достаточно иметь пульс.
Эффекты
Предположим, что в какой-то момент проект подразумевал получение каких-то эффектов. Вы должны пройтись по эффектам и проверить, имеют ли они какой-то смысл. Также обратите внимание на эффекты, которые не были идентифицированы в начале проекта. Иногда, по мере развития проекта, становятся очевидными новые эффекты.
Черновик отчета
К этому моменту у вас должен быть:
Идентифицирован ключевой игрок. Человек, который принимает решения или по крайней мере, дает рекомендации исполнительному комитету либо совету директоров.
Понимание содержания проекта – начальное и текущее, согласованное участниками.
Список ожиданий и реальности и различия между этими двумя
Определены основные проблемы и открытые вопросы, мешающие ходу проекта
Определены роли и ответственность, необходимые для продолжения проекта
Один или несколько рабочих планов для завершения проекта
Новый расчет затрат и эффектов
Теперь вы можете давать рекомендации. Никогда не сбрасывайте со счетов варианты «ничего не делать» и «отменить». Иногда вы обнаружите, что настоящей проблемой является различия между тем, что люди верят, должно произойти и тем, что на самом деле должно произойти. Если проблема в том, что все ожидают завершения проекта за 6 месяцев, в то время, как он будет идти еще 12, то решением может быть смириться с 12 месяцами. Проблема в том, что делать с ожиданиями по 6 месяцам. Проект может идти как идет, но нужно провести коммуникацию, которая объяснит почему проект займет в два раза больше, чем было запланировано.
И точно также, не стоит оставлять в живых проект только из-за того, что люди с ним эмоционально связаны. Играйте в адвоката дьявола, спрашивайте людей: «Почему нужно продолжать проект?»
Если не найдется хорошей, ориентированной на бизнес, причины, то выдвигайте рекомендацию с отменой. Даже в стадии рекомендации вариант «отменить проект» может быть приемлем и должен рассматриваться. Реальность многих организаций такова, что никто не хочет принимать сложное решение. Если среди вариантов, которые вы предложите, будут только варианты с продолжением проекта, люди, которые думают, что проект надо отменить, будут бояться что-нибудь говорить, т.к. они могут подумать, что это отразится на их карьере. Ваша задача – обсудить все возможные варианты.
После принятия решения
После того, как решение принято, вы столкнетесь с тем, что надо учесть массу человеческих факторов.
Нужно будет заменить ресурсы либо получить на проект новые ресурсы. Запомните, это не военный трибунал. Если нужно кого-то убрать с проекта, сначала поговорите с ним, и позвольте уйти с достоинством. Подумайте, как вы объявите об уходе.
«Билл покидает нас, потому что у него не хватает навыков для управления проектом. Да и вообще, Билл херовый проектный менеджер и поэтому его и увольняют».
Или
«Проект оказался намного сложнее, чем мы ожидали и теперь, принимая во внимание новые сроки, от нас потребуются сверхчеловеческие усилия. Нам посчастливилось нанять на этот проект Супермена. Большое спасибо Биллу, который вел проект до этого момента под давлением этих невероятно сложных обстоятельств. Мы попросили его ввести Супермена в курс дела перед уходом».
Помните, что Билл скорее всего пытался сделать все, от него зависящее, но ожидания по его работе просто превышали его способности.
Другой фактор, требующий рассмотрения, это рабочий настрой команды. Когда в проект приходят аудиторы, то вполне вероятно, что мораль команды будет невысокой и даже могут образоваться фракции. Есть много способов решения проблем с рабочим настроем, но мой любимый способ – это дать понять, что командой слишком долго пренебрегали и теперь руководство признало важность происходящего. Обычно я объясняю лицам, принимающим решения, что они руководители и сейчас правильный момент, чтобы начать руководить. Это означает, что они должны найти время на то, чтобы поддержать настроения участников проекта.
Другим вариантом может быть ужин, организованный спонсором проекта для команды, посещение им проектных совещаний, разговоры с участниками об их вкладе в проект, вознаграждения (все, что угодно, от билетов в кино до бонусов), обратная связь о ходе реализации, чтение еженедельной отчетности и самых важных документов. Полезно также определить, что делает эту команду отличающейся от других. Однажды я организовал для команды проекта особые места на парковке ближе к зданию, т.к. они надолго задерживались по вечерам. Это ничего не стоило для организации, разве что цену краски для разметки парковочных мест «Зарезервировано для команды проекта». Зато мораль взлетела до небес.
Реализация
Если проект продолжается, соберите команду проекта и лиц, принимающих решения вместе минимум на один день. Убедитесь, что все понимают:
- Свои роли и ответственность, включая все изменения
- Содержание проекта
- Согласованный план, включая контрольные точки
- Способ контроля исполнения плана
- Вовлечение и поддержка со стороны топ-менеджмента
- Текущие трудности и планы по их преодолению
- План коммуникации по управлению ожиданиями
Скорее всего, потребуется еще больше планирования, но «план по составлению плана» будет частью движения вперед. Если следующую неделю придется потратить на планирование, объясните как пойдет процесс и кто будет вовлечен. Организуйте еще одно рабочее совещание, когда план будет готов.
Заключение
Вернуть контроль над проектом, потерявшим управление, нелегкая задача. Вам будет нужна структура, прежде чем вы приняться за работу, иначе вы будете погребены под грудой «самых важных фактов и мнений» при попытке разобраться в проблемах. Кризисное управление требует особых навыков. Оно требует умения не отвлекаться на то, что было и лучше всего поручать эту работу кому-нибудь со стороны, лучше всего, вообще не из этой организации. Кого-нибудь, кто способен бесстрастно разобраться в ситуации и дать рекомендации по выполнению целей проекта. Эта статья дает представление, как это сделать. Конечно, в реальности ничто никогда не пойдет как по писаному, но следуя описанному процессу, вы быстро поймете, в какой точке вы сейчас находитесь, и куда двигаться дальше, если вообще куда-то двигаться.
Дополненный перевод, оригинал Rescuing a project in crisis