что такое вехи в проектной деятельности
Вехи (контрольные точки) проекта
Что такое веха проекта
Что такое веха
Веха (milestone, майлстоун) проекта — контрольная точка, значимый, ключевой момент (например, переход на новую стадию, новый этап в ходе выполнения проекта). Как правило, с этим моментом связано завершение какого-либо ключевого мероприятия, подписание важных документов или любые другие значительные действия, предусмотренные планом проекта. Сдвиг вехи приводит к сдвигу всего проекта.
В дополнение к сигнализации о завершении некого ключевого этапа, веха употребляется в значении принятие важного, ключевого решения, способного изменить весь ход проекта. В этом смысле вехи отмечают не только контрольные точки процесса, но и указывают направление движения.
Веха на диаграмме Ганта
Чтобы обнулить длительность задачи, надо:
При обнулении длительности:
Если веху с временем, равными окончанию рабочего дня, преобразовать в задачу, то задача будет перенесена на начало следующего рабочего дня.
Планирование контрольных точек
Контрольные точки – это значимые моменты, связанные, как правило, с выполнением промежуточных этапов проекта. При достижении контрольных точек сравнивают плановые и фактические показатели.
На основе контрольных точек производится мониторинг фактического прогресса проектов. Контрольная точка (КТ) является отражением результата проекта.
Контрольные точки устанавливают соответствие текущих действий составленному плану. В этом случае контрольная точка позволит проанализировать, насколько эффективно выбран путь реализации конкретного пункта плана. Отсюда еще одна дополнительная функция контрольной точки – корректировка плана.
Идея метода контрольных точек в Адванте в том, что вместо контроля исполнения проекта руководство компании концентрируется на контроле своевременного получения ключевых результатов. Таким образом, в фокусе остается требуемый результат, успех выполнения оценивается на основании отклонения сроков его получения, а приемка качества делегируется специалисту или непосредственно оценивается заказчиком.
Конкретные результаты, которые формулируются для контрольных точек, могут быть разного уровня: от завершения согласования рабочего документа до заключения миллионного контракта. В зависимости от уровня результатов выделим следующие КТ.
Уровни КТ
**0. Вехи**
КТ, результаты которых критически важны для продолжения работы над проектом.
Например, заключение контрактов с основными поставщиками, получение результатов исследований, факты поставки по внешним контрактам, приемка в эксплуатацию ключевых продуктов.
Контроль таких результатов выполняет сотрудник высокого уровня (Генеральный директор, заместитель Генерального директора) или специальное подразделение (Проектный офис).
**1. Критические**
Промежуточные результаты и события, которые критически важны для заказчика проекта.
На этом уровне могут находиться результаты, приемку которых производит непосредственно заказчик (отбор поставщиков, принятие решений по разработкам) или события, срок наступления которых является критичным с экономической точки зрения (конкурентная борьба, требования законодательства).
Контроль получения этих результатов выполняется на высоком уровне.
Отклонение сроков достижения таких результатов рассматривается первым лицом или специальным органом – проектным комитетом.
**2. Ключевые**
Промежуточные результаты, необходимые для получения критических результатов:
Такие контрольные точки зафиксированы базовым планом работ, который утверждается для проекта и контролируется проектным офисом.
Базовый план – рабочий документ руководителя проекта, а на основании его отклонений проектный офис определяет риски отклонения контрольных точек более высокого уровня и предупреждает заинтересованных сторон.
**3. Оперативные**
На нижних уровнях расположены оперативные результаты.
Результаты, которые определил руководитель проекта в рамка ежедневных, еженедельных планов – завершение разработки какого-то модуля, согласование документа, наладка конкретного механизма. Для масштабных проектов такие контрольные точки помогают Руководителю проекта сконцентрироваться на управлении результатами и экономить время на управлении.
Разделение уровней позволит каждому руководителю сосредоточиться на контроле важного дня него результата, не погружаться в тонкости более низкого управления. Для исполнителей работ разделение на уровни гарантирует политику невмешательства в ход работ до момента сдачи плановых результатов, что предоставляет определенную свободу действий, а не расстрельный контроль за каждый неверный шаг.
Генеральный директор контролирует ход выполнения, отклонения от планов, и для этого не нужно разбираться в диаграммах с большим количеством работ и этапов проектов.
За счет постоянной актуализации планов и перепланирования директор получает надежную информацию о выполнении проектных работ.
Руководителю планирование контрольных точек помогает видеть, кто из сотрудников за какую контрольную точку отвечает, быстро понимать состояние дел в проекте и принимать управленческие решения, анализировать, как отклонения одних КТ повлияли на другие, и принимать решения.
Даёт максимально прозрачную отчётность, которая не требует изучения лишней информации.
Контроль получения плановых результатов дает понимание движения проекта и не позволяет откладывать проблемы «на потом».
Аналитик, который организует запуск процесса управления проектом по контрольным точкам, получит инструменты создания и редактирования объектов на каждом этапе текущего процесса.
Для исполнителя планирование КТ – инструмент мотивации.
На диаграмме Ганта чётко отображено, на каком этапе произошли отклонения от плана, и какая контрольная точка повлияла на ход других. В случае успешного выполнения у сотрудника будет осознание того, что в назначенный срок удалось достичь то, что планировалось. Это дает новые силы шагать дальше, помогает почувствовать себя увереннее.
Диаграмма контрольных точек
Что такое «контрольная точка»
Контрольная точка (веха проекта) – это значимый, ключевой момент (например, переход на новую стадию, новый этап в ходе выполнения проекта). Как правило, с этим моментом связано завершение какого-либо ключевого мероприятия, подписание важных документов или любые другие значительные действия, предусмотренные планом проекта. Сдвиг вехи приводит к сдвигу всего проекта.
С т.зр. системы ADVANTA контрольная точка – это объект с нулевой длительностью.
Что такое диаграмма контрольных точек
Диаграмма контрольных точек в отчёте «Проекты и работы» – это визуальное представление прохождения, выполнения задач в рамках проекта.
Диаграмма строится на основе данных «Дочерние объекты».
Столбец с текущим периодом на диаграмме подкрашен светло-голубым цветом. Беглый взгляд на диаграмму позволит оценить аналитику по отклонению фактической даты от плановой/утвержденной.
Разработка графика реализации проекта. Часть 5
Ключевой частью разработки графика реализации проекта является распределения задач в правильном порядке, когда запуск или окончание задач часто контролируется началом или завершением предыдущих задач. Например, вам необходимо разместить оборудование в помещениях, прежде чем вы сможете подключить его к сети.
Связывая задачи, вы превращаете список задач в последовательность, которая определяет, каким образом будет работать ваш проект. Зависимость задачи – это когда одна задача контролирует время другой.
Поскольку у каждой задачи есть начало и конец, существует четыре типа зависимостей задач:
Вы можете выяснить, какой тип зависимостей использовать, задав несколько вопросов:
Как определить необходимые ресурсы для задач?
Предположим, вы расставили задачи проекта в последовательности и оценили их продолжительность. Вы по-прежнему не будете знать, как на самом деле выглядит ваш график реализации проекта, пока не узнаете, сколько людей работает над каждой задачей и когда они будут доступны.
Давайте посмотрим, как задачи меняются из-за назначения ресурсов. Продолжительность – это промежуток времени между началом задачи и ее окончанием. Работа, также называемая усилием – это количество часов или дней, когда кто-то работает над задачей. Если у вас будет больше или меньше людей, чем вы запланировали, продолжительность вашей задачи изменится. Посмотрим, как это работает.
Предположим, вы подсчитали, что на установку оборудования конференц-центра у пяти человек уйдет четыре дня. Это восемь часов в день на человека, а значит 40 рабочих часов в день в течение четырех дней, или 160 рабочих часов. Что случится, если вы получите только четыре человека? Сколько времени займет задание?
Теперь команда из четырех человек может работать только 32 часа каждый день. Если вы поделите 160 часов на количество часов в день, то есть 32, вы получите новую продолжительность в пять дней. Работа остается прежней, но продолжительность задачи варьируется. Тот же расчет применяется, если кто-то переключается на работу на полставки вместо полной. Поскольку вы делите объем работы на половину количества часов в день, задача займет вдвое больше времени.
С другой стороны, если вы получаете больше людей, продолжительность задачи уменьшается. Скажем, поставщик оборудования может дать вам восемь человек. Тот же самый объем 160 часов, команда из восьми человек работает 64 часа в день. Если вы разделите 160 часов на 64, ваша новая продолжительность составит два с половиной дня.
Опять же, некоторые задачи не становятся короче, независимо от того, сколько людей вы назначаете. Встречи являются классическим примером. Четырехчасовое собрание длится четыре часа, независимо от того, присутствуют на ней три человека или десять.
Когда назначенные ресурсы доступны, это также влияет на время выполнения работы. Например, в вашем графике указано, что установка оборудования начнется 9 февраля. Однако IТ-компания завершает другой проект, и команда не будет доступна до 18 февраля. Это означает, что вы должны отложить эту задачу в своем графике, чтобы отразить в нем, когда ресурсы доступны. Когда вы назначаете ресурсы для задач, вы, наконец, получаете четкое представление о том, когда в вашем проекте происходит работа.
Что такое вехи проекта?
Вехи (Milestones) получают свое название из прошлого, когда люди клали камни на обочине дороги, чтобы отметить каждый километр (или любой другой отрезок расстояния). В проектах вехи выполняют аналогичную работу, но они показывают прогресс и другие ключевые моменты проекта, а не расстояние. Они показывают, когда вы выполнили ключевые задачи или части проекта, и позволяют легко увидеть, сколько вы выполнили и когда закончили.
Вехи полезны как контрольные точки, отмечая первую и последнюю задачи в расписании вашего проекта. Последняя задача в графике проекта – почти всегда важный этап. Глядя на последний этап, вы можете определить, идет ли проект по графику, с опозданием или с опережением графика.
Вехи также помогают подчеркнуть прогресс, достигнутый вами между началом и окончанием проекта. Когда вся работа, ведущая к этому этапу будет выполнена, а вы удовлетворены результатом, вы отмечаете предыдущий этап как завершенный. Когда ожидается доставка чего-либо, то отметьте контрольной точкой такую доставку.
Наконец, используйте веху для обозначения решений, которые отражают, что будет дальше в проекте, или используйте веху для утверждения, которое отмечает, когда может начаться работа после ее утверждения. Вехи помогают указать прогресс в проекте. Когда вы связываете их с рабочими задачами, вы также можете использовать их для перепланирования частей проекта.
Понимание критического пути
Критическим путем является последовательность задач в вашем расписании с самой длинной продолжительностью. Почему критический путь так важен? Потому что любая задержка на этом пути задерживает дату окончания проекта. Не менее важно то, что вы можете сократить график проекта, если сможете найти способ сократить критический путь.
Итак, что делает задачи критическими? Простые, которые не имеют провисания, также называемые float в терминах управления проектами. Критичные задачи не имеют возможности продвигаться, не влияя на график. Например, все задачи по установке оборудования выполняются одна за другой, без провисания. Если какое-либо из этих заданий откладывается, дата окончания проекта переносится на более поздний срок. И наоборот, если задача имеет провисание, она может начаться позже, не задерживая задачи, которые следуют за ней.
Теперь давайте рассмотрим, как вы определяете, что задача имеет провисание. Задача имеет два набора дат начала и окончания, которые заключают в скобки, когда задача может совершиться. Раннее начало и раннее завершение – это самые ранние из возможных дат, когда задача может начаться или завершиться, учитывая ее зависимости от других задач.
Например, какая-то конкретная задача может начаться уже 3 октября и завершиться 14 октября. Поздний старт и позднее окончание – это самые поздние возможные даты, когда задача может начинаться и заканчиваться, без задержки последующих задач. Даты позднего старта и окончания – 24 ноября и 7 декабря соответственно. Это означает, что задача имеет несколько недель, поэтому она не находится на критическом пути, а значит, имеет провисание. С другой стороны, если ранние и поздние даты совпадают, тогда эта задача не имеет провисания.
Понимание критической цепи
Критическая цепь – это немного другой взгляд на критический путь. Используя подход с критической цепью, вы сможете реализовать свой проект раньше. Кроме того, методы критической цепи помогают предотвратить задержки в дате завершения проекта.
Как сократить график проекта?
Вы можете оценить свою дату завершения проекта, но заинтересованные стороны могут начать требовать от вас скорейшего выполнения проекта. Быстрое отслеживание, сбой и сокращение объема – вот несколько методов, которые можно использовать для сокращения графика проекта.
С помощью быстрого отслеживания вы перекрываете задачи, которые обычно выполняются одна за другой. Например, если вы хотите завершить установку оборудования быстрее, некоторые работники могут начать настройку оборудования, а другие – размещать оборудование в помещениях.
Быстрое отслеживание очень простой метод, потому что вы просто перекрываете две задачи с зависимостями начало-конец. Наиболее подходящие задачи для ускорения – это задачи на критическом пути. Это потому, что вы сокращаете график проекта, когда вы сокращаете критический путь. Кроме того, ускоряйте самые длинные задачи на критическом пути. Они сокращают график, генерируя наименьшее количество рисков и изменений.
Недостатком метода быстрого отслеживания может быть увеличивающийся риск. Когда вы перекрываете задачи, то может получиться так, что на уже выполненную работу может повлиять решение, которое будет принято позже, например, выполнить работу по-другому. Например, если вы решите изменить расположение оборудования, возможно, придется переделать часть конфигурации оборудования.
Второй метод, сбой, увеличивает стоимость проекта, так как вы тратите дополнительные средства, чтобы сократить его график. Обычно повышенная стоимость связана с дополнительным персоналом, который вы привлекаете к работе.
Применение метода сбоя на критическом пути
Естественно, что вы не хотите тратить средства на сокращение задач, которые не будут сокращать ваш общий график. Ключом к успешному сокращению является поиск альтернативы, которая сократит график на сумму, вписывающуюся в ваш бюджет.
Сначала вы начинаете сокращение с наименее дорогих задач. Затем вы должны «сбить» задачи с более высокими ценами, только до тех пор, пока вы не сократите график на необходимую вам сумму. Таблица сбоя, представленная ниже, позволяет легко увидеть, какие задачи вы должны сбить.
С чего начинается любой проект
Когда вы сталкиваетесь с созданием проекта (неважно, MVP это инновационной идеи или уже будущий highload-сервис, который вам поручило реализовать руководство), он всегда будет проходить через ключевые точки. От того, как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат, будет зависеть успех проекта.
Для начала немного теории. Что же такое проект?
Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.
Хотим отметить, что регулярные (рутинные) процессы, которые вы ежедневно выполняете — не равны проектной деятельности. Проектные и процессные задачи не должны перемешиваться между собой. Проектные задачи должны регламентироваться отдельными правилами и нормами в вашей компании или команде.
Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).
Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).
Очень часто причиной закрытия так и не вышедшего в свет проекта — является нехватка бюджета. Большая часть этой нехватки — связана с неверным планированием в начале пути.
Тщательное планирование необходимо.
“Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.” (Цитата С. Макконнелл “Совершенный код”)
Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают “серебрянной пули”.
Невозможно реализовать проект быстро, дешево, с максимально возможной функциональностью, без рисков для вас и с наивысшим качеством. Так или иначе, все аспекты придут в баланс и будут друг другу соответствовать.
Любой проект проходит через фазы развития. Каждую из них можно пройти циклично по несколько раз, перед тем как переходить к следующей.
Если на предварительном этапе выработки требований к проекту, можно описать только малую часть, то рекомендуется придерживаться более гибких методологий разработки и управлять проектом фрагментарно, определив на старте минимальные жизненно важные требования к проекту. Дополнительные требования добавляются по мере развития проекта.
Определить критический путь проекта. Есть те работы, которые идут параллельно или идут последовательно и их невозможно сделать, не выполнив предыдущую задачу.
“Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты” (Цитата С. Макконнелл “Совершенный код”)
Совет:
Обращайтесь за помощью к специалистам из финансовой, юридической, экономической, технической сферы, чтобы верно спланировать проект и не столкнуться в середине пути с тем, что нужно было решить вначале. Рекомендуем обращаться к потенциальным подрядчикам, т.к. это поможет определиться с выбором подрядчика и включиться им в работу.
“Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок” (Цитата С. Макконнелл “Совершенный Код”)
Функциональные области в проекте это сроки, бюджет (стоимость), задачи (качество их выполнения), риски, выгоды, команда, интеграция (объединение всех областей). Всё нужно описать еще на старте и дальше переходить к выполнению этапов проекта.
Какие же это будут этапы?
Что такое веха
Веха (milestone) – важное (ключевое) событие проекта, контрольная точка, в которой будет понятно, что достигнут определенный промежуточный результат проекта.
Обычно в списке задач в MS Project вехи формулируются так: что-то утверждено, что-то завершено, что-то подписано. Т.е. веха констатирует совершение какого-то факта. В качестве вех часто указывают подписание актов, получение денег на проект. Также принято в конце каждой крупной группы работ (суммарной задачи) ставить «техническую» веху – Группа работ завершена, даже если по смыслу в конце этой группы не подписывается никаких документов.
Руководству, которому вы отчитываетесь, часто не до подробностей проекта, отчетность «по вехам» — общепринятая практика.
Веха обычно не имеет длительности. Поэтому самый простой способ пометить задачу как веху – в столбце Длительность поставить 0, т.е. задать нулевую длительность. Project сразу изменит оформление такой задачи в диаграмме (она будет обозначена ромбом, по умолчанию).
Но иногда бывает нужно пометить как веху задачу с ненулевой длительностью (я считаю это вредной практикой, но тем не менее),
Для пометки задачи как вехи надо открыть окно Сведения о задаче (например, двойным щелчком по задаче) и на вкладке Дополнительно поставить флажок Пометить задачу как веху и нажать ОК:
Задача с ненулевой длительностью будет помечена вехой:
Добавление вехи
Перед развертыванием проекта, возможно, стоит отметить его основные цели вехами.
Создание вехи с нулевой длительностью
Самый простой способ создать веху — добавить в план проекта задачу без длительности.
Щелкните «Вид»,а затем в группе «Представления задач» выберите «Диаграмма Гэтта».
Введите имя вехи в первой пустой строке или выберите задачу, которую вы хотите превратить в веху.
Введите 0 в поле «Длительность» и нажмите ввод.
В диаграмме Ганта появится символ вехи.
Добавление вехи с длительностью
Иногда веха занимает время. Например, процесс утверждения в конце этапа может занять неделю, поэтому со временем эта веха должна будет проходить как обычная задача.
Щелкните «Вид»,а затем в группе «Представления задач» выберите «Диаграмма Гэтта».
Введите имя вехи в первой пустой строке или выберите задачу, которую вы хотите превратить в веху.
Выберите веху и нажмите кнопку «Задача». В группе «Свойства» нажмите кнопку «Сведения о задаче».
Перейдите на вкладку «Дополнительные действия» и введите длительность вехи в поле «Длительность».
Пометить задачу как вехуи нажать кнопку «ОК».
В диаграмме Гэтта в последний день задачи появится символ вехи. Оно не появляется в качестве отловка, несмотря на его длительность.
Добавление внешней вехи
Иногда может потребоваться веха для отслеживания задачи, которая находится за пределами проекта.
Если веха является частьюпроекта в вашей организации, ее можно отслеживать с помощью перекрестной связи.
Эти инструкции относятся к Microsoft Project 2007.
Создание вехи с нулевой длительностью
В меню Вид выберите пункт Диаграмма Ганта.
Введите имя новой вехи в поле «Название задачи» для первой пустой строки в списке.
Если вы хотите сделать существующую задачу вехой, пропустите этот шаг.
Введите 0 в поле «Длительность» вехи и нажмите ввод.
Если для задачи ввести ноль, Office Project Профессиональный 2007 в этот день в представлении » 
Гантта» отобразит символ вехи.
Создание вехи с длительностью больше нуля
Вехи обычно имеют нуль длительность; однако для некоторых вех может потребоваться длительность. Например, у проекта есть веха утверждения в конце этап, и вы знаете, что процесс утверждения займет неделю.
В меню Вид выберите пункт Диаграмма Ганта.
Введите имя новой вехи в поле «Название задачи» для первой пустой строки в списке.
Если вы хотите сделать существующую задачу вехой, пропустите этот шаг.
Выбрав веху в сетке, щелкните «Сведения о задаче» 
.
На вкладке «Дополнительные действия» введите длительность вехи в поле «Длительность».
Выберите поле «Пометить задачу как веху» и нажмите кнопку «ОК».
Office Project Профессиональный 2007 последний день задачи в в представлении «Диаграмма Гантта» отображается символ вехи.
Создание вехи с помощью Project в Интернете
Самый быстрый способ создать веху — добавить в проект задачу без длительности.
Перейдите в Project (project.microsoft.com) и выберите временную шкалу.
Нажмите кнопку «Добавить новую задачу»и введите ее имя.
Наведите курсор на название задачи и выберите значок «Открыть сведения».
Введите 0 в поле «Длительность» и выберите «Добавить зависимость».
Символ вехи 
теперь является частью временной шкалы.