Больше никаких изменений!

Martin Powell (tocpeople.com)Автор: Мартин Пауэлл (Martin Powell)

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

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

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

С помощью своей методики управления проектами Критическая цепь (CCPM), Голдратт бросил вызов этому: «Больше никаких изменений!», или «Ну, как всегда…», как люди обычно относятся к этому явлению.

Конечно, подход доктора Голдратта заставляет нас проанализировать и понять истинную природу основных проблем в области управления проектами.

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

  1. За какой проект (проекты) мы должны взяться?
  2. Каким должно быть содержание выбранного проекта?
  3. Как мы должны планировать и управлять выполнением проекта?

1. За какой проект (проекты) мы должны взяться?

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

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

Голдратт заявил, что сделать выбор и рассмотреть варианты возможно с помощью Мыслительных процессов (МП) Теории ограничений. Но в этой статье мы не будем подробно рассматривать их.

2. Каким должно быть содержание выбранного проекта?

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

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

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

Многие из этих несоответствий возникают на поздних стадиях выполнения, особенно, когда происходит интеграция отдельных частей проекта:

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

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

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

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

Это означает, что необходимо не только указать реальную задачу / действие / элемент дизайна, но также необходимо определить для этой задачи / действия / элемента:

  • Руководящие принципы / концепции и границы (обеспечиваем основу для работы).
  • Цель (цели) задачи (отвечаем, для чего она создана).
  • Необходимость (отвечаем, почему необходимо достижение этой цели).
  • Рабочие исходные посылки (отвечаем, почему эта задача выбрана для достижения этой цели).

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

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

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

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

Вот результаты, о которых сообщили нам наши клиенты:

  1. Устранено разрастание объемов:
    а) на этапе планирования определено, где нет необходимости в изменениях в спецификациях, требованиях и дизайне;
    б) на этапе выполнения улучшена синхронизация содержания проектных задач.
  2. Сокращено общее внимание руководства:
    а) внимание сфокусировано на будущее, а не на процессе выполнения.
  3. Увеличилась скорость выполнения проектов:
    а) уменьшилось количество принятий и согласований необходимых решений и, следовательно, задержки.
  4. Увеличилась скорость в совместных областях:
    а) улучшена синхронизация и взаимодействие между командами разработчиков, уменьшено количество переделок.
  5. Улучшена расстановка приоритетов релизов с помощью повышения прозрачности ROI.
  6. За 45 минут новый член проектной команды четко понял сложный долгосрочный проект [Руководитель проекта].
  7. Инженеры стали гораздо лучше понимать детали, которые требуются от разрабатываемого продукта, и потребности, лежащие в основе этих решений [Технический руководитель].
  8. Документы – не только спецификации того, что требуется, но что еще более важно, причины, почему проект необходим, что именно будет сделано и что не будет, все это ясно излагается всем заинтересованным сторонам. Они четко объясняют всем заинтересованным сторонам объем проекта, и, что еще более важно, устраняют любое неправильное толкование, непонимание и недопонимание, которые обычно вызывают продолжительные переделки на протяжении всего проекта [Технический директор].

3. Как мы должны планировать и управлять выполнением проекта?

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

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

Тем не менее, неопределенность (вариации) мешает. Задачи занимают больше времени, чем ожидалось, поставщики не поставляют вовремя, изменяются требования, происходят технические сбои и так далее.

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

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

Когда возникает неопределенность, ресурсы (люди) больше не могут следовать начальным графикам. Тогда они начинают самостоятельно работать над тем, что по их предположению приоритетно. По определению, такие самостоятельно установленные приоритеты не синхронизированы; в результате чего оказывается, что проект, скорее всего, ожидал от них что-то другое. Последствия: плохое использование ресурсов, многозадачность и тушение пожаров.

Решение полностью документировано в подходе Критической цепи для управления проектами.

Вот три руководящих принципа и правила для их принятия:

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

Вывод

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

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

 

Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Виктор Вальчук
Лидер трансформации

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

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 5 августа 2024 (273 часа).

ПОДРОБНЕЕ

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

Фото аватара

(Martin Powell)
Associate, FCA

2 комментариев “Больше никаких изменений!

  1. Фото аватара
    Николай Баранов

    «1. За какой проект (проекты) мы должны взяться?» Не в этой статье…
    «2. Каким должно быть содержание выбранного проекта?» Кто это определяет? не в этой статье… Там же список «достижений» от благодарных клиентов. У нас все получилось лучше чем что? Сравнение с какими иными методами управления проектами выявило уникальную крутость CCPM?
    «3. Как мы должны планировать и управлять выполнением проекта?»
    Одно только «планирование времени» отдельных задач на уровне 50% вероятности выполнения их в срок — само по себе мем, достойный «восхищения». И +50% времени задач в буфер на ветку цепи. Где-то из той же области точности оценок, что и в подходах DBM.

    Из всех наработок ТОС метод ССМР едва ли не самый спорный в адекватности получаемых результатов. Он лучше разве что линейных диаграмм Ганта. И никакие улучшения в части «учета конфликта ресурсов» ситуацию не исправят. Общая методология как максимум способна подсказать ЧТО должно быть сделано, но ничем не поможет для понимания того КАК это должно быть сделано.

    1. Александр

      Раз уж такая критика пошла, то хотелось бы услышать от Вас примеры. В частности:
      1) Какие методы управления проектами на Ваш взгляд «круче» метода ССРМ?
      2) Есть примеры случаев, когда метод ССРМ не приносил ощутимых результатов? Разумеется при правильном применении метода.

Давайте обсудим...