[Управление проектами] Управление по исключениям или эскалация в проектном менеджменте
Автор
Сообщение
news_bot ®
Стаж: 6 лет 7 месяцев
Сообщений: 27286
Известная всем «простая истина» гласит, что менеджер проекта всецело отвечает за достижение целей проекта (об этом говорит и PMBoK, и стандарты ISO). При этом в зависимости от масштаба и бюджета проекта различные группы навыков руководителей проектов выходят на разные уровни: маленький проект чаще всего предполагает сильные технические скиллы, крупные проекты – лидерские и стратегические навыки взаимодействия со стейкхолдерами и заинтересованными лицами.На основе личного опыта и проектных фреймворков выполнить проект успешно (сроки, качество, бюджет, удовлетворенность заказчика) можно только при постоянном проактивном управлении проектом, в рамках которого почти 80% времени должно уделяться прогнозированию. При этом любое планирование и прогнозирование необходимо производить методом набегающей волны, а успешным прогнозированием можно заниматься только при выстроенных и устоявшихся процессах. В противном случае менеджер проекта вместо прогнозов и планов в конечном итоге будет заниматься налаживанием процессов управления команды и создания продукта(ов) проекта. Процентное соотношение времени, затрачиваемое на управленческие процессы, очень хорошо отражает зрелость проектного менеджмента в команде/компании и в целом самого менеджера.Так как ни один проект невозможен без людей, то роль менеджера проекта, заключающаяся в интеграции и координации работ различных специалистов и заинтересованных лиц, при зрелом менеджменте всегда выходит на первый план (даже при прогнозировании). Управление заинтересованными сторонами (даже неблагоприятно влияющих на проект) – очень яркая и многогранная работа. А там, где есть люди, там всегда присутствуют конфликты: ресурсные, межличностные, приоритетные, административные и т.д.В странах со зрелым управленческим менеджментом давно применяются процессы управления по исключениям. Самое явное определение таким процессам дает стандарт PRINCE2: Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Допустимые отклонения должны быть определены для каждого уровня плана проекта.В словарях и экономических талмудах также можно встретить понятие «принцип исключений в менеджменте» - концепция, согласно которой только значительные отклонения должны побуждать срабатывать систему контроля. Чаще всего такие понятия разбираются в рамках антикризисного управления.К сожалению, в российском проектном менеджменте (даже в больших корпорациях) до сих пор не развивается применение принципа управления по исключениям. Многие большие начальники давно изучили техники и методики делегирования, но в обратную сторону «вскрытие» проблемных зон проекта до верхнего уровня заинтересованных сторон работает очень плохо. Другими словами, очень многие менеджеры проектов боятся эскалировать проблемы «наверх» и выносить лишний раз вопросы на уровень спонсоров и кураторов проекта. Возможно, в российской действительности это отчасти связано с моральными устоями, что жаловаться не хорошо, или с боязнью показаться некомпетентным.
Изначально слово «эскалация» произошло от латинского слова scala «лестница», в русский язык пришло из английского слова escalation «расширение, распространение». В современном русском языке чаще всего слово эскалация понимается больше с политическим или военным смыслом в части наращивания силы, расширение или распространение конфликта. Впрочем, в проектном менеджменте эскалация, при правильном понимании и использовании, не несет столь негативной окраски, а, наоборот, является полезным инструментом для достижения целей проекта и удовлетворенности заказчика. Нужно всегда помнить, что нерешенные вовремя проблемы повышают риски неуспеха проекта, вызывают нарушения сроков и бюджетов, снижают качество продукта проекта.Эскалация вопросов и проблем в проекте (ресурсных, межличностных, административных) не будет вызывать нездоровый негатив, если всегда пользоваться принципами честности и открытости. Шаги, которыми пользуясь я в своей практике (и они правда приносят успех):
- Выявите заинтересованность или ее отсутствие в решении проблемы путем диалога. Другими словами – попробуйте просто спросить почему нет (почему не решается проблема или у кого отсутствует интерес к ее решению).
- Открыто оповестите противоположную сторону о необходимости/потребности в эскалации, тем самым вы избавитесь от подковёрных игр и наращивания негатива в проекте после эскалации.
- Подготовьте аргументированную базу для эскалации с учетом планов проекта, управления рисками, допущений и ограничений. Здесь хорошим подспорьем будут ранее фиксированные договоренности, статус-встречи и планы.
- Эскалируйте на вышестоящие уровни, это страшно только в первый раз. В рамках договорных отношений Заказчик – Исполнитель эскалацию на уровни выше лучше переносить в разряд официальных писем (для юридической подстраховки от «плохих людей» и штрафных санкций).
В качестве личного совета могу добавить, что не надо забывать об открытости к сотрудничеству даже в момент эскалации, ведь любой конфликт – это точка для роста, и в проектной практике нужно использовать его конструктивные функции. Проектная эскалация не пересекается (и не должна пересекаться) с личными отношениями, и ни коем образом не является жалобой. В момент эскалации задача менеджера проектов – приведение вышестоящих уровней, принимающих решение, к принятию качественного и полезного решения для всех, а главное для проекта. Эффективна только открытая и честная эскалация.
===========
Источник:
habr.com
===========
Похожие новости:
- [Help Desk Software, CRM-системы, Service Desk, Управление проектами, Облачные сервисы] KPI сервиса с выездными сотрудниками: какие цели ставить и как достигать?
- [Управление проектами, Управление персоналом] Фактор демотивации №1: “Отсутствие стратегии в головах сотрудников”
- [Анализ и проектирование систем, Управление продуктом] Расчет рекомендованных предложений для клиентов Yota – что под капотом?
- [PHP, Программирование, Совершенный код, Проектирование и рефакторинг, ООП] Принцип подстановки Барбары Лисков (предусловия и постусловия)
- [Управление проектами] Как виртуальная копия музея может повлиять на физическую: что меняется при появлении метрик
- [Управление разработкой, Управление проектами, Agile, Конференции] 10 июня, 19.00 — онлайн-митап для скрам-мастеров
- [Управление разработкой, Управление проектами, Карьера в IT-индустрии] Гайд начинающего тимлида
- [Анализ и проектирование систем, Работа с 3D-графикой, CAD/CAM, Софт] Российские BIM-технологии: проектирование генерального плана в Model Studio CS
- [Анализ и проектирование систем, IT-инфраструктура, IPTV] Программные зонды Elecard Boro – Мониторинг IPTV
- [GitHub, Управление проектами, Здоровье, IT-компании, Удалённая работа] GitHub оценил, насколько сильно работу программиста нарушают собрания и прочие отвлекающие факторы
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_proektami (управление проектами), #_project_management, #_prince2, #_eskalatsija (эскалация), #_proekt (проект), #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Сен 09:22
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 7 месяцев |
|
|
Известная всем «простая истина» гласит, что менеджер проекта всецело отвечает за достижение целей проекта (об этом говорит и PMBoK, и стандарты ISO). При этом в зависимости от масштаба и бюджета проекта различные группы навыков руководителей проектов выходят на разные уровни: маленький проект чаще всего предполагает сильные технические скиллы, крупные проекты – лидерские и стратегические навыки взаимодействия со стейкхолдерами и заинтересованными лицами.На основе личного опыта и проектных фреймворков выполнить проект успешно (сроки, качество, бюджет, удовлетворенность заказчика) можно только при постоянном проактивном управлении проектом, в рамках которого почти 80% времени должно уделяться прогнозированию. При этом любое планирование и прогнозирование необходимо производить методом набегающей волны, а успешным прогнозированием можно заниматься только при выстроенных и устоявшихся процессах. В противном случае менеджер проекта вместо прогнозов и планов в конечном итоге будет заниматься налаживанием процессов управления команды и создания продукта(ов) проекта. Процентное соотношение времени, затрачиваемое на управленческие процессы, очень хорошо отражает зрелость проектного менеджмента в команде/компании и в целом самого менеджера.Так как ни один проект невозможен без людей, то роль менеджера проекта, заключающаяся в интеграции и координации работ различных специалистов и заинтересованных лиц, при зрелом менеджменте всегда выходит на первый план (даже при прогнозировании). Управление заинтересованными сторонами (даже неблагоприятно влияющих на проект) – очень яркая и многогранная работа. А там, где есть люди, там всегда присутствуют конфликты: ресурсные, межличностные, приоритетные, административные и т.д.В странах со зрелым управленческим менеджментом давно применяются процессы управления по исключениям. Самое явное определение таким процессам дает стандарт PRINCE2: Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Допустимые отклонения должны быть определены для каждого уровня плана проекта.В словарях и экономических талмудах также можно встретить понятие «принцип исключений в менеджменте» - концепция, согласно которой только значительные отклонения должны побуждать срабатывать систему контроля. Чаще всего такие понятия разбираются в рамках антикризисного управления.К сожалению, в российском проектном менеджменте (даже в больших корпорациях) до сих пор не развивается применение принципа управления по исключениям. Многие большие начальники давно изучили техники и методики делегирования, но в обратную сторону «вскрытие» проблемных зон проекта до верхнего уровня заинтересованных сторон работает очень плохо. Другими словами, очень многие менеджеры проектов боятся эскалировать проблемы «наверх» и выносить лишний раз вопросы на уровень спонсоров и кураторов проекта. Возможно, в российской действительности это отчасти связано с моральными устоями, что жаловаться не хорошо, или с боязнью показаться некомпетентным.  Изначально слово «эскалация» произошло от латинского слова scala «лестница», в русский язык пришло из английского слова escalation «расширение, распространение». В современном русском языке чаще всего слово эскалация понимается больше с политическим или военным смыслом в части наращивания силы, расширение или распространение конфликта. Впрочем, в проектном менеджменте эскалация, при правильном понимании и использовании, не несет столь негативной окраски, а, наоборот, является полезным инструментом для достижения целей проекта и удовлетворенности заказчика. Нужно всегда помнить, что нерешенные вовремя проблемы повышают риски неуспеха проекта, вызывают нарушения сроков и бюджетов, снижают качество продукта проекта.Эскалация вопросов и проблем в проекте (ресурсных, межличностных, административных) не будет вызывать нездоровый негатив, если всегда пользоваться принципами честности и открытости. Шаги, которыми пользуясь я в своей практике (и они правда приносят успех):
=========== Источник: habr.com =========== Похожие новости:
Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Сен 09:22
Часовой пояс: UTC + 5