Перевод статьи Эли Шрагенхайм Часть 3. Управление характеристиками продукта в проекте

При планировании проекта устоявшейся нормой является наличие детального плана всех характеристик продуктов уже на начале проекта. Методология планирования проектов ТОС, которая называется CCPM (Управление Проектами по Методу Критической Цепи), исходит из предпосылки, что уже в самом начале проекта существует хорошее понимание требуемого результата проекта и все задачи, которые необходимо выполнить для достижения этого результата, также известны вначале проекта.

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

В книге «Управление цепью поставки на невероятной скорости» (Шрагенхайм, Детмер и Паттерсон, 2009, стр. 5-8)[i] авторы коротко описали различные правила принятия решений между этапами планировании и исполнения. Природа проблем любого планирования состоит в том, что оно требует принятия решений загодя и, таким образом, вызывает Закон Мерфи (влияние неопределенности, приводящее к проблемам), который путает эти решения, мешает простому исполнению и вызывает неудачи в достижении целей проекта.

С точки зрения планирования, выводы следующие:

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

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

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

Этот обзор показывает необходимость определить два различных набора характеристик продукта/проекта:

  1. Обязательные (must-have) характеристики, отсутствие хотя бы одной из которых лишает результат проекта ценности. Эти характеристики определяют потребность в проекте.
  2. Характеристики «неплохо-чтобы-были» (nice-to-have), каждая их которых, безусловно, добавляет какую-то ценность результату проекта, но, если они не будут включены в проект, проект все равно будет полезным.

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

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

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

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

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

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

Безусловно, такая схема открывает двери для более широкого рассмотрения включения характеристик типа «неплохо-чтобы-было», что значительно добавляет ценность проекту.

Самостоятельно инициированные проекты и проекты по заказу другой стороны

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

Последствия[ii] при применении CCPM

Логика, на которой основывается предложение отложить окончательное принятие решения о включении характеристик типа «неплохо-чтобы-было» до того момента, когда эти характеристики понадобятся, безусловно находится в общем русле подходов ТОС. Тем не менее, общепринятая на текущий момент методология CCPM предполагает стабильный план выполнения задач проекта.

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

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

Но, если конкретная «неплохо-чтобы-было» характеристика все-таки влияет на критическую цепь (обычно – несильно), например, требуя широко востребованного ресурса, таким образом, становясь частью критической цепи, то в этом случае есть два способа справиться с проблемой:

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

Важно помнить: в мульти-проектном управлении ни один ресурс не может быть загружен до уровня «бутылочного горлышка». Люди знают, как выглядеть постоянно занятыми и по-прежнему иметь возможность делать больше. Но их слишком большая загрузка может иметь катастрофическое влияние на длительность выполнения проектов и даже качество результатов. Таким образом, гибкое планирование возможно и желательно, даже когда кажется, что один-два ресурса сильно загружены.

 Дальнейшее развитие подходов ТОС к проектно-ориентированному окружению

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

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

Обратите внимание, все, что нужно для принятия качественного решения о разработке нового продукта/технологии, – это оценка того, что генерируемая ценность значительно больше, чем инвестиции. НЕТ НЕОБХОДИМОСТИ давать конкретные финансовые оценки этим основным параметрам. Так или иначе, не существует способов перевести в конкретные цифры для переменных, которые находятся на таком уровне неопределенности.

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

Ссылки[iii]

По вопросам CCPM существует обширная литература, и автор предпочитает не указывать на какую-либо одну книгу

  1. Schragenheim, Decision making under uncertainty: A presemtation in TOCICO in Maiamy, 2004 (Шрагенхайм. Принятие решений в условиях неопределенности: Презентация на конференции TOCICO в Майами, 2004)

На тему шести вопросов для оценки ценности новой технологии

  1. Goldratt, Schragenheim, Ptak, Necessary but Not Sufficient, 2000, North River Press (Голдратт, Шрагенхайм, Птак «Цель-3. Необходимо, но недостаточно», 2009, Необхiдно та достаньо)

На тему планирования и реализации:

  1. Goldratt, The Haystack Syndrome, 1990, North River Press (Голдратт, «Синдром стога сена»)
  2. Schragenheim, Dettmer, Patterson, Supply Chain Management at Warp Speed, 2009, CRC Press (an Auerbach Book), pages 5-8 (Шрагенхайм, Деттмер, Паттерсон «Управление цепью поставок с невероятной скоростью»)

[i] «Supply Chain Management at Warp Speed» (Schragenheim, Detmer and Patterson, 2009, pages 5-8) – русскую версию найти не удалось. – Прим. Переводчика

[ii] Автором использован термин «ramifications», который может быть переведен как ответвление, отросток и как последствия или результат. В данном случае предпочтен вариант «последствия», поскольку речь далее идет о модификациях в методике CCPM, связанных с предлагаемым подходом к планированию. – Прим. Переводчика.

[iii] Все названия книг приводятся в русском и английском варианте, не вся литература, указанная в статье переведена на русский язык. – Прим. переводчика

Начало публикации

Часть 1

Часть 2


Добавить комментарий

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