KPI оценка сроков

 Индекс выполнения сроков

При планировании страховой сделать все по правильному

Резервы, риски и т.п.

Ошибки при управлении стоимостью

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

В том числе в управлении стоимостью описывается каким образом будет финансироваться проект

Постановка точно такая же работа как и программирование

Она точно также должна сдаваться и проверяться

Padding & reserves различия

Это одна из причин почему люди не верят в оценки

Данные об исполнении!!! 4.3.3.2

Оценку длительности операций

... можно делать вместе с командой проекта

Должно быть несколько вариантов
+ должны быть резервы

Оценка ресурсов проекта

Требования к ресурсам тоже можно составить
К компенсациям например
Интересная тема - иерархическая структура ресурсов (до уровня навыков)

Разница между подтверждением содержания и закрытием проекта (фазы)

Работу надо делать хорошо

Не только программировать надо качественно, но и

1) Собирать требования
2) Описывать требования

согласовывать требования

Всю работу выполненную некачественно придется переделать

Для чего можно использовать WBS

1) Сбор требований
2) Перечень объектов поставки
3) Перечень работ

Не забываем про словарь WBS

Процесс утверждения содержания занимает много времени!

Определение содержания это процесс определения что из требований входит, а что не входит в рамки проекта

кк

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

Требования могут быть разные
1) К продукту
2) К порядку выполнения
3) К качеству

И даже к проектному управлению

Порядок сбора требований
1) Определить заинтересованных сторон
2) Собрать требования с заинтересованных сторон. Вариантов сбора требование много...

Контроль содержания отвечает (в т ч) не делаем мы чего-нибудь лишнего

В описание содержание проекта

В том числе в него включается "Критерии приемки"

Активы процессов организации

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

Матрица отслеживания требований

5.2.2 Сбор требований: инструменты и методы

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

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

5.2.2.3 Семинары с участием модератора
Семинары с участием модератора (facilitated workshops) представляют собой сфокусированные обсуждения,
объединяющие ключевые заинтересованные стороны с целью определения требований к продукту. Семинары используются
в качестве основного метода, позволяющего быстро определить межфункциональные требования и урегулировать различия
между требованиями заинтересованных сторон. В силу особенностей формата групповой работы, хорошо скоординированные
обсуждения помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести
к повышению уровня согласия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и
решены быстрее, чем при индивидуальных обсуждениях.
Например, в области разработки программного обеспечения используются семинары с участием модератора под
названием «Совместная разработка/проектирование приложений» (joint application development/design, JAD). Данные
обсуждения с участием модератора сконцентрированы на том, чтобы собрать вместе бизнес-экспертов по предметной
области и команду разработчиков для улучшения процесса разработки программного продукта. В производственных
отраслях существует «Развертывание функций качества» (quality function deployment, QFD) — это еще один пример семинара
с участием модератора, который помогает определить критически важные характеристики для разработки нового продукта.
QFDначинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC).
Затем данные потребности объективно сортируются и приоритезируются, а также устанавливаются цели для их достижения.
Во время семинаров по требованиям зачастую разрабатываются пользовательские истории — краткие текстовые описания
требуемой функциональности. Пользовательские истории описывают заинтересованную сторону, которая получает пользу
от свойства продукта (роль), что заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной
стороны (мотивацию). Пользовательские истории широко используются в рамках гибких (agile) методов.

5.2.2.4 Методы группового творчества
Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже
представлены некоторые из методов группового творчества:
•  Мозговой  штурм.Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями
к проекту и продукту. Хотя сам по себе мозговой штурм не включает голосование или приоритезацию, его часто
используют с другими методами группового творчества, которые предусматривают данные процессы.
•  Метод номинальных групп.Метод, расширяющий мозговой штурм путем процесса голосования, используемого
для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритезации.
•  Построение ассоциативных карт.Метод, в котором идеи, возникшие во время отдельных сессий мозгового
штурма, объединяются в одну карту с целью отражения общности и различий в понимании и для генерирования
новых идей.
•  Диаграмма  сходства. Метод, позволяющий классифицировать большое количество идей по группам с целью
обзора и анализа.
•  Анализ решений на основе множества критериев.Метод, использующий матрицу решений для обеспечения
систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность
и определение ценности, для оценивания и ранжирования многочисленных идей

5.2.2.5 Методы группового принятия решения
Метод группового принятия решений — это процесс оценки различных альтернатив с ожидаемым результатом в форме
будущих действий. Данные методы могут быть использованы для создания, классификации и приоритезации требований к
продукту.
Существуют различные методы принятия группового решения, например:
•  Единогласие.Принятие решения посредством согласия каждого с единым курсом действий. Один из способов
достижения единогласия — это метод Дельфи, при котором группа выбранных экспертов отвечает на вопросы
анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора
требований. Для обеспечения анонимности доступ к ответам имеет только модератор.
•  Большинство.Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в
группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного
количества голосов.
•  Относительное  большинство.Выбирается решение самого большого блока в группе, даже если не достигнуто
большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора.
•  Диктатура.Данный метод предполагает, что одно лицо принимает решение за всю группу

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

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

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

5.2.2.8 Прототипы
Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем
предоставления рабочей модели ожидаемого продукта, прежде чем создавать продукт в действительности. Поскольку
прототипы реальны, это позволяет заинтересованным сторонам экспериментировать с моделью конечного продукта, а
не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию
последовательного уточнения в итеративных циклах создания экспериментальных моделей, проведения экспериментов
пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной
связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к
фазе проектирования или создания. Раскадровка (storyboarding) — это метод прототипирования, использующий
последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных
проектах во многих отраслях, например при создании фильмов, в рекламе, педагогическом проектировании, в проектах
гибкой (agile) разработки и других проектах разработки программного обеспечения. При разработке программного
обеспечения в раскадровке используются экспериментальные модели, чтобы продемонстрировать возможности навигации
по веб-страницам, экранам или другим интерфейсам пользователей.

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

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

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

План управления содержанием

План управления содержанием разъясняет какие требования надо собирать команде проекта.

Определение содержания —процесс разработки подробного описания проекта и продукта.

Реестр заинтересованных сторон (13.1.3.1) = мы обычно берем из организационной структуры

Качественно можно не только программировать

Качественно можно фиксировать требования и писать постановку задачи!!!

Качественно можно не только программировать

Качественно можно фиксировать требования и писать постановку задачи!!!

Контроль и мониторинг ключевая задача

Сообщить текущее состояние проекта

Совместные чтения документов Исполнителем и Заказчиком

Возможно это хорошая идея

Исполнение и измерение

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

Корректирующие действия

Нельзя выполнить корректирующие действия если вы не измеряете текущего состояния

Закрытие проекта

в обычной жизни не так просто определить когда проект закрывается. Кажется что он либо резко отменятся либо тянется бесконечно!!

Формальное закрытие проекта позволяет высвободить ресурсы для следующего проекта

Инициация проекта

Не забываем про формальное одобрение менеджера проекта
Составление устава проекта
Работ с заинтересованными сторонами
Планирование на верхнем уровне
Индустриальные стандарты
Предыдущие проекты

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