что такое проектный треугольник
Как работать с горящими дедлайнами?
Объясняем, как не поддаться панике и всё же успеть в срок
Сама по себе ситуация, когда дедлайны поджимают, абсолютно нормальна и даже может хорошо мотивировать. Проблемы возникают, когда такое происходит регулярно и приводит к срыву сроков всего проекта. Ещё одно негативное последствие — высокий уровень стресса и даже выгорание членов команды. Особенно если все выложились по максимуму и всё равно не успели. Разберёмся, что можно сделать, чтобы не сгорали ни дедлайны, ни участники команды, вместе с Галиной Нестеровой, наставником на курсе «Менеджер проектов» в Яндекс.Практикуме.
Почему возникают горящие сроки?
В рамках управления проектом менеджер поэтапно решает четыре важные задачи:
Все они тесно связаны друг с другом и образуют единую систему, от которой зависит успех в управлении проектом и конечный результат. Проблемы обычно возникают, если менеджер неверно спланировал или организовал процесс, вовремя не позаботился о мотивации и результате. Причины горящих сроков, как правило, кроются в первых двух этапах:
Планирование
Когда мы планируем сроки, то опираемся на прошлый опыт с подобными проектами, а также на информацию, которую получаем от команды или клиента. Но даже если учесть всё это и заложить возможные риски, план может не сработать.
Это происходит потому, что на начальном этапе мы переоцениваем известные нам вводные. Мы не можем знать, кто и когда заболеет, у кого упадёт продуктивность из-за личных проблем и какие технические ограничения внезапно возникнут по ходу проекта.
Поэтому остаётся просто принять как факт: есть вещи, о которых мы даже не подозреваем на этапе планирования, и поэтому не можем их учесть, как бы ни старались. И это нормально. Нужно просто вовремя замечать любые события, которые могут повлиять на сроки, и оперативно реагировать на них, а не впадать в панику.
Организация процесса
В этой части стратегические решения принять уже вряд ли получится, но можно своевременно реагировать на то, что происходит в команде.
Чтобы понять, всё ли в порядке и почему горят сроки на этом этапе, нужно ответить на главные вопросы:
Что такое проектный треугольник и как он может помочь?
Один из инструментов эффективного планирования — проектный треугольник. Есть разные стратегии проект-менеджмента, но большинство из них опирается на три ограничения:
Проектный треугольник, который образуют эти ограничения, похож на сообщающиеся сосуды: уровень жидкости в одном из них зависит от остальных. То же касается и углов треугольника: невозможно изменить бюджет, время или объем работ, не повлияв по крайней мере на одно из двух других ограничений. Это важно учитывать и на этапе планирования, и в процессе реализации проекта.
Если мы фиксируем сроки и бюджет, то задачи и объем работ можно менять. Представим, что вам нужен рабочий сайт через месяц, но в процессе вы понимаете, что не успеете уложиться в срок. Тогда вместе с командой вы меняете работу так, чтобы через месяц у вас был дизайн-макет и прототип с кликабельными иконками, но без части функций и контента.
Для каждого проекта нужна своя стратегия, которую можно менять на ходу, если потребуется. Иногда лучше пожертвовать сроками, чем конечным результатом, иногда — сделать меньше, но уложиться в срок.
Что делать, если сроки уже горят?
Здесь нужно уделить внимание сразу двум задачам — организации процесса и мотивации сотрудников.
Во-первых, важно вовремя реагировать на любые сигналы и внешние обстоятельства, которые влияют на проект. Например, если кто-то заболел или просто выгорел, внутри команды возник конфликт или корпоративный сервис перестал работать. Проблему нужно решать, параллельно сдвигая сроки или перераспределяя задачи. Не стоит надеяться, что всё рассосётся само собой.
Во-вторых, важно поддерживать продуктивную атмосферу. Не просто подбадривать, а предлагать реальную помощь или даже выходной, если сотрудник в этом нуждается. Не игнорировать конфликты, а вместе обсуждать, почему они происходят и как их можно преодолеть. Результат любой ценой — это победа на короткой дистанции, но марафон с таким подходом вы не пробежите.
Как извлечь пользу из горящих сроков?
Здесь мы переходим к четвёртой задаче менеджера — контролю результатов. С одной стороны, всем важно достичь поставленной цели — как минимум для того, чтобы все усилия были не напрасны. С другой стороны, важно помнить, что результат — это не просто цифры, а ещё и полезный опыт, извлеченный в процессе.
Горящие сроки можно использовать во благо: например, сплотить команду, перераспределив задачи и помогая друг другу, или стимулировать к поиску новых решений. Это помогает придать дополнительную мотивацию, ведь когда все участвуют в принятии решений и успешно справляются с трудностями, то результат становится более ценным для каждого из участников.
Важно не нагнетать, не давить на отстающих и не обрушиваться с критикой. Тогда ускоренный темп может привести к качественным скачкам в развитии проекта и команды в целом. Главное — вместе извлечь конструктивные выводы на будущее, и когда горящие сроки отступят, отрефлексировать этот опыт.
Вот что можно посоветовать всем, кто работает в условиях горящих сроков:
Что нужно сделать до старта проекта? Часть 3. Ограничения проекта
В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним, как необходимому шагу для снижения неопределенности проекта. Вторая статья цикла посвящена формулированию допущений по проекту и переходу от допущений к рискам, которые надо будет учесть при планировании сроков и бюджета проекта.
Для того чтобы перейти к подписанию документов, подтверждающих официальное признание проекта, нужно сделать еще один важный шаг – сформулировать ограничения по проекту.
В управлении проектами используется термин «проектный треугольник», для которого используют также название «тройное ограничение проекта». Проектный треугольник описывает взаимодействие ключевых ограничений проекта:
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?
Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата требованиям к нему.
Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).
Таким образом, качество результатов проекта тесно связано с содержанием проекта, в котором описаны требования к результатам.
Логика формирования ограничений по проекту следующая:
Как работает проектный треугольник?
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.
Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться о приоритетах: что важнее для проекта – срок, содержание, качество или бюджет.
Многие из вас уже видели похожие картинки:
Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника, то он пытается передать руководителю проекта все риски, связанные с изменениями в проекте. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например, равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть?
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
По выполнению проекта в рамках его ограничений судят об успехе проекта.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.
Итак, критерием успешности проекта является реализация всех запланированных результатов проекта, причем в срок и в бюджет.
Шаги по подготовке проекта к старту следующие:
Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!
Разработчик в треугольнике управления проектами
Излагаются два подхода, которые потенциально позволяют дать объективную оценку, на сколько работа разработчика на проекте удовлетворяет требованиям качества, сроков и бюджета.
Управление проектом — это организация процесса по успешному, т. е. за отведённое время и без превышения выделенного бюджета, достижению поставленной цели. Конечный продукт при этом должен обладать заданными изначально свойствами и быть приемлемого качества.
Во многих случаях приходится искать баланс между ограничениями по времени, затратам и содержанием проекта. Очень наглядной иллюстрацией является проектный треугольник, (картинка поскольку три стороны треугольника связаны, и изменение одной стороны влияет, по крайней мере, на одну из двух других сторон, демонстрируя процесс балансировки ограничений).
В качестве примера можно рассмотреть ситуацию, когда требуется сократить срок сдачи проекта. Для этого может понадобиться увеличить бюджет и использовать больше ресурсов, с помощью которых тот же объем работы будет выполнен за меньшее время. Если же увеличение бюджета недопустимо, необходимо уменьшить содержание проекта, поскольку с наличными ресурсам нет возможности выполнить весь запланированный объем работ за меньшее время.
Создание, за отведённое время и в рамках заданного бюджета, качественного программного обеспечения, которое удовлетворяет реальным потребностям заказчика — это процесс, который можно и нужно описывать на языке управления проектами. Разработчик — одна из ключевых ролей в этом процессе. Мне кажется, принципиально возможно оценить профессионализм девелопера, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройственной ограниченности.
В идеале каждая задача, которая поставлена разработчику, должна быть решена так, чтобы:
Естественно, что накладываемые ограничения должны быть адекватными, как с точки зрения общепринятых норм, так и относительно возможностей самого разработчика. (Но обсуждение этого вопроса выходит за рамки данной статьи, а по умолчанию мы считаем, что каждая задача, по решению которой оценивается профессионализм разработчика, является корректной поставленной и не имеющей чрезвычайно завышенных требований).
Зачем это нам нужно?
Но формирование таких критериев требует сильной формализации в описании процесса разработки. К текущему моменту у нас намечается два пути. Они различаются в подходах к двум из трёх сторон треугольника управления проектом: срокам и бюджету. Прежде чем перейти к этим различиям, очень кратко опишем идею нашего подхода к оценке качества.
В дополнение к стандартным методам QA, предполагается получать метрики качества кода с помощью статических анализаторов типа SonarQube. Думаю, что эти данные вполне можно соотнести с результатами работы каждого разработчика в проекте, а также оценивать любые части проекта и проект в целом. Возможно, что дополнительным параметром, оценивающим качество труда разработчика будет отношение времени потраченного на решение поставленной задачи к времени, потраченному на исправление относящихся к этой задачи багов.
Теперь о двух возможных подходах к деньгам и ко времени
Первый взгляд на эту проблему исходит из того, что далеко не в каждом случае можно рассчитывать на наличие всех исходных данных. В целом для расчёта показателей, относящихся к попаданию в сроки, необходимы:
Относительно бюджетных характеристик этот подход рассматривает три варианта проектов с точки зрения подхода к ценообразованию:
В связи со всем изложенным выше, возникает несколько естественных вопросов:
Во-первых, какой из двух подходов, на ваш взгляд, лучше описывает профессионализм разработчика в контексте попадания в сроки/бюджет/качество? И какие варианты, кроме проектного треугольника, можно было бы использовать?
Во-вторых, хотелось бы понять, можно ли соотнести бюджеты в деньгах с эстимейтами и реально потраченными часами в задачах? Что такое сроки и относятся ли они к эстимейтам или же к Start date и Due Date?
Возможно ли учесть различия в проектах с точки зрения подхода к ценообразованию (fixed cost, time and material, другие варианты) при расчёте бюджетной метрики для конкретного разработчика, или для него имеет смысл только fixed cost подход?
В-третьих, интересно, насколько корректно использовать модель, которая иллюстрирует объективные ограничения, возникающие при управлении проектами, для количественного описания профессионализма разработчика?
Буду рад услышать ваше мнение на этот счет!
Например, проект можно завершить быстрее за счет увеличения бюджета или сокращения объема работ. Точно так же увеличение объема может потребовать эквивалентного увеличения бюджета и графика. Сокращение бюджета без корректировки графика или объема приведет к снижению качества.
«Хорошо, быстро, дешево. Выбери два». и аналогичные операторы часто используются для краткой инкапсуляции ограничений треугольника.
Однако на практике торговля между ограничениями не всегда возможна. Например, вложение денег (и людей) в полностью укомплектованный проект может замедлить его. Более того, в плохо выполняемых проектах часто невозможно улучшить бюджет, график или объем без ущерба для качества.
Треугольник управления проектами используется для анализа проектов. Его часто неправильно используют для определения успеха как выполнения требуемого объема работ с разумным качеством в рамках установленного бюджета и графика. Треугольник управления проектом считается недостаточным в качестве модели успеха проекта, поскольку он не учитывает важнейшие аспекты успеха, включая влияние на заинтересованные стороны, обучение и удовлетворенность пользователей.
СОДЕРЖАНИЕ
Обзор
Ограничение по времени относится к количеству времени, доступному для завершения проекта. Ограничение по стоимости относится к бюджетной сумме, доступной для проекта. Ограничение объема относится к тому, что должно быть сделано для достижения конечного результата проекта. Эти три ограничения часто являются конкурирующими: увеличение объема обычно означает увеличение времени и затрат, жесткое ограничение по времени может означать увеличение затрат и сокращение объема, а ограниченный бюджет может означать увеличение времени и сокращение объема.
Дисциплина управления проектами заключается в предоставлении инструментов и методов, которые позволяют команде проекта (а не только менеджеру проекта ) организовать свою работу в соответствии с этими ограничениями.
Джеймс П. Льюис предполагает, что объем проекта представляет собой площадь треугольника и может быть выбран в качестве переменной для достижения успеха проекта. Он называет эту взаимосвязь PCTS (производительность, стоимость, время, объем) и предлагает проекту выбрать любые три.
Модель STR
Объем = Время × Ресурсы
Объем относится к сложности (что также может означать качество). Ресурсы включают людей (рабочих), финансовые и физические. Обратите внимание, что эти значения не считаются неограниченными. Например, если один пекарь может испечь буханку хлеба за час в духовке, это не значит, что десять пекарей могут испечь десять буханок за один час в одной и той же духовке (из-за ее вместимости). Девять женщин не могут родить за один месяц.
Темы треугольника управления проектами
Время
Задачи также распределяются по приоритетам, определяются зависимости между задачами, и эта информация документируется в расписании проекта. Зависимости между задачами могут повлиять на продолжительность всего проекта (с ограничениями по зависимостям), как и на доступность ресурсов (с ограничениями по ресурсам). Время отличается от всех других ресурсов и категорий затрат.
Использование фактической стоимости предыдущих аналогичных проектов в качестве основы для оценки стоимости текущего проекта.
Согласно Своду знаний по управлению проектами (PMBOK), процессы управления сроками проекта включают в себя:
Определить действия
Последовательность действий
Оценка ресурса деятельности
Оценка продолжительности деятельности
График разработки
Контроль расписания
Из-за сложного характера группы процессов «Время» были созданы учетные данные для управления проектами PMI Scheduling Professional (PMI-SP).
Расходы
Области затратного процесса
Инструменты оценки затрат на управление проектом
Программное обеспечение для управления проектами можно использовать для расчета отклонений стоимости проекта.
Сфера
Требования, указанные для достижения конечного результата. Общее определение того, что должен выполнить проект, и конкретное описание того, каким должен быть конечный результат. Основным компонентом объема работ является качество конечного продукта. Количество времени, затраченного на выполнение отдельных задач, определяет общее качество проекта. Некоторые задачи могут потребовать определенного количества времени для адекватного завершения, но большее время может быть выполнено в исключительных случаях. В ходе большого проекта качество может существенно повлиять на время и стоимость (или наоборот).
Вместе эти три ограничения породили фразу «вовремя, по спецификации, по бюджету». В этом случае термин «область действия» заменяется на «спецификацию».
Эволюция модели ограничений проекта
Традиционно модель ограничений проекта признавала три ключевых ограничения; «Стоимость», «Время» и «Объем». Эти ограничения образуют треугольник с геометрическими пропорциями, иллюстрирующий сильную взаимозависимую связь между этими факторами. Если есть требование изменить какой-либо из этих факторов, то по крайней мере, один из других факторов также должен быть изменен.
Такое широкое использование вариаций подразумевает уровень двусмысленности, связанный с нюансом третьего ограничивающего члена, и, конечно же, уровень ценности гибкости модели треугольника. Эта неоднозначность позволяет размыть фокус между результатами проекта и процессом проекта, при этом приведенные выше примеры терминов имеют потенциально разный импульс в двух контекстах. И «Стоимость», и «Время» / «Доставка» представляют собой затраты проекта верхнего уровня.
Модель «Project Diamond» порождает этот размытый фокус за счет включения «объема» и «качества» отдельно в качестве «третьего» ограничения. Несмотря на то, что добавление «качества» в качестве ключевого сдерживающего фактора, признавая растущую зрелость управления проектами, имеет свои достоинства, этой модели все еще не хватает ясности между результатами и процессом. Однако алмазная модель не отражает аналогию с сильной взаимосвязью между точками треугольников.
PMBOK 4.0 предлагает усовершенствованную модель, основанную на тройном ограничении, с 6 факторами, которые необходимо отслеживать и управлять. Это проиллюстрировано в виде шестиконечной звезды, которая поддерживает силу аналогии с треугольником (два наложенных треугольника), и в то же время представляет разделение и взаимосвязь между факторами входов / выходов проекта в одном треугольнике и факторами процессов проекта в другом. Звездные переменные:
При рассмотрении двусмысленности третьего ограничения и предложений «Проекта Бриллиант»; Вместо этого можно рассматривать цель или продукт проекта как третье ограничение, состоящее из подфакторов «Объем» и «Качество». Что касается результатов проекта, то и «Объем», и «Качество» могут быть скорректированы, что приведет к общему изменению цели / продукта. Эта интерпретация включает четыре ключевых фактора в исходной треугольной форме входов / выходов. Это может быть даже включено в PMBOK Star, демонстрируя, что «Качество», в частности, может контролироваться отдельно с точки зрения результатов проекта и процесса. В дополнение к этому предложению, использование термина «Цель» может лучше всего отражать результаты инициативы по изменению, в то время как «Продукт» может лучше всего представлять более ощутимые результаты.
Что нужно сделать до старта проекта. Часть 3
Что важно предусмотреть и учесть до начала проекта, чтобы он прошел успешно, продолжает рассказывать наш эксперт Максим Якубович.
– В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним (необходимый шаг для снижения неопределенности проекта). Вторая статья была посвящена определению допущений по проекту и переходу от них – к рискам проекта. Это важно при планировании сроков и бюджета проекта.
Чтобы перейти к подписанию документов, официально утверждающих проект, нужно сделать еще один важный шаг – сформулировать ограничения по проекту. Расскажу об этом подробнее.
В управлении проектами используется термин «проектный треугольник» (употребляют еще понятие «тройное ограничение проекта»). Проектный треугольник описывает взаимодействие ключевых ограничений:
1. Содержание проекта. В простейшем случае оно может выглядеть как список работ по проекту, которые нужно реализовать, чтобы достигнуть целей и получить запланированные результаты. Для некоторых проектов содержание описывают в виде совокупности документов, например:
Чем точнее описано содержание проекта, тем проще спрогнозировать сроки и бюджет проекта.
2. Время реализации. Это ограничения по продолжительности проекта, включающие дату, к которой нужно получить ожидаемые результаты
3. Бюджет. Ограничение по стоимости проекта.
4. Качество. Ограничение, связанное с тем, в какой степени выполняются требования к результатам. Например, заказчика может устроить, что будут реализованы лишь самые важные требования проекта.
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в виду? Можно рассуждать о качестве и самого проекта и его результатов. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата и требованиям к нему. Качество результатов можно проверить, сравнив то, что получилось – с тем, что требовалось получить. Грубо говоря, сравнив итоговый продукт проекта с требованиями к нему.
Таким образом, качество проекта тесно связано с его содержанием. В нем и описаны требования к этим результатам.
Логика формирования ограничений по проекту следующая:
1. Уточнить содержание проекта, определив цели. Понимая это, можно определить результаты и требования к ним.
2. Понимая требования к результатам проекта, определить список работ по проекту.
3. Понимая список работ по проекту, определить сроки и бюджет.
4. Зафиксировать договоренности о содержании, сроках, бюджете и качестве проекта как ограничения проекта.
Как работает проектный треугольник
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если не учтены важные требования во время их сбора – это приведет к появлению новых работ в содержании проекта. Сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «Бюджет», либо увеличив сторону «Срок». Либо увеличив обе.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие. Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться, что важнее для проекта – срок, содержание, качество или бюджет?
Многие из вас уже видели похожие картинки, которые помогают расставить приоритеты.
Если заказчик настаивает, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам – желательно, чтобы к моменту старта эти требования уже были собраны и утверждены. Тогда руководитель проекта под эти требования может просчитать бюджет и срок.
При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования – срок и/или бюджет проекта придется изменять.
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника – это значит, он пытается передать руководителю проекта все риски, связанные с изменениями. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Какова логика встраивания рисков в ограничения? В Своде знаний по управлению проектами PMBOK есть следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Они в свою очередь могут повлиять на содержание проекта, сроки или бюджет.
Стоит ли использовать шесть типов ограничений или достаточно определить три (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
Об успехе проекта судят по его выполнению в рамках ограничений.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались, то измерение успешности проекта будет делаться относительно последних согласованных с заказчиком параметров.
Итак, типовые критерии успешности проекта обычно следующие.
Проект реализовал все запланированные результаты, причем был выполнен в срок и в бюджет.
Шаги по подготовке проекта к старту выглядят так:
1. Согласовать цели проекта с заказчиком.
2. Описать результаты проекта.
3. Согласовать требования к результатам проекта.
4. Определить допущения проекта.
5. Определить ограничения проекта и критерии успешности проекта.
Этот документ становится гарантом, что руководитель проекта и заказчик одинаково понимают все важные аспекты.
Содержание Устава проекта может быть разным в различных компаниях. Но важность этого документа нельзя недооценивать.
Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».
Опыт работы в сфере управления проектами – более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.
Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.