Общая литература
Описание архитектуры тренинга № 1
Упражнение 1. Установление контакта с приобретающей стороной. Запуск предпроекта. Методы оценки работ, начальное планирование команды. Проверка возможности.
Практики “на один укус”: стейкхолдеры-практики-функциональные возможности-активы, управление функциональными возможностями, общий процесс разработки продукта, “7 самураев” (см. контекст продукта), управление проектами организации, альфы и чек-листы Эссенс, АрхиЭссенс моделирование в моделлере Archi
Теоретический блок.
Задача 1.1. Грант выделен, на завтра назначена первая встреча с директором по развитию ALLOEXPRESS (далее ДПР). Проректор Высшей школы экономики и менеджмента, который также ведет курс по международному электронному бизнесу, прозвонился к ДПР и уточнил его ожидания от встречи, он хочет увидеть структуру презентации предпроекта и сроки подготовки промежуточных результатов с детализацией не более недели. Кроме того, он выясняет, что ДПР 7 лет работал инженером по валидации.
Команда проекта - оба завкафедры, магистранты и студенты 4-го курса, всего 6 человек, собралась для планирования завтрашней встречи, на которой будут еще присутствовать директор эндаумента, проректор и ДПР.
Какие стейкхолдеры присутствуют на совещании?
- Менеджер проекта
- Системный инженер
- Продажник
- Презентатор
- Студент
- Организатор работ
- Переговорщик
- Технический писатель
- Директор по развитию
- Заказчик
- Покупатель
- Инвестор
- Финансист
- Оценщик талантов/Хэдхантер
Какие стейкхолдеры будут присутствовать на завтрашнем совещании?
- Менеджер проекта
- Системный инженер
- Продажник
- Презентатор
- Студент
- Организатор работ
- Переговорщик
- Технический писатель
- Директор по развитию
- Заказчик
- Покупатель
- Инвестор
- Финансист
- Оценщик талантов/Хэдхантер
- Должна ли команда обсудить состав стейкхолдеров этой встречи?
- Должна ли команда обсудить состав стейкхолдеров завтрашней встречи? В полном объеме или кратко?
- Нужно ли определить интересы и ориентировочные цели стейкхолдеров для завтрашнего совещания?
- Нужно ли определить роли стейкхолдеров, обязательные к исполнению на завтрашней встрече?
- Нужно ли определить практики, которые должны исполнять стейкхолдеры команды на завтрашнем совещании?
- Нужно ли в явном виде распределить роли стейкхолдеров внутри команды?
- Нужно ли при распределении ролей учитывать имеющиеся компетенции членов команды?
Что нужно сделать дальше и в каком порядке?
А) Определить цели, повестку и структуру совещания, выслать ее на согласование всем участникам
Б) Определить состав предпроекта, минимальные требования к оформлению презентации и ее разделам, распределить работы между участниками
В) Взять номер телефона ДПР у проректора и в телефонном разговоре уточнить характеристики использующей системы грузовика (логистическая система ALLOEXPRESS)
Г) По открытым источникам (социальные сети, сайт компании, публикации) как можно больше узнать о ДПР
После мозгового штурма команда проекта записала на флип-чарте следующие разделы презентации предпроекта:
- Варианты логической архитектуры
- Варианты физической архитектуры
- Стейкхолдеры
- План коммуникаций
- Модель жизненного цикла команды и необходимые компетенции
- Make or purchase решения
- Смета проекта
- Бизнес-кейс и финансовые сценарии проекта
- Схема финансирования проекта с обоснованием
- Риски проекта
- Целевая система, ее граница, использующая система и системы в операционном окружении
- Варианты модели жизненного цикла и обоснование выбора
- WBS и структура IPT
- Стоимость жизненного цикла
- Список системных платформ (платформа транспортного средства, платформа кузовного хранения грузов, платформа силовой установки, навигационная и ориентационная платформа)
- Мастер-план проекта
Какие из разделов надо оставить и в какой последовательности расположить? Почему? Как организовать разработку разделов, в какой последовательности? Каким стейкхолдерам нужны какие разделы и на какие интересы они отвечают? Какие методы описания будут использованы для подготовки презентации? Нужно ли уточнить на завтрашней встрече требования к методам описания и у кого уточнять?
Задача 1.2. Запуск предпроекта.
По результатам разговора с директором по развитию было подтверждено выделение денег на проект и был назначен менеджер проекта со стороны заказчика. Это будет начальник регионального отдела управления цепями поставок. Во время разговора было нарисовано несколько диаграмм на флип-чартах, а после собрания стороны составили и подписали протокол, в котором зафиксировали сумму, выделенную заказчиком на предпроект, ожидаемый результат предпроекта (отчет о технической реализуемости по установленной заказчиком форме, оценка бюджета и расписания проекта), менеджеров проекта со стороны заказчика и со стороны исполнителя и крайний срок готовности отчета (через 1 месяц после собрания). Договор на предпроект подписывается по форме заказчика, исполнитель начинает работы по согласованному протоколу собрания, не дожидаясь заключения договора и поступления оплаты.
Бизнес-аналитик вашей команды перерисовал фотографии флип-чартов в Архимейте:
Вам нужно составить план бизнес-анализа, состоящий из следующих разделов:
- системная холархия
- предположение по виду жизненного цикла
- список ключевых стейкхолдеров
- мероприятия по выявлению потребностей стейкхолдеров
- мероприятия по анализу потребностей стейкхолдеров
- мероприятия по архитектурной работе и уточнению технического решения
- предложения по управлению потребностей стейкхолдеров, включая их коммуникацию в проекте
- список задач бизнес-анализа, назначение ответственных и сроков
- оценка бюджета и сроков предпроекта
Проверьте получившийся план на соответствие карточкам альф Эссенс. Будете ли вы согласовывать план бизнес-анализа с заказчиком? С каким стейкхолдером и кто его представляет? Начнете ли вы работу до согласования плана? Что будете делать, если согласование затягивается и ставит под риск выполнение всего предпроекта?
После составления и оптимизации плана бизнес-анализа выяснилось, что для качественного отчета требуется дополнительное финансирование около 120 т.р., это выше порога вашего бюджетного согласования. Договор с заказчиком вы уже подписали. Докажите своему руководству необходимость этих затрат.
Пока вы проводили бизнес-анализ, инженеры составили высокоуровневую физическую архитектуру системы и модель жизненного цикла. А менеджер проекта составил ролевую организационную структуру проекта по разработке и созданию системы доставки последней мили (СДПМ).
Вам надо составить подход к верхнеуровневой оценке стоимости проекта (по модели таланты-технологии-постановка практики) и рассчитать стоимость и риски основных развилок:
- Делать реинжиниринг существующей системы (приобрести готовую автономную автомобильную платформу и доработать ее)
- Разрабатывать текущее решение
- Использовать курьерские, грузовые убер-доставки и доставку дронами в качестве альтернативы либо элементов системы
Какие вопросы надо задать заказчику для правильного ответа на эти вопросы? Каким стейкхолдерам заказчика их надо задать и как их найти? Какие компетенции необходимо получить в команду для проведения оценок?
Опишите альфу “Возможности”. Какие цели у вас были на планировании предпроекта? Что пошло не так? Что можно было сделать лучше?
Упражнение 2. Предпроект. Разработка ориентированной на продукты WBS, связь WBS с функциональной декомпозицией системы (логической архитектурой), диаграммы создания системы и оргинтерфейсы между пакетами работ, модели жизненного цикла, оргструктуры проекта. Оценка стоимости жизненного цикла системы. Целеполагание проекта для основных групп стейкхолдеров, планирование организационного уровня каналов взаимодействия (бизнес-интерфейсов). Планирование и организация совещаний по запуску проекта (kick-off meeting, KOM).
Практики “на один укус”: jobs to be done, модель практики, продуктовое разбиение (PBS), диаграмма создания продукта (PRINCE2 PFD), оргинтерфейсы пакетов работ, оргфункциональная структура проекта, целеполагание стейкхолдеров, моделирование целеполагания стейкхолдеров в АрхиЭссенс в Archi, бизнес-кейс и бизнес-контроль проекта, модели и виды жизненного цикла, драйверы выбора вида жизненного цикла, выбор модели взаимодействия и оргинтерфейсов команды проекта, совещание по запуску проекта.
Планирование содержания проекта, создание ИСР и проектирование интегрированной команды продукта
Иерархическая структура работ (ИСР)
Применение. В проекте существуют две ИСР: ИСР со стороны Заказчика (1) и ИСР со стороны Исполнителя (2), также называемая контрактной ИСР (включая требования к детальной отчетности).
ИСР проекта обеспечивает основу для определения целей проекта. Каждый элемент ИСР обеспечивает логические сводные уровни для оценки технических достижений, для поддержки требуемых технических обзоров, а также для измерения эффективности затрат и расписания. ИСР определяет проект с точки зрения иерархически связанных, ориентированных на продукт элементов.
ИСР проекта утверждается руководством Заказчика для целей отчетности по проектам и включает все проектные элементы (например, аппаратное обеспечение, программное обеспечение, услуги, данные или объекты), которые являются обязательными. ИСР допускает детализацию со стороны подрядчика на более низкие уровни в соответствии с требованиями договора и описания содержания (SOW).
ИСР проекта состоит из трех частей - физической архитектуры целевой системы (1), физической архитектуры обеспечивающей системы (2) и воплощения/реализации практик управления проектом (3). Практики и физические объекты онтологически объединены с помощью 4Д-экстенсионализма, см. разъяснения здесь.
ИСР определяется, разрабатывается и поддерживается на протяжении всего жизненного цикла системы на основе дисциплинированного применения процесса системной инженерии. Цель состоит в том, чтобы разработать ИСР, которая определяет логическую взаимосвязь всех элементов проекта до определенного уровня (обычно уровня 3 или 4), который не ограничивает возможности подрядчика определять приоритеты и управлять проектом и ресурсами. Однако, если Заказчик посчитает некоторые элементы проекта более дорогостоящими или высокорисковыми, система может быть определена на более низком уровне ИСР. При этом разбиение обязательно должно быть ориентировано на продукт. Подрядчик должен проработать элементы до уровня и формы, которая учитывает способ разработки, производства или управления системой. Вторичной, но все же важной задачей ИСР является предоставление систематического и стандартизованного метода сбора данных о расходах во всех проектах.
Наличие фактических исторических данных по сметам расходов на аналогичные проекты является ценным ресурсом для планирования последующих проектов.
Однако основной целью ИСР является определение структуры проекта, и потребность проектного офиса в данных в оценках стоимости не должна приводить к искажениям в структуре и определении проекта.
Кроме того, ИСР используется при координации деятельности. С помощью ИСР проекта и контракта документируется ход работ по мере выделения и расходования ресурсов. Для целей отчетности обычно используются данные по производительности, стоимости, графику и техническим характеристикам. ИСР предоставляет инфраструктуру для обобщения данных для различных уровней управления и предоставления соответствующей информации о прогнозируемом, фактическом и текущем статусе входящих в нее элементов. Правильная структура ИСР и ее корректное использование в сочетании с принципами системной инженерии, оценке стоимости, метода освоенного объема (EVM), интегрированного планирования и управления рисками, ИСР позволяет постоянно отображать статус проекта, поэтому менеджер проекта и подрядчик могут определять, координировать и внедрять изменения, необходимые для достижения желаемых результатов.
Проблемы. Основная задача заключается в разработке ИСР, которая
1) Определяет логическую взаимосвязь между всеми проектными элементами
2) Не ограничивает работы подрядчика, необходимые для достижения целей проекта
3) Отвечает всем требования к отчетности проекта.
ИСР должна быть достаточной для обеспечения необходимой информации о проекте для эффективного отчета о статусе и уклонения от рисков и облегчать подрядчику эффективное исполнение проекта.
Вторичная задача состоит в том, чтобы сбалансировать аспекты определения проекта с генерацией исторических данных для планирования последующих аналогичных проектов. ИСР используются в качестве исторически данных при планировании проектов. Использование ИСР проектов прошлых периодов является очень ценным ресурсом. Однако основной целью ИСР является определение структуры проекта, и потребность в данных не должна искажать или препятствовать определению проекта.
Как ИСР связана с другими требованиями контракта? ИСР обеспечивает основу для эффективных коммуникаций на протяжении всего процесса приобретения. Это общая база, которая объединяет дисциплины планирования, составления графиков, оценку стоимости, бюджетирование, заключение контрактов, управление конфигурацией и отчетности по эффективности. Это позволяет представителям Заказчика постоянно оценивать прогресс в плане выполнения контрактов.
ИСР формирует основу структур отчетности, используемой для контрактов, которые требуют соблюдение стандартов по освоенному объему, отчетности по стоимости и данным проекта, отчетам об эффективности и бюджетных расходах.
Задача 2.1. Планирование содержания
На этапе запуска предпроекта вы собрали и гармонизировали потребности стейкхолдеров и разработали три варианта архитектурных решений СДПМ с обоснованиями. Заказчик после содержательного обсуждения каждого из вариантов архитектурных решений выбрал один и составил к нему список доработок и замечаний к устранению. Вы подписали контракт, по которому будут производиться основные работы по оценке проекта, и получили грант, который будет использоваться для инженерной и исследовательской работы (1 инженер-исследователь материалов и 2 инженера-исследователя конструкций и перспективных решений).
Вы составили WBS контракта, которая пошла приложением к подписанному договору. Теперь вам надо составить детальную WBS. Детализацию будут делать члены команды, назначенные на пакеты планирования. Вам надо организовать процесс планирования содержания. Напишите план управления содержанием для основного транспортного средства (отдельно для сборки, “железа” и “софта”).
Структура плана управления содержанием:
- Кто отвечает за план проекта по содержанию и кто его держатель
- Как определяется содержание проекта (WBS, словарь WBS, описание содержания/SoW)
- Как измеряется и проверяется исполнение содержания (чек-листы, базовый план по содержанию и освоенный объем, метрики из трекеров или канбан систем, допускаются различные методики для различных пакетов планирования)
- Процесс изменения содержания - кто имеет право подать запрос, как он обрабатывается
- Кто отвечает за валидацию содержания и приемку окончательного продукта проекта и подтверждает выполнение объема работ
Какие стейкхолдеры вам нужны? Какие вопросы им надо задать?
Проверьте ваш план по чек-листам альф Эссенс.
Задача 2.2.
Детализация ИСР до уровня 4.
Используя детализацию следующего уровня для основного транспортного средства и систем удаленного контроля, составьте диаграмму создания продукта (ДСП, PFD, product flow diagram). Уточните план управления содержанием. Выделите 2 критических оргинтерфейса между пакетами планирования по ДСП, определите для них основные риски и спланируйте для них три уровня интероперабельности - организационный, семантический и технологический протоколы взаимодействия. Начните заполнять план управления коммуникациями.
Инженеры совместно с закупщиками определили стратегию приобретения модулей системы (make or purchase decisions) и выделили модули с наибольшими сроками поставки. Определите для них основные контрольные точки с помощью чек-листов Эссенс и наложите контрольные точки на выбранный ранее вид жизненного цикла. Обсудите получившуюся модель жизненного цикла, какие риски по ней выявляются? Наложите получившуюся модель жизненного цикла на практики, привязанные к элементам ДСП, получите уточненную модель жизненного цикла.
Обсудите модель жизненного цикла, определите выявленные риски проекта. Уточните план управления содержанием проекта.
Какие рекомендации вы бы дали конкурирующей команде по организации планирования содержания? С какими процессами планирования проекта связан процесс планирования содержания?
Вы проанализировали WBS и модель жизненного цикла с помощью design structure matrix (DSM) и распределили роли, привязанные к практикам, в организационной структуре проекта (рабочий продукт - органиграмма и бюджеты подразделений).
DSM ролей и получившаяся оргструктура:
Вам надо спланировать разработку должностных инструкций, положений о подразделениях и регламентации деятельности. В какой последовательности и почему вы будете регламентировать деятельность? Поясните предложенный вариант с использованием модели жизненного цикла (http://sdu2020.blogspot.gr/2017/05/blog-post_14.html и http://sdu2020.blogspot.gr/2017/05/blog-post_28.html )
Назначьте ответственные подразделения на каждую стадию жизненного цикла. Обоснуйте решения.
Используя модель жизненного цикла организуйте процесс оценки стоимости жизненного цикла. Сделайте предложение по организации гейтов (сколько, где, процедура прохождения).
Задача 2.3
Используя наработки, сделайте предположения по целям основных групп стейкхолдеров поставляющей и приобретающей стороны. Составьте план интервью для уточнения их потребностей.
Организуйте совещание по запуску проекта (kick-off meeting).
Обычно запуск проекта начинается с совещания по запуску проекта (kick-off meeting, KOM), в котором участвуют основные игроки, отвечающие за планирование, включая менеджера проекта, помощников менеджера проекта по отдельным областям знаний, экспертов в предметных областях (subject matter expert, SME) и функциональных руководителей. Обычная последовательность запуска проекта показана на рисунке 11-2. В проекте может быть несколько КОМ, в зависимости от размера, сложности и длительности проекта. Основные игроки обычно имеют полномочия принимать решения по срокам, стоимости и длительности задач в своих предметных областях, а также определять ресурсные требования. Обычно на КОМ обсуждают:
- Администрирование затрат на персонал и зарплат, если применимо
- Уведомляют исполнителей о том, в каком порядке их функциональный руководитель будет информироваться об их эффективности на проекте
- Начальные представления о технических и бизнес-задачах проекта
- Как будет определяться успех проекта
- Предположения и ограничения в том виде, как они описаны уставом проекта
- Организационная структура проекта, если она готова к этому моменту
- Роли и ответственность участников
Для небольшого или короткого проекта на КОМ можно также дать оценки длительности и сроков выполнения задач. Для таких проектов не нужно отдельно готовить расписание оценки сроков и стоимости проекта. Но если цикл оценки занимает больше двух недель, и требуется запрашивать данные из нескольких отделов или организаций, вам надо будет разработать отдельное расписание по подготовке оценок по срокам и стоимости (estimating schedule). В этом случае вам надо будет провести предварительное совещание по запуску проекта (pre-kickoff meeting), на котором дать предварительные оценки.
Минимальный список контрольных точек расписания по подготовке оценок такой: предварительное совещание по запуску проекта (1), совещание по правилам оценок (2), вводные по ресурсам (3), итоговое совещание (4).
Цикл оценки и описание этих контрольных точек см. ниже.
Предварительное совещание по запуску проекта
На это совещание зовут всех исполнителей, кто должен предоставить свои соображения по оценке стоимости. Обычно в их число входят технические специалисты из функций, отвечающих за реализацию проекта, специалисты от бизнеса, которые понимают влияние финансовых факторов, влияющих на оценку, представители команды управления проекта, которые понимают основные принципы реализации этого проекта, и, конечно, сметчики или другие оценщики стоимости.
В команду оценки не обязательно включать ответственных исполнителей. На совещание по запуску проекта нужно отвести достаточное время, за которое можно рассказать про все правила, применяемые в этом проекте, ограничения, предположения, передать все технические спецификации, чертежи, расписания и описания отдельных элементов работ и форм для оценки сроков и стоимости. Не забудьте, что на собрании нужно не только обсудить эти документы, но и ответить на все возникшие вопросы. КОМ также хорошо подходит для обсуждения корректности назначений оценщиков по каждой отдельной дисциплине.
КОМ может назначаться за срок от 6 недель до 3 месяцев до крайнего срока готовности оценок, это необходимо для того, чтобу у оценщиков было достаточно времени на разработку оценок.
Совещание по правилам оценок
Через несколько дней после КОМ, после изучения участниками материалов, необходимо назначить совещание по правилам оценки. На этом совещании менеджер по оценке должен ответить на все вопросы, возникшие у участников в части того, как проводить оценку стоимости и сроков, предположений, лежащих в основе оценок, а также назначений оценщиков. Если оценщики опытные, вопросов может быть очень немного.
Однако, если это первый опыт оценки для данной команды, участникам потребуется помощь и руководство в проведении оценок. Может потребоваться обучение инструментам и методам. Если оценку будут давать исполнители, что является предпочтительным вариантом, если вы хотите получить реалистичные оценки, то времени и усилий потребуется больше, чем если бы работу выполняли профессиональные оценщики.
Совещание по вводным для ресурсного обеспечения
Через несколько недель после первых двух совещаний, каждый оценщик представляет результаты своей работы перед командой оценки. И теперь начинается самая ценная часть процесса оценки - командное взаимодействие по устранению задвоенных оценок, перекрытий или наоборот, недостатков в данных. Ценность этого этапа невозможно переоценить, в особенности для междисциплинарной работы. Самые важные и разумные решения рождаются именно в ходе таких обсуждений. Фасилитатор этого собрания должен отследить, чтобы каждый оценщик предоставил обоснование своих оценок и защитил их перед своими коллегами. Иногда за одно собрание решить все вопросы не удается, и приходится организовывать второе.
Итоговое совещание
После готовности плана по ресурсам и оценки его стоимости, оценка проекта представляется на предварительную оценку руководству компании или запрашивающей организации. Во время предварительной оценки выявляются несоответствия, которые не были выявлены во время подготовки оценки, консолидации планов и вычитке планов. Во время итогового совещания могут всплыть также изменения в правилах оценки, предположениях или ограничениях, что может повлиять на бюджет и сроки.
Упражнение 3. Защита предпроекта у заказчика.
Упражнение 4. Определение стейкхолдеров по модели жизненного цикла. Поиск и выявление представителей стейкхолдеров.
Упражнение 5. Разработка плана управления проектом. Связь ПУпрП с планом системной инженерии и стратегией приобретения.
Упражнение 6. Планирование содержания проекта, организация детализации WBS, организация разработки словаря WBS. Разработка профилей компетентности IPT и CFT. Начальная оценка стоимости производства.
Упражнение 7. Разработка верхнеуровневой модели бизнес-кейса и формализация методов оценок.
Упражнение 8. Разработка модели жизненного цикла команды, обоснование выбора МЖЦ команды. Выбор модели лидерства для различных команд, разработка стратегии приобретения компетенций, разработка стратегии обучения и развития.
Упражнение 9. Календарно-сетевое планирование проекта, использование метода Монте-Карло для оценки рисков расписания. Ведомый рисками выбор гейтов, развилок и альтернатив плана реализации проекта.
Упражнение 10. Проведение КОМ.
Структура модуля/упражнения:
- Домашнее задание. Текст + видеолекция. Учебные задачи с тестами. Результатом является рабочая тетрадь с начальными ответами.
- Очный прогон в классе, 40 минут на упражнение результатов тестов, разбор вариантов решения. Результатом является рабочая тетрадь с ответами по результатам обсуждения.
- Эссе. Заполненная рабочая тетрадь с результатами рефлексии по каждому блоку. Обсуждение со студентами и преподавателями.
Комментариев нет:
Отправить комментарий