воскресенье, 9 декабря 2018 г.

Онтологический букварь крутого пиэма

Ontology based project management.
Проектное управление стало настолько сложным, что без более-менее формального моделирования предметной области системной инженерии и управления проектами не обойтись [1], [2], [3].
Онтологически грамотный пиэм оперативно решает кадровую проблему

1. Онтология BORO помогает создавать качественные планы и концепцию автоматизации PMIS
Плейлист уроков по BORO, DDD и практике инженерии требований:
Презентация уроков:

2. ArchiMate и SysArchi реализуют онтологию BORO и позволяют с помощью бесплатных средств автоматизировать самые важные практики программного менеджмента

3. Онтология BORO и технологии моделирования ArchiMate+SysArchi позволяют делать маленькие хорошо контролируемые шажки в сторону успешности проекта и программы
---

[1] https://www.researchgate.net/publication/221350154_Ontology-Based_Project_Management_for_Acceleration_of_Innovation_Projects

четверг, 6 декабря 2018 г.

Что такое архитектура системы простым языком

"Быстрые" элементы (зданий) учатся, несут обновление, поглощают удары; "медленные" запоминают, объединяют и сдерживают. "Быстрые" получают все внимание. "Медленные" обладают всей властью.

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


"Архитектура - это про все важное, что бы оно ни было". Ральф Джонсон.


1. Архитектура относительна и субъективна. Она определяется командой конкретного проекта. Для команды интерьерного проекта список и расположение предметов интерьера очень важно. Вся команда должна согласиться о том, какие предметы будут в интерьере и как они будут размещены. Это решение, которое сложно изменить, придется все пересогласовывать. Архитектурное решение. Для команды, которая меняет электрическую проводку и стояки расположение предметов в комнате не играет особой роли, это не архитектурный дизайн.
2. Архитектура хранит опыт реализации проектов. Часто архитектуру системы называют "заделами", "наработками". Та команда, которая несколько раз делала похожие системы, формирует разделяемое, общее понимание того, какие решения сложно поменять, а какие легко. Какие решения архитектурные, а какие не архитектурные. Архитектура системы ограничивает пространство выборов, объединяет и сдерживает функциональные и конструктивные решения в проекте.
3. Архитектура выражается архитектурными описаниями, которые состоят из архитектурных моделей. Одна из критических ошибок, которые делают в проектах описания архитектуры предприятия - это не определяют, а для чего делается архитектурное описание. Какой проект по нему будут делать - интерьерный, сантехнический или капремонт. Описания будут принципиально разными, выводы и рекомендации будут отличаться. Поэтому прежде чем вы начнете работу по описанию архитектуры, подумайте над простым вопросом "вот есть у вас набор архитектурных моделей, для чего он будет нужен, что вы с ними сделаете?"
Метамодель SysArchi позволяет описывать архитектуру системы и проекта в одном комплекте диаграмм



среда, 28 ноября 2018 г.

Орг. изменения и распределенное лидерство


Программа обучения

Онтология орг. изменения.
Тема 1. Общая теория орг.изменений.
Какие проблемы решает блок
: как ориентироваться в орг. изменении.
Результат: понимание причин и общей схемы проведения орг. изменений, V-модель орг. изменения SEPM. Понимание связи точек зрения собственников, топ-менеджмента, руководителей среднего звена, проектных офисов и исполнителей на орг.изменения. Понимание технических и организационных аспектов изменения. Понимание необходимости архитектуры предприятия и лидерства для проведения успешных орг. изменений. Умение оценить зрелость оргспособности лидерства на предприятии. Знание трех сценариев постановки практики архитектуры предприятия и лидерства.

Тема 2. Проблематика орг.изменений.
Какие проблемы решает блок
: как уточнять стратегию у руководства или клиентов, как расширять влияние в своей организации и организации клиента.
Результат: понимание точки зрения начальника на орг. изменение и его интересов в орг. изменении. Умение различать исполнителей и стейкхолдеров. Знание необходимых для успешного орг.изменения стейкхолдерских ролей. Понимание схемы обязательств (DEMO transaction) и концепции субъективного, объективного и социальных миров. Понимание концепции регуляции и поднадзорности. Понимание концепций диапазона подотчетности, диапазона контроля и предпринимательского дисбаланса. Понимание “проклятия среднего звена”. Понимание роли внутреннего предпринимателя и порядка уточнения стратегии предприятия у топ-менеджмента. Понимание роли лидера по отношению к топ-менеджменту и владельцам.

Тема 3. Инженерия команд и управление жизненным циклом человеческого капитала.
Какие проблемы решает блок
: как не запутаться в сложных изменениях. Как получить правильную помощью от директора по персоналу и директора по ИТ? Автоматизация управления персоналом.
Результат: понимание онтологии орг. изменений. Понимание системных уровней человеческого капитала. Понимание состояний работника и команд, видов жизненного цикла работников и команд. Понимание применимости различных ИТ-систем для управления людьми. Понимание принципов управления конфигурацией команд. Понимание связи между орг. изменениями и управлением конфигурацией команд.

Тема 4. Реализация орг. изменения.
Какие проблемы решает блок: как правильно структурировать команды проектов, рабочие группы и отделы. Как правильно организовать взаимодействие между командами, группами и отделами?
Результат: понимание онтологии команды. Понимание роли лидера по отношению к команде. Понимание методов описания как протоколов командных интерфейсов. Организационный анализ социальных сетей. 4 архитектуры команд: команды-”спагетти”, группы с командиром, сообщества практик и целеориентированные социальные сети. Понимание отличия работы руководителя проекта от менеджера талантов. Понимание типовых проектируемых систем орг.изменений. Умение составить структуру деятельности команды (terms of reference).

Понимание 4 аспектов человека - личность, актер, стейкхолдер, окружение. Понимание лидерства как совмещения личности и стейкхолдера. Необихевиоризм и архитектура выбора. Понимание дисциплин управления ресурсами команды. Понимание связи компетентности и прогнозирования развития ситуации (situational awareness). Понимание практики PDCA и ее связи с прогнозированием ситуации и компетентностью. Умение разрабатывать бизнес-интерфейсы: SLA, OLA, MOU, SPOC. Понимание правил взаимодействия и правила ядра (core protocols).

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

Умение диагностировать орг. изменение с помощью чек-листов альф "Команда", "Талант", "Командная роль", "Связь", "Орг. изменение", "Орг. способность".

Тема 5. Проблемные члены команды и внешние стейкхолдеры.
Какие проблемы решает блок
: как не переходить на личности, выходить и не допускать личных конфликтов и как избегать непродуктивного отношения к работе.
Результат: понимание модели уровней сопротивления орг. изменению. Понимание работы эмоций и чувств и их влияния на действия людей. Понимание последствий включения “кругов” лимбического мозга и прерывание цикла воспроизводства отрицательных эмоций. Понимание механизма триггеров. Понимание основ доверия внутри команды. Понимание концепции надежности человека и дела надежности человека.

Рабочие продукты тренинга
Профили ролей внутреннего предпринимателя, бизнес-архитектора, HR бизнес-партнера, руководителя проекта и операционного менеджера.
План развития своих лидерских компетенций.
Оценка уровня зрелости орг.возможности лидерства своего проекта, компании либо подразделения.
Результат FIT-GAP анализа орг.возможности лидерства в своей компании либо подразделении и план постановки практики лидерства.
Диаграмма системного контекста орг.возможности лидерства в вашем проекте.
Выбор и обоснование выбора стратегии приобретения либо изменения орг.возможности лидерства в вашем проекте, подразделении либо компании.
Архитектурное описание создаваемой либо модифицируемой вашей командой орг.возможности.
Диаграмма цепочки производственной кооперации для создаваемой либо модифицируемой вашей командой орг.возможности. Итоговая jobs-to-be-done.
Структура деятельности вашей команды (terms of reference).
Соглашение об уровне сервиса вашей команды (service level agreement).
Описание архитектуры вашей команды, обоснование архитектуры.


Что необходимо для успешного освоения материала?
Знания
- онтологика, понимание 4Д и функциональных объектов
- системное мышление, в особенности понимание системной холархии, разделение определения и воплощения системы, жизненный цикл 2.0 и стейкхолдеры, требования и архитектура
- системная инженерия в объеме управление жизненным циклом, функциональное и структурное представление жизненного цикла
- инженерия предприятия в объеме понимания архитектуры предприятия, циклов стратегирования и организационных изменений, понимание орг.модулей предприятия, концепта орг.возможности (capability) и цепочки производственной кооперации
Умения
- отличать индивиды и концепты
- строить системные холархии и классификаторы
- восстанавливать онтику стейкхолдера из нарратива
- разрабатывать профили должностей и положения о подразделениях
- разрабатывать функциональные и структурные модели жизненного цикла
Навыки
- построение команды
- проведение очных встреч, интервью и рабочих совещаний
- моделирование деятельности

Презентации:
Тема 1. Теория орг. изменений
Тема 2. Проблематика орг.изменений
Тема 3. Инженерия команд и управление жизненным циклом человеческого капитала
Тема 4. Реализация орг. изменения

пятница, 23 ноября 2018 г.

Сообразительные и доводят дела до конца

Ключевые выборы надо делать только на основании фактов и данных. Каких людей взять в команду - один из самых важных выборов, который делает руководитель. И именно здесь, по моим наблюдениям, данные используются меньше всего, людей берут на основании пары интервью и звонка предыдущему работодателю. Ситуацию усугубляет еще и то, что решение о найме часто принимают люди, которые сами не умеют делать работу, для которой нанимают других. Какой выход из ситуации? Я для себя выбрал метод Джоэля Спольски:

https://www.joelonsoftware.com/2007/06/05/smart-and-gets-things-done/
http://b-ok.cc/book/499004/c5bee5
и сделал несколько модификаций, т.к. нанимаю не программистов.
Итак, есть три признака людей, которых мы хотим нанимать в команду:
- они должны быть сообразительными
- они должны уметь доводить дела до конца
- они должны уметь работать в команде.

Правило №1. Нанимать только людей со знанием английского либо немецкого. Если человек не понимает необходимость владения иностранным языком или у него не хватает упорства его выучить, то он не нужен.
Правило №2. Человек должен уметь читать и писать. Разработка - это куча общения, надо уметь качественно извлекать смысл сообщения и доносить его до других. Не обязательно с ходу, не обязательно достигать британских высот коммуникации, но нельзя нанимать людей, которые не умеют общаться.
Правило №3. Человек должен уметь доводить дела до конца. Надо не только договориться, но и выполнить обещанное. Человек должен привести множество свидетельств того, что он может выполнять обещания в условиях множественных ограничений. Все могут быть капитанами в спокойном море, вам нужны те, кто умеют работать в реальном проекте.

Как проверять? Этапы найма см. у Джоэля Спольски. Обязательно телефонное интервью вначале.

Как получить данные для принятия решения?

Что подтверждает сообразительность?
Предметная компетентность напрямую зависит от скорости выполнения базовых навыков. Чтобы уметь делать сложную работу, надо в совершенстве делать простую работу. Читайте Джоэля Спольски, Atul Gawande. Better: A Surgeon's Notes On Performance и Дуг Лемов “Мастерство учителя”, там есть ссылки на исследования. Составьте список базовых навыков для данной позиции и попросите кандидатов показать их исполнение. Сделайте несколько попыток, запишите время для каждого кандидата. Испытания должны проходить в комфортной для кандидатов обстановке, можете по Скайпу.
Второй критерий - грамотность. Запускайте любой тест на словарный запас, регулярно заставляйте давать определение словам и проверяйте по словарю. В заданиях на синонимы просите объяснить различие в значениях. Просите привести примеры словоупотребления для синонимов. Проведите тест на английском, все то же самое, объяснения и словоупотребление должны быть на английском.
Что подтверждает умение общаться, давать разумные обещания и спрашивать по обещаниям других?
Попросите написать протокол вашей встречи. Факты, обещания, обязательства, сроки.
Теперь можно провести сравнение кандидатов. У вас есть данные по навыкам - скорость и количество ошибок. У вас есть словарный запас и вы понимаете, может ли человек извлекать смысл из речи и текста. У вас есть рабочий продукт, который показывает способность кандидата извлекать факты и обязательства из общения. Наконец можете посмотреть его резюме и проверить его достоверность исходя из того, что вы узнали о человеке. Составьте список вопросов к резюме и приглашайте на предметное собеседование.

пятница, 16 ноября 2018 г.

The Guide to Lean Enablers for Managing Engineering Programs на русском

Цепочка предшествующих текстов:
Когда руководитель проекта становится руководителем программы
Оригинал:
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 (сортировка, соблюдение правил, содержание в чистоте, стандартизация, совершенствование) и в базах данных
Ненужное перемещение людей:
- Ненужные перемещения при выполнении задачи
- Людям нужно передвигаться, чтобы получить информацию или доступ к ней
- Ручное вмешательство, которое компенсирует недостаток систематичности
Переделки, дефекты:
- Убийственные “пере-”: переделка, переписывание кода, перепрограммирование, перетестирование…
- Нестабильные требования
- Нескоординированная сложная задача, которая занимает слишком много времени на выполнение и результат которой становится невостребованным к моменту завершения так что она должна быть переделана
- Неполная, расплывчатая или неточная информация
- Инспекции по выявлению дефектов
К сожалению, в большинстве случаев топ-менеджмент программы заперт в рамках мышления по отдельным функциям в деятельности. Им не хватает понимания и признания критичности компетенций их контрагентов, и понимания того, как компетенции контрагентов дополняют их компетенции. PMI и INCOSE договорились, что будут всеми силами содействовать объединению проектного менеджмента и системной инженерии. Руководитель программы должен хорошо разбираться в обеих дисциплинах.


Тема 1. Борьба с пожарами - запаздывающее исполнение программы.
- ресурсы направляются на решение проблем, а не на их предотвращение
- конкуренция за ресурсы
- меняющиеся приоритеты проекта
- нечеткое или неподходящее распределение ответственности и прав на принятие решений
- недостаток управления приоритетами или согласованности в целях сотрудничающих организаций
- недостаточное понимание риска программы
- нет согласованной руководящей команды, которая представляет все важные функции
Тема 2. Нестабильные, нечеткие и неполные требования.
- неполное понимание требований стейкхолдеров
- недостаточное понимание всей сложности требований, пропуск производных требований
- нестабильные приоритеты программы
- стейкхолдеры не в состоянии четко выразить свои требования
- неправильное понимание требований стейкхолдеров
- неполное доведение до людей об изменениях в стоимости, сроках и требуемых характеристиках в течение программы
- требования формулируются с нарушениями правил
- недостаточная адаптация базисов по срокам, стоимости и техническим характеристикам к меняющемуся окружению и предположениям программы
- требования к соответствию (внутренние требования, стандарты, законодательные требования) различных стейкхолдеров не связаны друг с другом, не объединены, могут конфликтовать, все это приводит к дополнительной нагрузке, несогласованности требований и не дает возможности эффективно согласовывать похожие требования
- нечеткое понимание восприятия пользы стейкхолдерами
- отсутствие учета определенных ранее потребностей
- запрос коммерческого предложения выпущен заказчиком слишком рано
Тема 3. Недостаточная согласованность и нескоординированность производственной кооперации.
- конкурирующие требования к ресурсам
- недостаточное управление и согласованность приоритетов работы стейкхолдеров и организаций в производственной кооперации
- нечеткие приоритеты при исполнении непосредственных бизнес-целей (например, прибыльность текущей программы) и ответственностью за другие программы (например, сбор и распространение полученного опыта, постоянные улучшения)
- неструктурированная или незапланированная коммуникация стейкхолдеров
- нечеткое либо различное понимание состава предпринятия
- недостаточная интеграция стейкхолдеров (с конкретными заказчиками и поставщиками)
Тема 4. Практики оптимизированы локально и не учитывают работу предприятия в целом.
- недостаток усилий по оптимизации на уровне всего предприятия, оптимизация только локальных процессов и организации
- недостаток стандартизации процессов
- недостаток понимания того, как работать с различными видами потерь, оптимизация только потока создания ценности
- отсутствие механизмов улучшения потока создания ценности
Тема 5. Нечеткие роли, ответственность за исполнение и ответственность за результат.
- ведущее к проблемам распределение ответственности и прав принимать решения
- недостаток согласованности и интеграции между программным менеджментом и системной инженерии
- отсутствие поощрений и мер по поддержанию чувства личной ответственности за планы и результаты
- нет согласованной команды управления, которая бы представляла все важные функции
- роли и ответственность персонала программы и линейных функций не определены
- несогласованные и мешающие совместной работе KPI и премии персонала программы, команд проектов, поставщиков, заказчиков и других стейкхолдеров
Тема 6. Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- неэффективные практики передачи знаний от опытных сотрудников и членов команды к новым членам команды (в частности, это происходит в отраслях со стареющими кадрами)
- недостаток механизмов обратной связи, которые бы превращали накопленный опыт в действия, новые практики не ставятся по результатам накопленного опыта и рекомендаций
- нет адекватного распространения накопленного опыта по всему предприятию
- неадекватное определение личных потребностей в развитии навыков
- накопленный опыт не документируется
- неадекватный сложности задачи опыт команды
- недостаточный уровень личных навыков
Тема 7. Недостаточное планирование программы.
- нереалистичные базисы по срокам, стоимости и техническим характеристикам
- недостаточное распространение внутри программы изменений по стоимости, срокам и техническим характеристикам
- нереалистичное расписание программы
- проблемы с общением на нужном уровне организационной иерархии во время запуска и закрытия проекта
- оценки не отражают все аспекты жизненного цикла
- нехватка вероятностных оценок
- слишком редкие обновления оценок стоимости, сроков и технических характеристик на ранних стадиях программы и во время исполнения
Тема 8. Неправильно выбранные показатели, системы показателей и KPI.
- показатели дают ретроспективную оценку и не помогают предсказывать появление проблем
- показатели не учитывают человеческое поведение (теория игр)
- нет метрик для кросс-функциональных процессов
- распределенные и несвязанные ИТ-системы и хранилища данных не позволяют эффективно собирать и объединять данные для расчета показателей
- недостаточный присмотр за соблюдением базисов по срокам, стоимости и техническим характеристикам
- показатели ориентированы на короткий период
Тема 9. Недальновидное управление рисками.
- недостаточное вовлечение необходимых для управления рисками специалистов
- неполное понимание рисков программы
- недостаточное финансирование и ресурсное обеспечение мероприятий по управлению рисками (выявление, оценка, предотвращение и отслеживание)
- пренебрежение человеческим фактором при управлении рисками, такими как культура сокрытия ошибок и плохих новостей
- отсутствие тесной связи управления рисками и других практик жизненного цикла
- недостаточное внимание на быстрое устранение выявленных рисков
Тема 10. Плохое управление закупками и контрактацией.
- заказчик выпускает запрос на предоставление коммерческого предложения слишком рано, еще до того, как достаточно определится с требованиями
- отсутствие учета финансовых ограничений
- контрактные ограничения и стимулы не согласованы с задачами программы и профилем риска
- нет подходящей практики обкатки технологии для программ (технические характеристики и системная интеграция)
- непонимание между операционным менеджментом программы и контрактными требованиями


Обзор способствующих факторов

Как читать таблицы:

Первая строка - группа практик стандарта по управлению программами PMI. Т.е., открываете стандарт PMI и смотрите общий контекст применения практик.
Вторая строка - какие проблемы решает фактор.
Третья строка - группа практик стандарта по системной инженерии 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 Поддерживайте преемственность команды между стадиями, чтобы получить максимум опыта от исполнения программы. Постарайтесь взять в команду людей, которые готовили предложение.

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.2 Выявите повторяющиеся мероприятия в программе и введите на них стандарты.
4.8.3 Поощряйте стандартные практики проектирования с инженерными чек-листами, стандартными архитектурами целевых систем, модулями, шинами и платформами.
4.8.4 Поощряйте стандартизацию практик разработки, производства и управления.
4.8.5 Поощряйте стандартизацию навыков с их тщательной тренировкой и наставничеством, ротациями, стратегическими назначениями и оценкой компетентности.
4.9 Думайте, что практично делать в конкретных обстоятельствах, чтобы обеспечить непрерывный ход работ в программе.

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.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.2 Создавайте культуру получения только востребованных знаний и ограничивайте отсылку информации только тем, кому она самом деле нужна.
5.1.3 Тренируйте команду для каждой задачи определять заказчика и исполнителя. Используйте модель SIPOC для того, чтобы лучше понять модель жизненного цикла.
5.1.4 Оставайтесь на связи с внутренним заказчиком при исполнении задачи.
5.1.5 Поощряйте прямое общение между внутренним заказчиком и исполнителем непосредственно во время выполнения задачи. Такое общение должно быть построено на доверии, уважении и взаимном понимании потребностей и ограничений.
5.1.6 Для нестандартных задач координируйте требования к результату с внутренним заказчиком, это позволит избежать переделок.
5.1.7 Чтобы определить какие задачи делать и в каком объеме, руководствуйтесь пониманием пользы для заказчика. Так вы поймете, какие задачи надо взять из буфера и начать исполнять.
5.2 Создавайте эффективные механизмы контрактации программы, которые позволяют ей достигать запланированных выгод и создают эффективное вытягивание пользы из программы.

5.2.1 Создайте типовые структуры контрактов для программы.
5.2.2 Чтобы справедливо поделить между участниками программы риски и возможности, которые возникают из-за вероятностной природы оценок, согласуйте контракты и премии исполнителей. Это позволит вам избежать игр с прогнозированием и создаст выигрышную для всех ситуацию.
5.2.3 Убедитесь, что контракты поддерживают исчерпывающую и открытую коммуникацию между стейкхолдерами программы.
6. Совершенство программы.
6.1 Эффективно используйте существующие стандарты управления программой и управления практиками.

6.1.1 Используйте существующие стандарты управления программами, руководства и применимые модели уровней зрелости практик наилучшим для программы способом.
6.1.2 При выборе стандартов, руководств и моделей зрелости руководствуйтесь выгодами программы.
6.1.3 Согласуйте ввод целевой системы в эксплуатацию с существующей бизнес-стратегией предприятия и со стандартами предприятия.
6.1.4 Если программа требует обязательной сертификации, то не вводите стандарт только для того, чтобы пройти сертификацию.
6.1.5 Чтобы быстро оценить свой уровень готовности к бережливому управлению программами, используйте существующие инструменты самооценки. С их помощью вы быстро обнаружите слабые места, сможете поставить цели для развития и отслеживать постановку практик.
6.2 Стремитесь к обоснованности использования практик на всем жизненном цикле программы.

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.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.2 Четко документируйте контекст “лучших практик” и “ключевых уроков”, чтобы другие могли понять, применимы ли эти знания в их условиях.
6.4.3 Поставьте практику, которая будет регулярно просматривать, оценивать и стандартизировать накопленный опыт и готовить его к применению.
6.4.4 Назначьте ответственных за практику просмотра, оценки, стандартизации накопленного опыта и за его применение.
6.4.5 Настаивайте на том, чтобы определение корневых причин и реализация корректирующих действий с последующим обучением персонала всегда проводилась единообразно.
6.4.6 Ищите лучшие практики с помощью бенчмаркинга и в профессиональной литературе.
6.4.7 Если вы замеряете показатели внешних партнеров, то делитесь с ними этой статистикой и обсуждайте планы по улучшению ситуации.
6.5 В меняющейся обстановке эффективно используйте практику управления изменениями. Она позволит программе согласовывать внутренние изменения с изменениями внешней обстановки.

6.5.1 Целью практики управления изменениями должны быть достижение запланированных выгод программы. Меняйте курс, планы проектов либо останавливайте их только исходя из этой цели.
6.5.2 Практика управления изменениями на уровне программы должна охватывать все компоненты программы и вовлекать всех стейкхолдеров.
6.6 Дальновидно управляйте неопределенностью и рисками программы с целью получения максимальной выгоды.

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.2 Используйте стандартные форматы подачи информации на одну страницу, например, Тойота А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 Поставьте практики локальных улучшений в разных частях программы.