На каждый вопрос ответ ДА/НЕТ.
Заполнять нужно тот раздел, в котором проект находится сейчас и все предшествующие разделы.
Если ответов «да» < 3/4 в любом из разделов – проект под угрозой.
Если ответов «да» < половины в любом из разделов – проект обречен.
Общее количество «да» по всем разделам не имеет значения. Чек-лист не учитывает отраслевой
специфики. Чек-лист не учитывает специфики проекта (например, наличие закупок, распределенная
команда – должны быть добавлены соответствующие пункты в каждый раздел).

В конце формирования первоначальных планов

1. планы формировались ПМ совместно с командой (или, по крайней мере, ключевыми сотрудниками команды)
2. при формировании планов были учтены усвоенные уроки предыдущих проектов
3. ключевые заинтересованные стороны активно участвовали в согласовании содержания и сроков
4. при формировании планов использовались оценки по аналогу
5. при составлении предварительных оценок использовалось мат. методы стандартное распределение, аппроксимация в виде оценок по трем точкам и т.п.
6. при составлении предварительных оценок использовалось имитационное моделирование
7. план проекта содержит 100% работы (допускается неглубокая декомпозиция)
8. точность первоначальных оценок находится в пределах от -10% до +25% или в более узких
9. план декомпозирован до глубины состояния, достаточной для достоверных оценок
10. на каждую запланированную работу – предполагается минимум 1 осязаемый результат (документ, блок функционала), нет работ типа «подумать над…», допускаются – «подумать и написать 1 абзац текста о результатах»
11. менеджер проекта согласен с установленными правилами изменения содержания, сроков, ресурсов и целей проекта
12. план соответствует целям и ограничениям проекта
13. план содержит контрольные точки (вехи), не менее 4 на год
14. идентифицированы главные риски проекта
15. неснижаемые значимые риски составляют <10%
16. разработаны план реагирования на значимые риски проекта
17. для каждого значимого риска был сформирован резерв, если он требовался
18. резервы проекта сформированы, в основном, на основе рисков (а не иным образом)
19. команде понятно «кто что делает сейчас?»
20. команде понятно «что делать дальше?» (а не «у кого спросить»)
21. команде и заказчику понятно как будет происходить контроль качества (в смысле – проверка соответствия требованиям)
22. непосредственным пользователям понятно кто, когда, каким образом и как часто будет вовлекать их, получать о них обратную связь по ходу проекта
23. формально сформулированы критерии закрытия проекта
24. критерии закрытия соответствуют целям и рамкам проекта
25. после завершения первоначального планирования проведен kick-off meeting, в результате которого все члены команды познакомились друг с другом и каждый однозначно узнал свою роль, а также то, что работы по проекту начались с этого дня

В ходе контроля проекта

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. команда проекта укомплектована на 100%
все члены команды имеют прямой доступ друг к другу (могут коммуницировать непосредственно, а
не через начальников)
преодолено стартовое торможение – пройдена стадия, когда ПМ подталкивает команду;
обсуждение и работы по проекту ведутся командой и направляются ПМ и тим-лидами
есть эмоционально вовлеченные в проект члены команды (имеющие существенное влияние в
команде)
менеджеру понятно, насколько выполнены планы (а не «кто может знать, насколько выполнены
планы») с точностью до 1 недели
результаты всех работ (осязаемые результаты и ссылки на них) сохраняются, время поиска членом
команды (не автором) составляет до 1 минуты
команда и отдельные члены команды согласны, что система поощрений и вознаграждений
адекватна их усилиям
на проекте регулярно проводятся ретроспективы и / или сессии
соотношение сработавших предвиденных и непредвиденных рисков 10 к 1 или меньше
риски регулярно переоцениваются (не реже 1 раза в 2 недели)
любые работы планируются и распределяются по проектам, результаты – документируются (за
исключением задач отнимающих до 5 минут времени)
исключено спонтанное повышение требований к продукту (добавить неплановую
функциональность или развить технические характеристики вне ограничений)
менеджер проекта несет и осознает свою ответственность за «продукт в срок»
тим-лиды несут и осознают свою ответственность за «работу в срок»
к рядовым членам команды не применятся «кнут» за срыв сроков, в отличие от тим. лидеров и
менеджера проекта
на проекте нет сотрудников, чья деятельность не поддается планированию и контролю
на проекте нет сотрудников, чью деятельность никто не проверяет и обеспечивает обратную связь
изменения содержания, сроков и ресурсов проекта не происходят в обход ранее установленных
правил19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. менеджер проекта имеет право сказать «нет» на любое изменение проекта высшим руководством
кроме досрочного закрытия проекта
больше 90% членов команды разделяет цели и ценности проекта
для сотрудников, в чьи обязанности не входит взаимодействие с внешними заказчиками – нет
дресс-кода
заинтересованные лица привлекаются к уточнению планов, анализу промежуточных результатов
проекта
все результаты проекта проходят внутренний контроль качества (члены команды поверяют работу
других членов команды)
все результаты проекта, адресованные конечным пользователям демонстрируются и
пользователям по мере возникновения и проходят внешний контроль качества (пользователи
проверяют работу команды)
все замечания в ходе контроля качества обрабатываются (не обязательно исправляются, но трезво
оцениваются, приоритезируются, ключевые – берутся в работу)
команда в конструктивном состоянии справляется с большинство возникающих в ней конфликтов
без помощи менеджера (ПМ – не нянька, но фасилитатор если нужно)
не ведется контроль показателей, которые прямо не влияют на результат работы (количество строк
кода, количество документов, количество времени на рабочем месте и т.п.)
ведется контроль эффективности (есть результат работы или нет) – на уровне отдельных
сотрудников или команд – на усмотрение менеджера проекта
исключена торговля словами («пряник» только если есть результат работы, а не за объяснения
«почему его нет, но скоро или в следующий раз будет»)
в случае затруднений на проекте команда и менеджер в первую очередь пытаются найти способ
выполнить его в срок доступными ресурсами, а не сдвинуть сроки и запросить дополнительные
ресурсы
если проект положено закрыть – он закрыт (возможно – при этом переведен в стадию
«поддержки»)
В ходе закрытия проекта
1. проекты, проблемы на которых нельзя исправить – закрываются и, возможно, перезапускаются с
новыми рамками
2. если проект закрывается успешно (а не внепланово), то закрытие это не сдача-приемка методом
«большого взрыва», а финальное закрытие договоренностей (все основные поставки уже были
переданы раньше, обратная связь получена, пожелания учтены, возможные изменения внесены)
3. при закрытии проекта учтено мнение ключевых заинтересованных сторон, среди которых учтено
мнение непосредственных пользователей
4. подведены итоги соответствия результатов проекта первоначальным целям, запланированным
содержанию, срокам, ресурсам
5. подведены итоги удовлетворенности основных заинтересованных сторон в результате проекта
6. подведены итоги фактической используемости результатов проекта непосредственными
пользователям
7. 8. 9. проведена ретроспектива проекта и зафиксированы усвоенные уроки по проекту
к фиксации усвоенных уроков было привлечено более 2/3 членов команды
проведен формальный «kicik-off meeting наоборот», в результате каждый членов команды точно
знает что проект закрыт, каков результат проекта, а также что работы по нему прекращены и его
(сотрудника) на данный проект привлечь больше никто не может
10. 11. каждый член команды получил личную обратную связь от ПМ по результатам проекта
система поощрений и вознаграждений отработала завершение проекта (если уместно – все
обещанные и уместные материальные и нематериальные поощрения, которые не были еще
вручены по ходу проекта – вручены здесь)
12. обеспечена невозможность привлечь ни одного из членов команды к выполнению работ по «уже
закрытому проекту» (исключение – работы «переданы на поддержку», т.е. официально
выполняются вне проекта или запущен новый проект и сформирована новая команда)

В ходе закрытия проекта
1. проекты, проблемы на которых нельзя исправить – закрываются и, возможно, перезапускаются с
новыми рамками
2. если проект закрывается успешно (а не внепланово), то закрытие это не сдача-приемка методом
«большого взрыва», а финальное закрытие договоренностей (все основные поставки уже были
переданы раньше, обратная связь получена, пожелания учтены, возможные изменения внесены)
3. при закрытии проекта учтено мнение ключевых заинтересованных сторон, среди которых учтено
мнение непосредственных пользователей
4. подведены итоги соответствия результатов проекта первоначальным целям, запланированным
содержанию, срокам, ресурсам
5. подведены итоги удовлетворенности основных заинтересованных сторон в результате проекта
6. подведены итоги фактической используемости результатов проекта непосредственными
пользователям
7. 8. 9. проведена ретроспектива проекта и зафиксированы усвоенные уроки по проекту
к фиксации усвоенных уроков было привлечено более 2/3 членов команды
проведен формальный «kicik-off meeting наоборот», в результате каждый членов команды точно
знает что проект закрыт, каков результат проекта, а также что работы по нему прекращены и его
(сотрудника) на данный проект привлечь больше никто не может
10. 11. каждый член команды получил личную обратную связь от ПМ по результатам проекта
система поощрений и вознаграждений отработала завершение проекта (если уместно – все
обещанные и уместные материальные и нематериальные поощрения, которые не были еще
вручены по ходу проекта – вручены здесь)
12. обеспечена невозможность привлечь ни одного из членов команды к выполнению работ по «уже
закрытому проекту» (исключение – работы «переданы на поддержку», т.е. официально
выполняются вне проекта или запущен новый проект и сформирована новая команда)