II – ПРАВИЛА О ПЛАНИРОВАНИИ И УСТАНОВЛЕНИИ ПРЕДЕЛОВ
Эти правила помогут тебе убедиться, что тебе ясно то, ЧТО нужно достичь и КАК ты этого достигнешь. Мы увидим, как особые подходы и правила, адаптированные Оливером и другими Проектными Менеджерами, изменили ситуацию в этой сфере.
ПРАВИЛО #06 – НИКОГДА НЕ ПРЕДПОЛАГАЙ
“Предположение – мать всех проколов” (С англ. “Assumption is the mother of all fuck-ups”). Это прямолинейное выражение придумал не я – оно из известного фильма-боевика. Оно процитировано слово за словом, так как очень хорошо подходит для проектов и четко описывает, что случается с теми, кто относится к делу поверхностно и срезает дорогу. В самом деле, даже если Проектные Менеджеры не имеют волшебную палочку и не могут предсказывать будущее, то они в состоянии предугадывать и проверять как можно больше. Они не должны принимать что-либо как данность до тех пор, пока не заручились экспертным мнением и фамилией человека, который отвечает за данную тему. Ни один камень не должен остаться не перевёрнутым.
Они не должны оставлять ни единого зазора или сведений “для подтверждения” до того момента, пока не будут уверены, что все возможное сделано. Они должны убедиться, что используют реалистичные оценки и их не вовлекли в использование данных, которые не будут жизнеспособны. Более того, они не должны прятать голову в песок и полагать, что эти проблемы будут когда-нибудь в очень отдаленном будущем и вообще адресованы не им – даже если у них сейчас много задач для немедленного выполнения, слишком много неизвестных и “никогда раньше не делал”-задач. Путь простой – иметь четко именованного владельца для каждой и любой проектной задачи. Это снимет неопределённость и дыры в понимании того, кто чем должен заниматься.
Пример проекта из реальной жизни: В одной лидирующей туристической компании шел проект переезда в новое здание штаб-квартиры из 400 человек к определенной строго установленной дате. Этот проект успешно продвигался до того момента, пока в последнюю минуту не обнаружилась большая проблема. Проектный Менеджер Оливер и его команда обнаружила, что мощность кондиционирования нового здания недостаточна, чтобы удовлетворить нужды офиса. Кто-то сделал математические расчеты неверно, и все полагали, что об этом уже позаботились. Оказалось, что проблема была в том, что официально никому не была выдана задача проверить конечные цифры. Как заявил один из высших менеджеров, они чуть не въехали в “большого белого слона” (здесь приводится ссылка к сказке о белом слоне, которого король Сиама подарил несогласному с ним судье, и тот разорился на содержании этого слона – Прим.перев.), тем самым серьезно поставив бизнес под угрозу. В результате, большое количество устройств было исключено из первоначального проекта для того, чтобы переезд состоялся. С этого дня Оливер взял за правило никогда и ничего не предполагать, даже касательно простых и базовых задач.
ПРАВИЛО #07 – ИМЕЙ ПЫТЛИВЫЙ И НАСТОЙЧИВЫЙ УМ
В ходе проекта тебе придется несколько раз встречать вещи, которые не выглядят правильными или ясными, и которые захочется пропустить – ведь многие люди хотят просто делать свою работу, а не вести раскопки. Это очень рискованно! До тех пор, пока Проектный Менеджер не поймет всё и почувствует себя комфортно в том, что ни одна деталь не пропущена, он не будет прекращать задавать вопросы, тестировать и анализировать положение дел. Иметь пытливый ум и быть параноидальным насчет всего, что может пойти не так, это значит гарантировать, что у случая осталось мало шансов. Не стесняйся спрашивать совета у третьих лиц, если экспертов в этой области знаний нет в твоей компании. Может быть, это повлечет дополнительные расходы, но это будет стоить того.
Делая работу второпях, ленясь, или боясь задавать вопросы, Проектный Менеджер непременно придет позднее к эффекту обратной вспышки. Поэтому, когда бы ни наступила неясность в чем-либо – не стесняйся спрашивать. Более того, если люди сдаются оттого, что не могут найти решение проблемы, то именно Проектный Менеджер должен содействовать и способствовать команде проекта, пока решение не будет найдено. Как никто больше в команде, Проектный менеджер должен думать и анализировать для постоянного продвижения вперед. Найди правильный баланс, и требуй достижения нужного уровня детализации.
Пример проекта из реальной жизни: На старте важного проекта аутсорсинга команда переговорщиков компании-разработчика онлайн-игр предоставляла очень мало информации Саре, назначенной Проектным Менеджером. Недостаток коммуникации и совместной работы вызвал у нее тревогу. Хотя её уверяли, что всё под контролем, она продолжала задавать вопросы о специфичной части проекта до тех пора, пока кто-то не предоставил ей четкий ответ. Как выяснилось, она тревожилась не впустую. Провайдер аутсорсинга полагал, что команда переговорщиков клиента выполнит эту часть проекта, а клиент полагал, что это сделает вендор. Спасибо вендору: он смог выработать промежуточное решение до момента, пока клиент не предоставил и установил свое решение. Если бы Сара не настаивала на получении чёткого ответа, проблема бы проявилась спустя недели, подвергая опасности весь проект. Настойчивое поведение и подход Сары реально помогли проекту.
ПРАВИЛО #08 – БУДЬ ГУБКОЙ И НЕ ПРОПУСКАЙ НИЧЕГО
Быть Великим Проектным Менеджером – значит быть в курсе всего. Кто-то пробормотал что-то связанное с твоим проектом – запиши это и не отпускай, пока ты полностью не проверишь и оценишь эту информацию. То, что может сначала показаться наименее важной, полностью сторонней или незначительной деталью, может обернуться существенной проблемой. Не будет ничего хорошего, если ты наткнешься на вопрос и получишь ответ, что этим можно пренебречь, если только ты не проявишь должное усердие. Сначала твоя проектная команда будет думать, что ты слишком стараешься и создаешь много дополнительной работы просто так. Но вскоре, делая предположения в спорах и подтверждениях, твоя проектная команда будет на это обращать внимание, особенно если они смогут показать свои знания или доказать свою точку зрения. Цель здесь – не выработать самый наилучший план, а прийти к наиболее подходящему. Особенно тщательно нужно придерживаться этого правила, если твой проект включает авторские права, креативные решения, интеллектуальную собственность, патенты, права собственности на данные или исследования. Если пропустить крошечную деталь, то можно взорвать твой проект, компанию или клиента. Поэтому не надо делать фальшивую экономию на таких деталях, а прикладывать необходимое количество усилий для гарантии того, что ничего не упущено.
Пример проекта из реальной жизни: На старте технического проекта в сфере медицинских услуг один из инженеров, работающих над проектом, вскользь упомнил о правах клиента на хранении данных на стороне провайдера. Лаура, Проектный Менеджер, была ответственна только за техническую часть проекта, но смогла увидеть влияние этого в общем-то юридического вопроса на проект. Поэтому она взяла на себя задачу проконтролировать, что юридическая служба и отдел снабжения не пропустят этот момент. Оказалось, что такого пункта в контракте вендора не существует и никто не подумал об этом. Заходя за территорию ожидаемой от нее ответственности, Лаура сделала то, что было правильно для проекта.
ПРАВИЛО #09 – ИСПОЛЬЗУЙ 360-ГРАДУСНЫЙ ПОДХОД
Быть Проектным Менеджером – это значит уметь думать и действовать в разных измерениях, независимо от количества компонентов, участников проекта и числа взаимозависимостей. В случае наличия нескольких Проектных Менеджеров на проекте, один на стороне клиента и один на стороне вендора, клиентский Проектный Менеджер обязан быть полностью ответственным. Он представляет Проектных Спонсоров и имеет право видеть деятельность на обеих сторонах. Полная ответственность за управление проектом не может быть разделена.
Однако, требование к Проектному Менеджеру иметь 360-градусное видение является категоричным для успешности проектов. В ином случае будут ошибки, разрывы, предположения и сферы ответственности, которые взорвут твой проект. Главная суть в том, что Ведущий Проектный Менеджер, независимо от того, с какого он Департамента, должен осознать свою ответственность за результат работы других Департаментов и команд. Это подразумевает наличие 360-градусного видения для планирования и управления всеми командами. Просто, но чрезвычайно эффективно и “must-have” для любого проекта.
Пример проекта из реальной жизни: Имея успешный опыт запуска нескольких проектов, Технический Проектный Менеджер Эрнесто предполагал, что проект переноса колл-центра будет достаточно легкой задачей. К его удивлению, он закончил его, работая с более чем тридцатью рабочими потоками, а количество людей в проекте достигло 150 человек. От команды обработки кредитных карт и отдела кадров до юристов, безопасников, закупщиков, сервисников обслуживания оборудования – перечень команд, вовлеченных в проект, был самым разнообразным из того, с чем ему приходилось работать ранее. Каждое и любое требование и ограничение этих команд, в основном не техническое, должно было быть записано и вплетено в первоначальный план для полной уверенности, что он всё охватил. Не считаясь с требованиями и ограничениями каждой команды, а также их внутренними взаимосвязями, можно было поставить весь проект в большую опасность. Эрнесто же вовлек все рабочие потоки и усилил видение всех взаимозависимостей до такой детальности, которая помогла ему закончить проект успешно.
ПРАВИЛО #10 – ПОЛУЧИ ПРАВИЛЬНУЮ ДЕТАЛИЗАЦИЮ И НУЖНЫЙ ВИД
Понимание того, какой уровень детализации надо иметь – это тонкое искусство. Слишком большая детализация – и ты потеряешь контроль над всей картиной. Слишком маленькая – и ты можешь пропустить что-то важное. Но для выполнения успешных проектов оба параметра должны приниматься во внимание. И ответственность Проектного Менеджера заключается в том, чтобы удостовериться, что ни один ключевой элемент не прошел сквозь сеть. Ключевая особенность – структурировать проектную информацию так, чтобы для широкой аудитории проекта в любое время было понятно, где они находятся сейчас и куда движутся.
Проектный Менеджер делает это путем переваривания всей детальной информации и раскрыванием только релевантных частей. Он делает это каждую неделю, обновляя инструменты и формы, используемые для пилотирования проекта. Но он делится с проектной командой только “краткой версией” этого детального списка задач, фокусируясь на задачах последней недели и следующих двух неделях, для каждого человека. “Ключевые вехи” также представляются каждую неделю, и команда может видеть свое положение внутри “большой схемы проекта”.
Пример проекта из реальной жизни: В международной рекламной компании были обнаружены интересные факты при взгляде на два идентичных проекта, выполненных различными Проектными Менеджерами в различных регионах. В том время как Люк – Европейский Проектный Менеджер – был обвинен за излишнюю детализацию, Бекки – Американская коллега – получила похвалу за свой легкий подход. По окончании, Американский проект попал в неприятности и имел нерешенные проблемы, тогда как Европейский проект был завершен без критических проблем. Различие было в том, что Люк не полагался на случай и погружался на тот уровень детализации, где чувствовал, что ничего важного не пропустил. А Бекки слишком сильно полагалась на членов своей проектной команды и не видела, что некоторые из них не были вовлечены в работу и были недостаточно проактивными для предотвращения ключевых проблем.
ПРАВИЛО #11 – СДЕЛАЙ ПРОВЕРКУ ОСНОВ В ПЕРВЫЙ ЖЕ ДЕНЬ
Итак, тебя назначили Проектным Менеджером и дали зеленый свет. С этого момента успех или неудача этого проекта – это ответственность Проектного Менеджера и его команды. Что будет дальше – зависит от тебя. Либо ты принимаешь проект, его содержание и требования как есть, либо используешь здравый смысл и выполняешь проверку базовых основ перед началом работы. Мы сильно рекомендуем последнее. Почему?
Конец ознакомительного фрагмента.