Рассмотрим процесс еженедельного контроля сроков проекта или этапа проекта (в данной статье это будут синонимы). Новизна подхода будет заключаться в том, что нужно будет автоматически "сжимать" уже готовое расписание проекта.   За основу я взял модель бюджетирования, которую я видел в "Норникеле" и наложил ее на процесс контроля сроков. Факт  - это сколько ч/ч потрачено на задачу.Ожидание - это сколько ч/ч осталось, чтобы завершить задачу.Прогноз - это сколько дней (уже нас интересует длительность) требуется по будущим задачам.  Сперва берется из утвержденного плана, ничего не меняется. Таким образом мы можем составить модель окончания проекта. Отклонение - это разница между утвержденным дедлайном и окончанием в модели Факт + Ожид + Прогноз. Базовый план - это утвержденный план, относительно которого мы будем сравнивать. Я вижу основную задачу в том, чтобы оставшийся объем работ (Ожид + Прогноз) выполнить за оставшийся срок до дедлайна. Прошлым (фактом) мы уже не можем управлять, но из него мы можем извлекать причины. Об этом позже. В таск-менеджере Исполнители заносят свои фактические ч/ч Ответственный Исполнитель по задаче должен проставить Ожидания в ч/ч и в днях по текущим задачам. Менеджер проекта должен сделать мэппинг задач между планом и данными из таск-менеджера и перенести факт+ожид в MS Project. Хорошо, если у вас между 2 системами настроена интеграция, но это отдельная тема. Task Manager MS Project Комментарий Десктоп. версия Главная Главная - верстка Мобильная версия Главная Главная  - верстка Добавить анимацию БГ видео на ховере Главная задача - верстка Незапланированная подзадача, но в рамках задачи Главная - верстка. Перенести Факт + Ожид на родительскую задачу Новости - детальная страница  1. Добавить в MS Project новую задачу2. Связать ее с другими3. Перенести Факт + Ожид Новости - список новостей  Аналогично Берем Задачи, к которым еще не приступали, из последнего плана и их длительности. В прогнозе не меняем длительности! Задачи, которых не было в плане (хотелки или недооценки), но их нужно будет выполнить, тоже оцениваем в ч/ч и днях и заносим в Прогноз. Я описал уже, что: Отклонение - это разница между утвержденным дедлайном и окончанием в модели Факт + Ожид + Прогноз. Но некоторые допускают ошибку и считают, что Отклонение - это разница, насколько дней мы опаздываем по текущим задачам. Нужно считать разницу между итоговым прогнозом и дедлайном, потому что туда могут попасть незапланированные работы. Если такое упражнение делать добросовестно каждую неделю, то можно увидеть насколько быстро увеличивается отклонение каждую неделю. Дата Отклонение, дн. 1 фев -5 8 фев -9 . . .   9 мар -20 (почти месяц) Это дает повод для дальнейшего разбора полетов. Возможно заказчик постоянно накидывает требования, либо разработчики слабые.  Просроченные задачи. Почему они не могу закончиться? Не начатые задачи. Почему они по плану должны начаться, а еще не начинаются? Может мешает какая-то незавершенная задача. А может вообще появился внешний фактор, который мешает начать. Задачи с задержкой (те которые еще по плану не закончились, но есть просрочка). Если у вас задачи сильно длинные, то их тоже нужно анализировать. Используй индикаторы в MS Project. Как их использовать и как настроить - читайте в моей старой статье еще от 2014 года -  Навигатор для проекта: MS Project + формулы + индикаторы  На мой взгляд, самые частые причины это: Неверно произведена оценка и не было заложено резервов Слабые исполнители Заказчик постоянно накидывает требования Простои - из-за внешних факторов (Функциональный заказчик и другие вещи). Корректировать расписание по Ожиданиям и Прогнозу. Для задач, которые лежат на критическом пути Например, осталось 20 рабочих дней, а работы на 30 рабочих дней (6 недель).  Базовый план Рабочий план Ожид 0 10 Прогноз 20 20 Итого 20 30 Рассчитываем коэффициент отставания 20 / 30 = 0,67 Умножаем длительности в рабочем плане на этот коэф.  Корректировка Округляем до полудня Ожид 6,7 6,5 Прогноз 13,3 13 Итого 20 19,5 Для задач, которые не на критическом пути По задачам не на критическом пути появляется резерв относительно критического пути.  В MS Project это поле называется Временной резерв окончания. Рассчитаем коэффициент отставания для задач не на критическом пути. Например, резерв 5 дней, то коэффициент отставания будет равен 20 / (30-5) = 0,8 MS Project В следующей статье я опишу формулу для MS Project, которая позволит "сжать" расписание. Если мы использовали автоматическое расписание, то мы уже имеем кое-какие рекомендации. Теперь доводим это до ума. Потому что расчет нам может предложить сделать задачу за 6,666 дней, а на практике это будет все же не меньше 10 дней. Согласно PMBoK и здравому смыслу есть 4 способа ускориться. Я тут нового ничего не расскажу, но обобщу опыт. Ускорить работы (в PMBoK это называется Быстрый проход) Постоянно контролировать "отстающего" исполнителя и пушить его. Добавить еще людей на эту же задачу, если такое возможно. Внеурочка Поставить более сильного исполнителя Запараллелить работы Работать не по водопаду, а по гибкому подходу Задачи, которые должен был делать один человек, раскидать на несколько Не выполнять некоторые работы (урезать объем) Если к вам постоянно прилетали какие-то хотелки, то обменяйте их на урезание функциональности Выносите предложение, что к дедлайну вы покажите 80% главного, а 20% потом. Но вам обязательно подпишут бумаги о завершении этапа. Подвинуть сроки. Здесь нужно составить запрос на изменение и обоснование. На выходе мы должны иметь: Рабочий план (он отличается от файла на предыдущей неделе, не только процентиками, но и датами) Ресурсный план (устный или письменный запрос на ресусры). Если у вас планируется внеурочка или привлекать других людей Запрос на изменение с обоснованием