Для тех, кто не читал первую статью, советую с ней ознакомиться. В двух словах: в ней описаны "лайфхаки" (необходимый "прожиточный минимум"), который руководитель проекта может сделать (и крайне желательно, чтобы сделал) еще до того, как торжественно объявит о старте проекта. Оказывается, что много "скрытых граблей" можно увидеть заранее еще до того, как ты официально согласился быть руководителем проекта. И их, оказывается, можно также заранее успешно обезвредить. Так сказать, "подстелить соломку", формально не обладая ни обязанностью ни обязательствами. Более того, некоторые очень полезные действия, которые сильно облегчат тебе жизнь в проекте, можно и нужно сделать именно в этот момент.

Сразу раскрою итоги опроса из первой статьи. Проведенный опрос "В какой момент Вы соглашаетесь быть РП проекта?" показал, что почти 40% (грубо усредняем) приступают к проекту сразу и без лишних вопросов.

О чем это говорит?

О том, что 40% руководителей проектов теряют отличную возможность сделать свой проект легче или получить выгоду просто потому, что не знают или не применяют этих "лайвхаков".

30% используют возможность лишь частично

И лишь 15% используют "по полной" доступные возможности, которые есть до старта проекта.

* Для ровного счета отмечу, что оставшиеся 15% из приведенной выше статистики - не ведут проекты, но проявили интерес к теме

В общем решайте сами, вот ссылка на нее:

Ну а те, кто уже с ней знаком и у кого свежи воспоминания, добро пожаловать в продолжение! Вторая часть посвящается "Официальному Старту Проекта". В ней я также расскажу про поджидающие вас скрытые возможности, которыми также можно очень удачно воспользоваться. И которые (кто знает) возможно даже обернутся вполне приятными последствиями.

Итак, начнем....

Что я подразумеваю под стартом проекта? Для меня (это лично мое мнение), контрольная точка "старт проекта" начинается с формального объявления по всей компании о запуске проекта и назначении руководителя этого проекта.

Дзен №1: "Старт проекта - это как свадьба. Чем громче она будет, тем лучше о вас будут думать и вспоминать."

Многие относятся к старту проекта весьма формально. А зря. Старт проекта - это прежде всего возможность громко заявить о своем проекте и о себе. И тем самым поднять свой статус. Сделать необходимый PR.

Зачем он нужен? - спросите вы. Все просто. Чем ярче, чем громче, и чем выше вас представили, тем больше уважения и тем больший "кредит доверия" вы получите в самом начале проекта. При этом уважение может быть:

• в виде признания статуса вашей главенствующей позиции,

• в виде подтверждения вашего авторитета,

• в виде страха у команды откладывать (или не делать) поставленные вами задачи,

• иногда даже в виде желания угодить вам и сделать ваши задачи быстрее и лучше.

  Уважение в начале проекта - это, в том числе, признание вашего авторитета и вашего лидерства (как известно, люди стремятся идти за авторитетными лидерами).

Авторитет и лидерство можно получить двумя путями: можно долго и сложно, а можно быстро и просто.

Сложный путь - это зарабатывать их с нуля, долго, упорно, с самого нижнего уровня. Ежедневно доказывая это реальными поступками и способностями справляться со сложными задачами. Преодолевая при этом возможный негатив и даже вступая в соперничество с другими негласными или явными лидерами.

Простой путь - это получить их от первых лиц компании (при этом вас как бы сразу ставят на несколько ступенек выше). Да, эти авторитет и лидерство также придется подтверждать и удерживать ежедневно реальными поступками и способностями. Но по крайней мере, их не придется долго и упорно зарабатывать. Они как будто сразу даются вам. Удержаться на верхней ступеньке будет не просто, но это однозначно проще и легче, чем долго идти к ней с нуля.

"Дзен №2: "Добейтесь, чтобы старт вашего проекта и назначение вас как руководителя этого проекта официально объявили от имени первых лиц компании."

Как это сделать? Во многих компаниях просто делают "Приказ о запуске проекта". К этому документу часто также подходят весьма формально и не придают этой возможности должного внимания. Текст приказа составляется формально и также формально отравляется на подписание. После подписания просто рассылается по компании. Все читают его по диагонали и забывают о том, что в нем было написано уже через неделю. Отрабатывают, так сказать, "на троечку", а руководители проектов часто даже не видят в этом "окно возможностей".

Настаивайте на необходимости выпуска приказа по компании о запуске проекта, но используйте эту возможность "с умом". Для вас эта возможность открывается в виде прекрасного повода провести личную встречу о запуске проекта с топ-менеджментом или даже генеральным директором. Настаивайте на ней всеми возможными способами.

Дзен №3: "Напрашивайтесь на личную встречу с том-менеджментом, чтобы обсудить с ними цели, требования и ограничения проекта."

Зачем она нужна? Это ваш шанс рассказать детали проекта руководству компании. Причем рассказать не только цели проекта (о которых и так все знают). Но прежде всего "подсветить" какие требования к проекту и какие ограничения от стейкхолдеров вам удалось собрать пока вы готовились взять этот проект.

Понимаете теперь, почему в первой статье я писал о том, что Устав проекта должен быть вами подготовлен до того, как вас официально объявят руководителем проекта? Именно для того, чтобы у вас была четкая картинка по требованиям к проекту и его ограничениям, включая все его подводные камни.

Ваша встреча с топ-менеджментом будет прекрасной возможностью озвучить им какие требования к результатам проекта и ограничения предъявляют участвующие в нем подразделения и стейкхолдеры.

Это позволит погрузить руководство компании в детали вашего проекта. А заодно поднять ваш статус в глазах того же руководства. Ведь к ним придет человек, который уже будет знать о проекте намного больше, чем кто-бы то ни было в компании.

Пока ваша репутация не "запятнана" проблемами на проекте, у вас есть "кредит доверия" и вас заходят слушать. На самом деле до топ-менеджмента редко доходят детали. В иерархической лестнице часто выстраивается борьба за право доносить информацию высшему руководству. Ведь возможность общения с ними напрямую дает определенные привилегии. Кроме того, информация передается наверх часто в приукрашенном и упрощенном "удобном" виде. В итоге, руководство компании может иногда представлять себе проект совсем не так, как он выглядит на самом деле.

Станьте тем экспертом, которого топ-менеджмент захочет слушать. Тем человеком, который "откроет глаза" на детали проекта. Зарабатывайте очки авторитета в глазах руководства в самом начале проекта, пока у вас есть "кредит доверия". Они вам точно пригодятся.

Иногда такая встреча может привести к весьма интересным положительным результатам. Например, на моей практике однажды возникла ситуация: генеральный директор, узнав о специфических требованиях одного из стейкхолдеров, своим волевым решением просто отменил их, аргументируя это тем, что:

"- Компании надо зарабатывать деньги и адекватно относиться к рискам. Если мы будем каждый риск закрывать подобными избыточными требованиями, то это будут неоправданные расходы и долгие сроки проекта. Я считаю, что эти требования можно убрать. Если будут вопросы, то отправляйте ко мне."

Как итог, из проекта ушла достаточно большая часть неприятных работ (с соответствующими рисками по их выполнению).

Дзен №4: "Начинайте проповедовать Устав вашего проекта сразу после официального запуска проекта. Идите с этой Библией к вашей Пастве."

Итак, у вас на руках есть подписанный Указ от Короля (приказ о запуске проекта). Король лично представил вас своим подданным (официально объявил ваш проект, дал кредит доверия и подтвердил авторитет и статус). Вы сходили на личную аудиенцию к Королю и показали свою осведомленность в проекте (обсудили основные требования и ограничения, отраженные в Уставе). И прежде, чем начинать предпринимать дальнейшие шаги, нужно еще раз зафиксировать "правила игры".

Другими словами, получив подтверждение или даже корректировки проекта от топ-менеджмента, вам нужно еще раз пройти по всем ключевым участникам проекта и сообщить им, что все рамки проекта, отраженные в Уставе, согласованы с руководством (либо какие-то требования изменены или убраны, если такое случилось).

Для чего это важно сделать? Для того, чтобы явно зафиксировать у всех участников и стейкхолдеров подтверждение "правил игры" на вашем проекте, полученное на уровне топ-менеджмента. Нужно поставить все "точки над и" и четко дать понять, что проект будет вестись строго по Уставу, и ни как иначе. А те, кто не ознакомился с ним (многие ведь подписывают Устав "не глядя"), должны это сделать незамедлительно. Причем незнание Устава не освобождает их от ответственности. Более того, если кто-то в середине проекта вдруг придет с новыми требованиями, которые не укладываются в вашу версию Устава (как в поговорке "не нужно лезть со своим уставом в чужой монастырь"), то это будет неприемлемо и им потребуется обратиться к топ-менеджменту для согласования этих изменений. А, как вы догадываетесь, требования, выходящие за рамки Устава проекта, фактически приводят к тому, что пересмотр Устава может привести и к пересмотру ваших сроков, бюджета, ответственности и последствий. Этим аргументом можно и нужно пользоваться!

Справедливости ради, стоит отметить, что на практике часто в проектах не следуют "букве" Устава. Многие относятся к нему весьма скептически, и практически никто не знает, что же в нем написано. При этом Устав является одним из важнейших документов, регламентирующих весь проект. И отношение к Уставу, как к самому главному документу, формирует именно руководитель проекта. Если он не погружает команду в согласованные в Уставе пункты (не ведет проповеди), то возникает вполне стойкое впечатление, что у проекта нет никаких особых правил. Можно весть себя как хочется и без последствий. И в этом случае руководитель проекта своим бездействием начинает фактически способствовать тому, чтобы такое поведение "заражало" и остальных стейкхолдеров и членов команды.

Если вы сумели выполнить все эти задачи (или хотя бы честно постарались приложить максимум усилий), то аплодирую вам стоя. Вы тот самый руководитель проектов, о котором потом будут говорить: "...ОН СМОГ...".

Только после этого можно переходить к понятной всем фазе "Планирования проекта".

Дзен №5: "Честно определи для себя, к какому типу руководителей проектов ты относишься? Твое планирование проекта будет строиться в зависимости от этого."

Поговорим о том, какие бывают типы руководителей проектов и как это влияет на проекты:

• Администратор (или Координатор) проекта - как правило плохо разбирается в предметной области (или вообще ее не знает). При этом также плохо разбирается в принципах технической реализации своего проекта и в принципах организации проектной работы. Он словно "плывет по волнам" в надежде, что кто-то подскажет: что именно и когда именно нужно сделать. Основная его задача - "шедулировать" встречи, необходимость которых озвучивает команда (а не он сам). Для такого типа характерны частые проблемы "на ровном месте". Когда они возникают, то "администратор проекта" делаешь шаг назад (уходит в тень) и ждет, пока кто-то предложит выход из этих проблем. Решение проблем начинается после того, как они возникли. Отсутствуют или плохо выражены задачи управления рисками и превентивного анализа возможных проблем с подготовкой к их решению.

• Классический РП - как правило также не достаточно хорошо разбирается в предметных областях. Но в отличие от администратора, он хорошо понимает как управлять рисками и задачами на проекте. При этом прилагает максимум усилий к планированию узкопрофильных встреч на своем проекте. Четко разделяет команды и зоны ответственности каждого участника. Превентивно назначает встречи для контроля и управления движением проекта, рисками и соблюдением сроков. При необходимости погружается в технические детали проекта, чтобы понимать проблематику до того, как выстрелит сама проблема. Для него характерна черта искать выходы из сложившихся проблем путем регулярных личных консультаций с профильными специалистами. Это помогает проводить общие встречи более эффективно, поскольку он приходит на них уже подготовленным и технически подкованным.

• Профильный РП - детально разбирается в предметной области, в которой он реализует свои проекты. Вплоть до изучения технических деталей проектирования и разработки. Он отлично понимает суть бизнес-требований, а также отлично понимает какими средствами и как именно они могут быть реализованы. Причем зачастую он владеет как знаниями бизнес-аналитика (понимая с полуслова потребности Заказчика), так и знаниями архитектора (понимая какие модули, интеграции и стек технологий нужно для этого использовать). Часто таких людей называют "человек-оркестр". Наличие такого РП на проекте - это большая помощь всей команде, поскольку он может сразу грамотно определить с чего нужно начинать. А также вовремя подскажет и поправит участников своей команды, если видит, что проект свернул не туда (или разработка не поняла суть требований).

Я не утверждаю, что плохо быть администратором. Судьба может так распорядится, что вам дадут проект, в котором вы вообще не разбираетесь. При этом условия и культура проектного управления в каждой компании настолько индивидуальны, что они, например, не позволяют вырасти из администратора выше в принципе. Одни компании осознанно формируют в своем проектном офисе только "Классических РП", чтобы все были универсальными солдатами, которых можно направить на любой проект. Другие компании напротив, осознанно разделяют менеджеров проектов по направлениям, выращивая редких "Профильных РП".

Так или иначе нужно честно для себя определить к какому типу вы относитесь. Для чего? Для того, чтобы сразу определить, какой экспертизы вам не хватает и возложить эту экспертизу на членов своей команды. Иногда, может оказаться, что подходящих кандидатов просто нет. Как быть в этой ситуации? Выходом может стать найм необходимых специалистов на внешнем рынке. Или брать их на аутсорсинг у подрядчиков, с которыми вы работаете.

Итак, какие же советы к планированию можно дать разным типам руководителей проектов:

1. Если вы оцениваете себя как "Администратор проекта", то попросите дать вам в помощь на короткий срок "Профильного РП", который на старте проекта поможет вам с грамотным планированием проекта, ресурсов и его рисков, исходя из понимания специфики этого направления. Обратитесь к подрядчикам, которые участвовали ранее в подобных проектах - они тоже могут с этим помочь. Учитесь у них тому, какие этапы они выделяют, как распределяют ответственность, как формируют рабочие группы и т.д. Подумайте прежде всего над тем, как организовать превентивный анализ возможных проблем и рисков проекта. Вам нужно сформировать внутри команды центры экспертизы, которые будут планировать свои зоны ответственности. Вы должны стремиться делегировать все всплывающие проблемы и мониторинг потенциальных проблем на эти центры экспертизы. Чтобы они заранее сигнализировали о возможной проблеме, которая может возникнуть. Со стороны конечно это может выглядеть как полное перекладывание задач на плечи других. Да, часто так оно и есть. Но другого способа нет. Вы должны сделать это в самом начале проекта, чтобы минимизировать возможные проблемы. Используйте этот проект для того, чтобы на его примере научиться и постараться вырасти до уровня "Классического РП" или даже "Профильного РП".

2. Если вы оценили себя как "Классический РП", значит проблем с формированием команд, планированием работ, ресурсов и контролем рисков у вас нет. Вам нужно сделать акцент на погружение в бизнес-специфику. Идите к Заказчикам, которые формировали требования. Общайтесь с ними, пытайтесь выяснить какие проекты в этом же направлении они уже делали ранее, какие требования предъявляли, и как они были реализованы. Изучайте специфику предметной области вашего проекта и то, как она уже была автоматизирована до вас. С какими проблемами столкнулся Заказчик и как они решались. Наматывайте "на ус" пройденный до вас путь. Если есть возможность пообщаться с "Профильным РП", то сделайте это без колебаний. Даже если вы считаете себя "профи со стажем", консультация с профессионалом в этом направлении не помешает.

3. Если вы оценили себя как "Профильный РП" (или человек-оркестр), значит вы находитесь там, где вы должны быть. Поздравляю - вы тот редкий вид РП, за которыми охотятся все компании и все Заказчики. Лучше вас никто никакие рекомендации не сформулирует. Даже если вас критикуют, то это всего лишь проявление человеческой психологии. Занимайтесь теоретическим развитием: если есть возможность, то проходите профильные курсы. Получайте сертификаты и повышайте свою ценность - это мой совет.

В этой статье я хотел подсветить те моменты, которые вы не найдете в PMBOOK и других похожих источниках. Так сказать "лайфхаки", которые позволяют облегчить путь запуска проекта.

В следующей статье (если будет мотивация и обратная связь с идеями), я постараюсь рассказать о том, как жить "в махровой бытовухе" проекта. Т.е. когда начинаются срывы сроков, критика стейкхолдеров, демотивация команды и т.д. и т.п.

P.S. Прошу не критиковать за возможные грамматические ошибки, пишу во внерабочее время и без редактора.

Зачем я это делаю? Я не гонюсь за рейтингом (кто-то набирает его хейтерской критикой - так быстрее конечно, но это не мое). Я искренне надеюсь помочь тем, кому предстоит ступить на этот непростой путь. А еще я хочу собрать обратную связь от тех, кому довелось столкнуться с похожими проблемами. Или они видят, что вот-вот столкнутся с ними и хотят знать где еще "подстелить соломку".

Если какие-то идеи "зацепили" или показались интересным в процессе прочтения, то напишите об этом в комментариях. А еще лучше, если вы подкинете свои мысли, какие еще проблемы могли "подкосить" проект или привели к особенно жестокой схватке или неприятным последствиям. Я их постараюсь разобрать и описать в следующих постах. Или просто поделитесь этой статьей со своими знакомыми - кто знает, может именно это спасет их проект или даже сделает их будущими героями моих статей (мир тесен) :)