Самый главный хак!
Два дня назад у меня родилась дочь! Эта замечательная веха заставила меня посмотреть назад и взвесить все успехи и неудачи в моем Портфеле проектов под названием Жизнь.
И мне удалось прийти к выводам, которые вылились в хак с налетом философии (да простят меня любители простых технических решений!)
Итак:
- В портфеле Жизнь с первым приоритетом должны быть компоненты Семья и Здоровье, а потом все остальное.
- Успех проектов Семья и Здоровье – это основа для успеха в других проектах. Обратное неверно.
- Неуспех проектов Семья (а у меня не первый брак, но очень надеюсь, что последний) и Здоровье – прямая причина неуспехов в других проектах.
- Приоритет Семьи и Здоровья не означает, что мы должны отказываться от командировок, внеурочной работы и т.д. Главное – вовремя возвращать заимствованные ресурсы. А это прежде всего время, внимание, любовь и только потом деньги.
Да, звучит наивно, но, думаю, мой опыт будет полезным для 30-45 летних РП.
Риски проекта
Как просто обосновать меры реагирования на риски
В проекте после закупки нового оборудования были идентифицированы риски его поломки из-за низкой квалификации персонала.
Были запланированы две меры реагирования - обучение персонала и закупка запасного оборудования.
Стал вопрос, что выбрать и как обосновать затраты.
Мы использовали расчёт и сравнение ожидаемой денежной величины рисков - ЕМV (Expected Monetary Value) до и после применения мер с вычислением рычага мер по управлению рисками RL (Risk Leverage).
По оценкам экспертов вероятность ошибки персонала составила 70%, а убыток - 5 млн рублей.
EMV составила R0= 70%*(-5) = -3,5 млн.руб
Стоимость обучения S1= 0,5 млн, и оценка EMV после обучения составила R1=20%*(-3)= -0,6 млн.
RL1=(R1-R0)/S1=(-0,6-(-3,5))/ 0,5= 5,8
Это означает, что каждый рубль, потраченный на обучение, снижает EMV риска на 5,8, что может служить хорошим аргументом для обоснования затрат.
Рычаг по управлению рисками при закупке запасного оборудования стоимостью 1 млн рублей по оценке экспертов составил 2,8.
Стало понятно, что обучение эффективнее.
Лучшее обоснование - это цифры!
Избегайте ловушки при снижении рисков
Проблема: Предприняли все меры для снижения (mitigation) критического риска, а он все равно застал вас врасплох?
Решение:- Снижая величину критического риска, всегда продумывайте «план Б»
- При управлении рисками будьте немного «параноиком»
Приняв меры по снижению вероятности и последствий критического риска, руководители проекта часто на этом успокаиваются, переводя риск в разряд незначительных. Однако, если эти меры не сработают, РП могут столкнуться с неприятными неожиданностями.
Яркий пример тому – санкции подрядчику в договоре за невыполнение работы в срок. Много ли будет пользы от получения с подрядчика штрафных санкций в 100 тысяч рублей, если тот сорвал сроки выполнения работ на критическом пути, и это привело к миллионным потерям?
Если Вы работаете с критическим риском, всегда при принятии мер по снижению риска продумывайте, что Вы будете делать, если меры не сработают – готовьте «план Б».
При управлении рисками будьте немного «параноиком», загоняйте себя и команду в углы неудобными вопросами, и тогда риски не застанут Вас врасплох!
Персонал и коммуникации
Бесполезные и эффективные отчеты о статусе проекта
Часто я сталкиваюсь с бесполезными отчетами из серии “о чем вижу, о том и пою”. Они изобилуют фактами в тоннах, километрах, процентах завершения, отклонениями от плана, нерешенными вопросами.
В последнем проекте еженедельный отчет составлял около 60 страниц. На его создание каждую неделю тратилось не менее 10 человеко-дней. И, конечно, в большей части он был бесполезным.
Когда проект был передан в наше управление, мы существенно переработали отчет.
- Оставили только ключевые точки.
- Для каждого факта внесли план, прогноз и резерв по времени.
- Показали критические пути.
- Ввели показатели освоенного объема.
- Описали шаги для сокращения критических отклонений
- Добавили Топ-5 проблем и рисков.
- Отбросили все лишнее.
Теперь отчет занимал 8 страниц и не только показывал статус, но стал наконец отвечать на вопрос Заказчика о соответствии факта с планом, прогнозировать исполнение, показывать реальную критику.
В глазах Заказчика это стало “быстрой победой”. Он сразу заметил, что управление изменилось к лучшему.
Когда беспроблемный отчет – проблема!
На проектном комитете крупного нефтегазового проекта, куда я был приглашен как эксперт, рассматривались 4 проекта. Три были проблемными, а в последнем все было относительно хорошо – проект только входил в стройку.
Отчеты «проблемных» проектов изобиловали желтыми-красными цветами, тогда как в «хорошем» проекте превалировал зеленый.
Казалось, что у руководителя «хорошего» проекта проблем не будет. Но, если «проблемные» проекты рассматривались по 30 минут, то «хороший» проект обсуждался битых 2 часа!
Заказчик, найдя незначительные несоответствия в цифрах и датах, стал «раскручивать клубок». В результате проблемы были вскрыты, и, хотя по масштабу они были меньше, руководителю «хорошего» проекта досталось в разы больше остальных.
Два совета, если у вас в проекте все хорошо:
- Показывайте проблемы. В большом проекте они всегда есть. Если проблем действительно нет, показывайте риски.
- Будьте готовы к изучению «под микроскопом». Заказчик, получив «зеленый» отчет, думает, что его вводят в заблуждение и попытается вас вывести на «чистую воду».
Рисуйте картину проекта разными красками!
Приоритеты и матрица
В компании, где мы вели крупный проект в качестве PMC-подрядчика, основной проблемой были ресурсы.
Помимо нашего, велось еще 10 проектов. Все команды были сформированы по матричному принципу.
Ситуация становилась катастрофической - проекты увязали в ресурсных конфликтах, и генеральный директор попросил нас «что-то придумать».
Вместе с проектным офисом мы ввели простой метод, который позволил быстро изменить ситуацию к лучшему.
Членам проектного комитета было предложено определить приоритет проекта от 0 до 10. Оценки выставлялись независимо, и, если они сильно отличались, то заслушивались крайние мнения. Генеральный директор имел право коррекции получившейся оценки.
В результате каждый проект получил свой приоритет, операционная деятельность по умолчанию имела оценку 5.
При конфликте сравнивались приоритеты, и ресурс выделялся тому, у кого он был выше. «Проигравший» имел право апелляции, которая оперативно рассматривалась директором проектного офиса, наделенным правом принятия решения между комитетами.
В дальнейшем система приоритетов была усовершенствована, но первые результаты были получены благодаря простой процедуре приоритизации.
Определяйте приоритеты!
Как реагировать на моську…
Несколько лет назад в моем проекте мне пришлось расстаться с неэффективным членом команды: по согласию сторон, с графиком выплаты остатка зарплаты.
В проекте возникли задержки с финансированием, что вынудило меня обратиться с просьбой о пролонгации выплат. В ответ – шантаж публичной оглаской и судом.
Мое правило – с «террористами» переговоров не вести. Он выиграл суд и через год получил свое сполна. Казалось, конфликт был решен.
Но родилась моська… Упиваясь своей значимостью, она стала писать посты в соцсетях, демонизирующие и очерняющие меня и проект под видом борьбы за «глобальную справедливость».
Правила работы с моськами, которые я усвоил:
- Не отвлекайтесь и идите к своей цели! Если моськи лают, значит вы слон :-)!
- Не вступайте с моськами в диалог. Им нужно попиариться на вас, по-другому добиться известности они не могут.
- Не бойтесь последствий «лая» – думающие люди мосек видят сразу.
Два простых приема, как все-таки встретиться с Заказчиком
В одном из моих проектов основной проблемой был Заказчик. Несмотря на то, что он сам предложил обязательные еженедельные встречи, он был недоступен.
Его график был перегружен и постоянно «плыл». Все мои попытки переложить функцию Заказчика на кого-нибудь из его замов терпели фиаско – он не хотел никому делегировать проект. Вопросы не решались, проект останавливался.
Как-то мы неожиданно встретились на лестнице в офисе (мы оба предпочитали не пользоваться лифтом для укрепления здоровья). Благодаря двум нехитрым приемам мне удалось решить все накопившиеся вопросы:
- Elevator speech. Я заранее знал, что и как я буду говорить, когда мы с ним встретимся «на ходу», чтобы за 30 секунд возбудить интерес к проекту.
- «Тревожный чемоданчик». Мой администратор постоянно готовил и обновлял комплект материалов. Я был готов к встрече в любой момент.
Первый прием оказался успешным – через 15 минут была назначена встреча, где я с «тревожным чемоданчиком» решил все необходимые вопросы.
Ловите момент и будьте готовы к неожиданному!
Соцсоревнование никто не отменял!
Этим приемом поделились с нами английские коллеги, когда мы приехали к ним в Лондон для обмена опытом управления проектами строительства Олимпийских и гражданских объектов.
На проекте строительства небоскреба, которым они управляли, подошла очередь отделочных работ. Аккредитацию прошли 10 подрядчиков практически с одинаковыми ценами, опытом и качеством.
Для организации работ пула подрядчиков был применен простой, но крайне эффективный метод.
Каждому подрядчику был отведен одинаковый объем работ (работы можно было выполнять параллельно). Каждый месяц работы каждого подрядчика оценивались по параметрам выполнения сроков, качества и соблюдения техники безопасности.
После каждого подведения итогов определялся аутсайдер и победитель. С аутсайдером контракт не продлевался, а его объем работ отдавался победителям.
В результате через 7 месяцев были отобраны 3 подрядчика, с которыми были заключены контракты на оставшиеся объемы работ.
Заставь подрядчиков соревноваться и властвуй!
Конфликт «погон», или когда лейтенант командует генералом
В одном из моих проектов в матричную команду, входил в качестве эксперта заместитель генерального директора на 10% рабочего времени.
На первой встрече, поставив ему задачу, я в ответ услышал: «А ты кто такой, собственно, чтобы мне указывать?». Действительно, мое положение в компании было гораздо ниже.
Существует два известных мне способа решения этого конфликта:
- Придание РП полномочий и положения выше, чем у всех участников рабочей группы. Применимо для критически важных проектов
- Фиксация и отстаивание принципа «В рамках проекта все участники, несмотря на положение, подчиняются РП».
В моей ситуации мне пришлось напомнить о моих полномочиях, и меня поддержал Спонсор проекта, который понимал, к чему приведет то, что в команде все начнут вспоминать о своих должностях.
Важно, чтобы этот принцип поддерживался в корпоративной системе управления и был зафиксирован в плане управления проектом.
Отстаивайте свои полномочия и командуйте генералами!
«Наряд на песчаный карьер», или когда все могут, но никто не хочет.
В проекте возникла задача, которую могут (по квалификации и занятости) выполнить несколько человек, но никто не хочет ее делать. Например, поехать в командировку на «песчаный карьер», составить отчет и т.д.
При попытке назначения вы слышите в ответ: «Почему я? Почему не он?», «Огласите весь список, пожалуйста».
Несколько правил для выхода из ситуации:
- Выберите исполнителя. У всех нас разные мотивы что-то делать и не делать. Выберите из кандидатов того, у кого самая большая разность потенциалов между положительной и отрицательной мотивацией (расскажу об этом подробнее в одном из следующих PM-хаков), причем чем больше положительных мотивов, тем лучше. Если вы не знаете кандидатов, выбирайте наугад.
- Назначайте исполнителя наедине, избегайте демократии («Кто возьмется?»).
- Твердо пресекайте все дискуссии. Главный аргумент – «Это мое решение, и я не обязан его обсуждать!»
- В случае отказа применяйте жёсткие взыскательные меры, использовав формальную власть.
Помните, что вы ставите задачи перед исполнителями, а не наоборот!
«Бывают дни, когда опустишь руки…», или о выходе из личного кризиса в проекте
Когда вас назначают руководителем проекта, вы собираетесь внутренне и внешне, физически и морально - перед вами поставлена цель и вам вместе с командой предстоит долго к ней идти.
У вас резко вырастает способность противостоять стрессам, решать задачи и проблемы, вырастает ваша продуктивность.
Однако через некоторое время силы (моральные, физические) истощаются. Часто именно тогда приходит состояние, когда кажется, что все плохо, что в проекте куча проблем, падает ваша вера в успех, опускаются руки, хочется все бросить…
Есть одно универсальное, но крайне эффективное правило выхода из этого состояния, которое всегда мне помогает:
Не принимайте в такой ситуации решений – сначала восстановите силы! Не все так плохо! Именно истощение сил окрашивает ситуацию в вашем восприятии в мрачные тона.
Как восстановить силы – это индивидуальный вопрос. Изучите литературу по управлению стрессами, повышению энергетики, мотивации – там много разных советов, что-то точно подойдет. О некоторых я расскажу в своих следующих хаках.
Утро вечера мудренее!
Как защитить план проекта за 15 минут, или План-карта проекта
В одном из проектов мне нужно было защитить план у очень большого руководителя. Хотя мне было выделено целых 2 часа, я рассчитывал максимум на 15 минут, так как график босса постоянно “плыл” …. Более того, я знал, что он, как правило, больше одной страницы не смотрит, а мой План составлял более 100 страниц.
На встречу, нарушив все регламенты проектного офиса, я подготовил документ, который назвал «План-карта» проекта:
- На большом листе А3 выделил 6 областей, в каждой из которых поместил выдержки ключевых разделов планов - содержание, график, оргструктуру, риски и т.д;
- Заручился поддержкой проектного офиса в том, что План-карта соответствует Плану.
Босс внимательно изучил План-карту, задал уточняющие вопросы и утвердил План за 15 минут!
В заключение он сказал: “Вот, наконец-то проектный офис начал работать! Хороший формат предложили! Теперь все планы будем утверждать так!”
Награждение непричастных сработало!
Трясина совещаний
Большую часть времени ключевые участники проектов часто проводят в бесконечных совещаниях. «Работать некогда» жалуются они и идут на следующее...
Этому есть 2 причины:
- Плохая организация - излишнее количество участников, отсутствие или запоздалое подписание протоколов, длительность более часа, нечеткая повестка.
- Неосознанное, а зачастую и сознательное стремление участников проекта разделить ответственность за принятие решений с окружающими.
Эффективное совещание является мощным коммуникационным инструментом для быстрого обмена идеями, информацией, но, к сожалению, этот инструмент очень дорогой – 10 человек на часовом совещании тратят 10 часов работы!
Чтобы часы не пропадали, используйте несколько советов:
- Все совещания – только с вашей санкции как РП. И тогда вы принимаете решение, стоит ли собирать 10 человек или двое могут решить вопрос по телефону.
- Квалифицированный администратор проекта обеспечит повестку, тайминг, предварительное предоставление материалов, протокол с ответственными и сроками, ведение журнала контроля поручений.
- Подписывайте протокол сразу по окончании совещании, выведя его на экран.
Кто управляет коммуникациями – тот управляет проектом!
Сроки, бюджет, качество
Как погасить безнадежное отставание
Мы вошли в проект, где сроки горели синим пламенем. Основной задачей стало сокращение отставания до минимума (день задержки стоил около 20 млн рублей).
В команде, которая работала практически круглосуточно, царили авралы и неверие в своевременный запуск проекта.
Мы сделали три простых шага:
- Зафиксировали минимальный пусковой комплекс. Было очевидно, что весь объем в сроки выполнить невозможно. Однако, объект можно было запустить в урезанном варианте, а затем на следующих очередях закончить все остальное.
- Определили приоритеты работ. Временной резерв в календарно-сетевой модели показывает, как каждая работа задерживает срок окончания проекта. Выписав работы в порядке возрастания резерва, мы расставили приоритеты.
- Запустили раскрутку критического пути. Ежедневно проводилась встреча с участием руководителей проекта и соответствующих служб, где планировщик показывал критический путь, и мы принимали точечные решения, как его сжать.
В результате сроки запуска проекта были сокращены с 123 дней до 21. Наша команда многократно себя окупила.
Рецепт прост – жесткие рамки и фокус на приоритетах!
Без чего невозможно качество
Мы были приглашены вытащить горящий проект строительства объекта. Бюджет был уже превышен вдвое, сроки сдачи переносились три раза.
В одной из зон объекта подрядчик сдавал внутреннюю отделку. Председатель комиссии заходил в очередную комнату, «стрелял глазом», выносил вердикт «Некачественная отделка!» и карандашом ставил на стене крест.
Когда была испорчена уже треть стен, подрядчик взмолился и начал доказывать, что отделка качественная. Эмоции накалялись и грозили перерасти в серьезный конфликт.
Наш руководитель проекта быстро нашел решение.
Вначале он посмотрел договор с подрядчиком. К его большому удивлению, кроме слов «произвести качественную отделку», в договоре никаких измеримых критериев не было.
Тогда он собрал стороны и предложил следовать критериям СНиП, где четко прописано требование к высококачественной отделке – отклонение по вертикали не более 1 мм на 1 м.
Только после того, как были установлены измеримые требования (кстати, они могли быть не обязательно по СНиП), стало возможным оценивать качество.
Чтобы говорить о качестве, сначала определите измеримые требования!
Не спешите радоваться красивым цифрам бюджета!
Допустим, вы строите дорогу. Плановая стоимость 1 км - 10 млн. рублей, и на сегодня должны были построить 10 км. Реальные затраты составили 90 млн.
Что можно сказать о проекте? Только то, что потратили меньше (90), чем должны были по плану (100)… К сожалению, именно так контролируются бюджеты многих проектов и делаются неправильные выводы о реальной картине.
Чтобы узнать «здоровье» проекта, нужна еще одна цифра – освоение (плановая стоимость завершенных работ).
Допустим, вы построили 11 км, и тогда ваше освоение составило 110 млн. Тогда мы можем сказать, что опережаем сроки (освоили больше плана) и сэкономили деньги (вместо 110 млн потратили 90).
Просчитайте ситуацию, когда мы построили 9,5 км. Правильно, отстали по срокам (не освоили 5 млн), но сэкономили деньги (5 млн).
Я изложил основной принцип методики Earned Value Analysis (анализа освоенного объема). На первый взгляд все просто, но есть много подводных камней, о которых расскажу в следующих хаках.
Не всегда верьте цифрам!
«Лягушка в кипятке», или о ползущих сроках
Известно, что если лягушку поместить в медленно нагревающуюся воду, то она не выпрыгнет и сварится, постепенно привыкнув к повышению температуры…
Зачастую можно наблюдать тот же эффект в проектах – находится масса причин, почему работа, которая должна быть сделана сегодня, будет выполнена потом. В результате, из-за вала небольших (и на первый взгляд несущественных) сдвигов сроков временные резервы тают, и весь проект выходит за дедлайны.
Чтобы не свариться, как лягушка, следуйте правилам:
- Регулярно контролируйте резервы;
- Увеличивайте резервы, ставя исполнителям гораздо более жесткие сроки, чем нужно; (см. PM-хак "Золотое правило управления сроками в проекте")
- Вводите ощутимую ответственность за срыв сроков;
- При факте (а еще лучше прогнозе) срыва сроков включайте ежедневный (ежечасный) контроль исполнения.
Степень жесткости в п 2-4 должна возрастать в разы для работ на критическом пути.
Правда, нужно держать во внимании армейский принцип «Не спеши делать работу, так как может последовать команда “Отставить”!»
Но вы, а не исполнители должны определять его применимость!
Золотое правило управления сроками в проекте
Что делать, если исполнители постоянно срывают сроки?
Допустим, есть три оценки длительности работы:
- оптимистичная – 4 дня,
- вероятная – 6 дней,
- пессимистичная – 10 дней.
Какой срок установить для выполнения работ?
Если выбрать 6, то чем будет заниматься исполнитель первые 2 дня, зная, что в принципе он может все успеть за 4? В 90% случаях - всем чем угодно, только не работой проекта. В результате, работа будет сделана за 8 и более дней.
Любой резерв, который вы дадите исполнителю, будет им израсходован впустую!
С другой стороны, если вы каждый раз будете заставлять исполнителя выполнять работы в оптимистичные сроки, он будет закладывать резервы в своих оценках.
Следуйте правилу:
- На работах критического пути ставьте максимально жесткие сроки.
- На работах с запасом по срокам, вы можете позволить дать исполнителю резерв, но должны заранее учесть вероятную задержку, чтобы не оказаться на критическом пути.
Временные резервы должны быть у вас, а не у исполнителей!
Стейкхолдеры проекта
Когда в стейкхолдерах согласия нет, или об ограничениях и их приоритетах
В проекте важно все: сроки, бюджет, содержание, качество. Однако всегда есть что-то более важное. Большинство решений принимается в угоду одному и в ущерб другому.
Мы проводили экспертизу управления проектом строительства цеха на крупном заводе. На первый взгляд в проекте все было хорошо, но Заказчик жаловался, что руководитель проекта «не так расставляет акценты».
Простой прием позволил нам быстро вскрыть причину.
Руководитель и Заказчик проекта независимо описали ограничения и определили их приоритет методом попарных сравнений. В табличке (похожей на турнирную) нужно было определить, что более важно, например, сроки или качество, объем или бюджет и т.д.
Заказчик на первое место поставил сроки, затем - объем, качество и бюджет. Руководитель проекта – бюджет, сроки, качество, объем.
В этом и лежала причина разногласий – Заказчику нужно было запуститься как можно раньше, а Руководитель проекта экономил деньги!
После того, как были утверждены приоритеты, многое встало на свои места.
Убедитесь, что приоритеты всем одинаково понятны!
Как изолировать стейкхолдера
Практически в каждом проекте существуют персонажи (стейкхолдеры), которые по разным причинам так или иначе мешают проекту. Некоторые это делают явно, другие вставляют палки в колеса, на словах поддерживая проект.
В проекте внедрения ИТ-системы в нескольких ведомствах нашему руководителю проекта активно «помогал» один из Директоров департамента. Затягивание согласований, неконструктивная критика, открытые выпады против проекта были его основными приемами. Мы все знали, что изначально он лоббировал другого поставщика ИТ-системы.
К сожалению, на него не было управы. Все наши обращения к Заказчику проекта оставались без результата.
Тогда наш Руководитель проекта применил эффективный прием.
Каждый раз, когда наш «доброжелатель» интересовался, как идет проект, РП сознательно рисовал ему безрадостную картину. Хотя все шло по плану, РП акцентировал внимание на том, что у проекта большие риски и надо ещё постараться, чтобы он стал успешным.
Получая такую информацию, стейкхолдер успокаивался и существенно снижал свое сопротивление проекту. Это сэкономило много времени и усилий.
Формируйте нужную картинку у стейкхолдеров!
Дефект “черной дыры” в проекте. Как избежать?
Проект успешно стартовал. Назначен РП, утверждены планы. Первые результаты будут через год.
И хотя все отлично организовано и идет по плану, через некоторое время у Заказчика и Спонсора возникает все больше вопросов. Куда тратятся деньги? Зачем набирается столько людей? Чем они там занимаются? Получим ли результаты и когда? Возникает дефект “черной информационной дыры”.
Заказчик, конечно, получает формальные отчеты в соответствии с планом коммуникаций, но его беспокойство все больше усиливается. В некоторых случаях это может привести к смене Руководителя проекта и остановке проекта.
Чтобы избежать плачевного финала Руководителю проекта необходимо следовать правилам работы со стейкхолдерами:
- Встречайтесь чаще и объясняйте, что происходит в том числе за рамками официальных коммуникаций;
- Помните, что хорошая работа незаметна. Регулярно показывайте, что творится в проекте, чем занята команда и каким трудом достигаются результаты.
- И излучайте уверенность в успехе в любом случае!.
Создавайте нужную информационную картину для стейкхолдеров и получайте соответствующую реакцию!
Интеграция проекта
Если ваш проект не в приоритете
Часто руководители проектов осознают, что проект не важен для компании. Иногда невысокий приоритет устанавливается при инициации, часто проект теряет приоритет на середине исполнения при появлении более важных. Самая разочаровывающая ситуация – когда руководство декларирует, что проект очень важен, а на самом деле это не так.
Что можно сделать, если проект «не в приоритете»?
Смириться. Если проект действительно не приоритетен для компании, то не надо выдувать «из мухи слона» – сконцентрируйтесь на эффективном управлении в текущих условиях.
Бороться. Если считаете, что проект заслуживает большего приоритета, – подумайте, как повысить его значимость у стейкхолдеров.
Управлять изменениями. В неприоритетных проектах вовремя не выделяются ресурсы и не принимаются решения. Не оставляйте это «безнаказанным» – изменяйте в соответствии с процедурами базовые планы!
Не отдавайте ресурсы без боя. Для успеха ваша позиция должна быть аргументирована. Например, вам нужны ресурсы для критического пути, а в приоритетном проекте эти ресурсы привлекаются на работы с резервом.
Важен не приоритет, а тактика!
Что делать с отклонениями, когда их много!
Как-то я был приглашен на Наблюдательный совет одной из крупнейших программ в России.
Первое, что поразило – количество участников – более 50! Центральным вопросом было обсуждение отклонений в Плане-графике строительства объектов. Просроченных контрольных точек тогда было 185.
Начался совет с гневной тирады Председателя на тему «Никто работать не умеет!», а продолжился обсуждением отклонений в соответствии с номером строчки программы.
Как вы думаете, сколько отклонений удалось обсудить за 4-5 часов работы? Правильно, максимум 15-20!
Следующий Набсовет прошел гораздо эффективней, так как мы ввели усовершенствование.
Все отклонения мы разбили на классы:
- Класс А – отклонения на критическом пути Программы
- Класс B – отклонения на задачах с 2-месячным резервом
- Класс С – отклонения на задачах с резервом более 2 месяцев
В класс А вошло только 5 отклонений, и только они стали предметом обсуждения на новом Набсовете!
Все просто, конечно, с первого взгляда. Чтобы это заработало, мы сделали календарно-сетевую модель Программы и выделили критический путь.
Определяйте приоритеты!
Когда один в поле воин, или о PMC
В 2011 году ко мне обратился вновь назначенный Директор крупного проекта (Программы) по освоению масштабного нефтегазового месторождения в Новом Уренгое.
Ему необходимо было быстро наладить управление программой и входящими в нее 6 проектами.
В создаваемом Проектном офисе на то время было 4 человека. Все проекты были на стадии разработки ПИР, некоторые переходили на стадию стройки.
Для решения этого вопроса мы предложили передать нам операционное управление проектами как PMC-подрядчику (Project Management Contractor) с последующей заменой на штатную команду управления. В результате:
- в течение одного месяца мы мобилизовали команду из 25 руководителей проектов, планировщиков, администраторов, методологов и риск-менеджеров;
- в течение трех месяцев команда разработала и защитила планы управления и исполнения проектами, календарно-сетевую модель, и включилась в операционное управление;
- в течение 9 месяцев был проведен плановый поиск штатной команды с передачей ей функций управления проектами.
Опыт был признан успешным и тиражирован на другие проекты компании.
Когда нет своих профи в управлении проектами, нанимайте «варягов»!
Содержание проекта
Как заставить Заказчика понять, что он получит
Часто заказчики, зная основную цель, не желают входить в детали результатов проекта.
Руководители проекта, наоборот, стараются подробно описать содержание проекта. В результате – конфликт, который возникает, когда поздно уже что-то изменить – при передаче результатов.
Я использую простой прием, который заставляет Заказчика вчитываться в документы.
Первым пунктом я рассказываю о цели проекта. Эту стадию Заказчик проходит довольно быстро, так как он «и без вас все это знает!».
А вот вторым пунктом я рассказываю про исключения проекта – что он точно не получит в проекте!
Вот тут-то Заказчик «просыпается» и начинает задавать вопросы: «Как? Этого не будет? И этого!? А что все-таки будет?».
Цель достигнута! И пусть возникают споры и конфликты! Лучше, если они возникнут в самом начале проекта, чем при сдаче результатов.
Естественно, исключения проекта нужно очень хорошо продумать и говорить про то, что Заказчик действительно может ожидать, но не сможет получить в рамках вашего проекта.
Будите спящего Заказчика!
Именно из-за этого идеи остаются идеями
Как-то заказчик пригласил меня выступить коучем руководителя проекта по выводу нового продукта на финансовый рынок. Проект был инициирован, идея утверждена, команда назначена.
РП собрал экспертов «побрейнштормить» план проекта. Вначале все шло гладко, но через полчаса начались вопросы: «А где мы возьмем финансы?», «А кто это будет делать?», «В какой последовательности нужно что делать?», «Мы, вообще, то, что нужно, делаем?». В результате дискуссия на тему «как сделать?» перешла на обсуждение «почему сделать нельзя»!
После совещания я посоветовал РП последовательно сделать два шага:
- Сначала зафиксируйте Цель проекта. Техника SMART и ответ на вопрос “Что не делаем?” помогут прийти к однозначному ее пониманию. (см. PM-хак «Главный секрет достижения цели в проекте, или о букве А в критерии SMART»)
- Затем на основании цели, постройте иерархическую структуру работ (ИСР). Здесь самое важное – сами работы. Остальные вопросы (сроки, ресурсы, зависимости) оставьте на дальнейшее планирование!
Следующая встреча прошла гораздо эффективнее, а в ИСР, среди прочих, появились работы «поиск финансирования» и «поиск ресурсов».
Всегда ищите, как сделать!
Как не попасть в ловушку «хотелок» Заказчика?
Проект подходит к завершению, и вы передаете продукт проекта. В большинстве случаев Заказчик только в этот момент начинает понимать, что он получит в действительности.
В этой ситуации неизбежен поток небольших пожеланий, не оговоренных раннее в содержании проекта (например, в ТЗ). «Хотелки» действительно небольшие, и, допустим, у вас еще остались на них ресурсы.
Возможны 3 варианта:
- соглашаетесь – создаете прецедент, который заставит принимать дальнейшие пожелания, что может привести к существенному разрастанию границ проекта;
- настаиваете на процедуре управления изменениями - рискуете прослыть бюрократом (изменения слишком мелкие);
- отказываете – получаете шанс испортить отношения с Заказчиком.
Чтобы избежать ловушки, следуйте двум правилам:
- При планировании заранее закладывайте резерв на «хотелки». Лучше, если он будет явно оговорен с Заказчиком.
- Принимайте изменения в рамках резерва, но сразу же устанавливайте границы, после которых вы будете настаивать на процедуре управления изменениями.
Будьте проактивными в отношении с Заказчиком и не позволяйте загонять себя в ловушку!
Инициация проекта
Главный секрет достижения цели в проекте, или о букве А в критерии SMART.
Проблема: Цель гораздо шире, чем проект?
Решение:- Ставьте цели, достижимые проектом;
- Если заказчик настаивает на большем, требуйте расширений рамок проекта и своих полномочий.
Критерий SMART говорит, что цель должна быть:
- определена через спецификации (S),
- измерима (M),
- достижима (A),
- выражена в результатах (R)
- к определенному сроку (T).
Проблема возникает в букве А. Перед проектом часто ставятся достижимые цели в принципе, но недостижимые в рамках конкретного проекта.
Например, перед РП строительства ставится цель окупаемости объекта. Однако, если вы отвечаете только за стройку, но не участвовали в этапе ТЭО и не контролируете дальнейшую эксплуатацию объекта, Вы не можете отвечать за его окупаемость!
Заказчик все же настаивает на более широкой цели (достижении выгоды)? Требуйте расширения границ проекта и своих полномочий (возможно, до руководителя Программы).
Главный секрет достижения цели прост:
Цель должны соответствовать границам проекта и Вашим полномочиям!
Идеальный тандем крупного проекта
Проблема: Сложно определить команду управления крупным проектом?
Решение:- Идеальный тандем – харизматичный РП + его заместитель, системно реализующий технологию управления проектами
- Если РП – «технарь», назначьте в его заместители операционного руководителя проекта
Для успеха крупного проекта важно, чтобы его возглавлял яркий харизматичный лидер, однако такие руководители часто управляют проектом в «ручном» режиме.
В этом случае идеальная конфигурация - яркий лидер + его заместитель – профессиональный РП, системно реализующий технологию проектного управления.
На практике руководителем (директором) крупного проекта часто назначается опытный технический эксперт (ГИП, строитель, IT-специалист). Чтобы проект также не скатился в ручное управление, его заместителем должен быть операционный РП, основная задача которого – профессиональное системное управление проектом.
Кто бы ни возглавлял проект, важно, чтобы был ответственный за технологию управления проектом!
4 рецепта простой и быстрой инициации
Проблема: инициация проектов затягивается, и проект никак не стартует?
Решение:- Инициируйте планирование, а не реализацию
- Фиксируйте существование проекта, его цель и назначение руководителя проекта
- То, что непонятно, уточняйте на стадии планирования
- Устав – ТЗ для создания плана проекта
Инициация проектов, особенно внутренних, часто занимает длительное время. Это происходит из-за того, что вместо легкого документа, запускающего планирование проекта, делаются попытки сразу создать полноценный план проекта и начать его реализацию.
Хотя Вы можете внести в Устав (паспорт, приказ, карточку проекта) все, что на данный момент известно о проекте, в нем должно фиксироваться как минимум 3 факта – существование проекта, его цель и назначение РП. Цель, а также остальные параметры проекта подлежат уточнению при дальнейшем планировании и могут рассматриваться как ТЗ для создания плана проекта.
Делайте инициацию проекта легкой!
РП: менеджер или технарь?
Проблема: Проект погряз в технических деталях и ведется бессистемно? Возможно, проектом управляет хороший технический специалист (“технарь”), но плохой менеджер.
Решение:- Если есть выбор, назначайте Руководителем проекта менеджера со знанием технологий, а не «технаря» со знанием менеджмента.
- Если выбора нет, развивайте управленческие навыки технического специалиста
- В команде у Руководителя проекта должны быть «технари», а не наоборот
Конечно, самый лучший руководитель проекта – это и талантливый специалист, и прирожденный менеджер. Ярким представителем такого типа руководителя был Сергей Павлович Королев. Если у вас такой РП, вам очень повезло. Однако таких людей очень мало, и на ваш проект может не хватить.
Так как самая важная задача управления проектам – интеграция, руководителем проекта должен быть прежде всего хороший менеджер, владеющий технологиями управления проектами, обладающий хорошими лидерскими и организаторскими навыками. Знание технологий для него, конечно, важно, но вторично.
Одна из важнейших задач эффективного Руководителя проекта – собрать в своей команде лучших экспертов в нужных предметных областях и организовать управление ими.
Лучше менеджер с командой экспертов, а не технарь с командой менеджеров!
Когда РП не должен отвечать за успех проекта
Проблема: Проект размыт и сложно взять ответственность за его успех?
Решение:- Назначаете кого-то на роль – определите его ответственность и полномочия
- При инициации руководитель проекта отвечает за создание плана проекта, при утверждении плана – за успех проекта
- Дайте Руководителю проекта полномочия по привлечению экспертов
При инициации проекта многие положения Устава подлежат дальнейшему уточнению в ходе создания базового плана проекта. В этих условиях отвечать за успех проекта – безрассудство и большие риски.
Единственное, за что может и должен отвечать РП при инициации – это создание базового плана проекта к установленному сроку при условии наличия полномочий по привлечению необходимых экспертов.
Определяйте ответственность в соответствии с моментом!
Источник http://www.pmexpert.ru/pm-hack/
