Цепочка предшествующих текстов:
Когда руководитель проекта становится руководителем программы
Мыслить проектно — история и современность (Максим Цепков, SECR-2018)
INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
Оригинал:
Oehmen, Josef, (Ed.). 2012. The Guide to Lean Enablers for Managing Engineering Programs, Version 1.0. Cambridge, MA: Joint MIT PMI INCOSE Community of Practice on Lean in Program Management.
Конспект:
Руководство по факторам, которые способствуют экономически обоснованному управлению инженерными программамиДанное руководство является справочником с конкретными советами по улучшению для вашей программы. Эти советы разбивают системное мышление на небольшие тренируемые навыки и микропрактики. Основная польза такого подхода в том, что вы можете получать преимущества системного мышления быстро. Для этого вам надо реализовать отдельные пункты этого руководства. Какие? Решайте сами, их 300, что-нибудь вам точно подойдет.
Представьте, что программа, в которой вы работаете вдохновляет вас во всем. В этой программе каждый понимает как он меняет жизнь заказчика, организации-исполнителя и общества в целом. Профессионалы в ней взаимодействуют без преград и не замечают функциональных и организационных границ. Практики в ней работают как часы и выдают результат, который ожидался от их исполнения. Где предметом вашей озабоченности становится вылизывание небольших несовершенств в продукте и организации труда. Другими словами - бережливая программа, в которой нет ненужных и бесполезных задач и организационных звеньев. Вы можете управлять такой программой и это руководство поможет вам в этом.
Мы смирились с тем, что большие программы означают большие проблемы, большие счета и большие задержки. В дополнение к этому мы привыкли к постоянным пикировкам между функциональными направлениями, конфликтам с заказчиками, подрядчиками и поставщиками. Мы привыкли к раздражительности, неприязни и открытой вражде. Мы привыкли к тому, что программами управляют бюрократы и юристы, мы привыкли к тому, что в программе не делается никакой полезной работы, только пишутся бесконечные отчеты. И так удобно складывается, что для такого положения дел есть множество отговорок. Вы их слышали: нет времени нормально управлять программой потому что все заняты исправлением ошибок, требования все время меняются, буквальное следование законам и правилам и регламентам подменяют эффективность, новые технологии подводят, поставщики не выполняют обещания, а квалифицированных людей невозможно найти.
Это руководство было написано для руководителей и инженеров, которые хотят принять вызов и вести свои программы к совершенству.
В 40-х годах появились три новые предметные области: исследование операций, системная инженерия и проектное управление. Все вместе они позволили перейти к реализации очень больших и сложных инженерных и технических программ. 70 лет спустя Lean Advancement Initiative (LAI), Project Management Institute (PMI) и International Council of Systems Engineering (INCOSE) объединили усилия экспертов, чтобы вместе отобрать и объединить лучшие идеи и практики из этих трех областей, чтобы решать с помощью них сегодняшние проблемы.
Эта экспертная группа составила список самых больших проблем, с которыми сталкивается современная программа, и разбила их по 10 основным темам. Руководствуясь принципами адаптированного под обстоятельства мышления группа определила и проверила полезность приблизительно 300 лучших практик в 40 категориях. Эти практики способны решить заявленные проблемы проектного менеджмента и системной инженерии. Результатом этой работы и стало это руководство.
Любое самое большое изменение начинается с первого шага. Реализуйте хотя бы один способствующий фактор (lean enabler) и вы можете увидеть разницу. Мы рекомендуем посмотреть на наши рекомендации, выбрать 2-3 и сделать их.
Опыт успешных программ доказывает, что наша просьба реалистична и стало быть вы тоже можете ее выполнить!
Josef Oehmen, PhD
May 2012, Cambridge, MA (USA)
Краткая сводка для руководства
Это руководство описывает находки, сделанные Joint MIT PMI INCOSE Lean in Program Management Community of Practice в проекте, который осуществляла эта группа в 2011-2012. Группа была составлена из представителей коммерческих и правительственных и учебных организаций. Находки, которые описаны в этом руководстве, основаны на лучших практиках из литературы, экспертного опыта реализации программ и данных, полученных от широкого сообщества специалистов.Находки группы были тщательно проверены сообществом и практикующими специалистами, которые оставили свое мнение об этих практиках, на множестве рабочих совещаний конференций, которые проводили INCOSE и PMI, онлайн собраниях LAI и в широких опросах профессиональных сообществ. Опросы четко показали, что программы, в которых используются способствующие факторы показывают результаты гораздо лучше других по всем параметрам - по стоимости, по срокам и качеству и удовлетворенности стейкхолдеров.
Ядро документа составлено из 10 тем по количеству основных проблем управления инженерными программами и 43 основных и 286 подчиненных сопутствующих факторов, которые позволяют справиться с этими проблемами. Они также позволяют лучше объединить управление программой и системную инженерию и вести программу, приспособленную под обстоятельства, к совершенству.
Список основных проблем управления инженерными программами:
- Борьба с пожарами - запаздывающее исполнение программы.- Нестабильные, нечеткие и неполные требования.
- Недостаточная согласованность и нескоординированность производственной кооперации.
- Практики оптимизированы локально и не учитывают работу предприятия в целом.
- Нечеткие роли, ответственность за исполнение и ответственность за результат.
- Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- Недостаточное планирование программы.
- Неправильно выбранные показатели, системы показателей и KPI.
- Недальновидное управление рисками.
- Плохое управление закупками и контрактацией.
Способствующие факторы, структурированные по 6 принципам устранения потерь:
LE 1.x Уважайте людей в программе - 6 основных факторов и 38 вторичныхLE2.x Выявляйте пользу, которую видят ключевые стейкхолдеры заказчика - 6 основных факторов и 44 вторичных
LE 3.x Моделируйте жизненный цикл целевой системы, обосновывайте применение практик жизненного цикла и устраняйте потери - 11 основных факторов и 75 вторичных
LE 4.x Обеспечивайте проход работы через запланированные и выстроенные практики - 10 основных факторов и 64 вторичных
LE 5.x Позвольте стейкхолдерам заказчика самим определять пользу - 2 основных факторов и 10 вторичных
LE 6.x Стремитесь к совершенству всех практик - 8 основных факторов и 5 вторичных
Всего - 43 основных фактора и 286 вторичных
Влияние способствующих факторов на реализацию инженерных программ.
Три наиболее успешных программы, отобранных PMI Project of the Year Award, использовали от 60 до 75% факторов. Для остальных программ, которые попали в списки лучших, удалось найти свидетельства того, что они использовали около 30% факторов.Мы обнаружили, что все факторы присутствовали как минимум один раз, а некоторые были популярнее остальных. Вот некоторые из наиболее часто используемых факторов:
- Строить культуру программы с уважением к людям (LE 1.1)
- Часто вовлекать стейкхолдеров на всем жизненном цикле программы (LE 2.3)
- Разрабатывать план коммуникаций (LE 3.11)
- На каждой программе использовать роль руководителя программы, который должен объединять и вести программу от запуска до окончания (LE 4.3)
- Дальновидно управлять неопределенностью и рисками, чтобы получить максимальные выгоды от программы (LE 6.6)
Отрасли и области, в которых реализовывались программы, самые разные.
147 способствующих факторов, которые указаны в Lean Enablers for Systems Engineering, 2009, включены в 329 факторов, перечисленных в этом руководстве.
Потери в инженерных программах
Перепроизводство информации:- Производить больше, чем требует следующая практика
- Создавать документы, которые не запрашивали
- Избыточные и ненужные задачи
- Рассылка информации тому, кому она не нужна (например, почтовый спам)
- Отсылка нескольких образцов, когда запрошен был один
- Работа над неправильным некорректным релизом (работаю вхолостую)
- Недоиспользование имеющейся экспертизы, изобретение колеса
Ожидание:
- Ожидание информации либо принятия решения
- Информация есть или решение принято, но люди не ей пользуются и не исполняют
- Большие очереди в жизненном цикле
- Длительные согласования
- Ненужные повторяющиеся усилия
Ненужное движение информации:
- Переадресация
- Избыточное распространение информации
- Разрозненные технические средства, политически мотивированное географическое распределение работы (“сделано в 50 штатах”), недостаточное совместное размещение
Избыточная обработка информации:
- Избыточное уточнение информации
- Закрепление конструкции, отвечающей заданным требованиям (утверждение базиса конфигурации) происходит слишком рано и ведет к многочисленным итерациям
- Неконтролируемые итерации (слишком многие задачи повторяются, избыточная сложность)
- Недостаток стандартизации
- Преобразования данных
- 2D чертежи (необходимо везде использовать 3D)
- Использование избыточно сложного монолитного программного обеспечения без видимой причины (например, использование сложного софта, когда достаточно таблицы Эксель)
Запасы информации:
- Хранение большего количества информации, чем требуется
- Слишком большие промежутки между защитами и проверками
- Плохое управление конфигурацией и сложное извлечение и получение информации
- Плохое 5S (сортировка, соблюдение правил, содержание в чистоте, стандартизация, совершенствование) и в базах данных
Ненужное перемещение людей:
- Ненужные перемещения при выполнении задачи
- Людям нужно передвигаться, чтобы получить информацию или доступ к ней
- Ручное вмешательство, которое компенсирует недостаток систематичности
Переделки, дефекты:
- Убийственные “пере-”: переделка, переписывание кода, перепрограммирование, перетестирование…
- Нестабильные требования
- Нескоординированная сложная задача, которая занимает слишком много времени на выполнение и результат которой становится невостребованным к моменту завершения так что она должна быть переделана
- Неполная, расплывчатая или неточная информация
- Инспекции по выявлению дефектов
- ресурсы направляются на решение проблем, а не на их предотвращение
- конкуренция за ресурсы
- меняющиеся приоритеты проекта
- нечеткое или неподходящее распределение ответственности и прав на принятие решений
- недостаток управления приоритетами или согласованности в целях сотрудничающих организаций
- недостаточное понимание риска программы
- нет согласованной руководящей команды, которая представляет все важные функции
Тема 2. Нестабильные, нечеткие и неполные требования.
- неполное понимание требований стейкхолдеров
- недостаточное понимание всей сложности требований, пропуск производных требований
- нестабильные приоритеты программы
- стейкхолдеры не в состоянии четко выразить свои требования
- неправильное понимание требований стейкхолдеров
- неполное доведение до людей об изменениях в стоимости, сроках и требуемых характеристиках в течение программы
- требования формулируются с нарушениями правил
- недостаточная адаптация базисов по срокам, стоимости и техническим характеристикам к меняющемуся окружению и предположениям программы
- требования к соответствию (внутренние требования, стандарты, законодательные требования) различных стейкхолдеров не связаны друг с другом, не объединены, могут конфликтовать, все это приводит к дополнительной нагрузке, несогласованности требований и не дает возможности эффективно согласовывать похожие требования
- нечеткое понимание восприятия пользы стейкхолдерами
- отсутствие учета определенных ранее потребностей
- запрос коммерческого предложения выпущен заказчиком слишком рано
Тема 3. Недостаточная согласованность и нескоординированность производственной кооперации.
- конкурирующие требования к ресурсам
- недостаточное управление и согласованность приоритетов работы стейкхолдеров и организаций в производственной кооперации
- нечеткие приоритеты при исполнении непосредственных бизнес-целей (например, прибыльность текущей программы) и ответственностью за другие программы (например, сбор и распространение полученного опыта, постоянные улучшения)
- неструктурированная или незапланированная коммуникация стейкхолдеров
- нечеткое либо различное понимание состава предпринятия
- недостаточная интеграция стейкхолдеров, в особенности с заказчиками и поставщиками
Тема 4. Практики оптимизированы локально и не учитывают работу предприятия в целом.
- недостаток усилий по оптимизации на уровне всего предприятия, оптимизация только локальных процессов и организации
- недостаток стандартизации процессов
- что касается потока создания ценности, недостаток понимания того, как работать с различными видами потерь,
- отсутствие механизмов улучшения потока создания ценности
Тема 5. Нечеткие роли, ответственность за исполнение и ответственность за результат.
- ведущее к проблемам распределение ответственности и прав принимать решения
- недостаток согласованности и интеграции между программным менеджментом и системной инженерии
- отсутствие поощрений и мер по поддержанию чувства личной ответственности за планы и результаты
- нет согласованной команды управления, которая бы представляла все важные функции
- роли и ответственность персонала программы и линейных функций не определены
- несогласованные и мешающие совместной работе KPI и премии персонала программы, команд проектов, поставщиков, заказчиков и других стейкхолдеров
Тема 6. Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- неэффективные практики передачи знаний от опытных сотрудников и членов команды к новым членам команды (в частности, это происходит в отраслях со стареющими кадрами)
- недостаток механизмов обратной связи, которые бы превращали накопленный опыт в действия, новые практики не ставятся по результатам накопленного опыта и рекомендаций
- нет адекватного распространения накопленного опыта по всему предприятию
- неадекватное определение личных потребностей в развитии навыков
- накопленный опыт не документируется
- неадекватный сложности задачи опыт команды
- недостаточный уровень личных навыков
Тема 7. Недостаточное планирование программы.
- нереалистичные базисы по срокам, стоимости и техническим характеристикам
- недостаточное распространение внутри программы изменений по стоимости, срокам и техническим характеристикам
- недостаточная адаптация базисов по срокам, стоимости и техническим характеристикам к меняющимся предположениям и окружению программы
- нереалистичное расписание программы
- проблемы с общением на нужном уровне организационной иерархии во время запуска и закрытия проекта
- оценки не отражают все аспекты жизненного цикла
- нехватка вероятностных оценок
- слишком редкие обновления оценок стоимости, сроков и технических характеристик на ранних стадиях программы и во время исполнения
Тема 8. Неправильно выбранные показатели, системы показателей и KPI.
- показатели дают ретроспективную оценку и не помогают предсказывать появление проблем
- показатели не учитывают человеческое поведение (теория игр)
- нет метрик для кросс-функциональных процессов
- распределенные и несвязанные ИТ-системы и хранилища данных не позволяют эффективно собирать и объединять данные для расчета показателей
- недостаточный присмотр за соблюдением базисов по срокам, стоимости и техническим характеристикам
- показатели ориентированы на короткий период
Тема 9. Недальновидное управление рисками.
- недостаточное вовлечение необходимых для управления рисками специалистов
- неполное понимание рисков программы
- недостаточное финансирование и ресурсное обеспечение мероприятий по управлению рисками (выявление, оценка, предотвращение и отслеживание)
- пренебрежение человеческим фактором при управлении рисками, такими как культура сокрытия ошибок и плохих новостей
- отсутствие тесной связи управления рисками и других практик жизненного цикла
- недостаточное внимание на быстрое устранение выявленных рисков
Тема 10. Плохое управление закупками и контрактацией.
- заказчик выпускает запрос на предоставление коммерческого предложения слишком рано, еще до того, как достаточно определится с требованиями
- чрезмерное влияние финансовых ограничений
- контрактные ограничения и стимулы не согласованы с задачами программы и профилем риска
- нет подходящей практики обкатки технологии для программ (технические характеристики и системная интеграция)
- непонимание между операционным менеджментом программы и контрактными требованиями
- нереалистичное расписание программы
- проблемы с общением на нужном уровне организационной иерархии во время запуска и закрытия проекта
- оценки не отражают все аспекты жизненного цикла
- нехватка вероятностных оценок
- слишком редкие обновления оценок стоимости, сроков и технических характеристик на ранних стадиях программы и во время исполнения
Тема 8. Неправильно выбранные показатели, системы показателей и KPI.
- показатели дают ретроспективную оценку и не помогают предсказывать появление проблем
- показатели не учитывают человеческое поведение (теория игр)
- нет метрик для кросс-функциональных процессов
- распределенные и несвязанные ИТ-системы и хранилища данных не позволяют эффективно собирать и объединять данные для расчета показателей
- недостаточный присмотр за соблюдением базисов по срокам, стоимости и техническим характеристикам
- показатели ориентированы на короткий период
Тема 9. Недальновидное управление рисками.
- недостаточное вовлечение необходимых для управления рисками специалистов
- неполное понимание рисков программы
- недостаточное финансирование и ресурсное обеспечение мероприятий по управлению рисками (выявление, оценка, предотвращение и отслеживание)
- пренебрежение человеческим фактором при управлении рисками, такими как культура сокрытия ошибок и плохих новостей
- отсутствие тесной связи управления рисками и других практик жизненного цикла
- недостаточное внимание на быстрое устранение выявленных рисков
Тема 10. Плохое управление закупками и контрактацией.
- заказчик выпускает запрос на предоставление коммерческого предложения слишком рано, еще до того, как достаточно определится с требованиями
- чрезмерное влияние финансовых ограничений
- контрактные ограничения и стимулы не согласованы с задачами программы и профилем риска
- нет подходящей практики обкатки технологии для программ (технические характеристики и системная интеграция)
- непонимание между операционным менеджментом программы и контрактными требованиями
Обзор способствующих факторов
Как читать таблицы:
Вторая строка - какие проблемы решает фактор.
Третья строка - группа практик стандарта по системной инженерии INCOSE. Открываете руководство и смотрите общий контекст применения практик. 1. Относиться к людям как к самому важному активу
1.1 Строить культуру программы, основанную на уважении к людям.
1.1.1 Осознавайте, что программа проваливается или становится успешной в первую очередь за счет усилий людей, а не имеющихся практик. Обращайтесь с людьми как с ценными активами, а не как с материалом.
1.1.2 Вкладывайтесь в отбор и развитие людей, чтобы было какими силами достигать совершенства в программе и предприятии. Убедитесь, что практика найма соответствует реальным потребностям программы в талантах и компетенциях.
1.1.3 Руководитель программы должен быть ментором и показывать своим примером желаемое поведение. Он должен быть образцом доверия, уважения, честности, воодушевления, командной игры, надежности, мотивации и стремления к совершенству для всей команды.
1.1.4 При найме людей ориентируйтесь на страсть к делу, “искру в глазах” и широкий профессиональный кругозор, а не только на конкретно сейчас нужные вам навыки. Это принцип “нанимайте таланты, обучайте их навыкам”. Не поручайте эту работу компьютерам, которые ищут совпадения по ключевым словам.
1.1.5 Вознаграждайте за заслуги команды и оценивайте способность работать в команде при найме и продвижении. Поощряйте командообразование и командную работу.
1.1.6 Практикуйте обход территории, не управляйте сидя на рабочем месте. Сходите и посмотрите как все происходит лично.
1.1.7 Стройте культуру взаимного доверия и поддержки, когда людям не стыдно и не опасно просить помощи.
1.1.8 Поощряйте плотное взаимодействие и тесные отношения между внутренними заказчиками и поставщиками. Не позволяйте людям быть “одинокими волками”.
1.1.9 Когда набираете руководство программы, включая менеджера программы, предпочитайте командных игроков и людей, способных мыслить в группе. Люди с идеальными резюме и дипломам не всегда оказываются командными игроками.
1.1.10 Когда решаете вопросы, атакуйте проблему, а не людей.
1.2 Мотивировать людей, делая высшую цель и элементы программы прозрачными.
1.2.1 Создавайте общее видение, которое вызывает в людях лучшее и вдохновляет их.
1.2.2 Удостоверьтесь, что каждый понимает свой личный вклад в успешную реализацию общего видения.
1.3 Поддерживать автономный стиль работы.
1.3.1 Используйте и передавайте на места ответственность и полномочия действовать, чтобы решения принимались на как можно более низком, но приемлемом уровне.
1.3.2 Избавляйтесь от страха на рабочем месте. Поощряйте решение конфликтов на низовом уровне.
1.3.3 Разрешите совершать некоторое количество “ошибок” в контролируемых условиях на низовых уровнях, чтобы люди учились принимать риски и накапливать опыт.
1.3.4 В своей зоне ответственности и в рамках, дозволенных политиками программы, поощряйте людей принимать на себя ответственность и действовать. Реализуйте принцип: “Лучше просить прощения, чем разрешение”.
1.3.5 Четко доводите причины и принципы, по которым были приняты управленческие решения. При этом поощряйте низовую культуру постоянного улучшения, творчества и предпринимательства.
1.4 Ожидать от людей стремления к профессиональному совершенству и карьерному продвижению и поддерживать их в этом.
1.4.1 Основывать и поддерживать сообщества практик.
1.4.2 Вкладываться в развитие персонала.
1.4.3 Удостовериться, что все прошли обучение тому, как разумно приспосабливать практики под обстоятельства, чтобы избегать потерь.
1.4.4 Обучить лидеров на всех уровнях организации глубокому пониманию методов разумного приспособления практик под обстоятельства.
1.4.5 Поощрять и уважать профессиональное признание заслуг и продвижение по результатам работы.
1.4.6 Заведите собрание старейшин, которые показывают пример другим и задают образец поведения.
1.4.7 Закрепляйте профессиональное совершенство посредством наставничества, дружеской оценки коллегами, обучения, тренингов и с помощью других средств.
1.5 Поощрять способности быстро учиться и улучшаться.
1.5.1 Поощряйте и вознаграждайте постоянное саморазвитие. Саморазвитие может идти как по учебным материалам, так и на основе практического опыта.
1.5.2 Обеспечьте легкий доступ к знающим экспертам как к ресурсам и как к наставникам, включая их участие в дружественной оценке коллег.
1.5.3 Цените необычные идеи, которые люди реализуют в программе.
1.5.4 Фиксируйте и распространяйте скрытое знание, чтобы программу не трясло при смене команды.
1.5.5 Разрабатывайте стандарты с оглядкой на человеческий фактор, учитывайте наличие опыта и особенности восприятия.
1.5.6 Для новых стандартов и регламентов немедленно организуйте обучение, чтобы все про него знали и понимали, зачем этот стандарт нужен.
1.6 Поощрять развитие личных контактов и взаимодействий.
1.6.1 Если выбираете между физическим совместным размещением команды и регулярными собраниями онлайн, выбирайте первое.
1.6.2 При построении виртуальных команд вкладывайтесь в личные встречи на старте совместной работы, чтобы построить личные отношения.
1.6.3 Поощряйте прямой человеческий контакт, чтобы построить личные отношения.
1.6.4 Участвуйте в мероприятиях, которые задействуют различные функции, например, в планирование модели жизненного цикла программы.
1.6.5 Вовлекайтесь и поддерживайте интенсивное взаимодействие со стейкхолдерами.
1.6.6 Поддерживайте развитие неформальных сетей внутри программы и с ключевыми внешними стейкхолдерами.
1.6.7 Поощряйте и когда надо документируйте открытый обмен информацией внутри программы.
1.6.8 Руководитель программы должен иметь взаимное уважение и личные отношения со всеми четырьмя основными группами стейкхолдеров: заказчиками, руководителями, персоналом программы и ключевыми подрядчиками и поставщиками.
2. Максимум пользы от программы
2.1 Установить, в чем видят пользу и выгоды от реализации программы стейкхолдеры.
2.1.1 Определять пользу как результат, который отвечает минимум трем условиям:
а) Внешние стейкхолдеры заказчика готовы заплатить за него
б) Преобразует материалы или информацию или уменьшает неопределенность
в) Дает определенные в программе выгоды с первого раза
2.1.2 Определять добавленную пользу в терминах стейкхолдеров заказчика и их потребностей.
2.1.3 Разработать надежно выполняющуюся практику крайне точного формулирования пользы для стейкхолдеров заказчика, ее уточнения и распространения.
2.1.4 Дальновидно решайте возможные конфликты пользы и ожиданий различных стейкхолдеров и ищите полного согласия.
2.1.5 Объясняйте культуру стейкхолдеров заказчика персоналу программы, такие как систему ценностей, подходы, отношения, ожидания и ключевые моменты.
2.2 Сосредоточьте все мероприятия программы на выгодах, которые планирует принести программа.
2.2.1 Все мероприятия программы, включая коммуникации и работу с показателями, должно выполняться с оглядкой на ожидаемые результаты программы - запланированные выгоды программы.
2.2.2 Согласовывайте ресурсы программы, чтобы достичь запланированной выгоды и включите мероприятия, которые позволят поддерживать получение выгоды и далее, после закрытия программы.
2.2.3 Удостоверьтесь, что персонал программы и команды полностью понимают, как исполнение программы и выгоды соотносятся со стратегическими целями организации (конкурентоспособность и прибыльность).
2.3 Часто вовлекайте стейкхолдеров на всем жизненном цикле программы.
2.3.1 Все люди, которые работают в программе, должны руководствоваться прежде всего интересами и потребностями заказчика, которые выражены в выгодах и требованиях программы.
2.3.2 Установите частое и эффективное взаимодействие между внутренними и внешними стейкхолдерами.
2.3.3 Двигайтесь в направлении видения и архитектуры программы, которые четко выражают требования стейкхолдеров заказчика и могут адаптироваться к изменениям.
2.3.4 Разработайте план, который опишет рабочие продукты и взаимодействия, максимально подходящие для выявления потребностей и требований стейкхолдеров заказчика.
2.3.5 Структурируйте коммуникации стейкхолдеров (кто, с какой частотой, что).
2.3.6 Создайте разделяемое ключевыми стейкхолдерами понимание объема работ программы, целей, статуса и трудностей в программе.
2.3.7 Регулярно и без утайки сообщайте стейкхолдерам о достижениях и основных препятствиях программы.
2.3.8 Стройте доверительные и здоровые отношения со стейкхолдерами с помощью открытого общения и раннего вовлечения стейкхолдеров в планирование и исполнение программы.
2.3.9 Терпеливо слушайте комментарии и опасения стейкхолдеров и цените их точку зрения и вклад.
2.3.10 Четко отслеживайте предположения и изменение обстановки, которые влияют на требования стейкхолдеров и их восприятие выгод программы.
2.3.11 Используйте практику отбора и защиты компонентов программы с ключевыми стейкхолдерами как возможность постоянно отслеживать поставку выгоды программой.
2.4 Разрабатывайте высококачественные требования к программе с участием стейкхолдеров заказчика перед запросом коммерческих предложений и стартом исполнения программы.
2.4.1 Удостоверьтесь, что требования заказчика, определенные в запросе на предоставление коммерческого предложения (RFP) или в контракте, полностью описывают потребность. Удостоверьтесь, что они стабильные, полные, четко понимаются всеми, не конфликтуют друг с другом, не избыточные и сформулированы как можно более просто и понятно.
2.4.2 Для разработки запросов на коммерческие предложения, требований и положений контракта используйте только очень опытных людей и проектные институты.
2.4.3 Если у заказчика нет нужной для разработки требований экспертизы, создайте отдельный договор на разработку требований и написание запроса на коммерческие предложения. Отдайте исполнение этого контракта организации, которой вы доверяете и создайте условия, чтобы она несла ответственность вплоть до личной за качество разрабатываемых требований.
2.4.4 Избегайте непродуманной вставки взаимоисключающих и конфликтующих требований, избытка требований, стандартов и правил, которые нужно выполнять в программе. Избегайте бездумного переноса требований из предыдущих программ.
2.4.5 Сводите к минимуму общее количество требований. Включайте только те, которые нужны для создания пользы для стейкхолдеров заказчика.
2.4.6 Настаивайте на том, чтобы за все требования программы отвечал один человек, чтобы обеспечить их сквозную согласованность и эффективность.
2.4.7 Требуйте личной и корпоративной ответственности рецензентов требований, пока программа не продемонстрирует успех.
2.4.8 Всегда четко привязывайте требований к конкретным потребностям стейкхолдеров заказчика и трассируйте требования сверху вниз.
2.4.9 Организуйте экспертную оценку требований различными стейкхолдерами, чтобы убедиться в согласованности и отсутствии конфликтов.
2.4.10 Требуйте обязательную независимую оценку и защиту требований программы, концепции использования и других описаний пользы программы на предмет ясности, отсутствия неопределенности в формулировках, отсутствия конфликтов, стабильности и общей готовности к включению в контракт и реализации.
2.4.11 Четко поставьте задачи верхнего уровня, объясните пользу и выгоды программы, функциональные требования перед тем, как будут выпущены формальные требования или запрос на предоставление коммерческого предложения.
2.4.12 Используйте заранее определенную точку принятия решения, в которой оценивается зрелость требований, выбираются приоритеты выполнения основных задач программы, и оцениваются остаточные риски по требованиям. Эта точка должна быть до выпуска формальных требований или запроса на предоставление коммерческих предложений.
2.5 Уточняйте, расширяйте и расставляйте приоритеты по требованиям рано, часто и дальновидно.
2.5.1 Разработайте Эджайл-практику, чтобы предвидеть изменения требований заказчика, адаптировать программу к меняющимся требованиям заказчика и доводить измененные требования до общего сведения.
2.5.2 Сопровождайте письменные формулировки требований устными пояснениями контекста и ожиданий, чтобы удостовериться во взаимном понимании и согласии. Запишите и разошлите обсуждения и не позволяйте требованиям расползаться.
2.5.3 Используйте методы представления и моделирования архитектуры системы (3D CAE, цифровые двойники, модели, симуляции и инструменты проектирования ПО), которые позволяют взаимодействовать с заказчиком и другими стейкхолдерами и выявлять их требования.
2.5.4 Слушайте и записывайте неявно выраженные требования заказчика.
2.5.5 Чтобы согласовать позиции стейкхолдеров, определите небольшое количество основных целей и задач программы, которые составят миссию программы и определят как программа принесет пользу и какие у нее критерии успеха. Повторяйте цели и миссию, пока остальные их как следует не запомнят.
2.5.6 Настойчиво повышайте зрелость требований стейкхолдеров, например производите изучение вариантов решений, исследуйте реализуемость технических решений, делайте виртуальные прототипы.
2.5.7 Поощряйте общение между различными стейкхолдерами даже если их позиции расходятся. Это способствует общему пониманию и позволяет деятельно объединять интересы стейкхолдеров и повышает доверие в команде.
2.5.8 Создавайте эффективные каналы уточнения требований, например, включайте стейкхолдеров заказчика в работу команды проекта.
2.5.9 Быстро проверяйте решения на практике и отсеивайте неудачные решения на старте работ, еще до того, как потратите на их разработку много сил и времени. Разрабатывайте прототипы, испытывайте элементы системы, стройте цифровые модели, применяйте спиральные модели жизненного цикла системы.
2.5.10 Используйте методы Эджайл для работы с неизбежно меняющимися требованиями, производите устойчивые к таким изменениям требований предметы поставки. Добивайтесь модульности как предпринятия так и системы: практики и модули системы должны быть повторно используемыми, менять конфигурацию и масштабируемыми.
2.6 Активно боритесь с бюрократией, регуляторным и корпоративным бременем по документообороту на уровне программы и подпроектов.
2.6.1 Стремитесь к минимальному и согласованному документальному сопровождению работы для внешних стейкхолдеров. Для этого активно вовлекайте их в работу и объясняйте конкретную пользу от каждого заполняемого ими отчета.
2.6.2 Оптимизируйте внутренние требования к проектной отчетности. Это позволит согласовать и минимизировать документооборот внутри программы. Требуйте составления только необходимых отчетов и только в той мере, в которой они отвечают требованиям к документообороту.
2.6.3 Проверьте и убедитесь, что все шаги одобрения и утверждения решения на самом деле нужны и приносят пользу программе.
3. Оптимизация модели жизненного цикла
3.1 Явно моделируйте инженерные и управленческие практики с обоснованиями их применения и устраняйте практики, не приносящие пользы.
3.1.1 Планируйте разработку только того, что нужно разрабатывать.
3.1.2 Поощряйте повторное использование и совместное использование активов программы. Используйте стандарты, стандартные практики, модули знаний, технические стандарты и платформы, библиотеки программ.
3.1.3 Организуйте совместную разработку модели жизненного цикла стейкхолдерами различных функций и руководства программы.
3.1.4 Используйте стандартные методы разработки модели жизненного цикла для выявления и устранения потерь в практиках управления и инженерии и для адаптации задач к потребностям программы.
3.2 Интенсивно проектируйте предпринятие и управляйте программой, чтобы достичь ее максимальной эффективности как системы.
3.2.1 В начале программы мероприятия должно проводиться совместно размещенной группой исполнителей, т.к. на старте требуется высокая степень согласованности работ.
3.2.2 Создайте единую централизованную службу, которая будет заниматься системной инженерией и архитектурой предприятия на всем жизненном цикле. Это повысит ответственность и решит проблемы полномочий.
3.2.3 Обеспечьте объединение практик системной инженерии и архитектуры предприятия с практиками управления программой, не отдавайте их на подряд, т.к эти практики тесно взаимосвязаны и требуют высокой скоординированности.
3.2.4 Сформируйте четкое видение и целостный взгляд на будущее состояние вашего предпринятия, включая портфель продуктов, организацию и жизненный цикл. Обеспечьте руководство на движении к целевому состоянию и озаботьтесь ресурсным обеспечением этих планов.
3.2.5 Используйте четкое описание архитектуры согласованного решения, чтобы создавать согласованные между собой планы программы, инженерные и коммерческие структуры.
3.2.6 Меняйте настрой в программе на командную работу и общий результат, который будет сдан заказчику. Команда должна думать о той пользе, которую этот результат принесет.
3.2.7 Ведите и поддерживайте преобразование предприятия в организацию, в которой практики системной инженерии и управления программами заказчика и поставщиков тесно связаны между собой.
3.2.8 Настаивайте на выборе той системной архитектуры, которая отвечает производственной необходимости, но не привязана к проприетарным технологиям или особым технологическим возможностям конкретных подрядчиков.
3.3 Развивайте несколько наборов решений параллельно.
3.3.1 На старте проекта для оценки различных вариантов решений запланируйте использование межфункциональных команд, составленных из наиболее опытных и совместимых между собой людей.
3.3.2 Полностью исследуйте пространство выборов и границы перед тем как выбрать оптимальный вариант решения со слишком узкими границами.
3.3.3 Для ключевых решений исследуйте альтернативные решения в параллель до тех пор, пока получаемая информация окупает стоимость дополнительной ветки разработки.
3.3.4 На ранних стадиях разработки исследуйте несколько вариантов концепций продукта, архитектур и дизайнов.
3.3.5 Исследуйте ограничения и изучайте последствия выборов в натурных экспериментах прежде чем выберете конкретные параметры изделия.
3.3.6 При прочих равных выбирайте более простое решение.
3.4 Заранее убедитесь, что в предпринятии поставлены все необходимые практики и они способны принести ожидаемые результаты по количеству и качеству работы.
3.4.1 Убедитесь, что у вас есть сильная корпоративная, регламентированная и личная ответственность и личные штрафные санкции за намеренное занижение оценок бюджетов, сроков, рисков и переоценку уровня готовности технологии к применению (TRL) с целью выиграть контракт.
3.4.2 Если вы обнаружили намеренное занижение оценок на контракте с фиксированной ценой, настаивайте на продолжении работ по нему либо прекращайте программу и проводите тендер заново. Не позволяйте переключиться на контракт “издержки плюс”.
3.4.3 Убедитесь, что планировщики и сметчики несут ответственность за свои оценки в ходе исполнения программы. Сводите к минимуму самообман.
3.5 Активно используйте ресурсы на старте программы и интегрируйте предпринятие в цепочку производственной кооперации.
3.5.1 С самого начала планируйте проблемоустойчивое исполнение и правильное выполнение задач с первого раза в нормальных обстоятельствах. Не надо героически решать проблемы по мере их возникновения.
3.5.2 Заблаговременно уделите достаточно ресурсов и времени для того, чтобы понять какие в программе на самом деле ключевые требования и ожидаемые выгоды.
3.5.3 До начала работ запустите системы и наладьте практики, которые позволят вам осуществлять комплексное, эффективное и результативное заблаговременное планирование программы.
3.5.4 Команда управления проектом (руководитель программы, главные системные инженеры, технические руководители) должны до начала работ определить всех ключевых стейкхолдеров программы.
3.5.5 Проведите совещание по запуску программы с ключевыми стейкхолдерами, на котором расскажите про выгоды от программы и механизмы получения выгод, например, с помощью модели жизненного цикла. Определите и назначьте роли и ответственность, определите ключевые зависимости и риски программы, установите основные контрольные точки и зафиксируйте план действий.
3.5.6 В критических подпроектах проведите мероприятия, описанные в п. 3.5.5
3.5.7 Выясните, что доступно программе (таланты, ресурсы, бюджет, временные рамки) и что будет недоступно до того, как пообещаете что-то заказчику и другим стейкхолдерам.
3.5.8 Устройте сессии высокоуровневого планирования для программы и ключевых подпроектов. Вовлекайте всех стейкхолдеров в разработку модели жизненного цикла, мастер-плана, планирование рисков и выявление возможностей, ключевых предположений и составление плана действий.
3.5.9 Для всех самых важных мероприятий определите ответственных за исполнение, за результат, обеспечивающих выполнение и получающих информацию (матрица RACI). При этом используйте стандартный инструмент, уделяйте внимание последовательности задач и документируйте сдачу-приемку.
3.5.10 Тщательное заблаговременное планирование программы и ключевых подпроектов должно перейти в практику постоянного планирования и улучшения с регулярными рабочими совещаниями.
3.5.11 Предусмотрите возникновение и запланируйте решение вопросов смежников как можно раньше, чтобы не допустить их перерастания в проблемы.
3.5.12 Включите детальное выявление, оценку и реагирование на риски в ранние стадии планирования программы.
3.5.13 Убедитесь, что руководство уделило достаточно времени на планирование решения технических проблем.
3.5.14 Руководитель программы должен лично понимать, уточнять, и устранять неоднозначность, конфликты и потери в ключевых требованиях и ожиданиях на запуске программы.
3.5.15 Активно вовлекайте ключевых поставщиков в планирование программы и на ранних стадиях программы.
3.6 Используйте вероятностные оценки при планировании программы.
3.6.1 Делайте вероятностные оценки стоимости, сроков и других важных прогнозов.
3.6.2 Планируйте программу, основываясь на доверительных интервалах величин, а не точечных оценках.
3.7 Будьте дальновидны при работе с поставщиками, не допускайте возникновения конфликтов с ними в будущем, предсказывайте риски и уклоняйтесь от них.
3.7.1 Разрешайте вынос на аутсорс и субподряд только тех элементов программы, которые вы очень точно определили и маловероятно, что они изменятся. Не выносите на субподряд на ранних стадиях программы, когда потребность в тесной координации наиболее сильна.
3.7.2 Во время разработки концепции продукта поставщики должны рассказывать команде программы о своих текущих и будущих технологических и производственных способностях.
3.7.3 Чтобы выявить риски, связанные с поставщиками, и избежать их, надо вовлекать поставщиков с самого начала программы.
3.7.4 Указывайте своим партнерам и поставщикам на недостатки в их работе и помогайте им улучшать практики. Этим вы покажете свое уважение к ним.
3.7.5 Согласуйте шаги процесса поставок и сосредоточьтесь на поставке точно в срок, чтобы уменьшить уровень товарных запасов.
3.7.6 Когда разрабатываете требования, которые должны будут реализовать несколько поставщиков, удостоверьтесь, что эти требования независимы друг от друга. Если набор требований, который реализует один поставщик, зависит от набора требований, который реализует другой поставщик, то вам придется управлять этими зависимостями и нести дополнительные риски.
3.7.7 Четко и однозначно доводите до поставщиков все ожидания, включая системные контексты и потребности, все процедуры работы, сдачи-приемки и испытаний. Убедитесь, что требования, которые вы им передали, не изменяются.
3.7.8 Подбирайте поставщиков по их технической и культурной совместимости.
3.7.9 Старайтесь разрушить организационные барьеры между командой разработки и поставщиками. Они должны чувствовать себя партнерами.
3.7.10 Ключевые поставщики должны быть частью вашей команды.
3.7.11 Рассматривайте поставщиков как доверенных партнеров программы, предлагайте им внести серьезный вклад в практики системной инженерии, проектирования и разработки.
3.7.12 Разрешайте своим инженерам напрямую общаться с инженерами поставщиков, но при соблюдении установленных правил. Такое доверие позволит быстро и эффективно прояснять непонятные моменты, при этом важные вопросы будут решаться руководителями.
3.8 Разрабатывайте опережающие показатели и метрики для управления программой.
3.8.1 Используйте опережающие индикаторы, чтобы устранять риски до того, как они начнут приносить неприятности.
3.8.2 При выборе показателей ориентируйтесь на пользу для стейкхолдеров заказчика и выгоды программы.
3.8.3 Используйте небольшое количество понятных всем показателей и часто рассказывайте про динамику выбранных показателей всему предприятию.
3.8.4 Используйте показатели, которые поощряют правильное поведение. Будьте очень осторожны при выборе показателей, проверяйте, не приведут ли они к появлению плохих моделей поведения.
3.8.5 Используйте только те показатели, которые отвечают заявленной потребности, задачам или выгодам программы.
3.9 Разрабатывайте сводный мастер-план программы на том уровне детализации, на котором у вас есть надежная информация.
3.9.1 Создайте план, который объединит и согласует между собой все высокоуровневое планирование и координацию. Как минимум, там должны быть планы системной инженерии и управлению программой.
3.9.2 Максимально запараллеливайте исполнение задач, которые не зависят друг от друга либо получают друг от друга информацию, важную для исполнения.
3.9.3 Чтобы синхронизировать мероприятия, составляйте расписание со всеми бизнес-функциями, а потом подробно распишите работы внутри бизнес-функций.
3.9.4 Не планируйте полную загрузку, не позволяйте накапливаться вариативности в потоке работ. Создайте управленческие резервы на каждом уровне и разрешите менять загрузку ресурсов.
3.9.5 Готовьтесь точно балансировать поток работ, чтобы убрать вариативность прибытий задач и выдержать расписание программы.
3.9.6 Аккуратно планируйте последовательность управленческих и инженерных задач. Тщательно обдумайте, какая задача даст сведения и уточнит постановку для какой другой задачи. Поймите взаимосвязь и определите суммарные задачи и подзадачи.
3.9.7 Осуществляйте регулярное подробное планирование, чтобы отразить новую поступающую информацию и убедиться, что эта информация согласуется с долгосрочными планами. Не заставляйте программу соответствовать детальному устаревшему плану, который был построен на неполной информации.
3.10 Управляйте уровнями готовности технологии к использованию и защищайте программу от задержек и перерасходов, связанных с низким уровнем готовности технологии к использованию.
3.10.1 Перед заключением контракта на крупную программу полностью опишите все технологические риски и связанные с ними риски по срокам и стоимости. Заключите небольшие контракты, направленные на повышение уровня готовности технологии к применению перед запуском крупной программы.
3.10.2 Дайте руководящие указания и отслеживайте их исполнение в части повышения зрелости технологии и вставки технологии в рабочие процессы предприятия. Четко определите какой уровень технологических рисков и связанных с ними рисков по стоимости и срокам допустим в разных обстоятельствах (паралич от анализа против провала программы).
3.10.3 Полностью осознавайте риски и возможности использования новой технологии или производственного процесса.
3.10.4 Используйте эволюционные, инкрементальные или спиральные виды жизненного цикла, чтобы обеспечить наилучший баланс технологических рисков и выигрышей.
3.10.5 Чтобы справиться с технологическими рисками программы активно применяйте практику управления рисками. У вас должны быть планы реагирования на технологические проблемы.
3.10.6 На критическом пути программы не должно быть исследований, результаты которых могут остановить программу, и не обкатанных технологий. Такие исследования и обкатка технологий должны быть выделены в отдельные контракты, и планы по снижению рисков включены в план по снижению рисков. Повторно вернитесь к вопросу встраивания результатов таких исследований и новых технологий после того, как получите достаточный уровень знаний по ним.
3.10.7 Обеспечьте стабильное финансирование разработки технологии и доведения ее до промышленного уровня. Это даст вам надежный поток новых технологий, которые вы сможете использовать в программе.
3.10.8 Технологии должны отвечать требованиям и потребностям программы. Не допускайте избыточного уровня технологий в программе.
3.10.9 Практики инженерии требований и разработки системной архитектуры должны определять независимые от конкретной реализации требования к технологиям и уровень готовности технологии к применению.
3.10.10 Обеспечьте четкое и единое понимание того, какие технологии и технологические стандарты будут использованы в программе.
3.10.11 Перед началом использования новой технологии, которая может замедлить ход работ или привести к перерасходу бюджета или перед постановкой новой практики проводите независимую техническую оценку этой технологии либо практики.
3.11 Разрабатывайте план коммуникаций.
3.11.1 Разрабатывайте и исполняйте план коммуникаций, который охватывает весь жизненный цикл программы.
3.11.2 Используйте визуализацию где только возможно. Планы, загрузка ресурсов, изменения в требованиях заказчика - первые кандидаты на визуализацию.
4. Создание потока работ в программе.
4.1 Используйте системную инженерию для координации и интеграции всех инженерных задач в программе.
4.1.1 Вовлекайте системных инженеров в инженерные работы на протяжении всего жизненного цикла от подготовки предложения до итоговой поставки заказчику.
4.1.2 Поддерживайте преемственность команды между стадиями, чтобы получить максимум опыта от исполнения программы. Постарайтесь взять в команду людей, которые готовили предложение.
1.5.6 Для новых стандартов и регламентов немедленно организуйте обучение, чтобы все про него знали и понимали, зачем этот стандарт нужен.
1.6 Поощрять развитие личных контактов и взаимодействий.
1.6.1 Если выбираете между физическим совместным размещением команды и регулярными собраниями онлайн, выбирайте первое.
1.6.2 При построении виртуальных команд вкладывайтесь в личные встречи на старте совместной работы, чтобы построить личные отношения.
1.6.3 Поощряйте прямой человеческий контакт, чтобы построить личные отношения.
1.6.4 Участвуйте в мероприятиях, которые задействуют различные функции, например, в планирование модели жизненного цикла программы.
1.6.5 Вовлекайтесь и поддерживайте интенсивное взаимодействие со стейкхолдерами.
1.6.6 Поддерживайте развитие неформальных сетей внутри программы и с ключевыми внешними стейкхолдерами.
1.6.7 Поощряйте и когда надо документируйте открытый обмен информацией внутри программы.
1.6.8 Руководитель программы должен иметь взаимное уважение и личные отношения со всеми четырьмя основными группами стейкхолдеров: заказчиками, руководителями, персоналом программы и ключевыми подрядчиками и поставщиками.
2. Максимум пользы от программы
2.1 Установить, в чем видят пользу и выгоды от реализации программы стейкхолдеры.
2.1.1 Определять пользу как результат, который отвечает минимум трем условиям:
а) Внешние стейкхолдеры заказчика готовы заплатить за него
б) Преобразует материалы или информацию или уменьшает неопределенность
в) Дает определенные в программе выгоды с первого раза
2.1.2 Определять добавленную пользу в терминах стейкхолдеров заказчика и их потребностей.
2.1.3 Разработать надежно выполняющуюся практику крайне точного формулирования пользы для стейкхолдеров заказчика, ее уточнения и распространения.
2.1.4 Дальновидно решайте возможные конфликты пользы и ожиданий различных стейкхолдеров и ищите полного согласия.
2.1.5 Объясняйте культуру стейкхолдеров заказчика персоналу программы, такие как систему ценностей, подходы, отношения, ожидания и ключевые моменты.
2.2 Сосредоточьте все мероприятия программы на выгодах, которые планирует принести программа.
2.2.1 Все мероприятия программы, включая коммуникации и работу с показателями, должно выполняться с оглядкой на ожидаемые результаты программы - запланированные выгоды программы.
2.2.2 Согласовывайте ресурсы программы, чтобы достичь запланированной выгоды и включите мероприятия, которые позволят поддерживать получение выгоды и далее, после закрытия программы.
2.2.3 Удостоверьтесь, что персонал программы и команды полностью понимают, как исполнение программы и выгоды соотносятся со стратегическими целями организации (конкурентоспособность и прибыльность).
2.3 Часто вовлекайте стейкхолдеров на всем жизненном цикле программы.
2.3.1 Все люди, которые работают в программе, должны руководствоваться прежде всего интересами и потребностями заказчика, которые выражены в выгодах и требованиях программы.
2.3.2 Установите частое и эффективное взаимодействие между внутренними и внешними стейкхолдерами.
2.3.3 Двигайтесь в направлении видения и архитектуры программы, которые четко выражают требования стейкхолдеров заказчика и могут адаптироваться к изменениям.
2.3.4 Разработайте план, который опишет рабочие продукты и взаимодействия, максимально подходящие для выявления потребностей и требований стейкхолдеров заказчика.
2.3.5 Структурируйте коммуникации стейкхолдеров (кто, с какой частотой, что).
2.3.6 Создайте разделяемое ключевыми стейкхолдерами понимание объема работ программы, целей, статуса и трудностей в программе.
2.3.7 Регулярно и без утайки сообщайте стейкхолдерам о достижениях и основных препятствиях программы.
2.3.8 Стройте доверительные и здоровые отношения со стейкхолдерами с помощью открытого общения и раннего вовлечения стейкхолдеров в планирование и исполнение программы.
2.3.9 Терпеливо слушайте комментарии и опасения стейкхолдеров и цените их точку зрения и вклад.
2.3.10 Четко отслеживайте предположения и изменение обстановки, которые влияют на требования стейкхолдеров и их восприятие выгод программы.
2.3.11 Используйте практику отбора и защиты компонентов программы с ключевыми стейкхолдерами как возможность постоянно отслеживать поставку выгоды программой.
2.4 Разрабатывайте высококачественные требования к программе с участием стейкхолдеров заказчика перед запросом коммерческих предложений и стартом исполнения программы.
2.4.1 Удостоверьтесь, что требования заказчика, определенные в запросе на предоставление коммерческого предложения (RFP) или в контракте, полностью описывают потребность. Удостоверьтесь, что они стабильные, полные, четко понимаются всеми, не конфликтуют друг с другом, не избыточные и сформулированы как можно более просто и понятно.
2.4.2 Для разработки запросов на коммерческие предложения, требований и положений контракта используйте только очень опытных людей и проектные институты.
2.4.3 Если у заказчика нет нужной для разработки требований экспертизы, создайте отдельный договор на разработку требований и написание запроса на коммерческие предложения. Отдайте исполнение этого контракта организации, которой вы доверяете и создайте условия, чтобы она несла ответственность вплоть до личной за качество разрабатываемых требований.
2.4.4 Избегайте непродуманной вставки взаимоисключающих и конфликтующих требований, избытка требований, стандартов и правил, которые нужно выполнять в программе. Избегайте бездумного переноса требований из предыдущих программ.
2.4.5 Сводите к минимуму общее количество требований. Включайте только те, которые нужны для создания пользы для стейкхолдеров заказчика.
2.4.6 Настаивайте на том, чтобы за все требования программы отвечал один человек, чтобы обеспечить их сквозную согласованность и эффективность.
2.4.7 Требуйте личной и корпоративной ответственности рецензентов требований, пока программа не продемонстрирует успех.
2.4.8 Всегда четко привязывайте требований к конкретным потребностям стейкхолдеров заказчика и трассируйте требования сверху вниз.
2.4.9 Организуйте экспертную оценку требований различными стейкхолдерами, чтобы убедиться в согласованности и отсутствии конфликтов.
2.4.10 Требуйте обязательную независимую оценку и защиту требований программы, концепции использования и других описаний пользы программы на предмет ясности, отсутствия неопределенности в формулировках, отсутствия конфликтов, стабильности и общей готовности к включению в контракт и реализации.
2.4.11 Четко поставьте задачи верхнего уровня, объясните пользу и выгоды программы, функциональные требования перед тем, как будут выпущены формальные требования или запрос на предоставление коммерческого предложения.
2.4.12 Используйте заранее определенную точку принятия решения, в которой оценивается зрелость требований, выбираются приоритеты выполнения основных задач программы, и оцениваются остаточные риски по требованиям. Эта точка должна быть до выпуска формальных требований или запроса на предоставление коммерческих предложений.
2.5 Уточняйте, расширяйте и расставляйте приоритеты по требованиям рано, часто и дальновидно.
2.5.1 Разработайте Эджайл-практику, чтобы предвидеть изменения требований заказчика, адаптировать программу к меняющимся требованиям заказчика и доводить измененные требования до общего сведения.
2.5.2 Сопровождайте письменные формулировки требований устными пояснениями контекста и ожиданий, чтобы удостовериться во взаимном понимании и согласии. Запишите и разошлите обсуждения и не позволяйте требованиям расползаться.
2.5.3 Используйте методы представления и моделирования архитектуры системы (3D CAE, цифровые двойники, модели, симуляции и инструменты проектирования ПО), которые позволяют взаимодействовать с заказчиком и другими стейкхолдерами и выявлять их требования.
2.5.4 Слушайте и записывайте неявно выраженные требования заказчика.
2.5.5 Чтобы согласовать позиции стейкхолдеров, определите небольшое количество основных целей и задач программы, которые составят миссию программы и определят как программа принесет пользу и какие у нее критерии успеха. Повторяйте цели и миссию, пока остальные их как следует не запомнят.
2.5.6 Настойчиво повышайте зрелость требований стейкхолдеров, например производите изучение вариантов решений, исследуйте реализуемость технических решений, делайте виртуальные прототипы.
2.5.7 Поощряйте общение между различными стейкхолдерами даже если их позиции расходятся. Это способствует общему пониманию и позволяет деятельно объединять интересы стейкхолдеров и повышает доверие в команде.
2.5.8 Создавайте эффективные каналы уточнения требований, например, включайте стейкхолдеров заказчика в работу команды проекта.
2.5.9 Быстро проверяйте решения на практике и отсеивайте неудачные решения на старте работ, еще до того, как потратите на их разработку много сил и времени. Разрабатывайте прототипы, испытывайте элементы системы, стройте цифровые модели, применяйте спиральные модели жизненного цикла системы.
2.5.10 Используйте методы Эджайл для работы с неизбежно меняющимися требованиями, производите устойчивые к таким изменениям требований предметы поставки. Добивайтесь модульности как предпринятия так и системы: практики и модули системы должны быть повторно используемыми, менять конфигурацию и масштабируемыми.
2.6 Активно боритесь с бюрократией, регуляторным и корпоративным бременем по документообороту на уровне программы и подпроектов.
2.6.1 Стремитесь к минимальному и согласованному документальному сопровождению работы для внешних стейкхолдеров. Для этого активно вовлекайте их в работу и объясняйте конкретную пользу от каждого заполняемого ими отчета.
2.6.2 Оптимизируйте внутренние требования к проектной отчетности. Это позволит согласовать и минимизировать документооборот внутри программы. Требуйте составления только необходимых отчетов и только в той мере, в которой они отвечают требованиям к документообороту.
2.6.3 Проверьте и убедитесь, что все шаги одобрения и утверждения решения на самом деле нужны и приносят пользу программе.
3. Оптимизация модели жизненного цикла
3.1 Явно моделируйте инженерные и управленческие практики с обоснованиями их применения и устраняйте практики, не приносящие пользы.
3.1.1 Планируйте разработку только того, что нужно разрабатывать.
3.1.2 Поощряйте повторное использование и совместное использование активов программы. Используйте стандарты, стандартные практики, модули знаний, технические стандарты и платформы, библиотеки программ.
3.1.3 Организуйте совместную разработку модели жизненного цикла стейкхолдерами различных функций и руководства программы.
3.1.4 Используйте стандартные методы разработки модели жизненного цикла для выявления и устранения потерь в практиках управления и инженерии и для адаптации задач к потребностям программы.
3.2 Интенсивно проектируйте предпринятие и управляйте программой, чтобы достичь ее максимальной эффективности как системы.
3.2.1 В начале программы мероприятия должно проводиться совместно размещенной группой исполнителей, т.к. на старте требуется высокая степень согласованности работ.
3.2.2 Создайте единую централизованную службу, которая будет заниматься системной инженерией и архитектурой предприятия на всем жизненном цикле. Это повысит ответственность и решит проблемы полномочий.
3.2.3 Обеспечьте объединение практик системной инженерии и архитектуры предприятия с практиками управления программой, не отдавайте их на подряд, т.к эти практики тесно взаимосвязаны и требуют высокой скоординированности.
3.2.4 Сформируйте четкое видение и целостный взгляд на будущее состояние вашего предпринятия, включая портфель продуктов, организацию и жизненный цикл. Обеспечьте руководство на движении к целевому состоянию и озаботьтесь ресурсным обеспечением этих планов.
3.2.5 Используйте четкое описание архитектуры согласованного решения, чтобы создавать согласованные между собой планы программы, инженерные и коммерческие структуры.
3.2.6 Меняйте настрой в программе на командную работу и общий результат, который будет сдан заказчику. Команда должна думать о той пользе, которую этот результат принесет.
3.2.7 Ведите и поддерживайте преобразование предприятия в организацию, в которой практики системной инженерии и управления программами заказчика и поставщиков тесно связаны между собой.
3.2.8 Настаивайте на выборе той системной архитектуры, которая отвечает производственной необходимости, но не привязана к проприетарным технологиям или особым технологическим возможностям конкретных подрядчиков.
3.3 Развивайте несколько наборов решений параллельно.
3.3.1 На старте проекта для оценки различных вариантов решений запланируйте использование межфункциональных команд, составленных из наиболее опытных и совместимых между собой людей.
3.3.2 Полностью исследуйте пространство выборов и границы перед тем как выбрать оптимальный вариант решения со слишком узкими границами.
3.3.3 Для ключевых решений исследуйте альтернативные решения в параллель до тех пор, пока получаемая информация окупает стоимость дополнительной ветки разработки.
3.3.4 На ранних стадиях разработки исследуйте несколько вариантов концепций продукта, архитектур и дизайнов.
3.3.5 Исследуйте ограничения и изучайте последствия выборов в натурных экспериментах прежде чем выберете конкретные параметры изделия.
3.3.6 При прочих равных выбирайте более простое решение.
3.4 Заранее убедитесь, что в предпринятии поставлены все необходимые практики и они способны принести ожидаемые результаты по количеству и качеству работы.
3.4.1 Убедитесь, что у вас есть сильная корпоративная, регламентированная и личная ответственность и личные штрафные санкции за намеренное занижение оценок бюджетов, сроков, рисков и переоценку уровня готовности технологии к применению (TRL) с целью выиграть контракт.
3.4.2 Если вы обнаружили намеренное занижение оценок на контракте с фиксированной ценой, настаивайте на продолжении работ по нему либо прекращайте программу и проводите тендер заново. Не позволяйте переключиться на контракт “издержки плюс”.
3.4.3 Убедитесь, что планировщики и сметчики несут ответственность за свои оценки в ходе исполнения программы. Сводите к минимуму самообман.
3.5 Активно используйте ресурсы на старте программы и интегрируйте предпринятие в цепочку производственной кооперации.
3.5.1 С самого начала планируйте проблемоустойчивое исполнение и правильное выполнение задач с первого раза в нормальных обстоятельствах. Не надо героически решать проблемы по мере их возникновения.
3.5.2 Заблаговременно уделите достаточно ресурсов и времени для того, чтобы понять какие в программе на самом деле ключевые требования и ожидаемые выгоды.
3.5.3 До начала работ запустите системы и наладьте практики, которые позволят вам осуществлять комплексное, эффективное и результативное заблаговременное планирование программы.
3.5.4 Команда управления проектом (руководитель программы, главные системные инженеры, технические руководители) должны до начала работ определить всех ключевых стейкхолдеров программы.
3.5.5 Проведите совещание по запуску программы с ключевыми стейкхолдерами, на котором расскажите про выгоды от программы и механизмы получения выгод, например, с помощью модели жизненного цикла. Определите и назначьте роли и ответственность, определите ключевые зависимости и риски программы, установите основные контрольные точки и зафиксируйте план действий.
3.5.6 В критических подпроектах проведите мероприятия, описанные в п. 3.5.5
3.5.7 Выясните, что доступно программе (таланты, ресурсы, бюджет, временные рамки) и что будет недоступно до того, как пообещаете что-то заказчику и другим стейкхолдерам.
3.5.8 Устройте сессии высокоуровневого планирования для программы и ключевых подпроектов. Вовлекайте всех стейкхолдеров в разработку модели жизненного цикла, мастер-плана, планирование рисков и выявление возможностей, ключевых предположений и составление плана действий.
3.5.9 Для всех самых важных мероприятий определите ответственных за исполнение, за результат, обеспечивающих выполнение и получающих информацию (матрица RACI). При этом используйте стандартный инструмент, уделяйте внимание последовательности задач и документируйте сдачу-приемку.
3.5.10 Тщательное заблаговременное планирование программы и ключевых подпроектов должно перейти в практику постоянного планирования и улучшения с регулярными рабочими совещаниями.
3.5.11 Предусмотрите возникновение и запланируйте решение вопросов смежников как можно раньше, чтобы не допустить их перерастания в проблемы.
3.5.12 Включите детальное выявление, оценку и реагирование на риски в ранние стадии планирования программы.
3.5.13 Убедитесь, что руководство уделило достаточно времени на планирование решения технических проблем.
3.5.14 Руководитель программы должен лично понимать, уточнять, и устранять неоднозначность, конфликты и потери в ключевых требованиях и ожиданиях на запуске программы.
3.5.15 Активно вовлекайте ключевых поставщиков в планирование программы и на ранних стадиях программы.
3.6 Используйте вероятностные оценки при планировании программы.
3.6.1 Делайте вероятностные оценки стоимости, сроков и других важных прогнозов.
3.6.2 Планируйте программу, основываясь на доверительных интервалах величин, а не точечных оценках.
3.7 Будьте дальновидны при работе с поставщиками, не допускайте возникновения конфликтов с ними в будущем, предсказывайте риски и уклоняйтесь от них.
3.7.1 Разрешайте вынос на аутсорс и субподряд только тех элементов программы, которые вы очень точно определили и маловероятно, что они изменятся. Не выносите на субподряд на ранних стадиях программы, когда потребность в тесной координации наиболее сильна.
3.7.2 Во время разработки концепции продукта поставщики должны рассказывать команде программы о своих текущих и будущих технологических и производственных способностях.
3.7.3 Чтобы выявить риски, связанные с поставщиками, и избежать их, надо вовлекать поставщиков с самого начала программы.
3.7.4 Указывайте своим партнерам и поставщикам на недостатки в их работе и помогайте им улучшать практики. Этим вы покажете свое уважение к ним.
3.7.5 Согласуйте шаги процесса поставок и сосредоточьтесь на поставке точно в срок, чтобы уменьшить уровень товарных запасов.
3.7.6 Когда разрабатываете требования, которые должны будут реализовать несколько поставщиков, удостоверьтесь, что эти требования независимы друг от друга. Если набор требований, который реализует один поставщик, зависит от набора требований, который реализует другой поставщик, то вам придется управлять этими зависимостями и нести дополнительные риски.
3.7.7 Четко и однозначно доводите до поставщиков все ожидания, включая системные контексты и потребности, все процедуры работы, сдачи-приемки и испытаний. Убедитесь, что требования, которые вы им передали, не изменяются.
3.7.8 Подбирайте поставщиков по их технической и культурной совместимости.
3.7.9 Старайтесь разрушить организационные барьеры между командой разработки и поставщиками. Они должны чувствовать себя партнерами.
3.7.10 Ключевые поставщики должны быть частью вашей команды.
3.7.11 Рассматривайте поставщиков как доверенных партнеров программы, предлагайте им внести серьезный вклад в практики системной инженерии, проектирования и разработки.
3.7.12 Разрешайте своим инженерам напрямую общаться с инженерами поставщиков, но при соблюдении установленных правил. Такое доверие позволит быстро и эффективно прояснять непонятные моменты, при этом важные вопросы будут решаться руководителями.
3.8 Разрабатывайте опережающие показатели и метрики для управления программой.
3.8.1 Используйте опережающие индикаторы, чтобы устранять риски до того, как они начнут приносить неприятности.
3.8.2 При выборе показателей ориентируйтесь на пользу для стейкхолдеров заказчика и выгоды программы.
3.8.3 Используйте небольшое количество понятных всем показателей и часто рассказывайте про динамику выбранных показателей всему предприятию.
3.8.4 Используйте показатели, которые поощряют правильное поведение. Будьте очень осторожны при выборе показателей, проверяйте, не приведут ли они к появлению плохих моделей поведения.
3.8.5 Используйте только те показатели, которые отвечают заявленной потребности, задачам или выгодам программы.
3.9 Разрабатывайте сводный мастер-план программы на том уровне детализации, на котором у вас есть надежная информация.
3.9.1 Создайте план, который объединит и согласует между собой все высокоуровневое планирование и координацию. Как минимум, там должны быть планы системной инженерии и управлению программой.
3.9.2 Максимально запараллеливайте исполнение задач, которые не зависят друг от друга либо получают друг от друга информацию, важную для исполнения.
3.9.3 Чтобы синхронизировать мероприятия, составляйте расписание со всеми бизнес-функциями, а потом подробно распишите работы внутри бизнес-функций.
3.9.4 Не планируйте полную загрузку, не позволяйте накапливаться вариативности в потоке работ. Создайте управленческие резервы на каждом уровне и разрешите менять загрузку ресурсов.
3.9.5 Готовьтесь точно балансировать поток работ, чтобы убрать вариативность прибытий задач и выдержать расписание программы.
3.9.6 Аккуратно планируйте последовательность управленческих и инженерных задач. Тщательно обдумайте, какая задача даст сведения и уточнит постановку для какой другой задачи. Поймите взаимосвязь и определите суммарные задачи и подзадачи.
3.9.7 Осуществляйте регулярное подробное планирование, чтобы отразить новую поступающую информацию и убедиться, что эта информация согласуется с долгосрочными планами. Не заставляйте программу соответствовать детальному устаревшему плану, который был построен на неполной информации.
3.10 Управляйте уровнями готовности технологии к использованию и защищайте программу от задержек и перерасходов, связанных с низким уровнем готовности технологии к использованию.
3.10.1 Перед заключением контракта на крупную программу полностью опишите все технологические риски и связанные с ними риски по срокам и стоимости. Заключите небольшие контракты, направленные на повышение уровня готовности технологии к применению перед запуском крупной программы.
3.10.2 Дайте руководящие указания и отслеживайте их исполнение в части повышения зрелости технологии и вставки технологии в рабочие процессы предприятия. Четко определите какой уровень технологических рисков и связанных с ними рисков по стоимости и срокам допустим в разных обстоятельствах (паралич от анализа против провала программы).
3.10.3 Полностью осознавайте риски и возможности использования новой технологии или производственного процесса.
3.10.4 Используйте эволюционные, инкрементальные или спиральные виды жизненного цикла, чтобы обеспечить наилучший баланс технологических рисков и выигрышей.
3.10.5 Чтобы справиться с технологическими рисками программы активно применяйте практику управления рисками. У вас должны быть планы реагирования на технологические проблемы.
3.10.6 На критическом пути программы не должно быть исследований, результаты которых могут остановить программу, и не обкатанных технологий. Такие исследования и обкатка технологий должны быть выделены в отдельные контракты, и планы по снижению рисков включены в план по снижению рисков. Повторно вернитесь к вопросу встраивания результатов таких исследований и новых технологий после того, как получите достаточный уровень знаний по ним.
3.10.7 Обеспечьте стабильное финансирование разработки технологии и доведения ее до промышленного уровня. Это даст вам надежный поток новых технологий, которые вы сможете использовать в программе.
3.10.8 Технологии должны отвечать требованиям и потребностям программы. Не допускайте избыточного уровня технологий в программе.
3.10.9 Практики инженерии требований и разработки системной архитектуры должны определять независимые от конкретной реализации требования к технологиям и уровень готовности технологии к применению.
3.10.10 Обеспечьте четкое и единое понимание того, какие технологии и технологические стандарты будут использованы в программе.
3.10.11 Перед началом использования новой технологии, которая может замедлить ход работ или привести к перерасходу бюджета или перед постановкой новой практики проводите независимую техническую оценку этой технологии либо практики.
3.11 Разрабатывайте план коммуникаций.
3.11.1 Разрабатывайте и исполняйте план коммуникаций, который охватывает весь жизненный цикл программы.
3.11.2 Используйте визуализацию где только возможно. Планы, загрузка ресурсов, изменения в требованиях заказчика - первые кандидаты на визуализацию.
4. Создание потока работ в программе.
4.1 Используйте системную инженерию для координации и интеграции всех инженерных задач в программе.
4.1.1 Вовлекайте системных инженеров в инженерные работы на протяжении всего жизненного цикла от подготовки предложения до итоговой поставки заказчику.
4.1.2 Поддерживайте преемственность команды между стадиями, чтобы получить максимум опыта от исполнения программы. Постарайтесь взять в команду людей, которые готовили предложение.
4.2 Обеспечивайте четкие зоны ответственности и полномочий (RAA, responsibility, accountability, authority) в течение всей программы от сбора начальных требований до итоговой поставки.
4.2.1 Назначьте опытного руководителя программы, у которого будут все полномочия влиять как на бизнес аспекты, так и на технические аспекты. Он должен нести полную ответственность за результат и работы на всем жизненном цикле программы.
4.2.2 Если необходимо сменить руководителя программы, обеспечьте преемственность. Избегайте ротации персонала.
4.2.3 Четко донесите полномочия и ответственность руководителя программы до всех стейкхолдеров.
4.2.4 Заставляйте людей нести ответственность за краткосрочные и долгосрочные результаты их работы. Смежники, стоящие в ранних стадиях процесса, должны нести ответственность за проблемы, которые их работа вызывает дальше по процессу.
4.2.5 Стейкхолдеры команды управления программой при принятии решений должны демонстрировать высокий уровень взаимного понимания, командной работы, уважения интересов в предметной области.
4.2.6 Разработайте практику определения, поддержания и управления организационными интерфейсами программы. Организационные интерфейсы должны корректно работать на всем жизненном цикле программы.
4.3 В каждой программе должна быть роль руководителя программы, которая отвечает за то, чтобы вести и объединять программу от начала до окончания работ.
4.3.1 Выращивайте исключительно компетентных стейкхолдеров “руководитель программы”. У них должны быть хорошие навыки управления разработкой, людьми, они должны уметь взять на себя задачу достижения успеха программы.
4.3.2 Убедитесь, что у руководителя программы есть необходимый опыт в: бизнесе, общем менеджменте, инженерный опыт, лидерские навыки и навыки управления людьми, есть опыт работы в сложных инженерных программах.
4.3.3 Убедитесь, что компетентность, технические знания и знания предметной области руководителя программы и команды управления программы соответствуют технической сложности программы.
4.3.4 Убедитесь, что руководитель проекта понимает влияние изменений требований, технологии, объема работ. Обычно для этого используются механизмы прослеживаемости и трассировки в моделях архитектуры предприятия.
4.4 Руководство программы, например, офис управления программой, должно эффективно отслеживать происходящие в ней события.
4.4.1 В команде управления программой должны редко появляться новые люди, а текущая команда по возможности должна оставаться неизменной.
4.4.2 Делайте существенные вложения в развитие навыков и человеческий капитал. Вовлекайте в работу людей с глубокими знаниями продуктов и технологии.
4.4.3 По возможности размещайте команды управления программой, системных инженеров, бизнес команды совместно. Они должны постоянно координироваться, чтобы эффективно решать все возможные проблемы на старте программы.
4.5 Принимайте решения совместно и включайте в процесс принятия решения людей, которые помогут устранить корневые причины проблем.
4.5.1 Если решение основано на предположениях, которые могут измениться, отслеживайте такие предположения и меняйте решение, если факты отличаются от предположений.
4.5.2 При принятии решений определяйте свои потребности в информации и окно принятия решений. По мере приближения к точке принятия решений меняйте потребность в информации.
4.5.3 Не принимайте решения впопыхах, всегда исследуйте различные варианты.
4.5.4 Не откладывайте решение только потому, что не хотите брать за него ответственность или боитесь обсуждать проблемы, которые оно влечет.
4.5.5 Разбивайте крупные решения на несколько небольших независимых решений. Во время принятия решений не торгуйтесь по поводу того, кто круче, решайте вопросы так, как надо с точки зрения требований и ограничений программы.
4.5.6 Если вы не можете принять решение по каким-то причинам, запишите его и периодически возвращайтесь к нему.
4.5.7 Опишите четкую понятную практику принятия критических решений, решения конфликтов интересов и приведения к консенсусу.
4.5.8 Проблемы должны исправлять те, кто их создал, там, где они появились и как можно скорее.
4.5.9 Решения проблем должно быть единодушным, должна быть четкая ответственность за его исполнение, лица принимающие решение должны рассмотреть все варианты.
4.5.10 Дальновидно управляйте прохождением развилок и выборами вариантов. Решайте конфликты интересов, не пытайтесь их игнорировать или представлять в лучшем свете.
4.5.11 Убедитесь что архитектура целевой системы и архитектура предприятия поддерживает быстрое принятие решений. Как минимум, учтите орг. дизайн, структуру контрактов, практику принятия решений разных стейкхолдеров, показатели и KPI.
4.6 Объединяйте все функции и элементы программы посредством корпоративного управления программы (program governance).
4.6.1 Убедитесь, что корпоративное управление в программе имеет всю необходимую информацию, может контролировать и влиять на отдельные компоненты программы с целью эффективного направления и балансирования программы.
4.6.2 Используйте общие для всей программы практики, которые объединяют компоненты программы и помогают достичь запланированных выгод. Примером таких практик могут быть управление рисками, ресурсами, коммуникациями.
4.6.3 Устраивайте независимые проверки и защиты программы. Создайте команды за периметром программы, которые будут наблюдать и оценивать исполнение и здоровье программы. Используйте независимых оценщиков.
4.6.4 Используйте модель стадий-гейтов для планирования и исполнения программы. Активно используйте функциональную экспертизу в гейтах.
4.6.5 Обеспечьте интеграцию различных предметных областей по всему жизненному циклу программы. Например, убедитесь, что разработка архитектуры целевой системы, разработка ПО и аппаратной части согласованы.
4.6.6 Согласуйте показатели и KPI по всей программе.
4.7 Используйте эффективную и результативную коммуникацию и координацию с командой программы.
4.7.1 Собирайте и используйте опыт, накопленный в различных программах.
4.7.2 Максимально координируйте работы и поток.
4.7.3 Поддерживайте тесные взаимоотношения с контрагентами во всем предприятии. Это обеспечит эффективную коммуникацию и координацию внутри предприятия и с поставщиками.
4.7.4 Общайтесь часто, открыто, честно, вовремя.
4.7.5 Уменьшайте количество управленческих уровней, это упростит и ускорит общение.
4.7.6 Поощряйте прямое неформальное и личное общение.
4.8 Стандартизуйте основные элементы программы и проектов программы, чтобы повысить эффективность и улучшить взаимодействие.
4.8.1 Введите стандарты на показатели и системы отчетности в программе.
4.8.1 Введите стандарты на показатели и системы отчетности в программе.
4.8.2 Выявите повторяющиеся мероприятия в программе и введите на них стандарты.
4.8.3 Поощряйте стандартные практики проектирования с инженерными чек-листами, стандартными архитектурами целевых систем, модулями, шинами и платформами.
4.8.4 Поощряйте стандартизацию практик разработки, производства и управления.
4.8.5 Поощряйте стандартизацию навыков с их тщательной тренировкой и наставничеством, ротациями, стратегическими назначениями и оценкой компетентности.
4.9 Думайте, что практично делать в конкретных обстоятельствах, чтобы обеспечить непрерывный ход работ в программе.
4.9.1 Часто устраивайте формальные точки интеграции в добавок к точкам интеграции на уровне программы. Доискивайтесь до истинных причин с использованием техники “5 почему”. Выравнивайте поток принятия решений и поток работ. Решайте все проблемные моменты взаимодействия в формальных точках интеграции. Обсуждайте выборы и варианты.
4.9.1 Часто устраивайте формальные точки интеграции в добавок к точкам интеграции на уровне программы. Доискивайтесь до истинных причин с использованием техники “5 почему”. Выравнивайте поток принятия решений и поток работ. Решайте все проблемные моменты взаимодействия в формальных точках интеграции. Обсуждайте выборы и варианты.
4.9.2 Будьте готовы оспорить предположения заказчика, основываясь на технической экспертизе и дисциплинах не глядя на должности и звания. Ваша цель - увеличить стабильность программы.
4.9.3 Сведите к минимуму передачи результатов работы при технологических переделах. Это поможет уменьшить количество переделок.
4.9.4 При назначении задач учитывайте пользу, которую приносит исполнение задачи. Используйте профессионалов, чтобы делать задачи, которые приносят пользу; если профессионалы не нужны, либо задачу просто надо сделать, а пользу она не приносит, используйте обычные ресурсы.
4.9.5 Используйте единую систему измерений во всех проектах и единые справочные данные.
4.9.6 Используйте инструменты бережливого производства, чтобы облегчить протекание информации и свести к минимуму сдачи-приемки промежуточных результатов. Перейдите на малые партии при работе с информацией, держите минимальные запасы информации, сводите к минимуму количество одновременных задач на исполнителях, стремитесь уменьшать сроки исполнения задач, расширяйте ширину каналов связи, вводите стандарты, организуйте рабочие ячейки и обучение.
4.9.7 Уменьшайте количество используемых компьютерных программ и старайтесь унифицировать их использование на предприятии.
4.9.8 Для используемых компьютерных программ старайтесь устанавливать только критические обновления. Централизованно контролируйте смену версий прикладного программного обеспечения.
4.9.9 Адаптируйте прикладное программное обеспечение под производственные нужды.
4.9.10 Не используйте слишком навороченное прикладное программное обеспечение. Адаптируйте программное обеспечение к производственным потребностям, а не наоборот.
4.10 Делайте видимыми для всех достижения программы.
4.10.1 Делайте продвижение программы видимым и понятным для всех, включая внешних стейкхолдеров.
4.10.1 Делайте продвижение программы видимым и понятным для всех, включая внешних стейкхолдеров.
4.10.2 Отслеживайте, как программа в целом продвигается к тому, чтобы принести запланированные выгоды.
4.10.3 Используйте графики, диаграммы и канбаны там, где их будут видеть все. Не выводите средства визуального контроля на экраны мониторов.
4.10.4 Разработайте систему, которая делает задержки и несовершенства видимыми для всех.
4.10.5 Используйте цвета светофора, чтобы показывать статус задач и не позволять скрывать проблемы.
4.10.6 Задайте методологию управления подпроектами программы, чтобы оценить качество их работы и вклад в успех программы.
4.10.7 Согласуйте показатели программы с ожидаемыми выгодами и ожиданиями стейкхолдеров.
4.10.8 Обеспечьте четкую прослеживаемость между показателями подпроектов программы и показателями успеха всей программы.
4.10.9 Разработайте панель показателей программы, которая будет использоваться на протяжении всего жизненного цикла проекта либо программы и публикуйте ее в общем доступе.
4.10.10 Поставьте KPI “Уровень риска и неопределенности” и отслеживайте его уменьшение в ходе программы.
4.10.11 Отслеживайте с помощью KPI эффективность и качество организационных интерфейсов.
5. Вытягивайте пользу из программы.
5.1 Выполняйте задачи и добивайтесь результата там, где он востребован, отказывайтесь от выполнения остальных задач, т.к. они являются потерями.
5.1.1 Список задач должен определяться потребностью в информации, которая появляется в результате выполнения этих задач.
5.1 Выполняйте задачи и добивайтесь результата там, где он востребован, отказывайтесь от выполнения остальных задач, т.к. они являются потерями.
5.1.1 Список задач должен определяться потребностью в информации, которая появляется в результате выполнения этих задач.
5.1.2 Создавайте культуру получения только востребованных знаний и ограничивайте отсылку информации только тем, кому она самом деле нужна.
5.1.3 Тренируйте команду для каждой задачи определять заказчика и исполнителя. Используйте модель SIPOC для того, чтобы лучше понять модель жизненного цикла.
5.1.4 Оставайтесь на связи с внутренним заказчиком при исполнении задачи.
5.1.5 Поощряйте прямое общение между внутренним заказчиком и исполнителем непосредственно во время выполнения задачи. Такое общение должно быть построено на доверии, уважении и взаимном понимании потребностей и ограничений.
5.1.6 Для нестандартных задач координируйте требования к результату с внутренним заказчиком, это позволит избежать переделок.
5.1.7 Чтобы определить какие задачи делать и в каком объеме, руководствуйтесь пониманием пользы для заказчика. Так вы поймете, какие задачи надо взять из буфера и начать исполнять.
5.2 Создавайте эффективные механизмы контрактации программы, которые позволяют ей достигать запланированных выгод и создают эффективное вытягивание пользы из программы.
5.2.1 Создайте типовые структуры контрактов для программы.
5.2.1 Создайте типовые структуры контрактов для программы.
5.2.2 Чтобы справедливо поделить между участниками программы риски и возможности, которые возникают из-за вероятностной природы оценок, согласуйте контракты и премии исполнителей. Это позволит вам избежать игр с прогнозированием и создаст выигрышную для всех ситуацию.
5.2.3 Убедитесь, что контракты поддерживают исчерпывающую и открытую коммуникацию между стейкхолдерами программы.
6. Совершенство программы.
6.1 Эффективно используйте существующие стандарты управления программой и управления практиками.
6.1.1 Используйте существующие стандарты управления программами, руководства и применимые модели уровней зрелости практик наилучшим для программы способом.
6.1 Эффективно используйте существующие стандарты управления программой и управления практиками.
6.1.1 Используйте существующие стандарты управления программами, руководства и применимые модели уровней зрелости практик наилучшим для программы способом.
6.1.2 При выборе стандартов, руководств и моделей зрелости руководствуйтесь выгодами программы.
6.1.3 Согласуйте ввод целевой системы в эксплуатацию с существующей бизнес-стратегией предприятия и со стандартами предприятия.
6.1.4 Если программа требует обязательной сертификации, то не вводите стандарт только для того, чтобы пройти сертификацию.
6.1.5 Чтобы быстро оценить свой уровень готовности к бережливому управлению программами, используйте существующие инструменты самооценки. С их помощью вы быстро обнаружите слабые места, сможете поставить цели для развития и отслеживать постановку практик.
6.2 Стремитесь к обоснованности использования практик на всем жизненном цикле программы.
6.2.1 Разработайте долгосрочный подход к освоению мышления, ориентированного на минимизацию потерь. Встройте подход в практику управления портфелем проектов предприятия и начните использовать это мышления во всем предприятии.
6.2.1 Разработайте долгосрочный подход к освоению мышления, ориентированного на минимизацию потерь. Встройте подход в практику управления портфелем проектов предприятия и начните использовать это мышления во всем предприятии.
6.2.2 Организуйте отдел, который объединит в себе всю работу по освоению и постановке практики системной минимизации потерь. Этот отдел должен разрабатывать базовый метод, поддерживать и заполнять хранилище знаний и методов и собирать доказательства эффективности применения подхода и его влияния на достижение запланированных выгод программ.
6.2.3 Создайте инфраструктуру обучения методу системной минимизации потерь: руководители среднего звена и менеджеры проектов должны обучать и мотивировать своих подчиненных.
6.2.4 Создайте стимулы в программе и подпроектах, которые будут способствовать принятию практик системной минимизации потерь.
6.2.5 Дополните существующие практики организационных изменений и постоянных улучшений практиками системной минимизации потерь. Так вы создадите кумулятивный эффект от применения этих практик.
6.2.6 Начинайте постановку практик с небольших проектов по реализации наиболее выгодных для вашей программы факторов.
6.2.7 Запишите накопленный опыт и оцените эффективность полученных рекомендаций.
6.2.8 Ищите новые и необычные способы работы, которые приносят больше пользы.
6.3 Стремитесь к совершенству в программном менеджменте и системной инженерии.
6.3.1 Освойте базовые практики управления качеством. Не создавайте, не передавайте, не принимайте дефекты.
6.3.1 Освойте базовые практики управления качеством. Не создавайте, не передавайте, не принимайте дефекты.
6.3.2 Следуйте базовым техникам решения проблем (PDCA) и перенимайте культуру блокирования последствий и надежного решения проблем.
6.3.3 Поощряйте работу в нормальном режиме и постоянное улучшение практик. Вознаграждайте дальновидность и избегание проблем, а не героическое решение созданных своими же руками трудностей.
6.3.4 Используйте ошибки в качестве полезных уроков. При этом делайте упор на практиках, а не на людях.
6.3.5 Используйте любое несовершенство как возможность для улучшения. Часто обращайтесь к формально собранному и обработанному накопленному опыту, чтобы найти там возможности для улучшения.
6.3.6 Поддерживайте последовательный и дисциплинированный подход в управлении программой и системной инженерии. Сюда входит согласование целей, результатов, практик, коммуникации и стандартизации лучших практик.
6.3.7 Распространяйте идею о необходимости постоянных улучшений в программе.
6.3.8 Достигайте совершенства применения практики только в том случае, когда это приносит пользу программе. Избегайте потерь перепроизводства и излишней обработки. Добивайтесь выполнения практики с первого раза.
6.3.9 Используйте сбалансированную матричную либо сбалансированную проектную организационную структуру. Избегайте крайностей как в виде чисто функциональной организации так и в виде чисто проектной организации.
6.4 Дальновидно управляйте неопределенностью и рисками, чтобы получить максимум пользы от программы.
6.4.1 Создавайте механизмы, которые позволят фиксировать, коммуницировать и применять опыт реализации.
6.4.1 Создавайте механизмы, которые позволят фиксировать, коммуницировать и применять опыт реализации.
6.4.2 Четко документируйте контекст “лучших практик” и “ключевых уроков”, чтобы другие могли понять, применимы ли эти знания в их условиях.
6.4.3 Поставьте практику, которая будет регулярно просматривать, оценивать и стандартизировать накопленный опыт и готовить его к применению.
6.4.4 Назначьте ответственных за практику просмотра, оценки, стандартизации накопленного опыта и за его применение.
6.4.5 Настаивайте на том, чтобы определение корневых причин и реализация корректирующих действий с последующим обучением персонала всегда проводилась единообразно.
6.4.6 Ищите лучшие практики с помощью бенчмаркинга и в профессиональной литературе.
6.4.7 Если вы замеряете показатели внешних партнеров, то делитесь с ними этой статистикой и обсуждайте планы по улучшению ситуации.
6.5 В меняющейся обстановке эффективно используйте практику управления изменениями. Она позволит программе согласовывать внутренние изменения с изменениями внешней обстановки.
6.5.1 Целью практики управления изменениями должны быть достижение запланированных выгод программы. Меняйте курс, планы проектов либо останавливайте их только исходя из этой цели.
6.5.1 Целью практики управления изменениями должны быть достижение запланированных выгод программы. Меняйте курс, планы проектов либо останавливайте их только исходя из этой цели.
6.5.2 Практика управления изменениями на уровне программы должна охватывать все компоненты программы и вовлекать всех стейкхолдеров.
6.6 Дальновидно управляйте неопределенностью и рисками программы с целью получения максимальной выгоды.
6.6.1 Практика управления рисками должна сосредоточиться на создании и защите выгод программы.
6.6.1 Практика управления рисками должна сосредоточиться на создании и защите выгод программы.
6.6.2 Добейтесь общего понимания неопределенностей, которые существуют в программе. Поймите и задокументируйте ключевые факторы риска для программы и найдите какие есть лучшие практики, чтобы работать с этими рисками.
6.6.3 Поддерживайте принятие всех критических решений с помощью практики управления рисками.
6.6.4 Максимально снижайте все внутренние и внешние неопределенности программы.
6.6.5 Делайте программу устойчивой ко всем внешним неопределенностям, на которые вы не можете повлиять.
6.6.6 Развивайте организационную способность управления рисками и обеспечивайте ее достаточными ресурсами.
6.6.7 Адаптируйте практику управления рисками к потребностям программы и встраивайте ее в остальные практики управления программой.
6.6.8 Удостоверьтесь, что мероприятия по управлению рисками вносят свой вклад в постоянные улучшения практик и организации программы.
6.6.9 Регулярно отслеживайте и пересматривайте риски, планы реагирования на них, и оценивайте всю систему управления рисками в целом.
6.6.10 Отслеживайте появление возможностей и используйте их.
6.7 Стремитесь к совершенной координации, коммуникации и совместной деятельности организационных звеньев и практик.
6.7.1 Разработайте общую для всей программы политику, руководство либо базовый метод, в котором определите ожидания по координации, коммуникации и совместным действиям.
6.7.1 Разработайте общую для всей программы политику, руководство либо базовый метод, в котором определите ожидания по координации, коммуникации и совместным действиям.
6.7.2 Используйте стандартные форматы подачи информации на одну страницу, например, Тойота А3, для стандартизации общения. Не рассылайте неструктурированные протоколы собраний. Включите в дополнительные материалы подробную информацию на случай, если она понадобиться получателю.
Слайды доклада по внедрению А3 техники в Skype
Видео доклада по внедрению А3
Слайды доклада по внедрению А3 техники в Skype
Видео доклада по внедрению А3
6.7.3 Используйте стандартные форматы подачи информации на одну страницу для решения межфункциональных проблем. Это позволит быстро решать проблемы.
6.7.4 С самого начала программы создайте план, который установит ответственность за реализацию положений политики по коммуникации, совместной деятельности и порядку принятия решений.
6.7.5 Учитывайте компетентность в общении людей, которых вы назначаете на позиции, с требованиями их ролей в программе.
6.7.6 Опубликуйте инструкции по тому, как вести переписку.
6.7.7 Опубликуйте инструкции по содержанию хранилищ информации. Должен быть баланс между централизованным и распределенным хранением, достоверностью информации и уровнем бюрократии, бумажными и электронными копиями.
6.7.8 Опубликуйте органиграмму программы и список участников с их контактами. Учите вновь нанятых сотрудников искать нужных людей.
6.7.9 Обеспечьте своевременный и эффективный доступ к централизованным данным.
6.7.10 Разработайте эффективный и легкодоступный свод знаний программы. В нем должны быть исторические данные, поиск, а участники должны использовать его для передачи и распространения знаний в программе.
6.8 Содействуйте появлению взаимодополняющих методов постоянных улучшений, которые позволят раскрыть творческие способности и потенциал всех стейкхолдеров.
6.8.1 Используйте и вознаграждайте низовые предложения работников, направленные на решение проблем, которые возникают на их уровне.
6.8.2 Используйте небольшие команды быстрого реагирования для решения локальных проблем и разработки стандартов.
6.8.3 Для решения проблем на уровне программы организуйте большие оформленные формально проекты улучшений.
6.8.4 Поставьте практики локальных улучшений в разных частях программы.
Комментариев нет:
Отправить комментарий