Проектный треугольник
Классический клиент Project Online Project профессиональный 2021 Project стандартный 2021 Project профессиональный 2019 Project стандартный 2019 Project профессиональный 2016 Project стандартный 2016 Project профессиональный 2013 Project стандартный 2013 Project 2010 Project стандартный 2010 Еще. Меньше
«Вы можете иметь это хорошее, быстрое или дешевые. Выберите два».
Инженеры много лет говорят об этом руководителям проектов.
В разных терминах каждый проект имеет «треугольник» времени,денег и области охвата. Изменить один из них, не затроня хотя бы один из других, невозможно. Задача руководителя проекта — следить за тем, чтобы треугольник не распался.
Процедура Во-первых, когда возникает проблема, найдите ее в треугольнике проекта: имеет ли он время (расписание), деньги (бюджет) или область? Затем выясните, какие стороны треугольника можно изменить, а какие — фиксированные. В-третьих, устраив проблему и оптимизируйте проект. В-четвертых, завершите проект и отпразднуйте его!
В этой статье
- Time + money + scope = quality
- Что нельзя изменить
- Оптимизация расписания
- Оптимизация бюджета
- Оптимизация области
- Дополнительные информация об управлении проектами
Time + money + scope = quality
Треугольник проекта также называется «утюговом треугольником» и (менее широкое название — тройной ограничением). Это одно и то же: невозможно изменить бюджет, расписание или область проекта, не влияя на хотя бы одну из других частей.
Вот некоторые примеры того, как это работает:
- Чтобы привлечь дата окончания (времени), вы можете потратить больше ресурсов (денег), чтобы быстрее завершить работу или урезать функции (область), чтобы меньше работы необходимо сделать до нового крайнего срока.
- Чтобы завершить проект в рамках бюджета (затрат), можно избавиться от сверхурочных и завершить проект позднее (время) или срезать компонентов (область действия).
- Чтобы добавить функции в продукт (область), вы можете продлить крайний срок, чтобы уложить время на новую работу (время) или добавить людей для ее более быстрого выполнения (затраты). Вы также можете сделать и то, и другое!
Качество — это четвертая часть треугольника проекта. Оно расположено в центре, где любое изменение любой стороны влияет на его.
Например, если вы опережаете расписание, вы можете заменить функции вырезания или дать больше времени существующим задачам. Благодаря этому дополнительному времени и области результат может быть лучше.
Один из ключевых моментов: универсальный стандарт качества не существует. Для любого проекта качество определяется в самом проекте. Для некоторых компаний самой важной мерой качества является сохранение проекта в бюджете. Для других людей выход на рынок вовремя имеет больше значения. Руководитель проекта должен знать, как определяется качество для организации и конкретного проекта.
В предыдущем примере можно было просто завершить работу с продуктом раньше с большим количеством функций, чтобы он был раньше конкурентов. Это может быть определение качества для этого проекта в вашей компании.
Что нельзя изменить
В большинстве проектов по крайней мере одна сторона треугольника фиксирована. Изменить его нельзя.
Возможно, бюджет не подлежит обсуждению. (Похоже, вы знакомы?) Или, возможно, продукт должен выйти в продажу к определенной дате. Возможно, и то, и другое верно.
Часто фиксированные элементы проекта продиктуются руководителем проекта, но не всегда. Иногда решение о том, какой элемент является самым важным для успеха проекта, зависит от вашего плеча. И вам нужно быть понятным, если возникают проблемы (и они всегда возникают).
Когда проблема возникает на стороне исправлений, действовать не всегда достаточно. Например, если вы обнаружите, что разработка функции программного обеспечения займет больше времени, чем прогнозировался, и вы подписали контракт, в который будет добавлена эта функция (область), необходимо либо перенести дату окончания, либо добавить ресурсы, чтобы завершить ее вовремя.
Если стороны с исправлением и проблемойразные, не сдайте их. В этом и есть прелесть треугольника проекта. всегда есть место для внесения изменений. Например, если проект должен завершиться вовремя и он получил масштаб, вы все равно можете скорректировать затраты, добавив ресурсы.
Если все три стороны треугольниказависли, не стоит волнуйтесь. Возможно, у проекта возникли проблемы, но вы знаете, что у вас возникли проблемы, и у вас есть хорошая отправная точка для пересмотра целей проекта или стандартов качества.
Оптимизация расписания
Тем не менее вы столкнулись с проектом, который настроен на превышение крайнего срока.
Чтобы сократить расписание, можно сократить критический путь задачи, последняя задача которой завершается в дату окончания проекта. Изменение других задач может не сократить календарный план, но изменение задач критического пути будет выполняться. Чтобы сократить критический путь, вы можете:
- Сократите длительность задачи (уменьшите область действия или добавьте ресурсы).
- «Быстрое отслеживание» расписания: перекрытие задач, чтобы люди могли работать над ними одновременно (добавить ресурсы). Эту прием лучше использовать ближе к началу проекта.
- «Аварийное выполнение» расписания: добавление ресурсов для ускорения выполнения задач (деньги).
- Удаление задач (сокращение области действия).
Конечно, такое исправление расписания может существенно сказаться на бюджете, области и качестве проекта.
Оптимизация бюджета
В большинстве проектов наибольший фрагмент бюджета состоит из затрат на ресурсы: затраты на ресурсы с учетом ставок и фиксированные затраты на людей, оборудование и материалы. Для работы с бюджетом может потребоваться очень сложное решение.
- Сократите область проекта, чтобы сократить количество задач, для выполнения которые требуются ресурсы.
- Удаление ресурсов.
- Убедитесь, что подходят тарифы, сборы и сверхурочные.
- Убедитесь, что ресурсы лучше всего подходят для работы.
- Замените дорогой ресурс на более дорогой.
Контроль над затратами может привести к отключению крайнего срока или необходимости сократить масштаб проекта. Например, если для задач не разрешается сверхурочные работы, дата окончания может быть позже на месяц. Если же вы обрезали область, дата окончания может фактически переместиться в нее.
Оптимизация области
Можно ли сэкономить деньги, сделав мост на несколько футов короче его реки? Конечно, нет. Иногда область проекта не может измениться, поэтому вам придется принять другие меры:
- Добавьте ресурсы, чтобы убедиться, что все задачи завершены (затраты).
- Вырезание задач, которые не находятся на критическом пути (при их стоимости).
- Добавление задач или добавление длительности к задачам (затратам).
- Продлите крайний срок, чтобы разрешить время для всех задач с текущим уровнем ресурсов (времени).
Дополнительные информация об управлении проектами
- Выйдите за рамки Excel для управления проектами.
- История управления проектами.
- Как ваш проект должен в целом учитываться.
Ложь железного треугольника
Многие из вас слышали о таком термине, как Проектный Треугольник, описывающий баланс между содержанием, стоимостью, временем и качеством проекта. Но почему же он называется треугольником, если ограничения четыре? Сопоставим ли он со Scrum’ом? Читайте об этом в данной статье!
До моей карьеры в agile у меня часто бывал такой случай, когда проект был определен, спланирован, заложен в бюджет, объявлен, продан и расписан по времени — и затем почти сразу сходил с плана. Запоздалое уточнение или внезапное новое требование к планированию может мгновенно превратить лучшие планы менеджера проекта в бессмыслицу.
Даже если этого не произойдет, естественный ход развития проекта приведет к возникновению сложностей, которые невозможно было предвидеть при первичном планировании. Никакие благие намерения или интенсивная работа нам не могли помочь — все всегда заканчивалось тем, что мы должны объяснить клиенту, почему он не получит то, за что заплатил по графику, который мы обещали. Беседа выходит всегда веселой.
Оглядываясь назад на мою карьеру с использованием водопадной методологии управления проектами, я вспоминаю, что подобные проблемы происходили гораздо чаще, чем сейчас. Я могу вспомнить только два или три проекта, которые действительно шли в соответствии с планом, который мы заложили на первой же встрече с заказчиком. И все же мы продолжали работать по старинке снова и снова! Что может быть безумнее?
Так что можете себе представить мою радость, когда меня познакомили с Железным треугольником.
Также известный как проектный треугольник или тройственная ограниченность, Железный Треугольник — Это попытка простым способом передать взаимосвязь аспектов, влияющих на реализацию проекта.
Три стороны треугольника: содержание (scope), бюджет (budget) и время (time).
Исходя из принципа треугольника, все три аспекта соединены между собой в трех углах. Можно изменить любую из сторон, но, по крайней мере, одна из оставшихся двух тоже должна измениться, если вы собираетесь сохранить треугольник.
Как говорится: ”Если сломать треугольник, качество просочится наружу”. (Об этом позже.)
Ценность этой диаграммы заключается в том, что она легко передает идею о том, что, если вы увеличиваете содержание, вам нужно либо добавить бюджет (обычно с точки зрения количества членов команды), либо время. Если вы уменьшаете бюджет без изменения времени, вам нужно будет уменьшить содержание. И так далее.
Это довольно изящное выражение взаимосвязи некоторых факторов реализации проекта. И позвольте мне сказать вам, что иллюстрация этого треугольника на доске для заказчика, который запросил новую функцию, которую он только что придумал, обеспечило одни из самых тяжелых, но удовлетворительных моментов в моей карьере.
Это очень мощный инструмент для менеджеров водопадных проектов, чтобы исключить вмешательство заказчиков в проект. Мы называем это ”защитой содержания», но на самом деле речь идет о том, чтобы ценить подписанный лист бумаги, а не работать в коллаборации с реальными людьми.
То, что я никогда не понимал, пока не начал работать по-новому, — это то, что на самом деле есть четвертая сторона Железного треугольника.
Вот что делает все это ложью. Кто-то когда-нибудь слышал о четырехгранном треугольнике?
Подумайте вот о чем: сколько из нас, работающих над проектами по водопадной модели, застряли с неизменными требованиями, невозможными сроками и негибкими бюджетами одновременно? Когда все это просто не может работать, что вы делаете? Как вы это делаете?
Ответ для меня и многих других, кого я знаю, заключается в том, что вы отказываетесь от качества. Конечно, вы можете и не называть это так. Вы «сокращаете время тестирования» (то есть экономите на Quality Assurance — обеспечении качества). Вы “понижаете серьезность» стольких дефектов, сколько можете (т. е. игнорируете их), и все. Вы также можете сжать свой план развертывания, сократив время на обучение или найдя пользователей быстрее, что является компромиссом качества реализации.
Классический Железный Треугольник говорит, что качество страдает, если любая из трех сторон перемещается независимо от других, но я лично могу поручиться, что плохое качество также является результатом отказа подвинуть любую из трех сторон перед лицом неизбежных изменений проекта.
Качество не «утечет», если вы сломаете треугольник. Качество — это невидимая «четвертая сторона» треугольника, которая часто незаметно «меняется» в попытке удовлетворить остальные три ограничения.
И, конечно же, низкое качество грозит серьезными затратами на техническое обслуживание, снижает удовлетворенность пользователей и, конечно же, ценность, поставляемую клиенту. И, само собой, поскольку стандарты качества падают, а технический долг увеличивается, сроки поставки растягиваются, а затраты растут.
К счастью, Scrum спасает нас от всего этого. Мы можем потихоньку забывать о Железном Треугольнике!
В Scrum качество фиксируется. Это задано в определении «сделано» — вот и все.
В Scrum бюджет фиксирован. Scrum-команда стабильна и кросс-функциональна, содержит все наборы навыков, необходимые для доведения работы до конца.
Время в Scrum не фиксировано. Время до релиза — это неизвестное, небольшое число коротких спринтов фиксированной длины. Мы не притворяемся, что можем видеть будущее вплоть до даты развертывания; мы знаем эмпирически, что не можем.
Теперь можно поспорить, что Scrum все-таки фиксирован по времени. В конце концов, мы знаем, как долго длится каждый спринт, и мы знаем, что каждый спринт будет производить потенциальный прирост готовности продукта. Это правда! Но ключевое слово — ”потенциально». Только потому, что каждое приращение может быть развернуто, не означает, что они все будут развернуты. Количество спринтов, которые отделяют нас от релиза, заранее неизвестно и зависит от множества факторов, некоторые из которых не находятся под контролем команды. Мы делаем эту неопределенность планирования приемлемой для клиента, заставляя каждое приращение доставлять им ценность, даже если эта ценность не полностью наглядна пользователям.
Но самое главное, что не фиксируется в Scrum, — это содержание. Оно может меняться изо дня в день, прямо во время спринта, по мере изменения потребностей бизнеса и рыночных условий. Содержание очень легко изменяется, поскольку мы узнаем больше в процессе разработки или когда мы проверяем продукт с заинтересованными сторонами и клиентом. В Scrum мы не претендуем на то, что можем видеть будущее, даже в конце конкретного спринта! Принятие этой гибкости делает нас лучше в процессе разработки, и, конечно, оставляет нас с лучшим продуктом в конце концов.
Принципиально важно, что если ты хочешь быть гибким, то концепция “как долго это еще будет продолжаться?” должна быть выброшена из твоего мышления. “Как долго” задает непостижимый вопрос о времени. И что вообще означает «законченный», если вы не наткнулись на какие-то идеи на рынке по пути? (Но обратите внимание, насколько нерационально наше мышление при водопаде, что мы думаем, что это единственный самый важный вопрос, который нужно задать? Насколько наш подход основан на предположениях, мифологии, подчинении авторитету и полном отрицании того, что говорит нам наш послужной список?)
Попробуйте представить себе, что «закончено» — это не главное и никогда им не было. Вместо того, чтобы ползти до какой-то постоянно отдаляющейся финишной черты, выпустите что-то незаконченное и крошечное! Посмотрим, что получится! Просто попробуйте с этого момента спланировать небольшой релиз!
Вскоре у вас появится ощущение того, как небольшие версии вашего продукта находятся в тренде, что позволит вам планировать, основываясь на фактическом знании чего-то, а не работать с благими, но обреченными на провал намерениями. И вы обнаружите, что защита, которую призван обеспечить Железный Треугольник, больше не нужна.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
Что такое треугольник управления проектами и как он поможет вашему проекту
Бермудский треугольник? Любовный? А, может, музыкальный? В один ряд с ними затесался и треугольник управления проектами. Мы, Moroz Team, расскажем о нём и о том, какую пользу он может принести вашему проекту.
Введение в треугольник управления проектами: определение и сущность
Треугольник называется так, потому что имеет 3 угла, 3 стороны. Если в нём увеличить или уменьшить одну из сторон, то изменятся и другие. Именно такие незамысловатые правила геометрии в основе и у треугольника управления проектами (для удобства иногда будем называть его проектным треугольником).
В проектном треугольнике каждую сторону представляют ограничения любого проекта: объём работы, время и стоимость. Поэтому модель нашего треугольника также называют теорией тройственного ограничения.
Со временем к этой модели добавили ещё одно ограничение: качество. Оно тоже может изменяться при изменении объёма, времени и стоимости. Ограничений стало 4, но изображают их всё равно треугольником. Просто качество теперь ложится внутрь треугольника и заполняет его.
Концепция проектного треугольника и его роль в управлении проектами
Одной из задач руководителя проекта является поддержание треугольника, т.е. сохранение баланса между его сторонами. Этот баланс важно сохранять как на протяжении всего проекта, так и на небольших промежутках времени. Например, если вы работаете по методике Scrum, то каждый ваш спринт должен быть сбалансирован по ресурсам, времени и объёму работ.
Понимание, как изменяется треугольник под влиянием ограничений, важно в любом проекте. Оно поможет вам управлять проектом грамотно: принимать более взвешенные решения, реагировать на изменения и избегать неприятных последствий.
Ещё одно из преимуществ в понимании треугольника управления проектами — это правильное реагирование руководства на изменение ограничений. Постарайтесь донести до своего руководителя эту теорию, сформируйте у него реалистичный взгляд на изменения. Так вам будет проще в принятии решений для избежания негативных последствий.
Треугольник проекта
Реализации проекта подразумевает обязательное планирование. Планирование это разработка модели проекта в специализированном программном продукте к примеру MS Project. В процессе планирования команда проекта вписывает проект в ограничения проекта. Ограничения проекта можно разделить на три группы:
- Ограничение по содержанию. Это описание требований к продукту проекта, чем сложнее проект тем больше задач необходимо реализовать для создания продукта проекта. Если мы планируем построить одноэтажный коттедж без дополнительных строений то модель, данного проекта будет довольно простой. С увеличением сложности проекта растет количество задачи, усложняется технология и растут сроки и затраты проекта.
- Ограничения по срокам. Мы уже знаем что любой проект имеет ограничения по срокам, и в модели проекта данные ограничения обязательно должны быть четко указаны. В программном продукте MS Project ограничения по срокам указываются с помощью поля «Крайний срок» в котором указываются даты до которых должны быть реализованы задачи и получены результаты проекта. В плане-графике проекта может быть указанно несколько крайних сроков, но для одной задачи или вехи (описание продукта проекта) может быть указан только один крайний срок.
- Ограничение по затратам. Под ограничением по ресурсам понимает не только финансы которые компания готова потратить для реализации проекта, но и стоимость использования ресурсов компании для реализации проекта.
Желание заказчика или клиента получить максимальный результат (большой коттедж) в сжатые сроки (желательно за две недели) и за «смешные» деньги ( к примеру за 1000$). Можно ли реализовать такой проект? Большинство из Вас ответят НЕТ. Я бы сказал, МОЖНО, картонные коробки еще не перевелись. Как Вы уже наверно догадались это был пример того что в центре любого проекта лежит качество. И если заказчик или клиент пытается поставить нереальные сроки или бюджет при это заказывая уникальный продукт, он всегда жертвует получить продукт низкого качества. Хотя большой бюджет или длительные сроки не гарантируют качество продукта проекта, но одновременно сокращение предложенных исполнителем сроков и бюджетов может привести к продукту низкого качества. Это связано стем что строя модель проекта исполнитель (подрядчик) вписывает имеющуюся у него технологию реализации проекта. Изменение ограничений приводит к повышения вероятности наступления рисковых событий, а они всегда «бьют» по качеству.
Данный материал рассматривается на практических тренингах на ресурсе Онлайн-курсы.