Постановка практики трекинга

При запуске трекера допускают две основные ошибки:

1)    Не определяют процесс управления задачами и схему поддержки трекера, включая процедуры планирования, изменения и закрытия задач и проектов, шаблоны, индивидуальные планы работ, чек-листы запуска и закрытия проектов, проектных аудитов и связи трекера с Outlook и Exchange;

2)    Не обучают дисциплине управления задачами. Это может быть GTD, 18 минут, одноминутный менеджмент или сборная техника, например, пустой инбокс.

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

Про дисциплину не буду распространяться, книжек и вебинаров на эту тему предостаточно. Стоит только помнить – ограничивайте WIP (work in progress, количество одновременно исполняемых дел) и ставьте очень конкретные задачи.

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

Предельно упрощенные чек-листы Эссенс

Представители заказчика
Определены	1. Роли и ответственность представителей заказчика были определены 2. Есть конкретные люди, которые согласились исполнять эти обязанности 3. У назначенных на проект людей есть все необходимые полномочия для исполнения обязанностей 4. Принципы совместной работы определены
В согласии	1. Представители заказчика ходят на собрания и активно участвуют в решение вопросов по проекту 2. Представители заказчика выполняют все возложенные на них обязанности 3. Представители заказчика своевременно общаются с командой, дают обратную связь и принимают необходимые решения 4. Представители заказчика согласны с выставляемыми приоритетами
Удовлетворены	1. Представители заказчика согласовали минимальные ожидания к продукту проекта 2. Представители заказчика обеспечивают обратную связь по использованию продукта проекта 3. Представители заказчика согласны принять продукт проекта 4. Ожидания представителей заказчика были удовлетворены
Возможности и Бизнес-кейс
Определены	1. Спонсор видит возможность и хочет инвестировать ресурсы в исследование проблемы и поиск решения 2. Проблема, которую решает проект ясна, понятны ее корневые причины 3. Найдено как минимум одно решение проблемы
Польза ясна	1. Польза от успешного решения проблемы установлена и посчитана 2. Влияние реализованного проекта на представителей заказчика и на бизнес компании понятно всем 3. Все представители заказчика согласны с бизнес-кейсом и готовы реализовывать проект
Адресованы	1. Решение выбрано и стоимость его реализации, обслуживания и поддержки на пять лет посчитаны 2. Есть оценки, показывающие, что решение может быть разработано и развернуто в рамках заданных ограничений 3. Риски находятся под контролем 4. Есть пилотный проект либо практическая реализация, показывающая, как выбранное решение решает проблему
Эффект достигнут	1. Есть готовый к использованию продукт 2. Представители заказчика удовлетворены тем, как продукт реализует возможность, описанную бизнес-кейсом 3. Итоговый бизнес-кейс одобрен спонсором
Требования к продукту
Понятны в общем	1. Назначение и состав продукта согласованы всеми представителями заказчика 2. Критерии успешности проекта утверждены спонсором 3. Ключевые предположения и ограничения проекта определены, зарегистрированы и донесены до представителей заказчика на совещании по запуску проекта
Понятны полностью	1. Большая картинка и общая презентация по продукту согласована всеми представителями заказчика и командой 2. Основные сценарии использования продукта конечными пользователями определены 3. Приоритеты требований ясны 4. Требования описывают продукт, который представители заказчика считают приемлемым для дальнейшего использования
Выполнены	1. Польза продукта ясна 2. Достаточное количество требований было реализовано для того, чтобы считать, что качество продукта приемлемо 3. Представители заказчика готовы начать использование продукта 4. Продукт полностью соответствует изначально определенным требованиям
Продукт
Концепт выбран	1. Выбранная концепция снижает ключевые риски технической реализации и исполнения проекта 2. Критерии выбора концепции согласованы 3. Платформы, технологии и партнеры выбраны 4. Решения по покупке, самостоятельной разработке или повторному использованию элементов приняты
Можно использовать	1. Критичные интерфейсы и основные элементы продукта реализованы 2. Продукт можно использовать и его качество отвечает потребностям 3. Конечные пользователи могут использовать продукт 4. Функциональность и технические характеристики продукта протестированы и приняты представителями клиента 5. Уровень дефектности удовлетворителен
Готов	1. Пользовательская документация доступна 2. Представители клиента приняли продукт и хотят запустить его в эксплуатацию 3. Продукт используется в производственном окружении конечными пользователями
Команда
Сформирована	1. Миссия команды и зоны ответственности участников ясны 2. Необходимые компетенции определены 3. У команды есть достаточное количество ресурсов для начала работы 4. Участники команды знают, как выполнять назначенную им работу
Сотрудничает	1. Команда работает согласовано 2. Коммуникации в команде открытые и честные 3. Команда стремится выполнить миссию 4. Участники команды ставят коллективный успех выше собственных интересов
Эффективно работает	1. Команда результативно и эффективно работает 2. Адаптируется к изменяющимся обстоятельствам 3. Производит продукт высокого качества 4. Почти не занимается переделками и постоянно улучшает рабочий процесс
Рабочие практики и Технология
Определены	1. Ключевые практики и инструменты готовы к использованию 2. Различие между текущим и целевым уровнями владения практиками и технологиями понятны 3. Выбранные практики и технологии увязаны и могут быть использованы совместно
Используются	1. Некоторые участники команды используют практики 2. Использование практик и технологий регулярно отслеживается 3. У команды есть доступ к инструментам 4. Обучение использованию проведено, обратная связь по удобству использования собирается и вовремя отрабатывается
Работают хорошо	1. Практики и технологии хорошо подходят для команды 2. Работа выполняется вовремя

Управление целями проекта по контрольным точкам

Я завожу требования к проекту как групповые задачи, те из них, которые команда берет в работу, детально планируем, по ним ставим дедлайн и получаем контрольную точку (КТ). Проект движется от одной КТ к другой, а если есть несколько рабочих групп, то в отчетном периоде может быть несколько КТ.

Проект плывет от одной контрольной точки к другой

Контрольные точки проектов выделяются трех уровней.

Уровень 1. Определяется выбранным видом жизненного цикла проекта.

Жизненный цикл проекта диктует, как будут выделяться ресурсы на проект. Где он будет пересматриваться, какие ключевые результаты команда обязуется предоставить.

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

Первая точка в жизненном цикле проекта – это совещание по запуску проекта (кик-офф). Если вы используете Эссенс, то есть варианты жизненного цикла и, соответственно, контрольных точек первого уровня.

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

Уровень 2 (КТ2.х). Определяется изменением состояний альф и подальф проекта и реализацией важных требований.

Шестифазная модель жизненного цикла проекта по Эссенс. Фазы делятся КТ1.х. Состояния отдельных альф - КТ2.х

Уровень 3 (КТ3.х) определяется личными рабочими планами.

КТ1.х и КТ2.х всегда привязываются к требованиям и в них происходит проверка и приемка. Это значит, что их прохождение контролирует стейкхолдер, чьи требования выполняются.

Управление работами происходит только на уровне КТ3.х либо отдельных задач.

В схеме управления целями проекта из P2M пакет работ (work package) как раз и является КТ2.х при управлении в трекере

Правило. Типовой шаблон проекта должен включать в себя КТ1.х и КТ2.х, задаваемый видом выбранного жизненного цикла проекта и чек-листом Эссенс. Эти точки должны создаваться автоматически, по факту создания проекта.

Схема развертывания трекера