В статье нет теории, ведь она достаточно хорошо разработана и описана в десятках других статей, книг и стандартах. В статье приведены только лайфхаки — приемы, которые подтверждены практикой их применения, и которые помогут молодым руководителям проектов делать поменьше ошибок и сберечь побольше нервов себе, членам проектных команд и ключевым стейкхолдерам.
Все приведенные лайфхаки являются выжимкой моего 15-летнего опыта работы в сфере реализации проектов, из которых первые семь лет я выступал в роли участника проектной команды, а затем восемь лет в роли руководителя проектов.
1. Управлять проектом стратегически, а не операционно
Если при управлении проектом вы то и дело тушите пожары, а не занимаетесь размеренным управлением по всем направлениям, то значит есть фундаментальные системные ошибки: либо у вас, либо в проектной деятельности организации.
Управление проектом — это, в первую очередь, стратегический менеджмент, а не операционный, и уж тем более не инцидент менеджмент.
Давайте разберем ситуации, когда это не так:
Ошибка руководителя проекта
Наиболее популярные причины:
- Вы привыкли к микроменеджменту.
- Команда проекта постоянно обращается вам, и вы «с радостью решаете их задачи».
- Вы — перфекционист, трудоголик и т. д.
Решение тут одно — начните менять себя и свое взаимодействие с командой:
- Не контролируйте каждое действие команды, сократите количество встреч с командой, поставьте каждому участнику команды индивидуальные цели, определите зоны ответственности каждого участника команды, и отслеживайте только эти цели и ключевые показатели проекта.
- Если команда проекта постоянно обращается к вам с проблемами/вопросами, то, во-первых, привейте культуру, чтобы без вариантов решений к вам не приходили, а, во-вторых, задумайтесь о смене тех или иных членов команды, (но только после того, как не помог первый ход с тем, чтобы приносить вам не только проблемы, но и решения).
- Перфекционизм, трудоголизм и прочее лечите общеизвестными народными методами (хобби, тайм-менеджмент и пр.).
Ошибка в методологии проектной деятельности
Такая ситуация более сложная, но все равно решаемая:
- Проанализируйте свою работу и донесите до руководства / до проектного офиса, какие потери и минусы приносит такое управление проектом (прежде всего потери времени).
- Вместе с описанием проблемы предложите решение (не информируйте только о проблеме).
- Предложите на вашем проекте сделать пилот по использованию другого подхода в методологии проектной деятельности, (не забудьте при этом зафиксировать критерии, по которым будете оценивать успешность нового подхода, и срок, когда будете оценивать).
- Радуйтесь, что ваш проект в пилоте, и спокойно управляйте им.
Эти советы достаточно сложны, требуют больших усилий и могут сразу не привести к нужным результатам. Но их применение гораздо лучше ситуации, если вы вообще ничего не делаете в данном направлении и продолжаете заниматься операционным и инцидент менеджментом.
2. Минимизировать бюрократию
В любом проекте бюрократия неизбежна. И с одной стороны, она отнимает большое количество сил и времени, но с другой стороны — закрывает для руководителя проекта многие риски. Вопрос, как найти баланс, который позволит не увязнуть в бюрократии и не превратить проект в сущий ад?
Обязательно делайте минимально необходимый для любого проекта набор документов. Это устав проекта, реестр рисков, требования (бизнес, функциональные, эксплуатационные), календарный план (по вехам), ресурсный план, бюджет, протоколы испытаний и акты приемки. В различных проектах/компаниях названия данных документов могут варьироваться, поэтому ниже приведено описание документов в терминах «Для чего они нужны в проекте?».
|
Документ |
Для чего нужен |
|
Устав проекта |
Для фиксации цели, ожидаемых результатов и критериев успешности проекта |
|
Реестр рисков |
Для системного управления рисками в проекте |
|
Требования |
Для того, чтобы получить на выходе проекта то, что нужно заказчику |
|
Календарный план |
Для управления расписанием проекта и одинакового понимания всеми участниками проекта промежуточных результатов и сроков |
|
Ресурсный план |
Для контроля привлечения и получения ресурсов в ходе проекта |
|
Бюджет |
Для избегания кассового разрыва в ходе проекта |
|
Протокол испытаний |
Для фиксирования того, что результаты проекта соответствуют ожидаемым |
|
Акт приемки |
Для фиксирования факта приемки результатов проекта и их передачи в линейную деятельность |
По любым дополнительным документам (сверх данного минимально необходимого перечня) необходимо иметь ответ на вопрос — для чего они нужны? Какие риски они закрывают, какие задачи помогают решить? Может, в проекте нужен документ под названием «Итоговый отчет». Если в проекте много нематериальных составляющих, это заметно упростит сдачу результатов проекта. Или в проекте нужен документ под названием «Карта стейкхолдеров», так как в проекте огромное количество заинтересованных сторон.
При согласовании документов обязательно оценивайте:
- Насколько необходимо согласование с каждой стороной. Что это даст и что будет, если не согласовывать?
- Является ли перечень согласовантов полным? Не забыли ли вы кого включить в него?
И еще одно общее правило: если сомневаетесь, нужен документ или нет, или нужно включать в согласованты какую-то сторону или нет, то лучше подготовить такой документ и включить в согласованты эту сторону.
3. Визуализировать производительность и близость дедлайна
В бизнес-романе Тома Демарко есть отличная фраза: «День, потерянный в начале проекта, значит так же много, как и день, потерянный в конце». Но все знают, как бывает тяжело в начале проекта заставить работать себя и команду так же эффективно, как и при приближении дедлайна. Времени же еще много. И такой подход очень сложно сломить, так как заложен он у нас чуть ли ни на генетическом уровне со студенческой скамьи. И называется он даже с отсылкой на то время — «студенческий синдром».
Но есть некоторые лайфхаки, которые, если и не сводят влияние этого синдрома на нет, то заметно снижают:
- Посчитайте, сколько рабочих дней длится проект.
- Каждый день ведите отсчет того, сколько дней и процентов времени осталось до конца проекта, сколько дней и процентов времени прошло с начала проекта.
- Визуализируйте эту информацию так, чтобы каждый член проектной команды каждый день видел этот отсчет — через некоторое время все увидят, что, на самом деле, дедлайн приближается быстро и времени-то не так уж и много.
- Эта визуализация приводит к тому, что на подсознательном уровне все ведут себя более ответственно, сосредоточенно и продуктивно.
- Ну, а если на некоторых членов проектной команды такой подход не окажет никакого влияния, то это, как минимум, повод задуматься о том, что с ним надо расстаться.
- Если в проекте можно измерять процент выполненной работы, то наложите на визуализацию приближения дедлайна еще и визуализацию с процентом выполненной работы (как, например, это сделано в Scrum в Burn Down Chart или в подходе Earned Value Management в PMBok) — в этом случае ответственность, сосредоточенность и продуктивность проектной команды увеличится еще в несколько раз.
- При необходимости такую визуализацию можно делать не только со всем проектом, но и с отдельной его фазой.
4. Сокращать ненужные усилия
Практически любой результат в проекте, (в том числе и промежуточный), можно получить несколькими разными способами.
Можно заморочиться и делать супер-мега навороченный функционал, максимально целевым способом, который, если что, сможет позволить в дальнейшем, при необходимости, делать еще что-то и т. д. А можно сделать максимально просто с минимальными усилиями то, что нужно. Не больше и не меньше, а ровно то, что нужно. Это самый правильный и эффективный подход.
Сделайте минимальный (можно даже промежуточный) результат/функционал, покажите его заказчику, обкатайте на клиентах. Посмотрите на реакцию, и вы поймете, в правильном ли направлении вы двигаетесь, и надо ли что-то подправить.
Если же сразу все делать «по уму» и с желанием произвести эффект от масштабов проделанной работы/дополнительными возможностями и т. д., то, скорее всего, вы «сядете в лужу». С высокой вероятностью эти дополнительные возможности никому будут не нужны, и бОльшая часть результатов проделанной масштабной работы уйдет в корзину.
5. Принимать решения как можно раньше
Руководитель проекта каждый день должен принимать решения. Это его основная работа. От скорости и качества принимаемых решений зависит будущий результат проекта, а также то, в каком состоянии находится проект сейчас и в каком будет находиться в будущем.
Принятие решений, особенно управленческих, — сложный процесс. Как правило, руководителя проектов этому нигде не учат, так как эта дисциплина больше распространена в среде топ-менеджмента и МВА. И это приводит к тому, что очень часто у руководителя проекта с этим возникают сложности.
Чтобы разобраться в теории и научиться на практике принимать качественные решения, надо пройти соответствующее обучение. В рамках данной статьи невозможно полноценно описать всю дисциплину принятия решений, поэтому пока просто запомните: принимайте решения при управлении и реализации проекта как можно раньше. Не тяните, так как в данной области работает правило «1-10-100»: исправление ошибки на стадии планирования обойдется в 1 рубль, на стадии воплощения — в 10 рублей, а на стадии реализации, (когда все уже запущено и работает), — в 100 рублей.
6. Делать совещания реже и эффективнее
Есть хорошая поговорка: «Любую задачу можно загубить, если провести достаточное количество совещаний». Так и с проектом в целом: его можно загубить, если он погрязнет в совещаниях. Все сведется к тому, что все будут постоянно встречаться, что-то обсуждать, дискутировать, но действий, приближающих к успешному окончанию проекта, происходить не будет (или их будет крайне недостаточно).
По моему опыту большое количество совещаний, как правило, является следствием того, что мы просто не умеем их проводить. Если грамотно организовать сам процесс проведения совещаний, то их количество и их длительность сократятся в разы.
Вот несколько советов, как это сделать:
- Ведите учет времени и трудозатрат совещаний (время умножить на количество участников).
- Ведите жесткий тайминг в ходе совещания.
- Не мешайте форматы в рамках одной встречи. Если встреча посвящена мозговому штурму, то занимайтесь только мозговым штурмом. Если это планерка-оперативка, то занимайтесь только ей. Если это совещание по стратегическим вопросам, то занимайтесь только ими.
- Приглашайте на совещание только тех, кто там нужен. Не приглашайте большое количество людей.
- Всегда формулируйте и рассылайте всем заранее цель и повестку встречи.
- Заранее позаботьтесь о наличии необходимой инфраструктуры (доски, флип-чарты, видео конференция, телефонная конференция, маркеры и пр.).
- Максимально используйте визуализацию в ходе совещания.
- В ходе совещания фиксируйте решения в протоколе, по окончанию совещания протокол должен быть сразу же готов. Не через 10 минут, не вечером, не на следующий день, а сразу. И сразу же рассылайте его всем участникам совещания.
- Если совещание по своему содержанию является логическим продолжением какого-то другого совещания, то вставляйте протокол предыдущего совещания в приглашение на новое. И начинайте новое совещание с анализа данного протокола и текущего статуса поручений в нем.
7. Держать внутреннюю кухню проекта в приоритете
Всегда действуйте не с оглядкой на быстрый внешний эффект, а с оглядкой на долгосрочный внутренний эффект:
- Не надо торопиться, чтобы успеть запустить кривой функционал и кое-как до нового года, чтобы красиво отчитаться, (если, конечно, сверху никто не давит и такое допустимо), — запуститесь нормально в конце января и проанализируйте, почему не успели до 31 декабря, чтобы в следующем году это не повторилось.
- Не надо на слово верить критикам и сразу паниковать, что у вас что-то не работает: спокойно проанализируйте ситуацию, пообщайтесь с командой, снимите показатели, сделайте расчеты и исходя из этого, решите, где тут правда, а где нет, и что надо делать дальше.
- Не надо давать оптимистичных прогнозов (и даже с реалистичными прогнозами надо быть аккуратным) — лучше дать пессимистичный, а потом показать, что он не сбылся, чем дать оптимистичный и показать, что не сбылся он.
- Не надо бежать и устранять все подряд замечания: проанализируйте эффект от его устранения, проанализируйте его масштаб, подумайте, будет ли это оптимальной загрузкой ресурсов, если их направить на устранения замечания и т. д.
8. Не терять заказчика в ходе проекта
Частая ошибка: в начале проекта обо всем договорились с заказчиком, обсудили Устав проекта, зафиксировали цель проекта, ожидаемые результаты, показатели, критерии успешности. На этом руководитель проекта успокоился и ушел его выполнять. К концу проекта (или к концу первой фазы проекта) руководитель проекта возвращается к заказчику, а там… либо другой человек, либо этой должности уже нет и вообще не понятно, кто теперь заказчик, либо заказчик тот же, но поменялась ситуация, и теперь этот проект ему не нужен, либо заказчик в отпуске, а тебе надо в ближайшие несколько дней решить с ним очень важный вопрос и т. д. И начинается страшный период в жизни РП.
Чтобы этого избежать, нужно руководствоваться сводом простых правил:
- Регулярно поддерживайте контакт с заказчиком, держите его в курсе статуса проекта и убеждайтесь, что цели заказчика не поменялись.
- Если цели заказчика поменялись, то вносите изменения в проект (при необходимости).
- Если заказчик собирается в отпуск, (а о плановых датах его отпуска необходимо поинтересоваться заранее), то спросите, кто на период отпуска вместо него, (и начинайте заранее погружать замещающего в проект).
- Если заказчик уходит в отпуск и замещающего по проекту не оставляет, то зафиксируйте с заказчиком договоренности на период отпуска.
- Если заказчик ушел в отпуск внезапно, (по крайней мере внезапно для вас), то максимально перенесите важные активности, требующие участия заказчика, на период, когда он вернется из отпуска.
- Если заказчик увольняется/переходит на другую должность, то начинайте сразу беспокоится о том, кто займет его место и коммуницировать с новым заказчиком так, как коммуницировали с текущим перед открытием проекта, будьте готовы, что в этом случае проект может претерпеть кардинальные изменения.
9. Постоянно извлекать уроки
При руководстве проектом сегодня вы делаете то, что не делали вчера, а завтра будете делать то, что не делаете сегодня. Каждый день — это что-то новое: новые ситуации, новые задачи, новые кейсы, новые проблемы.
Да, есть фреймворки и методологии по управлению проектами. Они позволяют избежать основных ошибок в проекте. Но каждый проект уникален. Каждая компания, в которой делается проект, тоже уникальна. Каждый заказчик уникален. И так далее. Да и руководить проектом — это не «делай раз, делай два, делай три — и получишь понятный предсказуемый результат», это «делай раз, делай два, делай что-то еще — и, возможно, получишь то, что тебе более или менее подойдет».
То есть в управлении проектом очень много неопределенности и вероятностного исхода. И чтобы снизить неопределенность и увеличить вероятность нужного тебе исхода, надо постоянно анализировать свои действия, смотреть на то, к какому результату они приводят, и принимать решения о необходимости корректировки действий. А финальные выводы такого цикла надо фиксировать в реестре извлеченных уроков. Это позволит не делать повторные ошибки в текущем проекте и не допускать ошибки в следующих проектах.
Ниже приведен пример шаблона реестра извлеченных уроков:
|
№ |
Проект |
Стадия управления проектом |
Предметные области управления проектом |
Описание ситуации |
Решение |
Каких последствий позволит избежать |
|
1 |
… |
… |
… |
… |
… |
… |