Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Треугольник управления проектом

Треугольник управления проектом (называемый также тройные ограничение , железный треугольник и проект треугольника ) представляет собой модель ограничений управления проектами . Хотя его происхождение неясно, оно использовалось по крайней мере с 1950-х годов. [1] Он утверждает, что:

  1. Качество работы ограничивается проектом бюджета, сроками и сферой применения (функции).
  2. Менеджер проекта может торговать между ограничениями.
  3. Изменения в одном ограничении требуют изменений в других, чтобы компенсировать это, иначе качество пострадает.

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

«Хорошо, быстро, дешево. Выбери два». и аналогичные операторы часто используются для краткой инкапсуляции ограничений треугольника. [2] [3]

Однако на практике торговля между ограничениями не всегда возможна. Например, вложение денег (и людей) в полностью укомплектованный проект может замедлить его. [4] Более того, в плохо управляемых проектах часто невозможно улучшить бюджет, график или объем без ущерба для качества.

Треугольник управления проектами используется для анализа проектов. [5] Часто ошибочно определяют успех как выполнение требуемого объема работ с разумным качеством в рамках установленного бюджета и графика. [6] [7] [8] Треугольник управления проектом считается недостаточным в качестве модели успеха проекта, поскольку он не учитывает важнейшие параметры успеха, включая влияние на заинтересованные стороны, [9] обучение [10] и удовлетворенность пользователей. [11]

Обзор [ править ]

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

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

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

В качестве графического средства управления проектом треугольник может отображать время, ресурсы и техническую цель в виде сторон треугольника, а не углов. [12] Джон Сторк, бывший преподаватель курса «Базовое управление проектами» Американской ассоциации менеджмента, использовал пару треугольников, называемых внешним и внутренним треугольником, чтобы представить концепцию, согласно которой проект должен быть завершен не позднее. разрешенное время, в рамках бюджета или в рамках бюджета, и соответствовать или превышать требуемый объем. Расстояние между внутренним и внешним треугольниками иллюстрирует изгородь или непредвиденные обстоятельства для каждого из трех элементов. Смещение можно было показать по расстоянию. Его примером проекта с сильным уклоном во времени был трубопровод на Аляске.что, по сути, нужно было сделать вовремя, независимо от затрат. После нескольких лет разработки нефть вытекла из конца трубы в течение четырех минут по графику . На этой иллюстрации временная сторона внутреннего треугольника была фактически поверх внешней линии треугольника. То же самое касалось и линии технической цели. Линия затрат внутреннего треугольника, однако, была внешней, поскольку проект значительно превышал бюджет.

Джеймс П. Льюис [13] предполагает, что объем проекта представляет собой площадь треугольника и может быть выбран в качестве переменной для достижения успеха проекта. Он называет эту взаимосвязь PCTS (производительность, стоимость, время, объем) и предлагает проекту выбрать любые три.

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

Модель STR [ править ]

Модель STR - это математическая модель, которая рассматривает «модель треугольника» как графическую абстракцию отношения:

Объем = Время × Ресурсы

Объем относится к сложности (что также может означать качество). Ресурсы включают людей (рабочих), финансовые и физические. Обратите внимание, что эти значения не считаются неограниченными. Например, если один пекарь может испечь буханку хлеба за час в духовке, это не значит, что десять пекарей могут испечь десять буханок за один час в одной и той же духовке (из-за ее вместимости).

Темы треугольника управления проектами [ править ]

Время [ править ]

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

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

Использование фактической стоимости предыдущих аналогичных проектов в качестве основы для оценки стоимости текущего проекта.

Согласно Своду знаний по управлению проектами (PMBOK), процессы управления сроками проекта включают в себя:

  1. Планирование управления расписанием
  2. Определить действия
  3. Последовательность действий
  4. Оценка ресурсов деятельности
  5. Оценить продолжительность активности
  6. Разработать расписание
  7. График контроля

Определить действия [ править ]

  1. Входные данные: план управления, исходный объем работ, факторы среды предприятия, активы организационного процесса.
  2. Инструменты: декомпозиция, планирование катящейся волны, экспертная оценка.
  3. Выходы: список действий, атрибуты деятельности, список вех.

Последовательность действий [ править ]

  1. Входы: Project Scope себе , активность Список, активность Атрибуты, Вехи Список, Одобренные запросы на изменение
  2. Инструменты: метод построения диаграмм приоритета (PDM), метод диаграмм стрелок (ADM), шаблоны сети расписания, вырождение зависимостей, применение опережений и задержек.
  3. Выходные данные: сетевые диаграммы расписания проекта, обновления списка действий, обновления атрибутов действий, изменения запросов.

Оценка ресурсов активности [ править ]

  1. Входы: Факторинг среды предприятия, активы организационного процесса, список действий, атрибуты деятельности, доступность ресурсов, план управления проектом.
  2. Инструменты: сбор экспертных оценок, альтернативный анализ, публикация оценочных данных, реализация программного обеспечения для управления проектами, оценка снизу вверх.
  3. Выходы: требования к ресурсам деятельности, атрибуты деятельности, иерархическая структура ресурсов, календари ресурсов, обновления запросов на изменение.

Оценка продолжительности активности [ править ]

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

График разработки [ править ]

  1. Входы: активы организационного процесса, описание содержания проекта, список действий, атрибуты действий, сетевые диаграммы расписания проекта, требования к ресурсам действий, календари ресурсов, оценки продолжительности действий, план управления проектом, реестр рисков.
  2. Инструменты: анализ сети по расписанию, метод критического пути, сжатие расписания, анализ сценария «что если», выравнивание ресурсов, метод критической цепочки, программное обеспечение для управления проектами, применение календарей, корректировка опережения и запаздывания, модель расписания.
  3. Выходные данные: график проекта, данные модели расписания, базовый план расписания, обновление требований к ресурсам, атрибуты деятельности, обновления календаря проекта, изменения запросов, обновления плана управления проектом, обновления плана управления расписанием.

Управление расписанием [ править ]

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

Из-за сложного характера группы процессов «Время» были созданы учетные данные для управления проектами PMI Scheduling Professional (PMI-SP).

Стоимость [ править ]

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

Области затратного процесса [ править ]

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

Программное обеспечение для управления проектами можно использовать для расчета отклонений стоимости проекта.

Сфера [ править ]

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

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

Эволюция модели ограничений проекта [ править ]

Звезда управления проектами по PMBOK
Интерпретация модели треугольника
Интерпретация звездной модели, обратите внимание, что «риск» и «качество» поменяны местами.

Традиционно модель ограничений проекта признавала три ключевых ограничения; «Стоимость», «Время» и «Объем». Эти ограничения образуют треугольник с геометрическими пропорциями, иллюстрирующий сильную взаимозависимую связь между этими факторами. Если есть требование изменить какой-либо из этих факторов, то по крайней мере, один из других факторов также должен быть изменен. [15]

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

Такое широкое использование вариаций подразумевает уровень двусмысленности, связанный с нюансом третьего ограничивающего члена, и, конечно же, уровень ценности гибкости модели треугольника. Эта неоднозначность позволяет размыть фокус между результатами проекта и процессом проекта, при этом приведенные выше примеры терминов имеют потенциально разный импульс в двух контекстах. И «Стоимость», и «Время» / «Доставка» представляют собой затраты проекта верхнего уровня.

Модель «Project Diamond» [16] порождает этот размытый фокус за счет включения «объема» и «качества» отдельно в качестве «третьего» ограничения. Несмотря на то, что добавление «качества» в качестве ключевого сдерживающего фактора, признавая растущую зрелость управления проектами, имеет свои достоинства, этой модели все еще не хватает ясности между результатами и процессом. Однако алмазная модель не отражает аналогию с сильной взаимосвязью между точками треугольников.

PMBOK 4.0 предлагает усовершенствованную модель, основанную на тройном ограничении, с 6 факторами, которые необходимо отслеживать и управлять. [17] Это проиллюстрировано в виде шестиконечной звезды, которая сохраняет силу аналогии с треугольником (два наложенных треугольника), и в то же время представляет разделение и взаимосвязь между факторами затрат / результатов проекта на одном треугольнике и факторами процессов проекта на другой. Звездные переменные:

  1. Треугольник
    • Объем
    • Расходы
    • Время
  2. Треугольник
    • Риск
    • Качественный
    • Ресурсы

При рассмотрении двусмысленности третьего ограничения и предложений «Проекта Бриллиант»; Вместо этого можно рассматривать цель или продукт проекта как третье ограничение, состоящее из подфакторов «Объем» и «Качество». Что касается результатов проекта, то и «Объем», и «Качество» могут быть скорректированы, что приведет к общему манипулированию целью / продуктом. Эта интерпретация включает четыре ключевых фактора в исходной треугольной форме входов / выходов. Это может быть даже включено в PMBOK Star, демонстрируя, что «Качество», в частности, может контролироваться отдельно с точки зрения результатов проекта и процесса. В дополнение к этому предложению, использование термина «Цель» может лучше всего отражать результаты инициативы по изменению,в то время как Продукт может лучше всего представлять более ощутимые результаты. [18]

См. Также [ править ]

  • Качество, стоимость, доставка
  • Трилемма
  • Тернарный сюжет

Ссылки [ править ]

  1. ↑ Аткинсон, Роджер (декабрь 1999 г.). «Управление проектом: стоимость, время и качество, два предположения и феномен, пора принять другие критерии успеха». Международный журнал управления проектами . 17 (6): 337–342. DOI : 10.1016 / S0263-7863 (98) 00069-6 .
  2. ^ https://www.academia.edu/8294762/Theory_of_the_Triple_Constraint_a_Conceptual_Review
  3. ^ https://support.microsoft.com/en-us/office/the-project-triangle-8c892e06-d761-4d40-8e1f-17b33fdcf810
  4. ^ Брукс, Фредерик (1995). Мифический человеко-месяц (Юбилейный ред.). Бостон, Массачусетс, США: ISBN Addison-Wesley Longman Publishing Co., Inc. 0-201-83595-9.
  5. ^ Эрик Bethke (2003). Разработка и производство игр . стр.65.
  6. ^ Майкл В. Ньюэлл, Марина Н. Грашина (2004). Книга вопросов и ответов по управлению проектами . стр.8
  7. ^ Памела МакГи, Питер Макэлини (2007). Безболезненное управление проектом . стр.74.
  8. ^ Майкл Джентиле, Рональд Д. Коллетт, Томас Д. Август (2005). Справочник CISO . стр.172
  9. ^ Ральф, Пол; Келли, Пол (2014). «Измерения успеха программной инженерии» . Материалы 36-й Международной конференции по программной инженерии . ACM: 24–35. DOI : 10.1145 / 2568225.2568261 . ISBN 9781450327565. S2CID  14897722 .
  10. ^ Шенхар, А .; Двир, Дов (1997). «Отображение размеров успеха проекта». Журнал управления проектами . 28 (2): 5–13.
  11. ^ Делоне, Уильям Х .; Маклин, Эфраим Р. (1 апреля 2003 г.). «Модель успеха информационных систем Делона и Маклина: последние десять лет». Журнал информационных систем управления . 19 (4): 9–30. DOI : 10.1080 / 07421222.2003.11045748 . ISSN 0742-1222 . 
  12. ^ Карл С. Чатфилд, Тимоти Д. Джонсон (2003). Microsoft Office Project 2003 Шаг за шагом: шаг за шагом . С. 476.
  13. ^ Льюис, Джеймс П. (2005). Планирование, составление графиков и контроль проекта, 4E . Макгроу Хилл. ISBN 978-0-07-146037-8.
  14. ^ PMBOK Третье издание 2004 с.165
  15. ^ ( Чатфилд, Карл. «Краткий курс управления проектами» . Microsoft.)
  16. ^ ( Браун, Крейг. «Раньше это был Железный треугольник» . Better Project.)
  17. ^ Институт управления проектами (2009) Руководство к своду знаний по управлению проектами: Руководство PMBOK . Глава 1
  18. ^ Брем (2011) T214 Понимание сложных систем - TMA02 . 4 квартал

Внешние ссылки [ править ]

  • СМИ, связанные с треугольником управления проектами на Викискладе?