50 Золотых Правил Управления Проектами
Шрифт:
Пример проекта из реальной жизни: На старте технического проекта в сфере медицинских услуг один из инженеров, работающих над проектом, вскользь упомнил о правах клиента на хранении данных на стороне провайдера. Лаура, Проектный Менеджер, была ответственна только за техническую часть проекта, но смогла увидеть влияние этого в общем-то юридического вопроса на проект. Поэтому она взяла на себя задачу проконтролировать, что юридическая служба и отдел снабжения
ПРАВИЛО #09 – ИСПОЛЬЗУЙ 360-ГРАДУСНЫЙ ПОДХОД
Быть Проектным Менеджером – это значит уметь думать и действовать в разных измерениях, независимо от количества компонентов, участников проекта и числа взаимозависимостей. В случае наличия нескольких Проектных Менеджеров на проекте, один на стороне клиента и один на стороне вендора, клиентский Проектный Менеджер обязан быть полностью ответственным. Он представляет Проектных Спонсоров и имеет право видеть деятельность на обеих сторонах. Полная ответственность за управление проектом не может быть разделена.
Однако, требование к Проектному Менеджеру иметь 360-градусное видение является категоричным для успешности проектов. В ином случае будут ошибки, разрывы, предположения и сферы ответственности, которые взорвут твой проект. Главная суть в том, что Ведущий Проектный Менеджер, независимо от того, с какого он Департамента, должен осознать свою ответственность за результат работы других Департаментов и команд. Это подразумевает наличие 360-градусного видения для планирования и управления всеми командами. Просто, но чрезвычайно эффективно и “must-have” для любого проекта.
Пример проекта из реальной жизни: Имея успешный опыт запуска нескольких проектов, Технический Проектный Менеджер Эрнесто предполагал, что проект переноса колл-центра будет достаточно легкой задачей. К его удивлению, он закончил его, работая с более чем тридцатью рабочими потоками, а количество людей в проекте достигло 150 человек. От команды обработки кредитных карт и отдела кадров до юристов, безопасников, закупщиков, сервисников обслуживания оборудования – перечень команд, вовлеченных в проект, был самым разнообразным из того, с чем ему приходилось работать ранее. Каждое и любое требование и ограничение этих команд, в основном не техническое, должно было быть записано и вплетено в первоначальный план для полной уверенности, что он всё охватил. Не считаясь с требованиями и ограничениями каждой команды, а также их внутренними взаимосвязями, можно было поставить весь проект в большую опасность. Эрнесто же вовлек все рабочие потоки и усилил видение всех взаимозависимостей
ПРАВИЛО #10 – ПОЛУЧИ ПРАВИЛЬНУЮ ДЕТАЛИЗАЦИЮ И НУЖНЫЙ ВИД
Понимание того, какой уровень детализации надо иметь – это тонкое искусство. Слишком большая детализация – и ты потеряешь контроль над всей картиной. Слишком маленькая – и ты можешь пропустить что-то важное. Но для выполнения успешных проектов оба параметра должны приниматься во внимание. И ответственность Проектного Менеджера заключается в том, чтобы удостовериться, что ни один ключевой элемент не прошел сквозь сеть. Ключевая особенность – структурировать проектную информацию так, чтобы для широкой аудитории проекта в любое время было понятно, где они находятся сейчас и куда движутся.
Проектный Менеджер делает это путем переваривания всей детальной информации и раскрыванием только релевантных частей. Он делает это каждую неделю, обновляя инструменты и формы, используемые для пилотирования проекта. Но он делится с проектной командой только “краткой версией” этого детального списка задач, фокусируясь на задачах последней недели и следующих двух неделях, для каждого человека. “Ключевые вехи” также представляются каждую неделю, и команда может видеть свое положение внутри “большой схемы проекта”.
Пример проекта из реальной жизни: В международной рекламной компании были обнаружены интересные факты при взгляде на два идентичных проекта, выполненных различными Проектными Менеджерами в различных регионах. В том время как Люк – Европейский Проектный Менеджер – был обвинен за излишнюю детализацию, Бекки – Американская коллега – получила похвалу за свой легкий подход. По окончании, Американский проект попал в неприятности и имел нерешенные проблемы, тогда как Европейский проект был завершен без критических проблем. Различие было в том, что Люк не полагался на случай и погружался на тот уровень детализации, где чувствовал, что ничего важного не пропустил. А Бекки слишком сильно полагалась на членов своей проектной команды и не видела, что некоторые из них не были вовлечены в работу и были недостаточно проактивными для предотвращения ключевых проблем.
ПРАВИЛО #11 – СДЕЛАЙ ПРОВЕРКУ ОСНОВ В ПЕРВЫЙ ЖЕ ДЕНЬ
Итак, тебя назначили Проектным Менеджером и дали зеленый свет. С этого момента успех или неудача этого проекта – это ответственность Проектного Менеджера и его команды. Что будет дальше – зависит от тебя. Либо ты принимаешь проект, его содержание и требования как есть, либо используешь здравый смысл и выполняешь проверку базовых основ перед началом работы. Мы сильно рекомендуем последнее. Почему?
Конец ознакомительного фрагмента.