Что значит проект завершен строительством

В жилых корпусах первой очереди Ever от Tekta Group на 90% выполнены монолитные работы. Строительство первой очереди квартала продолжается высокими темпами, по некоторым видам работ даже с опережением графика. Проект планируется завершить в соответствии с заявленными сроками в IV квартале 2023 года, сообщали в пресс-службе компании.

Квартал Ever строится на улице Обручева, в 10 км от Садового кольца и 5-6 минутах ходьбы от станций метро «Калужская» и БКЛ «Воронцовская». В составе первой очереди общей площадью 240 000 квадратных метров возводятся три 34-этажных башни, трехуровневый подземный паркинг и торговая галерея с коммерческими помещениями. В жилых зданиях, объединенных стилобатом, запроектировано 1106 квартир, 655 машино-мест и 363 кладовые.

Готовность монолитного каркаса корпусов достигла 90%, а полностью монолитные работы в 1 и 2 корпусах будут завершены в августе текущего года. В настоящий момент работы ведутся на высоте 28-33 этажей. Одновременно продолжается остекление и кладка стен и перегородок. В первом и третьем корпусах кладка завершена на 20-22 этажах. Во втором – стены появились на 25-27 этажах.

Mars4 Garage construction project completed / Марс4 Строительство гаража проект завершен

На уже готовых этажах строители приступили к отделке фасада: монтажу кронштейнов и утеплителя. Внутри корпусов идет устройство стояков вентиляции и электромонтажные работы. На подземных уровнях продолжается отделка помещений паркинга. Выполняется монтаж лифтового оборудования от европейского производителя ThyssenKrupp.

Восемь из двенадцати лифтов уже привезены на строительную площадку, остальные отгружены с производства и будут доставлены в течение месяца. В каждом корпусе предусмотрена установка четырех лифтов – двух пассажирских и двух грузовых, грузоподъемностью до 1300 кг.

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

Ранее мы сообщали о том, что в комплексе Ever начался монтаж скоростных лифтов ThyssenKrupp.

Источник: cud.news

Завершение проекта. Заключительные действия. Часть 8

Данная статья – продолжение нашей большой статьи по управлению проектами. Чтобы начать читать сначала, пожалуйста, перейдите по этой ссылке .

1. Как получить подтверждение клиента
2. Документация извлеченных уроков
3. Как подготовить отчет о завершении проекта
4. Закрытие и передача проекта

Когда результаты вашего проекта получены, вы можете подумать, что проект завершен, но у вас есть несколько действий, которые нужно выполнить, прежде чем вы сможете назвать проект выполненным.

Никогда НЕ СТРОЙ дом БЕЗ ПРОЕКТА. Начало строительства дома — проект дома!

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

Теперь пройдемся по пунктам немного подробнее.

Как получить подтверждение клиента

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

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

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

Документация извлеченных уроков

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

• Во-первых, назначьте время для регулярных встреч по извлеченным урокам (раз в несколько недель). Не ждите окончания проекта, чтобы спросить о них, так как со временем детали забываются и реальные примеры начинают искажаться.
• Во-вторых, сохраняйте позитивные и продуктивные встречи . Начните с того, что прошло правильно. Попросите каждого человека дать совет или методику, которые помогли им в их работе, например, что сэкономило им больше всего времени или какая самая сложная задача, которую они решили, и как они это сделали.
• В-третьих, переходите к урокам из проблем, с которыми столкнулись сотрудники. Задавайте вопросы о проблемах в положительном ключе, например, «что бы вы сделали по-другому в следующий раз?».
• В-четвертых, дайте людям возможность быть открытыми и честными. Попробуйте планировать встречи без менеджеров. Подумайте о включении анонимного метода для отправки извлеченных уроков, например, ящика для предложений.
• В-пятых, задокументируйте извлеченные уроки. Например, поместите их в записную книжку проекта, но вы также можете создать веб-страницу с часто задаваемыми вопросами, советами и приемами или базу знаний. Таким образом, каждый в вашей компании может узнать то, что уже знает ваша проектная группа.

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

Как подготовить отчет о завершении проекта

Отчет о завершении проекта подводит итоги проекта в кратком информативном документе: что сделал проект, как он это сделал, и насколько хорошо он прошел. Отчет начинается с краткого описания проекта и того, был ли проект успешным. Краткое изложение проекта освещает основные моменты. Получил ли проект то, что предполагалось? Завершился ли он вовремя и в рамках бюджета?

Если нет, то почему?

Затем включите информацию, которой вы хотите поделиться с другими, например, о значительных изменениях, проблемах, извлеченных уроках или рисках. Например, если в проекте не было выполнено все, что указано в заявлении о содержании, определите объем, который не был выполнен.

Что касается рисков, опишите, как вы с ними справились, и каков результат. Вы также можете указать на возникшие риски, которые не были определены в первоначальном плане управления рисками, чтобы другие не упустили их в будущем.

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

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

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

Закрытие и передача проекта

В самом конце проекта у вас есть несколько скучных, но важных действий, которые нужно совершить.

1. Закройте подписанные вами контракты. Если ваш проект включал контракт с заказчиком, подписи в форме согласия клиента являются ключом к соглашению о том, что контракт завершен. В зависимости от условий контракта, у вас может быть несколько других обязанностей, например, поддержка результатов проекта или выполнение последующих действий через несколько месяцев. Если вы заключаете контракты с поставщиками или подрядчиками, убедитесь, что другие стороны сделали то, что должны были делать. Затем выполните шаги, чтобы закрыть эти контракты.
2. Закройте счета, которые вы использовали для выставления счетов по проекту. Для большинства проектов финансовые книги остаются открытыми в течение короткого времени, обычно несколько месяцев после завершения проекта.
3. Как руководитель проекта помогите своим людям перейти к их следующим заданиям. Лучший способ сделать это – заранее уведомить функциональных менеджеров о том, что их сотрудники будут задействованы.

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

Заключение

Мы изучили основные процессы в области управления проектами и обнаружили множество методов эффективного управления проектами. Это был длинный курс, но даже при таком объеме нам не удалось подробно описать множество деталей в управлении проектами.

В будущих статьях мы обязательно вернемся к этой теме, как, например, в статье «Чем занимается бизнес-аналитик. Суть работы, роль и навыки» .

Источник: www.your-mentor.ru

Как завершать проекты в срок

В предыдущей статье мы выяснили, что высокая степень неопределенности проектной среды не является основной причиной срыва сроков проекта . Причина заключается в нашей организации работ на проекте. Таким образом, нам нужно решение, которое бы изменило нашу работу и позволило устранить такие явления как Закон Паркинсона, студенческий синдром, потеря выигрыша времени и передача опозданий в цепи зависимых заданий. Решение должно минимизировать перепрыгивание от задания к заданию, при этом оценка длительности заданий не должна переводиться в разряд обязательств. Что собой представляет решение читаем далее.

Бегло напомню к чему мы пришли в прошлой статье (//infostart.ru/public/1199781/):

1. Качественной оценка длительности задания считается такая оценка, которая гарантирует не менее 80% вероятности завершения задания в срок.
2. Оценка, гарантирующая вероятность 80% и более завершения в срок содержит не менее 50% подстраховки.
3. Традиционно считается, что для того, чтобы весь проект завершить в срок, совершенно необходимо каждое задание завершить в срок.
4. Из-за неправильной организации работ на проекте большинство заданий не завершается в срок, приводя тем самым к срыву сроков проекта.

Мы также выяснили, что есть как минимум 4 основные причины, из-за которых мы теряем двукратные резервы времени, закладываемые командой проекта при планировании:

• Закон Паркинсона.
• Студенческий синдром.
• Потеря выигрыша и передача опозданий в цепи зависимых заданий.
• Перепрыгивание от задания к заданию в мульти-проектных средах.

Нам нужно решение, которое бы изменило нашу работу. При этом анализ ключевой проблемы указывает на ряд требований, которым должно удовлетворять наше решение.
Решение должно обеспечить, чтобы:

• Оценка длительности заданий не переводилась в разряд ОБЯЗАТЕЛЬСТВ — это должно значительно сократить количество подстраховки.
• Выигрыш по времени и опоздания компенсировали друг друга.
• Перепрыгивания от задания к заданию резко сократились.

И так, что собой представляет решение?

Методы критической цепи

Метод №1: Эшелонирование

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

Такой подход называется «Эшелонирование». При этом необходимо эшелонировать проекты относительно самого загруженного ресурса проектной команды!
Вот пример эшелонирования графика по ресурсу «F»:

1. Не начинайте работу раньше графика, даже если ресурсы простаивают!
2. Обычно существует остаточная конкуренция и за другие типы ресурсов. Возникает соблазн выровнять все ресурсы проекта, однако, попытка убрать остаточную конкуренцию – просто выброшенное время: Мерфи все равно вмешается и вернет все на свои места. Не нужно оптимизировать в рамках шума!

Давайте промоделируем на нашем симуляторе проектов, как изменится время выполнения проектов при использовании метода Эшелонирования.

Напомню, что условия экспериментального проекта для моделирования мы описывали в предыдущей статье: //infostart.ru/public/1199781/

Исходные условия были такими:

• В производство запущено одновременно три одинаковых проекта.
• Каждый проект содержит 7 в разной степени зависимых друг от друга заданий.
• Всего на трех проектах заняты 10 различных спецов и каждый может выполнять задания только своего типа.
• Каждое задание длится 20 дней и вероятность выполнения его в срок 80%.
• В каждом задании 10 дней подстраховки.
• Плановое время выполнения проекта 140 дней.
• Для переключения между заданиями работа ресурса не прерывается чаще, чем один раз в неделю.
• Отсутствуют затраты времени на переключения от задания к заданию.

В таблице результаты моделирования до и после эшелонирования 3-х проектов.

• Третий проект закончится на 5 дней раньше — 1% ускорения.
• Второй ускорился уже на 70 дней (16%).
• Самые выдающиеся результаты у Первого проекта: 54% ускорение!

Неплохой результат! Эшелонирование работает!

Давайте посмотрим, что с этим еще можно сделать.

Метод №2. Управление подстраховкой.

Вернемся к истории с избыточной подстраховкой в оценках длительности каждого задании. Мы тогда согласились, что должны обеспечить защиту завершения всего проекта, а не каждого отдельного задания («нам важно, чтобы проект был завершен в срок»). Напрашивается логичное предложение: а давайте передвинем ВСЮ подстраховку, заложенную в КАЖДОМ отдельном задании, В КОНЕЦ проекта!

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

На самом деле не важно то, сколько подстраховки заложено в каждом задании – мы ведь никуда не дели эту подстраховку, мы просто передвигаем ее в конец проекта. И даже если мы ошиблись, определяя ее размер, то когда нам не будет хватать времени на задачу, мы просто будем брать это время из буфера в конце проекта. А раз так, то давайте просто на половину сократим количество времени, указанного в оценке. Тем более, что наш опыт показывает, что до внедрения Методов критический цепи исполнители закладывают не менее 50% времени на подстраховку.

1. Никто не будет вести себя так, как будто у него есть масса времени. Уйдет Студенческий синдром и закон Паркинсона.
2. Через какое-то время накопится реальная статистика по схожим задачам. Мы будем давать более реалистичные оценки задач.

Как убедить исполнителей?

1. Необходимо, чтобы все знали, что большое количество той подстраховки, которую забрали, заново вносится в план, только в конце проекта и может быть, как и ранее, использовано для защиты от Мерфи для каждого задания.
2. Необходимо, чтобы все знали, что менеджмент не рассматривает новые оценки по времени как обязательства. Уложиться в эти намного более короткие сроки не является обязательным, но, по возможности, желательным.
3. Использование подстраховки теперь централизовано, а значит ее будет сложнее разбазаривать. Время – это невосполнимый ресурс! И более чем нормально, если учет резервов времени в команде будет вестись тщательно и прозрачно!

Идем дальше. Оказывается, подстраховка бывает двух разных видов. Чтобы объяснить это, нам нужно ввести такое понятие как «Критическая цепь».
Вопрос: Что определяет время исполнения проекта?
Ответ: Самая длинная цепь зависимых заданий.
Без учета конкуренции за ресурсы сама длинная цепь — это «Критический путь проекта».

А как изменится ситуация, если есть конкуренция за ресурсы?

Возникает необходимость выстроить последовательно (эшелонировать) выполнение заданий, конкурирующих за ресурсы. В данном случае есть два варианта решения этой проблемы. И мы уже получаем 2 варианта «Критического пути».

Ситуацию, когда «Критический путь» зависит от варианта распределения ресурсов, принято называть «Критическая цепь».
Формулирую определение: Самая длинная цепь зависимых заданий с учетом конкуренции за ресурсы и будет называться «Критическая цепь проекта».
Обратите внимание: каждый раз, когда имеет место зависимость ресурсов, критическая цепь зависит от решения РП относительно того, какое задание выполняется первым!

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

Теперь, как мы и договорились, соберите в одно целое всю подстраховку, заложенную в каждом задании критической цепи, разделите ее на 2 и используйте для защиты ВСЕГО проекта.
Обратите внимание, что получившийся буфер подстраховки критической цепи не должен составлять более 1/3 всего времени исполнения проекта. Назовем общий резерв проекта в критической цепи «Буфер завершения»

Однако, у нас есть еще примыкающие цепи заданий в проекте. В цепи зависимых заданий опоздания по примыкающим цепям неизбежно будут передаваться в критическую цепь («опоздания передаются, выигрыш по времени нет»). При этом в примыкающих некритических цепях есть своя подстраховка, которую мы пока не трогали.

Нужно собрать эту подстраховку и использовать для защиты от опозданий в некритических цепях, создав таким образом собственный буфер. Назовем его «Питающий буфер». Напомню, что буфер должен составлять 1/3 от длины цепи, в которой до этого подстраховку сократили вдвое.

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

Давайте посмотрим, как изменится ситуация в нашей модели, когда мы к «Эшелонированию» введем в систему «Буфер завершения» в критической цепи и «Питающий буфер» в каждой некритической цепи заданий.

Результаты моделирования в таблице.

Смотрите, совсем другое дело!

• Третий проект заканчивается уже через 240 — минус 190 дней.
• Второй ускорился на 125 дней.
• Первый улучшил свой предыдущее значение на 5 дней

Неплохой результат? Да, но мы хотим быстрее! Мы хотим определенно более прорывное решение!

Метод №3. Приоритеты выполнения заданий

Следующий рывок достигается за счет изменений в установке приоритетов запуска заданий в производство. Буфер завершения и питающие буферы дают нам надежный механизм для этого. Приоритеты будут устанавливаться в соответствии с типом потребляемого буфера и с тем, сколько процентов буфера было потреблено. Как это сделать?

Очевидно, что для того, чтобы следить за потреблением резервов, специалисты должны регулярно сообщать о прогрессе выполнения задания. Специалист должен сообщать «когда будет ЗАВЕРШЕНО задание», а РП должен вести учет расхода резервов.

Для управления приоритетами необходимо ввести следующие 2 правила:

1. Задание критической цепи, которое начало потреблять буфер завершения, всегда будет иметь более высокий приоритет, чем задание в цепи, потребляющее питающий буфер.
2. Задание имеет более высокий приоритет, если оно имеет более высокий процент потребления буфера в конце своей цепи.

Промоделируем эффект от использования Правил установки приоритетов.
Единственное отличие – каждый раз, когда ресурс может выбирать между двумя заданиями, симулятор рассчитывает приоритеты в соответствии с типом буфера и данными по текущему уровню потребления буфера.

Внимание на таблицу!

• Третий проект – еще минус 30 дней!
• Второй – минус 55 дней!
• Первый — фантастический результат — 115 дней! Напомним, что самая первая модель с одним проектом давала нам 180 дней с той же вероятностью.

Важный побочный эффект: до внедрения Методов критической цепи ресурсы были заняты на протяжении 375 дней и это давало только 50% вероятности успеть в срок. В результате внедрения все ресурсы высвобождаются уже после 210 дней, при этом вероятность успеть в срок не менее 90%! Методы критической цепи высвобождают большое количество ресурсов, которые можно использовать на других проектах!

Но каким бы впечатляющим не был наш результат, тем не менее существует 10% вероятности не завершить первый проект в амбициозный срок 115 дней. В тоже время обязанность РП обеспечить выполнение проекта в срок!

Это можно сделать если:

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

Для этого нам нужна система показателей состояния дел на проекте.

Показатели оценки проектов

Для оценки ситуации на проекте и сравнения результатов нескольких проектов между собой нам достаточно всего три показателя:

1. Сколько процентов критической цепи уже завершено.
2. Сколько процентов буфера завершения потреблено в соотношении к проценту завершенной части критической цепи.
3. Текущая скорость потребления буфера завершения.

Рассмотрим все три показателя более подробно.

Показатель №1. Прогресс проекта

Взгляните на этот график проекта:

• Длительность проекта: 120 часов
• Плановые трудозатраты: 300 часов
• Фактически израсходовано: 150 часов

Традиционно прогресс проекта измеряется в соответствии с процентом выполненных работ в соотношении с общим количеством предполагаемых работ. На сколько процентов, по вашему мы завершили проект? Чаще всего мы услышим, что работы завершены на 50%.

Теперь представим, что на проекте на одном из заданий возникла заминка – работы приостановлены, скажем, по вине заказчика – они никак не могут ТЗ согласовать. Знакомая ситуация? Куда мы скорее всего назначим ресурсы, если не хотим, чтобы проект останавливался и ресурсы простаивали? Конечно на задания, по которым нет проблем!

В итоге получаем такую закономерную картину:

• Плановые трудозатраты проекта: 300 часов
• Фактически израсходовано: 210 часов
• Статус проекта: 70% завершено!

Какой молодец наш РП – прошло всего 50% времени, отведенного на проект, а он уже отчитывается о 70% выполнении работ! Того и гляди, проект завершиться раньше срока!

В результате проявляется тот самый неожиданный феномен: Исполнение последних 10% проекта занимает половину времени всего проекта!

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

При новом подходе прогресс приведенного для примера проекта будет: 25%. Статус проекта не меняется, пока не будет завершено проблемное задание.

Теперь мы знаем прогресс проекта, но как мы сможем понять, на сколько проблемное задание портит нам жизнь? Может 25% на данный момент — это норма? Для этого нам понадобится второй показатель.

Показатель №2. Процент потребления резервов времени

Статус проекта должен определяться в соответствии с тем, сколько процентов буфера завершения потреблено в соотношении к проценту завершения критической цепи. Рассмотрим применение этого показателя.

Взгляните на рисунок:

3-я задача сверху в критической цепи вызвала проблему и начала потреблять буфер завершения. При этом сдвинулись сроки завершения зависимой от нее задачи.
Статус проекта: 50% критический цепи завершено, при этом потреблено 20% буфера завершения.
Все хорошо, у нас нет повода волноваться!

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

И так, теперь мы знаем не только прогресс проекта, но и состояние резервов времени, и есть ли у нас проблема со сроками. Однако, возникает еще пара вопросов:

• Как можно определить на регулярной основе, находится ли проект под контролем?
• Если на проекте случился перерасход буфера завершения, мы приняли меры, возможно ли как-то проверить – идет проект на поправку или нет?

Для этого нам понадобится третий показатель.

Показатель №3. Скорость потребления буфера

Этот показатель позволяет увидеть, когда проблема возникает и вернули ли наши действия проект в свои рамки. Напомним, что буфер завершения составляет 1/3 времени исполнения проекта. А это значит, что если в определенный интервал времени скорость потребления буфера завершения выше, чем 1/3 (33%) времени данного интервала, то у нас проблемы накапливаются.

Пример: Прошло еще 10 дней проекта, было потреблено дополнительно 5 (5 это 50% к 10) дней буфера завершения. Вывод: у нас проблема.

Если в определенный интервал времени скорость потребления буфера завершения ниже, чем 1/3 времени данного интервала – это означает, что относительная подстраховка увеличилась, мы накапливаем резервы времени.

Пример: Прошло еще 10 дней проекта, было потреблено дополнительно 1 (1 это 10% к 10) день буфера завершения. Вывод: проект восстанавливается (накапливает подстраховку).

Выводы

Не важно, чтобы каждое отдельное задание было завершено в срок. Важно, чтобы в срок был завершен весь проект!
Для этого необходимо использовать 3 приема:

1. Эшелонирование проектов.
2. Критическая цепь с буфером завершения и питающими буферами подзадач.
3. Расстановка приоритетов и правильные показатели оценки проектов.

Для того, чтобы начать применение методов критической цепи, необходимо выполнить 3 действия:

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

Действие №2. Внедрите Эшелонирование проектов. Придите к общему согласию о введении эшелонирования проектов в соответствии с выбранным дефицитным ресурсом, который и будет задавать темп и график всех проектов. В мульти-проектной среде эшелонирование проектов – абсолютная необходимость!

Действие №3. Внедрите управление буфером. Фокусируйте свое внимание на приоритетных задачах. Ресурсы должны регулярно отчитываться о том, сколько еще времени, по их оценке, уйдет на выполнение текущего задания. Менеджеры по ресурсам должны устанавливать приоритеты в соответствии с типом потребленного буфера и с тем, сколько процентов буфера было потреблено.

РП должны фокусировать свое внимание на заданиях, вызывающих самое большое потребление из буфера своего проекта.

При внедрении и использовании методов критической цепи учтите, что это вызывает изменение в проектной среде:

• Ресурсы начинают привыкать к тому, что перепрыгивание от задания к заданию резко сократилось и что их оценки по длительности выполнения больше не воспринимаются как обязательства. В результате они закладывают в свои оценки значительно меньше подстраховки.
• После того как ресурсы исполнили несколько проектов по методу Критической цепи, будет ошибкой продолжать следовать правилу о сокращении времени оценки наполовину. Правило, которому необходимо продолжить следовать: «Буферы равны 1/3 времени исполнения в цепи»
• Изначально наиболее загруженный ресурс совсем не является «бутылочным горлышком». Применение Методов критической цепи выявляет избыточную мощность и позволяет увеличивать количество проектов. В конечном итоге «бутылочное горлышко» все-таки возникает. На этом этапе важно, чтобы «бутылочное горлышко» никогда не оставалось без работы. Этого можно легко добиться за счет небольшого изменения в методе эшелонирования.

Для более углубленного понимания Методов критической цепи рекомендуем к прочтению следующие книги автора методики и создателя Теории ограничений систем (TOC – Theory of Constraints) Элияху Голдратта:

1. Цель: Процесс непрерывного улучшения
2. Критическая цепь.

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/

Источник: infostart.ru

Как завершать проекты так, чтобы максимизировать результаты?

Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Managment Institute, квалификация Project Managment Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

Однажды меня попросили проконсультировать одну крупную фабрику по вопросам модернизации работы Проектного офиса. Я встретилась с управляющим фабрики и руководителем Проектного офиса, чтобы понять, какие функции и как выполняются, какие есть задачи и проблемы.

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

Другим примером той же проблемы был случай на стратегической сессии, которую я проводила для крупного холдинга. Во время одного из докладов прозвучала шутка: «Говорят, что хороший проект всегда заканчивается неоплаченным долгом. Давайте сделаем так, чтобы у нас таких проектов не было»!

Участники улыбнулись, но только не я. Мой доклад о КСУП был следующим, и мне захотелось объяснить смысл фразы. «А кто у вас после завершения проекта отвечает за возврат инвестиций?» – спросила я. Наступила тишина. Директор холдинга встал и оглядел присутствующих. «Действительно, кто отвечает за то, чтобы вернуть мне вложенные деньги?» – спросил он. Мне стало понятно, что в процессе завершения многомиллионных проектов холдинга существует явная брешь, которую срочно нужно нивелировать.

Эти примеры говорят не только об определенном недопонимании функций Проектного офиса, но и явном неумении завершать проекты. Качественно поставленная точка при завершении проекта и эффективный запуск работы результатов в операционный цикл – еще одна важная способность КСУП, которая должна быть включена в работу Проектного офиса.

Роли и конфликты проекта при его завершении

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

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

Почувствуйте разницу: для организации в целом главное не то, что нужны именно эти результаты, а то, что мы хотим достичь целей. Именно этот факт и должен проектировать весь процесс по завершению проекта в КСУП: не столько закончить работу команды проекта, сколько включить результаты в операционный цикл, начать использовать их и получать выгоды.

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

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

1. Спонсор (руководство) отвечает за принятие решения о проекте. Это значит, что он берет на себя ответственность за реализацию бизнес-плана. Задача руководства – понять, возможно ли получить результаты и использовать их предложенным образом, чтобы обеспечить заявленные выгоды. Соглашаясь выделить ресурсы, топ-менеджмент принимает и риски, связанные с эксплуатацией результатов: продажи, использование в операционном цикле, актуальность для клиентов, возможности и мощности инфраструктуры и т.п.
2. Руководитель проекта отвечает за получение необходимых продуктов и услуг с требуемым уровнем качества. Его ответственность – реализовать задуманное и передать готовый к использованию продукт или услугу Заказчику.
3. Заказчик ответственен за непосредственное использование результатов после завершения проекта и получение выгод.

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

Итак, какие же основные роли, их интересы и конфликты существуют при закрытии проекта:

Задачей КСУП при создании процесса завершения проекта является максимальная защита интересов его основных стейкхолдеров и минимизация возможных конфликтов.

Документы и их роль в разрешении конфликтов

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

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

Не менее важным фактором успеха является качество документов и их применения. Только не стоит подразумевать под качеством максимально полный по объему документ. Бюрократия не поможет добиться цели по ускорению использования результатов, а, напротив, может затянуть весь процесс завершения работ. Чтобы документ был коротким, понятным и работающим, необходимо формировать его на протяжении всего проекта. Как же готовиться к завершению?

1. Обучать команду методам управления проектами. Знакомить с жизненным циклом и используемыми документами. Нужно создать среду, внутри которой участники и, конечно, руководитель проекта понимают, для чего нужны результаты и как их нужно передавать. В своей практике я проводила регулярное обучение для руководителей проектов и основных заказчиков, в рамках которого давала понимание всех процессов и способы применения ключевых документов. Кроме того, объясняла сотрудникам, как правильно завершить проект и запустить результаты.
2. Управлять проектом, ориентируясь на результат, по методу контрольных точек. Это означает, что вся работа на проекте должна быть обращена именно на его завершение: получение итоговых продуктов и услуг, передача результатов в операционный цикл, мотивацию команды. Для этого уже при стартовом совещании по проекту необходимо установить целевые ориентиры для команды и определить требования для завершения работ. Как будет оцениваться работа участников, какая мотивация будет применена и какие параметры будут влиять на мотивацию. Какие продукты должны быть переданы, как их предполагается использовать, и что ожидается по итогам проекта в организации. Важно акцентировать внимание и на такие ключевые для итогов проекта моменты. Тогда при завершении проекта фиксация параметров мотивации будет логичным и менее конфликтным делом.
3. Использовать стандартные планы работ. Если в компании есть схожие по сути проекты (ИТ, строительные, регуляторные, социальные), то стоит использовать типовой набор контрольных точек (фаз), в которые включены работы по передаче ответственности. Например, для разработки ИТ-решений достаточно стандартные шаги:

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

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

Все наши проекты в обязательном порядке проходили приемку и передачу на сопровождение. Это позволяло сразу после завершения проекта запускать результаты и поддерживать использование продуктов для клиентов и пользователей. Мы минимизировали риски простоя и обеспечили максимальные возможности для достижения выгод.

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

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

Перечислю основные параметры такого финального документа:

• Ответственные лица: Руководитель проекта, Заказчик, Куратор, Спонсор;
• Плановые ограничения и отклонения проекта: сроки, бюджет, материалы;
• Полученные результаты проекта, кто и когда их принял;
• Решение о вводе в промышленную эксплуатацию: число и ответственность;
• Исключения и допущения проекта. Здесь стоит зафиксировать ключевые угрозы и возможности результатов, о которых знает команда и которые необходимо передать в эксплуатацию;
• Оценка работы команды проекта;
• Оценка работы Проектного офиса.

Помимо итогового отчета по проекту могут использоваться и другие полезные документы: отдельные акты приемки работ, разрешения, сертификаты и допуски, презентация результатов проекта. С развитием КСУП и культуры управления можно создать целостный и удобный набор шаблонов, который может быть еще и автоматически заполнен данными из программного продукта. Автоматизация заполнения документов, с одной стороны, упрощает работу руководителя проекта, а, с другой, позволяет сделать отчет более полным.

Приведу пример из своей практики. На последнем месте работы я автоматизировала создание итогового отчета по проекту на базе системы ADVANTA. Программный продукт позволил быстро cформировать по итогам проекта единый документ, в котором указаны все параметры проекта из системы, а также данные по полученным результатам (контрольным точкам). Для каждого результата указаны плановые и фактические сроки завершения, отклонение, ссылка на раздел системы, где хранятся итоговые документы. В шаблоне также размечены поля для свободного заполнения.

Во второй части статьи речь пойдет о роли КСУП и Проектного офиса в процессе завершения проекта.

Источник: www.advanta-group.ru