Недавно я завершила обучение на курсе от Google по программе Управление проектами Поэтому я решила подготовить цикл из шести статей, в которых постараюсь передать ключевые идеи курса для русскоязычной аудитории.
Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:
Основы управления проектами (Foundations of Project Management)
Инициация проекта: запуск успешного проекта (Project Initiation: Starting a Successful Project)
Планирование проекта: объединяя всё воедино (Project Planning: Putting It All Together)
Исполнение проекта: реализация на практике (Project Execution: Running the Project)
Agile‑управление проектами (Agile Project Management)
Итоговый проект: применение управления проектами в реальном мире (Capstone: Applying Project Management in the Real World)
Надеюсь, этот материал поможет вам получить базове представление об основах управления проектами и применять полученные знания в реальных задачах на работе, учебе и в жизни. В комментариях буду рада обсудить подходы к управлению проектами и узнать о вашем опыте.
Приятного чтения!
Планирование: Собираем все воедино
Данный курс, являющийся третьей частью программы сертификации Google Project Management, посвящен фазе планирования проекта.
Вы научитесь:
Запускать фазу планирования.
Устанавливать контрольные точки и распределять нагрузку.
Составлять и управлять бюджетом (включая документацию).
Идентифицировать и снижать риски проекта.
Разрабатывать коммуникационный план и вести проектную документацию.
Полезные ресурсы
https://docs.google.com/document/d/101xnQbFiwhFMBgq5C72yXeJy8I21u_YMHxqrNKDEpRM/template/preview
https://docs.google.com/spreadsheets/d/1EfGDZKDxeuEzhcfwNCZAFQck_87-FRCtRrcZVkWGltI/template/preview
https://www.workamajig.com/blog/critical-path-method
https://www.wrike.com/blog/critical-path-is-easy-as-123/
https://www.lucidchart.com/blog/how-to-create-a-work-breakdown-structure-and-why-you-should
https://www.smartsheet.com/content/project-plan-templates
https://www.smartsheet.com/free-google-docs-templates-google-timeline-templates
https://docs.google.com/document/d/101xnQbFiwhFMBgq5C72yXeJy8I21u_YMHxqrNKDEpRM/template/preview
https://docs.google.com/spreadsheets/d/1TauRTFipsWDWGqaw6tmqJeknKhVI5IjR5jJvBfVzfGw/template/preview
https://asana.com/guide/videos/anatomy-of-projects-and-tasks-chapter
https://www.atlassian.com/software/jira/guides/getting-started/basics
https://docs.google.com/spreadsheets/d/1DuY4viZtcjPzhdC1EotnJMxLd61v0eYNkRtJwHGww8U/template/preview
https://docs.google.com/spreadsheets/d/1xsUJeRBDkoGuwrLMSQ1R2FEnlHnlfNzCkRLKkLTjSWw/template/preview
https://docs.google.com/document/d/1TA55da0QI6aJousn5sLzOzN0X-Tcx5iwUaWmnOoUj50/template/preview
https://www.projectmanager.com/blog/risk-management-process-steps
Фаза планирования проекта: От ключевых точек до задач и успешного старта
Фаза планирования — это второй и один из самых важных этапов жизненного цикла проекта. На этом этапе закладывается фундамент для успешной реализации, определяя график, бюджет и план управления рисками.
Почему планирование так важно?
Планирование необходимо для любого проекта, независимо от его масштаба. Оно обеспечивает:
Чёткое понимание объёма работы: Помогает определить все необходимые действия для достижения целей проекта.
Эффективную координацию: Синхронизирует усилия команды, подрядчиков и поставщиков.
Управление рисками: Позволяет заранее выявить потенциальные проблемы (задержки, уход ключевых сотрудников, изменение направления) и разработать стратегии их смягчения.
Вовлечённость команды: Гарантирует поддержку со стороны ключевых участников.
Доверие заинтересованных сторон: Демонстрирует серьёзный и продуманный подход к проекту.
Формирование сильной команды: Совместное планирование способствует сплочению коллектива.
Запуск фазы планирования
На этом этапе создаётся прочная основа для всего проекта. Три ключевых элемента, которые определяются:
График: Подробная временная шкала проекта с датами начала, завершения и промежуточными этапами. Для её составления используются методы оценки времени.
Бюджет: Общая стоимость проекта, разбитая на отдельные статьи расходов.
План управления рисками: Выявление потенциальных проблем и разработка стратегий для их предотвращения или минимизации воздействия. Цель — предвидеть, где график может сместиться или бюджет превысить оценки.
Встреча по запуску проекта (Kick-off Meeting)
Встреча по запуску проекта — это официальное начало фазы планирования. На ней команда, заинтересованные стороны и спонсор собираются, чтобы:
Сформировать единое видение проекта.
Достичь общего понимания целей и объёма работ.
Определить индивидуальные роли каждого участника.
Кто участвует: Все члены команды, заинтересованные стороны и спонсор проекта.
Зачем нужна: Встреча позволяет установить общее видение, согласовать объём работ, создать командный дух, дать возможность задать вопросы и установить ожидания по вкладу каждого.
Как провести эффективную встречу:
Оптимальное время и длительность: Выбрать удобное для всех время (до 1 часа), учитывая часовые пояса.
Правильные участники: Приглашать только тех, кто непосредственно участвует в реализации проекта.
Назначение ответственного за записи: Пока вы ведёте встречу, кто-то другой должен фиксировать ключевые моменты и пункты действий.
Подготовка и рассылка повестки дня: Заранее отправьте повестку участникам.
Соблюдение повестки: Держите обсуждение в рамках намеченных тем.
Последующие действия: После встречи отправьте письмо с резюме, ключевыми решениями и пунктами действий.
Пример структуры повестки:
Вступления: Знакомство участников и их ролей.
Обзор проекта: Краткая история, значимость, общее видение.
Цели и объём: Чёткое определение границ проекта, важные даты, ключевые этапы.
Роли и обязанности: Уточнение ответственности каждого.
Сотрудничество и инструменты: Методы совместной работы и каналы связи.
Дальнейшие шаги и ожидания: Ближайшие действия для команды.
Вопросы и обсуждение: Время для вопросов, обратной связи и оценки уверенности команды.
Основные контрольные точки проекта и задачи
Для эффективного отслеживания прогресса используются основные контрольные точки и задачи.
Основная контрольная точка проекта (Key Control Point): Важная точка в расписании, обозначающая прогресс и завершение значимого результата или фазы проекта (например, утверждение дизайна сайта, завершение первого черновика отчёта).
Задача проекта (Task): Конкретное действие, которое необходимо выполнить в установленный срок. Множество задач ведут к достижению одной основной контрольной точки.
Почему основные контрольные точки важны:
Ясность объёма работы: Разделение проекта на управляемые части.
Контроль графика: Помогают убедиться, что проект движется в нужном темпе.
Выявление корректировок: Позволяют обнаружить необходимость изменения объёма, сроков или ресурсов.
Мотивация команды: Достижение основных контрольных точек мотивирует команду и демонстрирует прогресс заинтересованным сторонам.
Основные контрольные точки должны завершаться в срок и в определённой последовательности, так как часто одна контрольная точка зависит от завершения предыдущей.
Установка основных контрольных точек и детализация задач
Оценка проекта: Определите главную цель и составьте список всех необходимых действий. Крупные пункты — это основные контрольные точки, мелкие — задачи.
Назначение сроков: Присвойте каждой основной контрольной точке реалистичный срок, учитывая время, необходимое для выполнения всех связанных задач, и ожидания заинтересованных сторон.
Для детализации задач используется Иерархическая структура работ (Work Breakdown Structure, WBS). Это инструмент, который организует основные контрольные точки и задачи в иерархическом порядке выполнения. WBS помогает разбить сложный проект на управляемые части.
Как создать WBS:
Начните с общей картины: Определите основные результаты и ключевые этапы.
Детализируйте основные контрольные точки в задачи: Разбейте каждую основную контрольную точку на конкретные задачи.
Разбейте задачи на подзадачи: Если задача большая, разделите её на более мелкие подзадачи.
Хотя WBS обычно не включается в официальный план как диаграмма, информация из него переносится в таблицы или ПО для управления проектами.
Назначение задач
После создания WBS и детализации задач необходимо назначить ответственных. Это даёт чёткое понимание следующих шагов и основу для распределения обязанностей.
Как назначать задачи:
По роли: Распределяйте задачи в соответствии с ролью человека в проекте.
Учитывая опыт: Если несколько членов команды имеют схожие роли, учитывайте их опыт в конкретных задачах.
Баланс нагрузки: Равномерно распределяйте задачи, чтобы никто не был перегружен. Перегрузка может снизить качество работы и вызвать задержки.
Инструменты для назначения задач: Используйте программы для управления проектами (например, Asana).
Чёткие формулировки: Начинайте каждую задачу с глагола («Разработать макет», «Добавить изображения»).
Сроки и ответственные: Указывайте, кто и к какому сроку должен выполнить задачу.
Подробности: Добавляйте максимум деталей для предотвращения недопониманий (описания, ссылки на файлы).
Преимущества назначения задач:
Сфокусированность руководителя: Позволяет руководителю сосредоточиться на управлении проектом в целом.
Личная ответственность: Создаёт чувство сопричастности и ответственности у членов команды.
Развитие навыков: Предоставляет возможности для профессионального роста.
Мотивация: Поддерживает команду в выполнении работы в срок.
Создание и управление планом проекта.
Зачем нужен план проекта?
План проекта необходим для:
Документирования объёма работ, задач, ключевых этапов и общей деятельности.
Оценки времени, необходимого на выполнение проекта.
Отслеживания прогресса команды относительно поставленных целей.
Основные элементы плана проекта
Хотя детали могут различаться, большинство планов включают пять базовых элементов:
Задачи (Tasks): Действия, выполняемые в определённый срок, распределённые между членами команды в соответствии с их ролями и навыками.
Основные контрольные точки (Milestones): Важные этапы в графике, указывающие на прогресс и обычно означающие завершение значимого результата или фазы проекта.
Команда (People): Список участников проекта и их роли. Важно, чтобы каждый понимал свои обязанности.
Документация (Documentation): Ссылки на важные документы, такие как устав проекта (определяет цели и детали), RACI-матрица (определяет роли и обязанности), бюджет и план управления рисками.
Время (Time): Оценочное время, необходимое на проект, включая даты начала и завершения задач, контрольных точек, а также всего проекта.
Как связаны компоненты плана проекта?
План проекта — это живой документ, служащий дорожной картой для команды. Его компоненты взаимосвязаны:
График проекта: Находится в центре плана, помогает оценить время и отслеживать прогресс.
Объём и цели проекта: Изначально определяются в уставе проекта, ссылки на который должны быть в плане. Это напоминает команде о целях и границах проекта.
Иерархическая структура работ (WBS): Инструмент, упорядочивающий основные контрольные точки и задачи. В плане проекта задачи должны быть видны в одном месте с описанием, ответственными и сроками.
Бюджет: Управляется и отслеживается на протяжении всего проекта. Часто связан с планом проекта из-за зависимости от ключевых элементов.
Планы управления: Включают план управления изменениями, рисками, коммуникациями. Их также следует ссылаться в плане проекта.
Оценка времени и усилий
Оценка времени — это прогноз общей продолжительности задачи от начала до конца, включая «неактивное» время (например, время не только стирки вещей, развешивания, но и сушки). Оценка усилий — это прогноз количества и сложности активной работы, необходимой для выполнения задачи человеком.
Важно различать эти понятия для эффективного использования ресурсов. Если в задаче есть неактивное время, исполнитель может в это время заниматься другими делами.
Пример: Покраска стены может потребовать 30 минут активных усилий, но 24 часа по времени (из-за сушки). В период сушки маляр может выполнять другие работы.
Оптимизм может привести к недооценке усилий и негативно сказаться на графике. Чтобы избежать этого, общайтесь с исполнителями задач. Они лучше всех понимают необходимый объём работы и могут дать наиболее точную оценку.
Использование буферов(закладывание дополнительного времени на форсмажоры, как буферная зона) для защиты от задержек
Даже точные оценки могут быть нарушены. Для защиты от этого используются буферы — дополнительное время, добавляемое в конце задачи или проекта для учёта неожиданных задержек.
Существуют два типа буферов:
Буферы задач: Дополнительное время, добавленное к конкретной задаче, особенно для тех, что находятся вне контроля команды (например, ожидание ответа от поставщика). Их следует использовать умеренно для задач, находящихся под контролем команды, чтобы избежать ненужного удлинения графика.
Буферы проекта: Дополнительное время, добавляемое к общему графику проекта (например, 2–3 дня в конце проекта), которое можно использовать по мере необходимости в течение всего проекта для компенсации мелких задержек.
Цель — создать реалистичный график. Недооценка времени и усилий может привести к срыву сроков и негативно сказаться на успехе проекта.
Планирование ресурсов и «критический путь»
После оценки времени необходимо определить, достаточно ли у вас ресурсов (людей) для выполнения работы.
Планирование ресурсов/мощностей — это процесс распределения людей и ресурсов по задачам проекта, а также определение достаточности ресурсов для своевременного завершения работы. Оно помогает понять, нужно ли привлекать дополнительные ресурсы.
Для эффективного использования ресурсов/мощностей определяется критический путь.
Критический путь — это последовательность основных контрольных точек и обязательных задач, которые необходимо выполнить, чтобы уложиться в срок проекта. Это «скелет» проекта, задержка любой задачи на критическом пути напрямую задержит завершение всего проекта.
Как определить критический путь:
Собрать все задачи: Используйте WBS, чтобы зафиксировать все необходимые задачи. Сосредоточьтесь на задачах типа «обязательно сделать», а не «желательно сделать».
Установить зависимости: Определите, какие задачи должны быть завершены до начала других (последовательные задачи) и какие могут выполняться параллельно.
Последовательные задачи: Выполняются строго одна за другой (например, сначала утверждение бюджета, потом найм поставщика).
Параллельные задачи: Могут выполняться одновременно (например, найм водителей и разработка сайта).
Создать сетевую диаграмму: Визуализируйте задачи и их зависимости, чтобы увидеть путь от начала до конца проекта.
Оценить время: Согласуйте с заинтересованными сторонами точные оценки длительности для каждой задачи.
Найти самый длинный путь: Самый длинный путь через сетевую диаграмму, состоящий из задач с нулевым резервом времени (float/slack), является критическим путём. Задачи на критическом пути не имеют запаса по времени — любая задержка влияет на весь проект.
Методы расчета критического пути: Прямой и обратный проход
Для более точного определения критического пути и управления гибкостью графика используются методы прямого и обратного прохода. Они полезны для определения ранних и поздних сроков начала задач, а также для расчета резерва времени (slack) — допустимого времени задержки задачи без влияния на общий срок проекта.
Прямой проход (Forward Pass): Начинается с первой задачи в списке и движется к концу проекта, суммируя продолжительность задач на критическом пути. Этот метод помогает определить самые ранние даты начала и завершения каждой задачи, исходя из зависимостей.
Обратный проход (Backward Pass): Движение начинается с конечной задачи или ключевой контрольной точки проекта и идёт в обратном направлении по графику. Этот подход позволяет определить самые поздние даты начала и завершения каждой задачи, при которых не будет нарушен общий срок проекта. При наличии жёстких дедлайнов обратный проход помогает выявить, какие задачи действительно критичны и, возможно, от каких задач можно отказаться или выполнить их позднее, чтобы уложиться в срок.
Факторы, влияющие на планирование:
Параллельные и последовательные задачи: Идентификация этих типов задач помогает оптимизировать график.
Фиксированные даты начала: Некоторые задачи должны начаться в определённый день для достижения цели.
Ранние возможные даты начала: Самая ранняя дата, когда можно начать задачу, помогает планировать ожидания, например, для новых поставщиков.
Резерв времени (Float/Slack): Время, на которое можно отложить задачу, не влияя на общий срок проекта. Задачи на критическом пути имеют нулевой резерв.
Анализ ошибок планирования (кейс-стади)
Неточные оценки времени часто являются причиной провалов проектов. Пример: менеджер торопится с планированием и не привлекает команду, что приводит к нереалистичным срокам. Это вызывает задержки, переделки, стресс у команды и срыв сроков.
Уроки из ошибок:
Вовремя эскалировать проблемы: Если сроки кажутся нереалистичными, сообщите об этом руководству, подкрепив свои опасения данными.
Тщательное планирование: Продумайте каждый этап, чтобы создать реалистичный план. Возможно, удастся устранить ненужные задачи, запросить дополнительные ресурсы или оптимизировать процессы.
Привлекать команду: Вовлекайте команду и заинтересованные стороны в процесс планирования и учитывайте их опасения.
Преодоление ошибки планирования (Planning Fallacy)
Ошибка планирования — это человеческая склонность недооценивать время, усилия, затраты и риски, необходимые для выполнения задачи, из-за оптимистического смещения. Мы склонны верить, что негативные события маловероятны для нас.
Даже опытные менеджеры могут столкнуться с этой ошибкой. Важно быть «оптимистично реалистичным»: стремиться к лучшим результатам, но при этом закладывать достаточно времени на выполнение каждой задачи.
Как избежать ошибки планирования:
Ищите «что если»: Продумывайте ситуации, которые могут повлиять на сроки проекта (погода, болезни, непредвиденные проблемы).
Используйте команду как ресурс: Привлекайте команду для выявления потенциальных рисков и корректировки оценок. Для получения точных оценок при планировании от команды менеджеру необходимо задействовать «мягкие навыки» (soft skills) — личные качества, помогающие эффективно взаимодействовать с людьми.
Применение «мягких навыков» для точных оценок
Три ключевых подхода для получения точных оценок:
Задавать правильные вопросы:
Рассматривайте разговор как интервью, цель которого — понять особенности работы над задачей и стиль работы коллеги.
Используйте открытые вопросы, на которые нельзя ответить «да» или «нет». Они побуждают к развёрнутым ответам.
Пример: Вместо «Сможешь сделать макеты за неделю?» спросите «Сколько времени обычно занимает создание макета такого дизайна?». Затем уточняйте: «Насколько сложны этапы выполнения этой задачи?», «Какие риски связаны с этой задачей?», «Когда, по твоему мнению, это будет готово?».
Со временем, практикуясь в таких беседах, менеджер будет лучше понимать роли и задачи команды, и сможет меньше полагаться на неё в вопросах оценки.
Эффективно вести переговоры:
Задача менеджера — объединить высокоуровневые цели проекта с повседневной работой команды.
У членов команды могут быть другие приоритеты. Эффективные переговоры помогают влиять на выбор приоритетов, находя решения, которые устроят всех.
Пример: Если дизайнер оценил макеты в две недели, а вы рассчитывали на одну, задайте уточняющие вопросы: «Включает ли оценка макеты для нескольких страниц?», «Можешь ли показать одну‑две страницы раньше предложенного срока?». Это поможет понять гибкость оценки или потребность в дополнительных ресурсах.
Эффективные переговоры создают чувство общей ответственности за результат и позволяют составить график, соответствующий реальной загрузке каждого.
Проявлять эмпатию:
Эмпатия — это способность сопереживать чувствам и мыслям других. На работе это помогает строить доверительные отношения.
Учитывайте, что каждый человек имеет ограниченные возможности. Обсуждая оценки, спрашивайте о общей рабочей нагрузке коллеги, включая задачи вне вашего проекта, и об их балансе между работой и личной жизнью.
Уточняйте планы на отпуск или нерабочие дни (праздники). Это поможет избежать назначения задач на время, когда коллеги не смогут их выполнить.
Пример: Если дизайнер также работает над сайтом для другой команды, можно договориться с другим менеджером о балансировке загрузки.
Всегда проявляйте благодарность за работу, сотрудничество и поддержку, демонстрируя, что их вклад ценится.
Применение этих «мягких навыков» помогает получать надёжные и точные оценки задач от команды, что является основой для успешного планирования проекта.
Как создать эффективный план проекта: Инструменты
Расписание проекта: Диаграмма Ганта
Диаграмма Ганта — полезный инструмент для расписания. Это горизонтальная гистограмма, которая визуализирует ход проекта. Она показывает задачи, ответственных и сроки, помогая понять работу и взаимосвязи.
Как сделать диаграмму Ганта в таблице:
Организуйте столбцы по:
Названию задачи
Исполнителю
Дате начала/завершения
Длительности
Проценту выполнения
Справа укажите недели, а полосы — это даты выполнения задач.
Преимущества таблиц для плана:
Можно добавить другие документы (RACI, устав проекта, планы рисков).
Все в одном месте — экономит время и помогает оставаться организованным.
Альтернативы:
Цифровой документ со списком задач.
Канбан-доски (для Agile): визуальное отслеживание задач карточками.
Что обязательно включить в план:
Цели проекта
Задачи
Исполнители
Даты начала и окончания
Планировочная документации
Управление бюджетом проекта: основы
В мире управления проектами бюджет — это не просто цифры, это ключевой инструмент для достижения целей, эффективной коммуникации со стейкхолдерами и контроля над расходами. Он создается на этапах инициации и планирования, но требует постоянного пересмотра и контроля на протяжении всего жизненного цикла проекта.
Что такое бюджет проекта?
Бюджет проекта — это оценка денежных ресурсов, необходимых для достижения целей и задач проекта. Он включает все потенциальные и прогнозируемые затраты, необходимые для завершения проекта. Бюджет детализируется по контрольным точкам и задачам, показывая связанные с ними расходы, и служит прогнозом затрат на определенный период.
Важность бюджета
Инструмент коммуникации: Бюджет четко показывает заинтересованным сторонам, что и когда необходимо.
Метрика успеха: Соответствие бюджету является показателем успешности проекта.
Финансовая жизнеспособность: Бюджет напрямую влияет на финансовое состояние компании.
Основа для будущих проектов: Точное расходование средств помогает обосновать бюджеты для следующих проектов.
Создание и управление бюджетом
Начальная оценка: Бюджет создается на этапе инициации, но он будет корректироваться по мере развития проекта.
Утверждение расходов: Важно знать политику компании в отношении утверждения расходов и кто имеет право на подписание.
Сотрудничество: Менеджер проекта тесно сотрудничает с командой для оценки затрат. Спонсор проекта или ключевые стейкхолдеры утверждают и при необходимости корректируют оценки.
Приоритезация: Необходимо расставлять приоритеты в распределении средств для достижения максимальной отдачи.
Компоненты бюджета
Бюджет проекта должен учитывать множество факторов:
Потребности заинтересованных сторон: Понимание ожиданий стейкхолдеров в отношении стоимости для обеспечения прибыльности.
Непредвиденные расходы (Contingency Budget / Резервный фонд): Деньги, заложенные на покрытие потенциально непредвиденных событий, не учтенных в первоначальной смете.
Стоимость ресурсов (Resource Cost Rates): Затраты на рабочую силу, инструменты, оборудование, материалы и программное обеспечение.
Анализ резервов (Reserve Analysis): Метод проверки оставшихся ресурсов проекта и определения необходимости добавления буферных средств.
Стоимость качества (Cost of Quality): Все затраты, понесенные для предотвращения проблем с продуктами, процессами или задачами (включая затраты на предотвращение, оценку, внутренние и внешние сбои).
Пересмотр и перепрогнозирование (Review and Reforecasting): Регулярный пересмотр бюджета и создание новой версии на основе текущих показателей проекта. Это позволяет перераспределять средства между категориями при необходимости.
Практики бюджетирования
Используйте исторические данные: Анализируйте бюджеты прошлых аналогичных проектов.
Привлекайте команду и наставников: Получайте дополнительный «свежий взгляд» на свои расчеты.
Разбивайте бюджет по времени (Time‑Phased Budgeting): Распределяйте затраты по временной шкале, чтобы отслеживать и сравнивать плановые и фактические расходы.
Тщательная проверка: Убедитесь в точности и отсутствии ошибок, так как бюджет часто требует утверждения финансовым или высшим руководством.
Категоризируйте затраты: Различайте прямые затраты (непосредственно связанные с проектом: зарплаты, материалы, оборудование) и косвенные затраты / накладные расходы (непрямые, но необходимые: административные расходы, коммунальные услуги, страховка).
Разработайте базовый бюджет (Baseline Budget): Утвержденная начальная смета, с которой сравниваются фактические показатели. При существенных изменениях может потребоваться «перебазирование» (re‑baselining).
Анализ рисков: Используйте анализ резервов для учета буферных средств.
Управление и Контроль Бюджета Проекта
Мониторинг бюджета: Регулярный мониторинг бюджета критически важен для проектного менеджера, чтобы обеспечить финансовую и операционную подотчетность. Это позволяет убедиться, что запланированные действия реализуются.
Контрольные точки: Контрольные точки (milestones) в графике проекта являются отличной возможностью для пересмотра бюджета и внесения необходимых корректировок. Они также могут служить точками для оплаты, особенно в фиксированных контрактах.
Контроль затрат (Cost control): Это проактивная практика, при которой менеджер проекта выявляет потенциальные факторы, влияющие на бюджет, и разрабатывает действия для минимизации отклонений. Проактивное управление бюджетом всегда лучше, чем реактивное.
План утверждений: Необходимо установить план утверждений (sign-off plan) для табелей учета рабочего времени подрядчиков/поставщиков и счетов. Все изменения в бюджете должны быть согласованы, и траты должны быть предварительно утверждены стейкхолдерами или спонсором проекта.
Управление отклонениями бюджета: Необходимо заранее согласовать со спонсорами и стейкхолдерами допустимый лимит перерасхода бюджета (например, 1% или 10%).
Перерасход бюджета (Over budget): Означает, что у компании будет меньше средств для других сфер деятельности.
Недорасход бюджета (Under budget): Несмотря на кажущуюся привлекательность, это часто свидетельствует о неточной первоначальной оценке. Это может указывать на то, что можно было бы потратить больше на проект для улучшения качества или ресурсов, а также может привести к урезанию бюджетов будущих проектов, так как компания будет ожидать аналогичного «экономии».
Преодоление проблем бюджетирования
1. Предварительное выделение бюджета (Budget Pre‑allocation): Иногда бюджет устанавливается до начала проекта. В таких случаях важно работать с заказчиком, чтобы согласовать объем и результаты проекта в рамках выделенного бюджета, что требует детального планирования и тщательного отслеживания всех расходов.
2. Неточный расчет Общей Стоимости Владения (Total Cost of Ownership — TCO): TCO учитывает все расходы, связанные с продуктом или услугой на протяжении всего их жизненного цикла, а не только первоначальные затраты, но вторичные (например, обслуживание, лицензии, гарантии, расходные материалы, обновления). Недооценка TCO может привести к неожиданным расходам.
3. Расползание объема работ (Scope Creep): Изменения или расширение объема проекта после его начала приводят к дополнительной незапланированной работе и, как следствие, к перерасходу бюджета. Причины включают:
Нечеткое описание работ (Statement of Work — SoW).
Недокументированные соглашения
Нереалистичные сроки
Запросы от приоритетных стейкхолдеров в последнюю минуту.Своевременное устранение этих факторов на этапе планирования помогает предотвратить «расползание объема».
Ключевые термины бюджетирования
Денежный поток (Cash Flow): Приток и отток денежных средств в проекте. Важно отслеживать его, чтобы обеспечить достаточное финансирование для выполнения проекта.
CAPEX (Capital Expenses — Капитальные затраты): Крупные, долгосрочные, первоначальные расходы организации на активы (здания, оборудование, транспорт). Направлены на создание будущих выгод.
OPEX (Operating Expenses — Операционные затраты): Краткосрочные, текущие расходы, необходимые для повседневной деятельности (зарплата, аренда, коммунальные услуги).
Резервы на непредвиденные расходы (Contingency Reserves): Средства, добавляемые к расчетной стоимости проекта для покрытия выявленных рисков (также называются «буферами»). Сумма определяется в процессе управления рисками.
Управленческие резервы (Management Reserves): Средства, выделяемые для покрытия невыявленных рисков. Обычно составляют 5–10% от общей стоимости проекта, зависят от его сложности. Для их использования обычно требуется одобрение спонсора проекта.
Управление закупками (Procurement) в проектах
Что такое закупки? Закупки (procurement) — это процесс получения всех необходимых материалов, услуг и ресурсов для завершения проекта. Это включает в себя не только физические товары, но и услуги внешних специалистов или компаний, называемых поставщиками (vendors). Управление поставщиками (vendor management) по сути является закупками для отдельных лиц или компаний, предоставляющих специализированные услуги, которых нет внутри вашей организации.
Этапы процесса закупок: Процесс закупок обычно состоит из пяти этапов:
Инициирование (Initiating): Планирование того, какая внешняя помощь потребуется для достижения целей проекта, и обоснование необходимости этих дополнительных ресурсов.
Выбор (Selecting): Определение необходимых ресурсов и выбор подходящих поставщиков.
Составление контракта (Contract Writing): Разработка, рассмотрение и подписание контрактов.
Контроль (Controlling): Осуществление платежей, управление логистикой и требованиями для поддержания качества, а также обеспечение выполнения условий соглашения об услугах.
Завершение (Completing): Оценка успеха закупок и документирование извлеченных уроков.
Различия в закупках: Agile против традиционного подхода:
Agile-закупки:
Более гибкий и адаптивный подход с акцентом на сотрудничество между командой проекта и поставщиком.
Контракты не являются фиксированными, а «живыми» (living contract), способными адаптироваться по мере развития проекта.
Вся команда проекта активно участвует в определении потребностей в закупках.
Требуется постоянное взаимодействие, обратная связь и готовность к пересмотру условий.
Позволяет быстро и легко вносить изменения.
Важность позитивных отношений с поставщиком.
Традиционные закупки:
Ориентированы на стандартные контракты с четкими условиями и фиксированными результатами.
Проектный менеджер часто отвечает за весь процесс закупок «от начала до конца».
Контракты содержат обширную документацию с фиксированными требованиями и подробным описанием услуг/результатов.
Более жесткий подход, который обеспечивает ясность рабочих процессов и сроков, защищая от непредвиденных обстоятельств.
Переговоры сложнее, и пересмотр контрактов затруднен, часто требуется начинать процесс заново.
Советы по процессу закупок:
Инициирование:
Определите, что будет сделано самим, а что на аутсорсинг.
Тщательно сверяйте спецификации, качество и характеристики внешних ресурсов с требованиями проекта, чтобы избежать лишних функций и сократить затраты.
Выбор:
Исследуйте и оценивайте различных поставщиков.
Ищите поставщиков с хорошей репутацией в своевременной и качественной работе.
Проводите интервью и, если возможно, посещайте поставщиков лично.
Составление контракта:
Обращайте пристальное внимание на детали, включая и исключения в предложении поставщика.
Выявляйте пункты, которые можно выполнить внутренними силами для экономии.
Всегда консультируйтесь с юридическим отделом для обеспечения этичности и законности контракта.
Контроль:
Регулярно проверяйте производительность и качество работы поставщика.
Поддерживайте профессиональные, но твердые отношения, чтобы все требования и сроки выполнялись.
Проводите регулярные встречи для проверки хода работы.
Завершение:
Оцените успех закупок (качество материалов, проблемы с контрактами, отношения с поставщиками).
Документируйте извлеченные уроки для использования в будущих проектах.
Важные документы в процессе закупок:
Соглашение о неразглашении (NDA — Nondisclosure Agreement):
Стандартный документ, подписываемый внешними подрядчиками.
Цель: защита конфиденциальной информации организации от конкурентов или публичного доступа до готовности компании.
Неизменный документ на протяжении всего процесса.
Запрос предложений (RFP — Request for Proposal):
Документ, описывающий детали и требования проекта для потенциальных поставщиков.
Цель: получение предложений/ставок от поставщиков для выбора наилучшего варианта.
Включает: обзор проекта, желаемые результаты и цели, бюджет, сроки, контрольные точки, контактную информацию, а также требования к подаче предложений и вопросы для поставщика.
Неизменный документ.
Техническое задание (SoW — Statement of Work):
Документ, который четко описывает продукты и услуги, которые поставщик или подрядчик будет предоставлять организации.
Отправляется после выбора поставщика.
Эволюционирует по ходу проекта.
Включает: название компании, проект, дату, ключевых стейкхолдеров, таблицу для изменений, цель, целевую аудиторию, объем работ (что входит и что не входит), ожидаемые результаты, контрольные точки, количество часов работы и сроки выполнения.
Также содержит условия оплаты и отказ от ответственности (например, о возможности пересмотра в случае непредвиденных обстоятельств).
Составляется менеджером проекта с привлечением экспертов из юридического отдела.
Поддержка с юридической стороны и этика в процессе закупок
Необходимость поддержки юридического отдела и отдела соответствия (Compliance): Процесс закупок не заканчивается подписанием контрактов, он требует постоянного отслеживания и оценки эффективности. В этом процессе критически важна помощь юридического отдела.
Роль юридического отдела:
Обзор контрактов: Юристы помогают разобраться с незнакомой терминологией и обеспечивают законность и этичность условий.
Размер компании: Наличие юридического отдела варьируется от внутренних команд в крупных компаниях до аутсорсинговых или привлечения консультантов по мере необходимости в стартапах.
Соблюдение законов: В любой стране существуют законы, касающиеся честной и этичной торговли, производства и потребительских прав, которые необходимо соблюдать.
Отдел этики и соответствия:
Отвечает за обеспечение соответствия повседневных операций ценностям компании и государственной политике.
Предотвращает дискриминацию и обеспечивает корпоративную социальную ответственность.
Проектный менеджер должен убедиться, что все стейкхолдеры соблюдают эти политики.
Независимо от структуры юридического отдела вашей компании, обязательный юридический обзор контрактов — это хорошая деловая практика и приоритет для менеджера проекта.
Этика в закупках: Предотвращение этических ловушек
Важность этичности в закупках: Выбор поставщиков без должной осмотрительности может привести к серьезным последствиям для компании, включая репутационные скандалы. Менеджеры проектов несут большую ответственность за этичность каждого аспекта проекта.
Меры по обеспечению этичности закупок:
Знание юридических требований: Глубокое понимание правовых норм, применимых к вашему проекту и закупкам в данной стране.
Соблюдение кодекса этики: Придерживайтесь профессионального кодекса этики (например, Кодекса этики PMI: честность, ответственность, уважение, справедливость). Если есть сомнения, руководствуйтесь здравым смыслом и обращайтесь к экспертам (например, юристам).
Мониторинг рисков: Менеджер проекта должен постоянно отслеживать этические аспекты на протяжении всего процесса:
На этапе инициирования: Является ли сам проект этичным? Соответствует ли он кодексу этики бизнеса и экологическим нормам? Будет ли труд этически получен?
Перед подписанием контрактов: Убедитесь, что потенциальные поставщики этичны, и что вы осуществляете закупки этичным способом и платите им справедливую цену.
Во время выполнения: Обеспечивайте контроль качества, утверждайте счета, и поддерживайте ежедневные отношения с поставщиками, чтобы убедиться, что они соблюдают договоренности.
Распространенные этические ловушки:
Коррупция и взяточничество:
Снижение конкуренции: Поставщик может пытаться подкупить членов организации (деньгами, подарками, билетами), чтобы повлиять на решение в свою пользу.
«Откаты» (kickbacks): Предложение процента от присужденного контракта должностному лицу, которое обеспечит выигрыш торгов.
Sourcing от единственного поставщика (Sole‑supplier sourcing):
Этические проблемы возникают, когда другим квалифицированным поставщикам не дают возможности участвовать в торгах.
Это ограничивает конкуренцию, лишая компанию и общественность преимуществ, таких как разумные цены, стандарты качества и быстрая доставка.
Требует четкого обоснования, почему торги ограничены одним поставщиком (например, защита коммерческой тайны).
Взаимодействие с государственными структурами:
Государственные учреждения часто имеют более строгие этические стандарты и правила.
Незнание этих ограничений может привести к непреднамеренному попаданию в этическую ловушку.
Как избежать этических ловушек (Тест этичности): Задайте себе следующие вопросы:
Стыд (Shame): Будет ли вам стыдно, если кто-то узнает о вашем поступке?
Сообщество (Community): Хотели бы вы, чтобы ваши друзья знали о принятом вами решении?
Юридические последствия (Legal): Столкнетесь ли вы с юридическими действиями, если совершите этот поступок?
Ситуация (Situation): Будут ли ваши действия оправданы в данной ситуации?
Последствия (Consequence): Стоит ли негативный результат ваших действий?
Управление рисками в проектах
Крайне важно выявлять и планировать риски, которые могут повлиять на ваш проект.
Риски и проблемы:
Риск — это потенциальное событие, которое может произойти и повлиять на ваш проект. Риски гипотетичны — они могут случиться, но не обязательно.
Проблема (issue) — это известная или реальная проблема, которая в данный момент влияет на способность выполнить задачу.
Различие: Риск — это «что если», а проблема — это то, что уже происходит. Если риск реализуется, он становится проблемой.
Управление рисками (Risk management): Это процесс выявления и оценки потенциальных рисков и проблем, которые могут повлиять на проект. Это не разовая задача, а постоянная практика на протяжении всего жизненного цикла проекта.
Цель: Понять, что может пойти не так, с кем консультироваться по поводу рисков и как их смягчить. Это позволяет иметь готовый план действий на случай возникновения проблем.
Последствия отсутствия управления рисками:
Проект может не достичь своих целей, сроков или критериев успеха.
Снижается гибкость плана, что затрудняет адаптацию к изменениям.
Может возникнуть нехватка ресурсов или непредвиденные сокращения бюджета.
Фазы управления рисками: Процесс управления рисками обычно включает пять этапов:
Выявление риска: Определение и формулирование потенциальных рисков проекта вместе с командой.
Анализ риска: Определение вероятности возникновения риска и его потенциального воздействия на проект. Серьезные риски с высокой вероятностью представляют наибольшую угрозу.
Оценка риска: Использование результатов анализа для приоритизации рисков.
Обработка риска: Разработка плана по управлению каждым риском. Незначительные риски могут быть проигнорированы, но серьезные требуют детальных планов смягчения.
Мониторинг и контроль риска: Назначение членов команды для отслеживания и смягчения рисков по мере необходимости.
Выявление возможностей через управление рисками: При оценке рисков важно также учитывать потенциальные позитивные события, которые являются возможностями. Возможность — это потенциальный положительный исход риска, который может принести дополнительную ценность проекту.
Примеры возможностей: Завершение этапа раньше срока, скидки на материалы, появление дополнительных ресурсов (люди, инвестиции, оборудование).
Как выявлять возможности: Используйте те же инструменты и методы, что и для управления рисками (выявление, анализ, оценка, обработка, контроль). Планируйте, как воспользоваться возможностями, если они появятся, используя мозговой штурм и прошлый опыт.
Инструменты и методы выявления рисков
Мозговой штурм: Один из самых эффективных методов выявления рисков — мозговой штурм с командой. Он позволяет группам спонтанно делиться идеями без осуждения.
Формирование команды: Приглашайте разнообразную команду, включающую людей с разным опытом и из разных ролей. Это поможет выявить риски, о которых вы могли бы не подумать самостоятельно.
Диаграмма причинно‑следственных связей («рыбий скелет» / диаграмма Исикавы): была разработаны японским организационным теоретиком Каору Исикавой в 1960-х годах для контроля качества в судостроительной промышленности. Она представляет собой визуальный способ анализа причин и следствий, напоминая по форме скелет рыбы.
Шаги по созданию:
Определите проблему: Четко сформулируйте проблему и разместите ее в «голове» диаграммы.
Определите категории: Выделите основные категории, которые могут быть причинами проблемы (например, «люди», «технологии», «материалы», «транспорт», «окружающая среда»).
Проведите мозговой штурм причин: В каждой категории найдите конкретные причины, которые могут привести к проблеме. Важно поощрять свободный поток идей и избегать осуждения.
Проанализируйте причины: Определите первопричину (root cause) проблемы. Это не обязательно первая выявленная причина; это исходная причина, порождающая проблему.
Реестр рисков и оценка рисков: После мозгового штурма занесите все потенциальные риски в реестр рисков — таблицу или список, содержащий все выявленные риски. Затем переходите к оценке рисков.
Оценка рисков (Risk assessment): Это этап, на котором оцениваются или измеряются характеристики риска, в основном вероятность его возникновения и его потенциальное влияние на проект.
Матрица вероятности и воздействия (Probability and impact matrix): Популярный инструмент для приоритизации рисков.
Воздействие (Impact): Ущерб, который может нанести риск, если он произойдет (высокий, средний, низкий).
Высокое: существенно изменит проект
Средний: окажет заметное влияние
Низкое: окажет небольшое влияние, но не сорвет проект
Вероятность (Probability): Вероятность возникновения риска (высокая, средняя, низкая).
Высокая: большая вероятность того, что это произойдет
Средний: средняя вероятность, нужно учитывать такой риск
Низкая: риск может произойти, но это маловероятно
Внутренняя оценка риска (Inherent risk rating): Мера риска, рассчитанная на основе его вероятности и воздействия (также высокая, средняя, низкая).
Риски с высоким воздействием и высокой вероятностью имеют высокую внутреннюю оценку риска и требуют детальных планов смягчения.
Риски с средним воздействием и средней вероятностью имеют среднюю внутреннюю оценку риска и требуют планов митигирования.
Риски с низким воздействием и низкой вероятностью имеют низкую внутреннюю оценку риска и не вызывают больших опасений.
Толерантность к риску (Risk appetite): То, как вы управляете рисками, также зависит от толерантности организации к риску — ее готовности принять возможные последствия риска. Важно, чтобы ваша команда и стейкхолдеры согласовали эту толерантность.
Распространенные типы рисков в проектах
Планирование рисков имеет решающее значение для успеха любого проекта. Хотя существует множество различных типов рисков, менеджеру проекта особенно важно знать о следующих:
Временные риски (Time risks):
Вероятность того, что выполнение задач проекта займет больше времени, чем ожидалось. «Время — деньги». Плохое управление временем может привести к исчерпанию бюджета и недовольству стейкхолдеров из‑за задержек.
Бюджетные риски (Budget risks):
Вероятность того, что стоимость проекта возрастет из-за плохого планирования или расширения объема проекта. Бюджетирование является основой контроля затрат проекта. Перерасход средств может привести к невозможности оплаты поставщикам и нанести репутационный ущерб компании.
Риски объема (Scope risks):
Вероятность того, что проект не принесет результатов, указанных в целях проекта. Результаты вашего проекта могут оказаться неприемлемыми для стейкхолдеров или клиентов, что может свести на нет всю цель проекта.
Внешние риски (External risks):
Риски, возникающие из‑за факторов, находящихся вне контроля компании (например, стихийные бедствия, изменения в законодательстве). Важно быть в курсе таких рисков, даже если вы не можете их контролировать, чтобы иметь план действий на случай их возникновения.
Единая точка отказа (Single point of failure):
Риск, который может быть катастрофическим и полностью остановить работу по всему проекту. Если этот риск реализуется, он может парализовать команду и сделать невозможным дальнейшее продвижение.
Пример: Отказ внутренней базы данных, где хранится вся информация о проекте.
Управление: Необходимо выявлять и отслеживать потенциальные единые точки отказа на ранних этапах проекта.
Избегание (Avoid): Полностью исключить ситуацию (например, использовать другие, широко доступные семена).
Минимизация (Minimize): Смягчить катастрофические последствия (например, использовать двух поставщиков семян вместо одного).
Передача (Transfer): Переложить ответственность за риск на кого‑то другого (например, покупать семена у поставщика, который сам берет на себя риски регулирования в Южной Америке).
Принятие (Accept): Принять риск как обычные операционные издержки. Активное принятие включает выделение дополнительных средств; пассивное принятие — это подход «ничего не делать» (не рекомендуется для единых точек отказа).
Зависимости (Dependencies):
Взаимосвязь между двумя задачами проекта, когда начало или завершение одной зависит от начала или завершения другой. Зависимости — это «связи», соединяющие задачи проекта. Зависимости являются частым источником риска. Если задача, от которой зависит другая, задерживается, это может повлиять на весь график проекта и бюджет.
Пример: Команда не может размещать заказы, пока не подписан контракт с поставщиком растений (зависимость). Если процесс найма затягивается, это задержит проект.
Типы зависимостей:
Внутренние зависимости: Те, что находятся внутри проекта и контролируются вашей командой (например, утверждение дизайна сайта перед началом разработки).
Внешние зависимости: Те, что находятся вне вашего контроля (например, засуха у поставщика растений, влияющая на доступность растений).
Визуализация зависимостей: Графики зависимостей помогают визуализировать поток работы и выявить связанные с ними риски.
Завершение‑Начало (Finish to Start — FS): Задача А должна быть завершена, прежде чем может начаться Задача Б (самый распространенный тип).
Завершение‑Завершение (Finish to Finish — FF): Задача А должна быть завершена, прежде чем может быть завершена Задача Б (менее распространенный).
Начало‑Начало (Start to Start — SS): Задача Б не может начаться, пока не начнется Задача А (задачи начинаются одновременно и идут параллельно).
Начало-Завершение (Start to Finish — SF): Задача А должна начаться, прежде чем может быть завершена Задача Б (редкий тип).
Документирование и коммуникация рисков
План управления рисками (Risk management plan): Это живой документ, содержащий информацию о высокоуровневых рисках и планах по их снижению. Он обеспечивает четкое понимание потенциальных проблем для членов команды и стейкхолдеров.
Динамичность: Поскольку управление рисками — это непрерывный процесс, план должен регулярно обновляться: добавлять новые риски, удалять неактуальные и вносить изменения в планы снижения.
Содержание:
Название компании и проекта.
Автор документа и его статус («в процессе», «финал»).
Дата создания и последнего обновления (для прозрачности).
Цель документа: Краткое изложение планов по снижению рисков.
Краткое содержание (Executive summary): Краткое введение в нормальные условия проекта и обзор потенциальных рисков.
Реестр рисков: Таблица или список с выявленными рисками, их внутренней оценкой (на основе вероятности и воздействия) и соответствующим планом снижения.
Приложения: Диаграммы вероятности и воздействия, а также матрица, используемые для оценки рисков.
Согласование: После заполнения план передается команде и стейкхолдерам для получения их мнения и обеспечения согласованности.
Коммуникация рисков стейкхолдерам: Недостаточно просто знать о рисках — их необходимо эффективно донести до стейкхолдеров.
Почему это важно?
Позволяет стейкхолдерам быть готовыми помочь в случае возникновения проблем (например, предоставить дополнительный бюджет или ресурсы).
Предотвращает неприятные сюрпризы, которые могут подорвать доверие к вам как к руководителю проекта.
Помогает установить ожидания относительно того, чего потенциально ожидать на этапе выполнения проекта.
Демонстрирует, что вы предприняли шаги для снижения рисков и спланировали действия на случай их возникновения.
Дает вам возможность предложить стейкхолдерам способы помощи, если риск все-таки возникнет.
Стейкхолдеры могут иметь ценный опыт и стратегии, которые вы не учли.
Как общаться в зависимости от серьезности риска:
Низкоуровневые риски: Достаточно простого электронного письма, возможно, в рамках еженедельных обновлений планирования, с кратким объяснением того, как вы будете их решать.
Среднеуровневые риски: Более прямое электронное письмо со стороны менеджера проекта стейкхолдеру, с более подробным описанием риска, детальным планом снижения и ссылкой на план управления рисками. Можно использовать пометку «Срочно» в теме письма.
Высокоуровневые риски: Требуют тщательного и прямого общения. Включите их в повестку дня встреч со стейкхолдерами по плану проекта. Используйте это время, чтобы собрать обратную связь по вашему плану управления рисками и получить ценные идеи от стейкхолдеров.
Важность документации и организации в управлении проектами
Надёжная документация и её централизованное хранение — это основа эффективной работы в любом проекте. Они служат мощным инструментом коммуникации, обеспечивают прозрачность, подотчётность и непрерывность проекта, а также способствуют управлению знаниями.
Централизованное хранение и доступность:
Ускоренная коммуникация: Когда все планы и отчёты хранятся в одном централизованном месте (например, в Google Drive), члены команды могут быстро найти нужные документы, что делает общение быстрее и эффективнее.
Чёткая организация: Файлы должны быть чётко помечены и организованы по папкам.
Видимость и подотчётность:
Проектный план является отличным примером: каждая задача имеет своего ответственного и срок выполнения. Это обеспечивает прозрачность для команды и подотчётность для владельца задачи.
Актуальность: Наличие актуальных планов помогает избежать недоразумений и ошибок в коммуникации, так как члены команды и стейкхолдеры всегда могут свериться с текущим состоянием проекта.
Непрерывность проекта:
Смена ролей: Если менеджеру проекта (или другому ключевому члену команды) нужно внезапно покинуть проект (из-за болезни, перевода или отпуска), хорошо задокументированные и централизованно хранящиеся планы позволяют новому человеку быстро сориентироваться и продолжить работу без значительных задержек.
Важность: Храните руководства, инструкции, заметки о встречах, планы и процессы в одном месте с чёткими метками. Убедитесь, что соответствующие роли имеют доступ к этим документам, чтобы проект мог продолжаться даже в ваше отсутствие.
Управление знаниями:
Будущее использование: Документирование и доступность планов являются частью передовой практики управления проектами, называемой управлением знаниями. Это позволяет будущим командам (или тем, кто принимает решения) легко получить доступ к информации для принятия решений или планирования аналогичных проектов.
Исторический контекст: Например, архитектор, работающий над реконструкцией кухни, может обратиться к старым планам, чтобы понять, почему раковина была размещена в определённом месте, или новый архитектор может быстро получить контекст для уже принятых решений.
Распределение информации на основе принципа «Необходимость знать»:
Целесообразность: Определяйте, какую информацию, кому и когда следует предоставлять. Фокусируйтесь на ключевой информации, которая действительно нужна конкретным лицам.
Избегайте перегрузки: Ежедневные обновления для топ‑менеджеров, которые получают множество писем, скорее всего, будут проигнорированы, что является пустой тратой вашего времени и затушевывает действительно важные сообщения.
Конфиденциальные данные: Будьте предельно осторожны при обмене конфиденциальными данными (например, финансовыми данными, результатами опросов пользователей с персональными данными PII — Personally Identifiable Information). Делитесь только тем, что необходимо.
Пример: Сырые данные опросов с PII должны быть доступны только утверждённым членам команды. Результаты могут быть представлены в виде графиков или отчётов без PII для более широкой аудитории.
Безопасность и репутация: Предоставление полного доступа к конфиденциальным данным тем, кому нужен только конечный результат, может привести к утечкам, нарушению политики компании и ущербу вашей репутации. Делитесь информацией только по принципу «необходимость знать» (need‑to‑know basis).
На этом курс 3 заканчивается.
В заключение советую углублённо почитать про OIMS — Operations Integrity Management System от ExxonMobil.
Почему это важно? Потому что OIMS — одна из самых зрелых и практически применяемых систем управления рисками и проектной деятельностью в промышленности. Она была разработана на основе десятилетий опыта в высокоопасной отрасли и легла в основу многих международных стандартов.
Система построена на 11 ключевых принципах (элементах), которые формируют сквозной подход к управлению на всех этапах проекта:
Лидерство и подотчётность — руководство обязано формировать культуру безопасности и быть лично вовлечённым в процессы управления рисками.
Анализ и управление рисками — системная идентификация, оценка и минимизация рисков на всём жизненном цикле проекта.
Проектирование и строительство — проекты должны соответствовать требованиям безопасности и надёжности с момента концепции.
Операции и техническая целостность — эксплуатация осуществляется в пределах безопасных и контролируемых границ.
Управление персоналом и подрядчиками — все участники проекта должны обладать нужной квалификацией и следовать единым стандартам.
Управление изменениями — никакие изменения не допускаются без предварительной оценки их последствий и рисков.
Реагирование на чрезвычайные ситуации — обязательна готовность к авариям с планами реагирования и регулярными учениями.
Исследование инцидентов — все происшествия тщательно анализируются с целью выявления первопричин и исключения повторов.
Аудит и оценка — регулярные внутренние и внешние проверки системы управления.
Обратная связь и совершенствование — система строится как развивающаяся, включающая обучение и внедрение уроков из практики.
Документирование и соблюдение требований — процессы и процедуры формализованы и подчинены внутренним и внешним регуляциям.
OIMS — это не просто внутренний документ ExxonMobil, а целая философия управления сложными проектами в высокоопасных отраслях. Его принципы адаптируют и другие энергетические гиганты, а международные стандарты (ISO, API RP) всё чаще ссылаются на аналогичные структуры.
Если вы хотите управлять проектами не только эффективно, но и безопасно — изучение OIMS станет вашим мощным конкурентным преимуществом.
