Please enable JavaScript.

Coggle requires JavaScript to display documents.

Проектное управление - Coggle Diagram

- - - - R – Responsible (исполняет)
      - A – Accountable (несет ответственность)
      - C – Consult before doing (консультирует до исполнения)
      - I – Inform after doing (оповещается после исполнения)
  - - - Создатели (Shapers) - люди, которые побуждают команду к улучшениям. Им нравится искать новые подходы к решению проблем, они воспринимают задачи как увлекательные вызовы, способны преодолеть любые преграды. Слабой стороной их может быть их склонность к спорам и возможность оскорбить других.
      - Реализаторы (Implementers) – люди, которые выполняют поставленные задачи. Они воплощают идеи в практические планы и действия. Они консервативны, дисциплинированы, сдержаны, работают систематически и эффективно, хорошо организованы. На них можно положиться в выполнении работы. Недостатком их может быть негибкость и сопротивление изменениям.
      - Завершатели (Completers – Finishers) – люди, которые видят проект полностью. Они следят, чтобы в работе команды не было никаких ошибок и упущений, обращают внимание на все мелочи. Завершатели добросовестные перфекционисты. Однако, они могут тревожиться понапрасну, им трудно делегировать ответственность.
    - - Координаторы (Coordinators) – люди, которые хорошо проясняют цели, помогают выработке решений, легко делегируют ответственность. Они выдержаны, уверены в себе. Прекрасные слушатели, хорошо видят пользу, приносимую каждым членом команды. Недостатком может быть манипуляция людьми и большое делегирование своих личных обязанностей.
      - Работники команды (Team Workers) - люди, склонные к сотрудничеству, к групповой деятельности. Они хорошо знают и выполняют свое дело, гибки, дипломатичны, восприимчивы. Их недостатком является нерешительность и пассивность в кризисных ситуациях.
      - Искатели ресурсов (Resource Investigators) – это коммуникаторы. Они исследуют возможности, налаживают контакты, ведут переговоры от имени команды. Они энтузиасты, контактирующие с внешними заинтересованными сторонами. Их слабостями могут быть излишний оптимизм, а также возможная потеря интереса к работе после спада первоначального энтузиазма.
    - - Генераторы (Plants) – творческие инноваторы, разрабатывающие новые идеи и подходы. Они черпают вдохновение из похвалы, но тяжело воспринимают критику. Чаще всего работают индивидуально. Их идеи могут быть не слишком практичными, иногда они игнорируют установленные правила и ограничения.
      - Наблюдатели (Monitors – Evaluators) – они хорошо анализируют и оценивают чужие идеи, сначала взвешивают все плюсы и минусы, а потом выбирают решение. Наблюдатели имеют критическое и стратегическое мышление. Но они не эмоциональны, у них негативные мотиваторы.
      - Специалисты (Specialists) – люди, имеющие специальные знания и навыки, необходимые для работы команды. Они испытывают потребность в подтверждении своего профессионального статуса, их главная задача в команде – быть экспертом в той или иной области. Их недостатки чрезмерная озабоченность технической стороной дела, ограниченный вклад в общий результат.
  - - - «Hygiene factors»: ► Зарплата и премии ► Условия работы ► Политика и внутренние правила компании ► Статус в компании ► Безопасность на работе ► Взаимоотношения с начальством ► Взаимоотношения с сослуживцами ► Личные факторы
      - «motivators ► Чувство успеха – наиболее сильный побуждающий фактор ► Признание значимости выполняемой работы ► Удовлетворение, интерес к самой работе ► Ответственность (брать на себя риск, принимать решения, управлять) ► Продвижение, рост
  - - - Начальная фаза
        
        ► Стратегия ► Приоритеты выбора проектов ► Распределение ответственности ► Технические решения ► Финансовые схем
      - Промежуточные фазы
        
        ► Ресурсы (сроки, стоимость, люди) ► Поставки ► Взаимодействия ► Реализация технических решений ► Нечеткость процедур
      - Финальная фаза
        
        ► Сдача-приемка результатов ► Итоговая оплата ► Расформирование команды ► Подведение итогов
    - - ► Постарайтесь предотвратить последствия конфликта, ссылаясь на принятые в проекте нормы поведения ► Сосредоточьте внимание на проблеме, а не на высказываниях участников. Обратите их внимание на цели проекта и требования к результату ► Попытайтесь поставить себя на место других, оцените, в чем причина нежелания согласиться с вашей точкой зрения. ► Отделите формулирование вариантов решения проблемы от выбора окончательного варианта, стимулируйте выработку большего количества идей, временно отложив их оценку. ► Если не можете достичь согласия по поводу конечного решения, попытайтесь достичь согласия хотя бы по поводу процесса принятия решения
    - - ► Консенсус. В выработке решения принимают участие все члены команды проекта. Целесообразно при приятии сложных решений с далеко идущими последствиями, когда качество решения и личная заинтересованность всех в успехе перевешивают потребность в быстром решении. ► Голосование. После обсуждения разных вариантов, окончательное решение принимается большинством голосов. Целесообразно, когда в выработке решения участвует большое число людей. ► Делегирование полномочий. Принятие решения поручается одному или нескольким членам команды, обладающим необходимой информацией и знаниями. Целесообразно, когда решение требует специальных знаний. ► Автократический метод. Решение принимается единолично менеджером проекта. Целесообразно, когда решение должно быть принято обязательно, однако, команда не располагает достаточной информацией
- - - - ► Оказывать поддержку проекту
        ► Отслеживать и поддерживать приоритет проекта относительно других
        ► Помогать руководителю проекта в преодолении организационных препятствий
        ► Регулярно обсуждать с менеджером проекта текущее состояние, давать советы
        ► Обеспечивать проект ресурсами
  - - - Техническое управление проектами. Знания, навыки и типы поведения, относящиеся к конкретным областям управления проектом, программой и портфелем
      - Лидерство. Знания, навыки и типы поведения, необходимые для управления, мотивации и руководства командой с целью помочь организации достичь ее бизнес-целей
      - Стратегическое проекта управление и управление бизнесом. Знания, профессиональная квалификация и опыт работы в отрасли и организации, которые улучшают исполнение и дают более высокие бизнес-результаты
  - - - Поддерживающая (оказывает консультативную помощь, обеспечивает шаблонами документов, обучает)
      - Контролирующая (обеспечивает поддержку, проверяет соответствие методологии корпоративному стандарту)
      - Руководящая (обеспечивает контроль выполнения проектов через непосредственное управление)
      - Ключевые возможности ОУП
        
        ► Усиление потенциала, ориентированного на поставку и конечные результаты.
        ► Видение общей картины. Следование целям проекта остается ключевым элементом успеха. Расползание содержания и новые приоритеты, не согласованные со стратегическими или бизнес целями, могут привести к отклонению проекта от намеченного курса.
        ► Непрерывное совершенствование, передача знаний и управление изменениями. Сильные ОУП оценивают исполнение проектов с прицелом на непрерывное совершенствование.
    - - ► Предоставляет процедуры, методологию и шаблоны для управления проектами в компании
      - ► Осуществляет обучение и поддержку в области управления проектами в компании
      - ► Распределяет менеджеров по проектам и отвечает за результаты этих проектов
    - - ► Управляет взаимодействием различных проектов
      - ► Осуществляет помощь в предоставлении ресурсов
      - ► Аккумулирует «lessons learned» и распространяет их на другие проекты
      - ► Обеспечивает проекты методическими материалами, шаблонами, информационными системами для управления проектами (ИСУП)
      - ► Участвует в работе Комитета по управлению изменениями
      - ► Прекращает проекты.
    - - Руководитель программы - отвечает за управление связанными друг с другом проектами, координируя их реализацию для получения синергетического эффекта. Сфера ответственности: достижение целей программы, управление синергией.
      - Заинтересованные стороны (Stakeholders) - юридические или физические лица, как непосредственно участвующие в проекте, так и те, чьи интересы могут быть затронуты процессами выполнения проекта и/ или его результатами.
        
        Любой проект - это изменения, которые затрагивают интересы многих людей и организаций, в том числе способных существенно повлиять на реализацию проекта. Неизвестные заинтересованные стороны или их неправильно интерпретированные интересы выявленных могут погубить проект!
        
        Управление заинтересованными сторонами
        
        Команде проекта необходимо:
        ► Выявить заинтересованные стороны (как внутренние, так и внешние)
        ► Определить их требования и ожидания
        ► Управлять влияниями различных групп таким образом, чтобы снизить возможные негативные последствия для проекта и увеличить позитивные
        
        Выявление ЗС (рекомендации практиков)
        
        По какому принципу мы называем того или иного человека «заинтересованной стороной»:
        ► Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
        ► Во-вторых, ЗС всегда являются конечные пользователи продукта (не пренебрегайте их интересами в проекте!)
        ► В третьих, не забывайте о руководителях членов вашей команды
        ► В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние
        
        Полезно систематизировать заинтересованные стороны следующим образом:
        ► связанные с проектом и/или с его конечными результатами
        ► привлеченные к выполнению проекта
        ► являющиеся потенциальными потребителями продукции (услуг) проекта
        ► стороны, от решений (разрешений) которых зависит реализация проекта
        ► испытывающие влияние от осуществления проекта и его результатов
        
        ЗС: Заказчик, Потребитель, Менеджмент, Акционеры, Поставщики, Правительство, Команда проекта, Общественность
        
        Реестр заинтересованных сторон (Stakeholder Register) – это документ, включающий определение, оценку и классификацию заинтересованных сторон проекта.
        
        Содержание реестра ЗС
        
        ► № стейкхолдера
        
        ► Наименование (организация, должность, ФИО)
        
        ► Категория (внешний, внутренний)
        
        ► Роль в проекте (заказчик, спонсор, член команды...)
        
        ► Заинтересованность
        
        ► Влияние на проект (в т.ч. на содержание, сроки, стоимость)
        
        ► Степень участия (нейтральный, сопротивляющийся...)
        
        ► Важность поддержки
        
        ► Стратегия взаимодействия
        
        Классификация ЗС по степени участия
        
        ► Неосознанный – нет понимания проекта и его возможных последствий
        
        ► Сопротивляющийся – есть осознание проекта и потенциальных последствий, но сопротивляется изменениям
        
        ► Нейтральный - есть понимание проекта, но нет ни поддержки, ни сопротивления
        
        ► Поддерживающий - есть осознание проекта и потенциальных последствий, благосклонен к изменениям
        
        ► Влияющий - есть осознание проекта и потенциальных воздействий, и активное участие в проекте для достижения успеха.
        
        Классификация ЗС по интересу и влиянию на проект
        
        ИНТЕРЕСЫ В ПРОЕКТЕ: низкие - средние - высокие
        
        Влияние на проект:
        
        низкое
        
        среднее
        
        1 more item...
        
        Мониторинг
        
        Сохранять информированность
        
        Выстраивать взаимодействие
        
        Поддерживать удовлетворенность
- - - - Процессы исполнения
        
        Поцессы монирторинга и контроля
        
        Процессы завершения
        
        ►
        
        ►
- - - - определяются заранее
        
        в конце проекта
        
        ограничено
        
        при наступлении КТ
        
        согласно детальному плану
    - - по окончанию фазы
        
        в конце проекта
        
        периодически
        
        регулярно
        
        согласно постепенно разрабатываемых планов и новой информации
    - - регулярно в ходе поставки инкрементов
        
        в ходе проекта инкрементами
        
        регулярно в ходе проекта
        
        постоянно
        
        с учетом поступления информации о требованиях и ограничениях
    - - Поставка продукта
        
        Внесение изменений
        
        Участие ключевых ЗС
        
        Контроль рисков и стоимости
- - - - Устав проекта (Project Charter) – документ, формально санкционирующий проект. Документирует первоначальные требования и ожидания заинтересованных сторон, а также наделяет полномочиями менеджера проекта. Устав подписывается внешним по отношению к проекту лицом (спонсором, руководителем офиса управления проектами). Он связывает проект со стратегией и текущей деятельностью компании.
  - - - Состав плана управления проектом
        
        Базовые планы проекта: Что? Когда? За сколько?
        ► Базовый план по содержанию
        ► Базовое расписание
        ► Базовый план по стоимости
        
        Вспомогательные планы Как управлять проектом? (техники, инструменты, методы)
        :
        ► План управления содержанием
        ► План управления расписанием
        ► План управления стоимостью
        ► План управления качеством
        ► План управления ресурсами
        ► И др.
      - Содержание продукта – это свойства и функции, которые характеризуют продукт, услугу или результат.
        
        Отвечает на вопрос «Какими свойствами и характеристиками должен обладать поставляемый результат проекта?»
      - Содержание проекта – это работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с требуемыми характеристиками и функциями.
        
        Включает в себя все работы непосредственно по созданию поставляемых результатов, а также деятельность по планированию, координации, управлению и контролю проекта.
        
        Содержание проекта является сферой Конфликта интересов: заказчик стремится к его расширению (без изменения сроков и бюджета), команда проекта – к его сокращению. Точное и однозначное определение содержания является важным фактором успеха проекта
      - Планирование содержания
        
        1. Собрать и сбалансировать требования заинтересованных сторон
        
        Сбор требований - это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей. Этот процесс предоставляет основу для определения содержания продукта и проекта.
        Требования собираются от всех заинтересованных сторон, а не только от заказчика и/ или спонсора.
        
        ВИДЫ ТРЕБОВАНИЙ
        
        Бизнес-требования (высокоуровневые потребности организации и причины, по которым был инициирован проект)
        
        Требования к продукту (свойства, функции и характеристики продукта, требования к качеству: тестирование, сертификация
        
        Требования на переходный период (условия перехода из текущего состояния в желаемое)
        
        Требования к проекту (даты контрольных событий, договорные обязательства, ограничения)
        
        Инструменты для сбора требований
        • Изучение исторических записей • Интервью • Фокус-группы • Фасилитационные сессии • «Мозговой штурм» • Карты памяти • Диаграммы сродства • Анкеты и обзоры • Наблюдения • Прототипы • Групповое принятие решений • Бенчмаркинг
        
        Требования должны быть выявлены, проанализированы и зарегистрированы достаточно подробно. Сначала они могут быть описаны высокоуровнево, и постепенно детализироваться по мере поступления новой информации. До включения в базовый план требования должны стать:
        ► однозначными (измеримыми и проверяемыми)
        ► отслеживаемыми
        ► полными
        ► непротиворечивыми
        ► приемлемыми для ключевых заинтересованных сторон Работа с требованиями продолжается на протяжении всего проекта, список требований может быть дополнен или изменен
        
        Матрица отслеживания требований — это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Основные параметры требований в матрице: ► № требования ► Текстовое описание ► Источник ► Приоритет ► Версия ► Текущий статус (активно, отменено, отложено и т.п.) ► Дата выполнения. Дополнительные: стабильность, сложность и критерии приемки
        
        Балансирование требований – это отбор тех требований, реализация которых предполагается в рамках проекта. ► Требования должны быть оценены по отношению к целям проекта для определения, что входит, а что не входит в содержание. ► Требования ранжируются, приоритизируются, проверяются на противоречивость, между ними устраняются конфликты. Процесс балансирования может быть долгим и сложным, но он существенно влияет на успех проекта
        
        Разработать описание содержания
        
        Описание содержания проекта (Scope Statement) - это изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. Описание содержания проекта документирует все содержание, включая содержание проекта и продукта и содержит детальное описание всех поставляемых результатов проекта.
        
        Состав разделов описания содержания проекта
        Описание содержания продукта (уточнение характеристик продукта проекта) Поставляемые результаты: 1. все уникальные и поддающиеся проверке продукты, которые необходимо произвести для завершения фазы или проекта 2. вспомогательные результаты – отчеты, документы по управлению проектом Критерии приемки (набор условий, которые должны быть выполнены до того, как поставляемые результаты будут приняты) Исключения из проекта (явная формулировка того, что исключено из проекта)
        
        Разработать иерархическую структуру работ
        
        ИСР
        
        Иерархическая структура работ (Work Breakdown Structure, WBS) - это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых результатов.
        
        ИСР служит основой длядетального планирования всего проекта.
        
        Нижний уровень ИСР называется «пакеты работ».
        
        Декомпозиция – это метод, предполагающий разбиение содержания и поставляемых результатов проекта на более мелкие и более управляемые элементы. Глубина декомпозиции определяется так, чтобы на нижнем уровне можно было: ► Достоверно оценить стоимость и продолжительность ► Управлять выполнением работ
        
        Верхний уровень ИСР может быть детализирован по: ► По основным результатам проекта ► По фазам жизненного цикла проекта ► По подпроектам и подрядчиками. ИСР проверяется на полноту и отсутствие избыточности. Для проверки используется правило 100% - сумма работ нижнего уровня дает достижение результата более высокого уровня. Внимание! В ИСР должны быть включены работы по управлению проектом.
      - Базовый план по содержанию
        
        Базовый план по содержанию (Scope Baseline) включает:
        
        ► Описание содержания проекта и продукта, включая критерии приемки результатов заказчиком
        
        ► Иерархическую структуру работ (ИСР) и ее описание
        
        ► Словарь ИСР
      - Планирование расписания
        
        Этапы
        
        Определить последовательность операций
        
        Параметры зависимостей
        
        Обязательные зависимости — требуются по закону или договору или являются неотъемлемым свойством данной работы
        
        Дискреционные зависимости (предпочтительная или мягкая логика) - предпочтительна одна последовательность, хотя могут существовать и другие приемлемые
        
        Внешние зависимости - связь между операциями проекта и вне проекта. Обычно находятся вне контроля команды проекта
        
        Внутренние зависимости связь предшествования между операциями проекта и обычно контролируются командой проекта
        
        Четыре типа связей между работами. Повторение
        
        Финиш – Старт (Finish to Start, FS)
        Старт последующей операции зависит от финиша предшествующей операции
        
        Финиш – Финиш (Finish to Finish, FF)
        Финиш последующей операции зависит от финиша предшествующей операции
        
        Старт – Старт (Start to Start, SS) Старт последующей операции зависит от старта предшествующей операции
        
        Старт – Финиш (Start to Finish, SF) Финиш предшествующей операции зависит от старта последующей операции
        
        Определение последовательности операций - это процесс определения и документирования связей между операциями проекта. При связывании операций между собой необходимо учитывать разные параметры зависимостей.
        
        Во взаимосвязях между работами проекта могут встречаться задержки (lags) и опережения (leads).
        
        Задержки (lags) – это временной интервал, на который задержится исполнение последующей операции относительно предшествующей.
        Пример: начало технологического процесса + 20 минут (выход на стабильный режим работы) – замер параметров процесса (связь SS с задержкой 20 мин.)
        
        Опережения (leads) – это временной интервал, на который может быть сдвинуто исполнение последующей операции относительно предшествующей на более ранний срок. На время опережения две работы выполняются параллельно.
        Пример: производство товара А – переналадка оборудования на выпуск товара Б. Операции по переналадке надо начать за 20 мин. до завершения выпуска партии товара А (Связь FS с опережением 20 мин.).
        
        Диаграмма сети расписания проекта (Project schedule network diagram) - это графическое отображение логических связей (зависимостей) между операциями расписания проекта
        
        Оценить длительность операций
        
        Оценка длительности операций
        
        Методы оценки длительности операций
        ► Экспертная оценка – профессиональное суждение экспертов
        ► Оценка по аналогам – использование фактической длительности аналогичных работ, выполненных в прошлом
        ► Параметрическая оценка – расчет, исходя из норм времени на единицу работы
        ► Оценка по трем точкам (PERT) – учет неопределенности в оценке работ
        ► Оценка «снизу вверх» - консолидация оценок компонентов ИСР более низкого уровня
        
        Оценка по трем точкам:
        ► tP – пессимистическая
        ► tM - наиболее вероятная
        ► tО - оптимистическая
        Ожидаемая продолжительность работ tE = (tО + 4 х tM + tP)/6
        Стандартное отклонение SD = (P - О) / 6
        Вероятность отклонений от PERT:
        +/- 1 SD - 65%,
        +/- 2 SD - 95%,
        +/- 3 SD - 99%
        
        Определение ресурсов операций
        
        Оценка длительности операций производится после назначения ресурсов, т.к. зависит от их количества и качества
        
        Ресурсы, необходимые для выполнения операций проекта
        
        Внутренние - Получение у функциональных руководителей или владельцев ресурсов
        
        Внешние. Приобретение через процессы закупок
        
        Оценка длительности операций – это процесс оценки количества рабочих периодов, требуемых для завершения отдельных операций с учетом оценки ресурсов.
        При оценке длительности операций используется информация о содержании работ, требуемых типах ресурсов или уровнях навыков, оценках количества ресурсов, а также календарях ресурсов.
        
        Разработать расписание
        
        Планирование расписания - это процесс анализа последовательностей операций, их длительности, потребностей в ресурсах и ограничений расписания для создания модели расписания в целях исполнения проекта, а также мониторинга и контроля:
        
        Расписание в виде диаграммы Гантта
        
        Диаграмма контрольных событий
        
        Диаграмма сети расписания
        
        Метод критического пути
        
        Критический путь (Critical Path) – это последовательность операций, представляющая собой самый длительный путь в расписании проекта, который определяет минимально возможную длительность проекта
        
        Метод критического пути (Critical Path Method) используется для оценки минимально возможной длительности проекта и определения степени гибкости расписания в рамках модели расписания.
        
        Знание критического пути позволяет
        
        Оценить продолжительность проекта
        
        Определить, на каких операциях сфокусировать внимание менеджера проекта
        
        Определить, какие проблемы требуют неотложного решения
        
        Узнать, сжатием или запараллеливанием каких операций можно сократить продолжительность проекта
        
        Узнать, какие операции имеют временные резервы и могут быть отсрочены без ущерба для продолжительности проекта.
        
        Ранние и поздние даты. В расписании для каждой операции вычисляются:
        
        ► Ранние даты старта и финиша (Early Start, Finish). Они оцениваются прямым счетом от даты начала проекта (прямой проход сети)
        
        ► Поздние даты старта и финиша (Late Start, Finish). Они оцениваются обратным счетом от даты завершения проекта (обратный проход сети).
        
        Правила расчета расписания проекта
        
        5 more items...
        
        Общий временной резерв (Total float) или степень гибкости расписания – это количество времени, на которое может быть отложена или продлена операция расписания с раннего старта без просрочки даты завершения проекта или нарушения ограничений расписания
        Общий резерв = Позднее начало – Ранее начало = Поздний конец – Ранний конец
        
        Выравнивание ресурсов – это метод регулирования дат старта и финиша операций с учетом ограничений ресурсов в целях уравновешивания спроса на ресурсы с доступным предложением. Используется когда:
        ► общие или критически важные ресурсы доступны только в определенное время или в ограниченном количестве
        ► при переназначении ресурсов (ресурс был назначен для выполнения двух или более операций в один и тот же период времени)
        ► существует необходимость поддерживать использование ресурсов на постоянном уровне. Может приводить к изменению первоначального критического пути.
        
        Провести декомпозицию пакетов работ до операций
        
        Определение операций - процесс определения и документирования конкретных действий, которые необходимо выполнить для создания поставляемых результатов проекта.
        В процессе разработки ИСР определяются пакеты работ, которые потом декомпозируются до операций.
        
        Планирование методом набегающей волны (Rolling Wave Planning) – это планирование, при котором ближайшие работы планируются подробно (на нижнем уровне ИСР), работы в отдаленном будущем планируются в общем виде, на высоком уровне ИСР.
        Выполнение проекта начинается уже при частичной детализации содержания. После окончания очередной фазы конкретизируется содержание следующей фазы. Таким образом, по проекту постепенно проходит «волна» детализации.
        
        Базовое расписание — одобренная версия модели расписания, которая может быть изменена только с помощью формальных процедур контроля изменений и используется как база для сравнения с фактическими результатами. Является компонентом плана управления проектом.
        
        Резервирование на риски в расписании проекта В расписании проекта могут создаваться резервы времени для покрытия рисков, влияющих на сроки исполнения проекта (резервы на возможные потери и управленческий). Резервирование осуществляется аналогично формированию резервов в бюджете проекта
        
        Методы сокращения продолжительности проекта
        
        Быстрый проход - Параллельное выполнение операций критического пути на протяжении по крайней мере некоторой части их длительности. негативным следствием метода является увеличение рисков (повышение вероятности переделок, которые, в свою очередь, могут вызвать задержку выполнения проекта).
        
        Сжатие - Сокращение длительности операций критического пути за счет добавления ресурсов учетом минимизации дополнительных затрат на уменьшение длительности. При применении этого метода проводится анализ компромиссов между стоимостью и сроками, для определения, каким образом можно максимально сжать сроки при минимальных затратах.
        Негативными следствиями метода являются: ► Увеличение стоимости проекта ► Дополнительное время и затраты на координацию ресурсов ► Невозможность применения для операций, не подлежащих сжатию
        
        Расписание проекта (Project Schedule) - это документ, представляющий взаимосвязанные операции проекта с запланированными датами начала и окончания, длительностями, контрольными событиями и ресурсами.
    - - 1. Оценить стоимость
        
        Фазы жизненного цикла проекта и точность оценок
        
        Точная оценка (Definitive Estimate)
        / -5% +10% / Исполнение (прогнозы до завершения)
        
        Порядок величины (Rough Order of Magnitude Estimate, ROM) / -25% +75% / Инициация (бизнес-кейс, Устав проекта)
        
        Бюджетная оценка (Budget Estimate) /-10% + 25% / Планирование (разработка бюджета проекта)
        
        Методы оценки стоимости
        ► Экспертная оценка ► Оценка по аналогам ► Параметрическая оценка ► Оценка «снизу вверх» ► Оценка по трем точкам ► Стоимость качества ► Анализ резервов
        
        Стоимость качества (Cost of Quality, COQ), связанная с проектом, включает в себя одну или несколько из перечисленных ниже затрат
        
        Стоимость соответствия требованиям
        
        ► Затраты на предотвращение ► Затраты на оценку
        
        Стоимость несоответствия требованиям
        
        ► Стоимость внутреннего отказа ► Стоимость внешнего отказа
        
        Метод анализа резервов (для реагирования на риски)
        
        «Неизвестные Неизвестные» (полная неопределенность) / Пассивное реагирование (принятие) / Управленческий резерв
        
        - Управленческие резервы — сумма в бюджете проекта, предназначенная для выполнения непредвиденной работы, находящейсяв пределах содержания проекта. Резервы связаны с «неизвестными неизвестными».
        Управленческий резерв не включен в базовый план по стоимости, но является частью общего бюджета проекта.
        В случае, когда часть управленческого резерва использована для финансирования непредвиденных работ, эта сумма добавляется к базовому плану по стоимости, требуя внесения в него одобренного изменения.
        
        «Известные неизвестные» (общая неопределенность) /специфическая неопределенность) / Проактивное
        реагирование / Затраты на реагирование
        
        «Известные неизвестные» (общая неопределенность) // Пассивное реагирование (принятие) / Резерв на возможные потери
        
        Резерв на возможные потери - это бюджет в составе базового плана по стоимости, который выделяется для принятия мер против идентифицированных рисков («известных неизвестных»).
        
        Он может быть обеспечен на любом уровне: от уровня конкретной операции до уровня проекта в целом.
        
        По мере поступления более точной информации о проекте резервы на возможные потери могут быть использованы, сокращены или исключены.
        
        «Известные» (полная определенность)
        
        Метод анализа резервов – это создание в бюджете проекта резервов для покрытия рисков, влияющих на стоимость проекта:
        
        ► Управленческого резерва (не входит в базовый план по стоимости, но входит в бюджет проекта)
        ► Резервов на возможные потери (входят в базовый план по стоимости)
        
        ► Базовый план по стоимости (Cost Baseline) санкционированный распределенный по времени бюджет, по которому производится сверка, мониторинг и контроль использования денежных средств по проекту.
        ► Базовый план по стоимости - это часть общего бюджета проекта, контроль над которой получает руководитель проекта. Он включает в себя все санкционированные бюджеты, за исключением управленческого резерва.
        
        Оценка стоимости - это количественная оценка возможной стоимости ресурсов, необходимых для выполнения операций проекта. Это прогноз, основанный на информации, известной в конкретный момент времени.
        Для разных точек принятия решений в ходе проекта целесообразно использовать разные оценки стоимости. Точность оценок повышается по мере продвижения проекта по его жизненному циклу.
        
        Оптимальная стоимость качества - это стоимость, которая отражает баланс вложения средств в предотвращение и оценку для недопущения возникновения затрат на отказы
      - 2. Определить бюджет
        
        Определение бюджета — это процесс консолидации оценочных стоимостей отдельных операций или пакетов работ для создания авторизованного базового плана по стоимости.
        Бюджет проекта может быть структурирован по:
        ► Видам работ ► Статьям ► Отчетным периодам ► Иной структуре.
        
        Базовый план по стоимости (Cost Baseline) санкционированный распределенный по времени бюджет, по которому производится сверка, мониторинг и контроль использования денежных средств по проекту.
        ► Базовый план по стоимости - это часть общего бюджета проекта, контроль над которой получает руководитель проекта. Он включает в себя все санкционированные бюджеты, за исключением управленческого резерва.
    - - Два уровня риска в проекта
        
        Индивидуальный риск проекта - это неопределенное событие или условие, наступление которого позитивно или негативно сказывается на одной или нескольких целях проекта
        
        Совокупный риск проекта - это воздействие неопределенности на проект в целом, возникающее из любых источников неопределенности, включая индивидуальные риски, представляющие собой влияние последствий вариаций результатов проекта на заинтересованные стороны.
      - Этапы:
        
        Идентифицировать риски
        
        - Идентификация рисков — это процесс выявления рисков проекта и документирование их характеристик.
        ► Является итеративным процессом, поскольку новые риски проекта могут возникать на всем протяжении его жизненного цикла.
        
        Лица, привлекаемые к идентификации рисков
        ► руководитель проекта ► члены команды проекта ► специалист по рискам проекта (если назначен) ► заказчики ► эксперты по предметной области, не входящие в команду ► проекта ► конечные пользователи ► другие руководители проектов ► руководители производственных подразделений ► заинтересованные стороны и эксперты по управлению рисками в организации
        
        Методы идентификации рисков проекта
        ► Экспертная оценка ► Мозговой штурм ► Контрольные списки ► Интервью ► Анализ первопричины ► Анализ документов ► Совещания, фасилитации и др
        
        Иерархическая структура рисков (risk breakdown structure, RBS) - иерархическое представление потенциальных источников риска проекта
        
        Контрольный список - это перечень вопросов, действий или пунктов, которые требуется рассмотреть. Он служит памяткой. Контрольные списки разрабатываются на основе исторической информации и знаний, полученных в ходе исполнения аналогичных проектов или из других источников информации. Организация может вести контрольный список рисков на основе ее собственных завершенных проектов использовать типовые контрольные списки отрасли.
        
        Справочные списки - это предварительно составленный перечень категорий рисков, которые могут служить источниками индивидуальных рисков проекта, а также совокупного риска проекта. Основа PESTLE (политические, экономические, социальные, технологические, правовые, экологические риски) Основа TECOP (технические, экологические, коммерческие, операционные, политические риски) Основа VUCA (изменчивость, неопределенность, сложность, неоднозначность)
        
        Реестр рисков – это документ, в который вносятся подробные сведения об идентифицированных индивидуальных рисках проекта. После процесса идентификации рисков в него включаются:
        
        ► Список идентифицированных рисков
        
        ► Потенциальных владельцев риска
        
        ► Список возможных мер реагирования
        
        Провести качественную оценку рисков
        
        Качественный анализ рисков - это процесс расстановки приоритетов в отношении индивидуальных рисков проекта для дальнейшего анализа или действий, выполняемый путем оценки вероятности возникновения и воздействия рисков, а также других характеристик
        ► Качественная оценка производится по отношению ко всем идентифицированным рискам
        
        Матрица определения степени воздействия
        
        Показатели:
        Стоимость, Содержание, Сроки, Качество
        
        Влияние:
        Ничтожное 0,05, Слабое 0,1, Среднее 0,2, Сильное 0,4, Очень сильное 0,8
        
        Матрица оценки вероятности и воздействия (для угроз)
        Мера риска = Вероятность х Воздействие
        
        Карта рисков – это наглядное представление всей совокупности рисков с точки зрения их значимости и вероятности наступления
        Воздействие / Вероятность
        
        Обновления реестра рисков могут включать в себя: ► оценки вероятности и воздействия каждого индивидуального риска проекта ► уровень его приоритета или балл оценки ► назначенного владельца риска ► информацию о срочности или категоризации риска ► список отслеживания для рисков с низким приоритетом или рисков, требующих дальнейшего анализа
        
        Оценить риски количественно
        
        Количественный анализ рисков - это процесс численного анализа совокупного воздействия идентифицированных индивидуальных рисков проекта и других источников неопределенности на цели проекта в целом.
        Не требуется осуществлять данный процесс во всех проектах, но там, где он используется, он исполняется на всем протяжении проекта.
        
        Методы количественного анализа рисков
        ► Имитация. Используется модель, которая имитирует совокупное воздействие индивидуальных рисков проекта и других источников неопределенности для оценки их потенциального влияние на достижение целей проекта
        ► Анализ чувствительности. Помогает определить, какие индивидуальные риски проекта или другие источники неопределенности могут потенциально оказать наиболее сильное воздействие на конечный результат проекта
        ► Анализ дерева решений. Используется для выбора наилучшего из нескольких альтернативных путей действий.
        ► Диаграммы влияния. Представляют проект как набор объектов, результатов и влияний вместе с взаимоотношениями между ними и их влиянием друг на друга
        
        Спланировать меры реагирования на риски
        
        Стратегия эскалации
        
        Эскалация. Угроза выходит за рамки проекта или предлагаемые меры реагирования выходят за рамки полномочий менеджера проекта. Управление эскалацией рисков осуществляется на уровне программы, портфеля или другой подходящей части организации, но не на уровне проекта. После осуществления эскалации команда проекта не ведет мониторинг угрозы, переданной в порядке эскалации, хотя эта угроза может быть внесена в реестр рисков (для информации).
        
        Стратегии реагирования на негативные риски (угрозы)
        
        УКЛОНЕНИЕ
        Меры с целью устранить угрозу или защитить проект от ее воздействия. Предполагает изменение плана управления проектом или целей проекта так, чтобы полностью устранить угрозу Ликвидация причины угрозы, увеличение сроков, изменение стратегии проекта, сокращение его содержания
        
        ПЕРЕДАЧА
        Передача владения угрозой третьей стороне, которая берет на себя управление риском и несет его последствия Страхование, гарантия исполнения, гарантийные сроки, гарантийные обязательства
        
        СНИЖЕНИЕ
        Меры по снижению вероятности наступления и/или воздействия угрозы внедрение менее сложных процессов, проведение большего числа испытаний, выбор более надежного продавца, разработка прототипа
        
        ПРИНЯТИЕ
        Осознание существования угрозы без принятия проактивных мер. Активное принятие - установление резерва на возможные потери, пассивное - рассмотрение изменения состояния угрозы
        
        Вторичный и остаточный риск
        
        Остаточный риск (Residual Risk) - риск, который сохранится после запланированного реагирования, а также риск, который был принят осознанно. Для остаточных рисков используется только стратегия принятия.
        
        Вторичный риск (Secondary Risk) - риск, возникающий как прямое следствие осуществления реагирования на риски. Для вторичных рисков возможно применение различных стратегий реагирования.
        
        Реагирование на случаи возможных потерь
        
        Некоторые способы реагирования на риски используются только в случае наступления определенных событий. Команда проекта задействует план реагирования, когда имеются достаточные предупреждающие сигналы – триггеры.
        
        Такие планы называются планами на случаи возможных потерь или резервными планами и включают в себя триггерные события. Триггеры подлежат отслеживанию.
        
        Пример: триггер - срыв сроков по промежуточному контрольному событию в расписании проекта. Реагирование – работа команды проекта сверхурочно.
      - Роли по управлению рисками
        
        Менеджер проекта отвечает за общее управление рисками в проекте.
        
        Владелец риска – лицо, которые имеет полномочия и несет ответственность за управление конкретным риском и реализацию плана реагирования на риск.
      - Целями управления рисками проекта является использование или усиление влияния позитивных рисков (благоприятных возможностей) и, в то же время, избежание или смягчение последствий негативных рисков (угроз).
      - Склонность ЗС к риску
        
        Склонность к риску (Risk Appetite) – это степень неопределенности, которую хочет принять организация или отдельное лицо в предвкушении вознаграждения. Выражается как количественно измеряемые пороги рисков применительно к каждой цели проекта.
        
        Порог риска (Risk Threshold) - уровень подверженности риску, выше которого на риски реагируют, а ниже которого риски могут приниматься.
    - - Зачем. Цели и техзадание
      - Что. Качество, риски. ИСР
      - Кто. Organizational structure (OBS)
      - Кто что делает. Activity/
        ,Responsibility matrix
      - КОГДА и в КАКОЙ последовательности, Logical network
      - 6 Стоимость
      - Риски
  - - - Управление исполнением проекта
        ► Формирование команды проекта и управление ею ► Приобретение и использование ресурсов (материалов, инструментов, оборудования и др.) ► Применение запланированных методов и стандартов ► Оценка соответствия создаваемых результатов проекта требованиям заинтересованных сторон ► Выполнение плана управления проектом ► Управление рисками ► Управление изменениями ► Создание и использование каналов коммуникации ► Сбор и документирование усвоенных уроков
      - Управление изменениями в проекте
        
        Интегрированное управление изменениями
        
        Интегрированное управления изменениями – это процесс анализа всех запросов на изменения, их одобрения и управления изменениями поставляемых результатов, документов проекта и плана управления проектом, а также предоставления информации о решениях
        
        Процесс управления изменениями проводится с самого начала проекта и вплоть до его завершения.
        
        План управления проектом и другие проектные документы поддерживаются в актуальном состоянии через систему интегрированного управления изменениями.
        
        Схема интегрированного управления изменениями
        
        Идентификация потребности в изменениях, регистрация запросов на изменение
        
        Оценка влияния запрошенных изменений на цели проекта и его выполнение. Анализ альтернатив
        
        Рассмотрение запросов на изменение
        
        Внесение одобренных изменений во все необходимые документы проекта и информирование ЗС
        
        Отслеживание исполнения одобренных изменений
        
        Запрос на изменение (Change request) - это формальное предложение внести изменения в какой-либо документ, поставляемый результат или базовый план. Запрос на изменение содержит следующую информацию: ► дата запроса ► название проекта и фазы ► инициатор изменения ► описание изменения ► причины, вызвавшая необходимость изменения ► оценка влияния изменения на проект (содержание, сроки, стоимость, качество, риски, ресурсы) и др.
        
        Запросы на изменения могут включать в себя: ► Корректирующее действие (действие с целью привести исполнение работ проекта в соответствие с планом) ► Предупреждающее действие (действие, обеспечивающее соответствие будущего исполнения работ проекта плану) ► Исправление дефекта (действие с целью исправления несоответствующего требованиям продукта или его компонента) ► Обновления (изменения в формально контролируемых документах, отражающие модифицированные либо дополнительные идеи)
        
        Расползание содержания (Scope creep) – неконтролируемое увеличение/ изменение содержания продукта или проекта без учета влияния на сроки, стоимость и ресурсы.
        Расползание содержания происходит в процессе выполнения проекта и часто приводит к неудаче проекта.
        
        Причины «расползания содержания»
        ► Недостаточные или неполно выявленные требования заинтересованных сторон по проекту ► Плохое управление изменениями ► Слабый контроль со стороны руководителя проекта ► Нечеткое понимание заинтересованными сторонами их собственных требований ► Слишком много заинтересованных сторон, имеющих разные приоритеты и цели
        
        Одобрение и отклонение изменений
        
        Каждый задокументированный запрос на изменение должен быть одобрен или отклонен каким-либо уполномоченным лицом из команды управления проектом или сторонней организации, например: ► Руководителем проекта (в пределах делегированных ему полномочий) ► Советом по управлению изменениями (change control board) ► Спонсором ► Заказчиком
        Распределение полномочий по одобрению запросов на изменения в проекте должны быть четко определены и зафиксированы.
        
        Совет по контролю изменений (Сhange control board, CCB) формально созданная группа, ответственная за изучение, оценку, одобрение, отсрочку или отклонение внесения изменений в проект, а также за фиксацию соответствующих решений и информирование о них всех заинтересованных сторон
    - - Методы балансирования проекта
        
        Выполнить повторную оценку проекта, пересмотреть оценки
        
        Изменить распределение работ между исполнителями, перебросить ресурсы на выполнение работ, находящихся на критическом пути; использовать на этих работах высококвалифицированных специалистов
        
        Увеличить количество исполнителей проекта
        
        Сократить функциональные возможности (содержание) продукта.
        
        Передать часть работ сторонним организациям, использовать услуги внешних подрядчиков
        
        Использовать работы в сверхурочное время
        
        Использовать инструменты повышения производительности (например, совершенствование процессов управления проектами)
        
        Передавать продукт заказчику поэтапно
        
        Перенести работы в организацию заказчика
  - - - Мониторинг и контроль работ проекта
        
        ► сравнение фактического исполнения проекта с планом управления проектом
        ► периодическая оценка исполнения для определения необходимости корректирующих или предупреждающих действий
        ► проверка статуса отдельных рисков проекта
        ► поддержание точной, своевременно обновляемой информации относительно продукта проекта и сопутствующей документации
        ► предоставление информации для составления отчетов о статусах, проведения измерений исполнения и прогнозирования
        ► предоставление прогнозов, позволяющих обновлять информацию о текущей стоимости и текущем расписании
        ► мониторинг реализации одобренных изменений
        ► предоставление соответствующих отчетов об исполнении и статусе проекта руководству программы (если проект является ее частью)
        ► обеспечение согласованности проекта с бизнес-потребностями компании
        
        Метод освоенного объема. Прогнозы до завершения
        
        Метод освоенного объема (Earned Value method) – способ измерения и анализа выполнения проекта по содержанию, расписанию и стоимости
        
        Для каждого пакета работ осуществляется расчет следующих трех показателей:
        
        Плановый объем (Planned Value, PV) – бюджетная стоимость работ, запланированных к выполнению на определенный момент времени
        PV = План объем * План цена
        
        Фактическая стоимость (Actual Cost, AC) – фактически понесенные затраты на выполнение работ на определенный период времени
        АС = Факт объем * Факт цена
        
        Освоенный объем (Earned Value, EV) – бюджетная стоимость фактически выполненного объема работ на определенный момент времени
        EV = Факт объем * План цена
        
        :Отклонения исполнения расписания и стоимости
        
        Отклонение по стоимости (Cost Variance) = Освоенный объем – Фактическая стоимость
        
        Индекс выполнения стоимости (Cost performance index) = Освоенный объем / Фактическая стоимость
        
        Индекс исполнения стоимости - используется для прогнозирования бюджета до завершения проекта
        
        Отклонение по расписанию (Schedule variance) = Освоенный объем - Плановый объем
        
        Индекс выполнения расписания (Schedule performance index) = = Освоенный объем / Плановый объем
        
        Индекс исполнения расписания - используется для
        прогнозирования сроков окончания проекта
        
        Оценка отклонений
        
        Отклонение по стоимости (Cost Variance, CV): если отклонение >0 – экономия средств, <0 – перерасход средств
        
        Индекс исполнения стоимости (Cost Performance Index, CPI):
        если индекс >1 – экономия средств, <1 – перерасход средств
        
        Отклонение по расписанию (Schedule Variance, SV): если
        отклонение >0 – опережение графика, <0 – отставание от графика
        
        Индекс исполнения расписания (Schedule Performance Index, SPI): если индекс > 1 – опережение графика,
      - Правила 8/ 80 и отчетного периода
        
        Правило 8/ 80: ни одна операция проекта не должна иметь продолжительность меньше 8 часов и больше 80 часов. ► 8 = 1 рабочий день х 8 часов ► 80 = 2 недели х 5 рабочих дней х 8 часов
        
        Правило отчетного периода: выполнение ни одной операции не должно занимать времени больше, чем два отчетных периода. Иными словами, если совещания идут раз в неделю, то максимальная продолжительность работы – 2 недели (80 часов).
        
        Два этих правила позволяют применять грубые трехуровневые шкалы для оценки выполнения проекта: ► 0% (операция не начата) ► 50% (операция выполняется) ► 100% (операция выполнена) При соответствующей декомпозиции (8/ 80) ни одна операция не может иметь статус «выполняется» на двух идущих последовательно друг за другом совещаниях по прогрессу проекта. Правила 8/ 80 и отчетного периода - альтернативная шкала оценивает выполнение в 20% при статусе операции «выполняется». Такая шкала считается более стимулирующей.
      - Прогнозы стоимости проекта
        
        После анализа выполняются 2 вида прогнозов:
        ► Прогноз до завершения (Estimate to completion, ETC) – скорректированная оценка стоимости работ, оставшихся до завершения проекта
        ► Прогноз по завершении (Estimate at completion, EAC) – скорректированная оценка ожидаемой стоимости всего проекта
        
        EAC = ETC + AC
        
        Варианты разработки прогноза до завершения (EТC)
        
        Оставшиеся работы будут заново оценены «снизу вверх»: ЕTС = Прогноз «снизу вверх» (ETC «bottom-up»)
        
        Оставшиеся работы будут выполнены по заложенным в бюджет значениям (причины, вызвавшие отклонения стоимости, были нетипичны): ETC = Бюджет проекта (BAC) – Освоенный объем (EV)
        
        Оставшиеся работы будут выполнены с текущим CPI (причины, вызвавшие отклонения стоимости были типичны): ETC = (Бюджет проекта (BAC) – Освоенный объем (EV)) / Индекс исполнения стоимости (СPI)
    - - Содержание отчетности по исполнению
        
        ► Анализ прошлой деятельности
        
        ► Текущий статус рисков проекта
        
        ► Работы, выполненные за отчетный период
        
        ► Работы, подлежащие завершению в плановом периоде
        
        ► Одобренные за отчетный период изменения
        
        ► Результаты анализа отклонений
        
        ► Прогнозы до завершения проекта
        
        ► Другая уместная информация, которая должна оговариваться заранее
      - Виды отчетов
        ► Отчет о статусе (измерение текущего состояния проекта по сравнению с базовым планом)
        ► Отчет о прогрессе (выполнение проекта за отчетный период)
        ► Отчет о тенденциях (исследование результатов проекта во времени для оценки динамики исполнение проекта)
        ► Прогноз (ожидаемые результаты проекта)
        ► Отчет об отклонениях (отклонения фактических результатов от базового плана)
        ► Отчет об освоенном объеме (оценка выполнения проекта методом освоенного объема).
  - - - Действия, необходимые для удовлетворения критериев завершения или выхода из проекта (или фазы)
      - Мероприятия по сбору документов, аудиторской проверке, извлечению уроков, архивированию документов
      - Сбор предложений по совершенствованию политик и процедур организации
      - Мероприятия, связанные с завершением договорных соглашений (приемка результатов, урегулирование претензий)
      - Действия по передаче продуктов проекта в следующую фазу или операционную деятельность
      - Измерение удовлетворенности заинтересованных сторон
    - - 1 Определить ответственных в рамках операционной деятельности
      - 2 Передать опыт проектной команды сотрудникам операционной деятельности (провести обучение)
      - 3 Уточнить формальные результаты проекта. Они должны быть понятны сотрудникам операционной деятельности
      - 4 Согласовать процесс мониторинга и контроля в рамках операционной деятельности, определить контрольные точки
      - 5 Определить возможные риски
      - 6 Обеспечить непрерывное управление процессом после завершения проекта
    - - Потери компании от неуспешных проектов ► Потерянные деньги, ресурсы ► Упущенное время ► Упущенные возможности ► Деморализованные сотрудники компании ► Репутационные потери.
      - Анализ «усвоенных уроков»
        
        Усвоенные уроки (lessons learned) – это структурированная информация и формализованные знания о проблемах и решениях, принятых в проектах.
        
        Практика анализа «усвоенных уроков» позволяет формально зафиксировать произошедшие в прошлом события, допущенные ошибки, возникшие проблемы и использованные методы их преодоления для того, чтобы минимизировать риски, связанные с реализацией проектов в будущем.
- - - - Низкая
        
        Высокая
    - - Низкая
        
        Высокая
    - - Процесс
      - Задача
      - Проект
  - - - ► Обучение лучшим практикам управления проектами (процессы, методы, инструменты)
      - ► Формирование единой профессиональной терминологии
      - ► Разработка квалификационных и сертификационных требований к проектному персоналу
      - ► Содействие при подборе, оценке и развитии проектного персонала
      - ► Оценка уровня зрелости проектного управления в компании и помощь в его повышении.
    - - ► Международные
      - ► Национальные
      - ► Отраслевые
      - ► Корпоративные
    - - Институт управления проектами США
        (Project Management Institute, PMI)
      - Международная организация по стандартизации (International Organization for Standadization – ISO), Швейцария
      - Правообладатель - Cabinet Office, Великобритания
      - Ассоциация проектных менеджеров Японии (Project Management Association of Japan - PMAJ)
      - Международная ассоциация управления проектами (International Project Management Association - IPMA), Швейцария
      - Российская Национальная ассоциация
        управления проектами «СОВНЕТ».