Для тех, кто не читал первую статью, советую с ней ознакомиться. В двух словах: в ней описаны "лайфхаки" (необходимый "прожиточный минимум"), который руководитель проекта может сделать (и крайне желательно, чтобы сделал) еще до того, как торжественно объявит о старте проекта. Оказывается, что много "скрытых граблей" можно увидеть заранее еще до того, как ты официально согласился быть руководителем проекта. И их, оказывается, можно также заранее успешно обезвредить. Так сказать, "подстелить соломку", формально не обладая ни обязанностью ни обязательствами. Более того, некоторые очень полезные действия, которые сильно облег��ат тебе жизнь в проекте, можно и нужно сделать именно в этот момент.
Сразу раскрою итоги опроса из первой статьи. Проведенный опрос "В какой момент Вы соглашаетесь быть РП проекта?" показал, что почти 40% (грубо усредняем) приступают к проекту сразу и без лишних вопросов.
чем это говорит?
О том, что 40% руководителей проектов теряют отличную возможность сделать свой проект легче или получить выгоду просто потому, что не знают или не применяют этих "лайвхаков".
36% используют возможность лишь частично (в голосовании можно было выбрать несколько вариантов)
И лишь 8% используют все доступные возможности до старта проекта.
* Для ровного счета отмечу, что оставшиеся 16% из приведенной выше статистики - не ведут проекты, но проявили интерес к теме
В общем решайте сами, вот ссылка на нее:
Ну а те, кто уже с ней знаком и у кого свежи воспоминания, добро пожаловать в продолжение! Вторая часть посвящается "Официальному Старту Проекта". В ней я также расскажу про поджидающие вас скрытые возможности, которыми также можно очень удачно воспользоваться. И которые (кто знает) возможно даже обернутся вполне приятными последствиями.
Итак, начнем....
Что я подразумеваю под стартом проекта? Для меня (это лично мое мнение), контрольная точка "старт проекта" начинается с формального объявления по всей компании о запуске проекта и назначении руководителя этого проекта.
Дзен №1: "Старт проекта - это как свадьба. Чем громче она будет, тем лучше о вас будут думать и вспоминать."
Многие относятся к старту проекта весьма формально. А зря. Старт проекта - это прежде всего возможность громко заявить о своем проекте и о себе. И тем самым поднять свой статус. Сделать необходимый PR.
Зачем он нужен? - спросите вы. Все просто. Чем ярче, чем громче, и чем выше вас представили, тем больше уважения и тем больший "кредит доверия" вы получите в самом начале проекта. При этом уважение может быть:
в виде признания статуса вашей главенствующей позиции,
в виде подтверждения вашего авторитета,
в виде страха у команды откладывать (или не делать) поставленные вами задачи,
иногда даже в виде желания угодить вам и сделать ваши задачи быстрее и лучше.
Уважение в начале проекта - это, в том числе, признание вашего авторитета и вашего лидерства (как известно, люди стремятся идти за авторитетными лидерами).
Авторитет и лидерство можно получить двумя путями: можно долго и сложно, а можно быстро и просто.
Сложный путь - это зарабатывать их с нуля, долго, упорно, с самого нижнего уровня. Ежедневно доказывая это реальными поступками и способностями справляться со сложными задачами. Преодолевая при этом возможный негатив и даже вступая в соперничество с другими негласными или явными лидерами.
Простой путь - это получить их от первых лиц компании (при этом вас как бы сразу ставят на несколько ступенек выше). Да, эти авторитет и лидерство также придется подтверждать и удерживать ежедневно реальными поступками и способностями. Но по крайней мере, их не придется долго и упорно зарабатывать. Они как будто сразу даются вам. Удержаться на верхней ступеньке будет не просто, но это однозначно проще и легче, чем долго идти к ней с нуля.
"Дзен №2: "Добейтесь, чтобы старт вашего проекта и назначение вас как руководителя этого проекта официально объявили от имени первых лиц компании."
Как это сделать? Во многих компаниях просто делают "Приказ о запуске проекта". К этому документу часто также подходят весьма формально и не придают этой возможности должного внимания. Текст приказа составляется формально и также формально отравляется на подписание. После подписания просто рассылается по компании. Все читают его по диагонали и забывают о том, что в нем было написано уже через неделю. Отрабатывают, так сказать, "на троечку", а руководители проектов часто даже не видят в этом "окно возможностей".
Настаивайте на необходимости выпуска приказа по компании о запуске проекта, но используйте эту возможность "с умом". Для вас эта возможность открывается в виде прекрасного повода провести личную встречу о запуске проекта с топ-менеджментом или даже генеральным директором. Настаивайте на ней всеми возможными способа��и.
Дзен №3: "Напрашивайтесь на личную встречу с том-менеджментом, чтобы обсудить с ними цели, требования и ограничения проекта."
Зачем она нужна? Это ваш шанс рассказать детали проекта руководству компании. Причем рассказать не только цели проекта (о которых и так все знают). Но прежде всего "подсветить" какие требования к проекту и какие ограничения от стейкхолдеров вам удалось собрать пока вы готовились взять этот проект.
Понимаете теперь, почему в первой статье я писал о том, что Устав проекта должен быть вами подготовлен до того, как вас официально объявят руководителем проекта? Именно для того, чтобы у вас была четкая картинка по требованиям к проекту и его ограничениям, включая все его подводные камни.
Ваша встреча с топ-менеджментом будет прекрасной возможностью озвучить им какие требования к результатам проекта и ограничения предъявляют участвующие в нем подразделения и стейкхолдеры.
Это позволит погрузить руководство компании в детали вашего проекта. А заодно поднять ваш статус в глазах того же руководства. Ведь к ним придет человек, который уже будет знать о проекте намного больше, чем кто-бы то ни было в компании.
Пока ваша репутация не "запятнана" проблемами на проекте, у вас есть "кредит доверия" и вас заходят слушать. На самом деле до топ-менеджмента редко доходят детали. В иерархической лестнице часто выстраивается борьба за право доносить информацию высшему руководству. Ведь возможность общения с ними напрямую дает определенные привилегии. Кроме того, информация передается наверх часто в приукрашенном и упрощенном "удобном" виде. В итоге, руководство компании может иногда представлять себе проект совсем не так, как он выглядит на самом деле.
Станьте тем экспертом, которого топ-менеджмент захочет слушать. Тем человеком, который "откроет глаза" на детали проекта. Зарабатывайте очки авторитета в глазах руководства в самом начале проекта, пока у вас есть "кредит доверия". Они вам точно пригодятся.
Иногда такая встреча может привести к весьма интересным положительным результатам. Например, на моей практике однажды возникла ситуация: генеральный директор, узнав о специфических требованиях одного из стейкхолдеров, своим волевым решением просто отменил их, аргументируя это тем, что:
"- Компании надо зарабатывать деньги и адекватно относиться к рискам. Если мы будем каждый риск закрывать подобными избыточными требованиями, то это будут неоправданные расходы и долгие сроки проекта. Я считаю, что эти требования можно убрать. Если будут вопросы, то отправляйте ко мне."
Как итог, из проекта ушла достаточно большая часть неприятных работ (с соответствующими рисками по их выполнению).
Дзен №4: "Начинайте проповедовать Устав вашего проекта сразу после официального запуска проекта. Идите с этой Библией к вашей Пастве."
Итак, у вас на руках есть подписанный Указ от Короля (приказ о запуске проекта). Король лично представил вас своим подданным (официально объявил ваш проект, дал кредит доверия и подтвердил авторитет и статус). Вы сходили на личную аудиенцию к Королю и показали свою осведомленность в проекте (обсудили основные требования и ограничения, отраженные в Уставе). И прежде, чем начинать предпринимать дальнейшие шаги, нужно еще раз зафиксировать "правила игры".
Другими словами, получив подтверждение или даже корректировки проекта от топ-менеджмента, вам нужно еще раз пройти по всем ключевым участникам проекта и сообщить им, что все рамки проекта, отраженные в Уставе, согласованы с руководством (либо какие-то требования изменены или убраны, если такое случилось).
Для чего это важно сделать? Для того, чтобы явно зафиксировать у всех участников и стейкхолдеров подтверждение "правил игры" на вашем проекте, полученное на уровне топ-менеджмента. Нужно поставить все "точки над и" и четко дать понять, что проект будет вестись строго по Уставу, и ни как иначе. А те, кто не ознакомился с ним (многие ведь подписывают Устав "не глядя"), должны это сделать незамедлительно. Причем незнание Устава не освобождает их от ответственности. Более того, если кто-то в середине проекта вдруг придет с новыми требованиями, которые не укладываются в вашу версию Устава (как в поговорке "не нужно лезть со своим уставом в чужой монастырь"), то это будет неприемлемо и им потребуется обратиться к топ-менеджменту для согласования этих изменений. А, как вы догадываетесь, требования, выходящие за рамки Устава проекта, фактически приводят к тому, что пересмотр Устава может привести и к пересмотру ваших сроков, бюджета, ответственности и последствий. Этим аргументом можно и нужно пользоваться!
Справедливости ради, стоит отметить, что на практике часто в проектах не следуют "букве" Устава. Многие относятся к нему весьма скептически, и практически никто не знает, что же в нем написано. При этом Устав является одним из важнейших документов, регламентирующих весь проект. И отношение к Уставу, как к самому главному документу, формирует именно руководитель проекта. Если он не погружает команду в согласованные в Уставе пункты (не ведет проповеди), то возникает вполне стойкое впечатление, что у проекта нет никаких особых правил. Можно весть себя как хочется и без последствий. И в этом случае руководитель проекта своим бездействием начинает фактически способствовать тому, чтобы такое поведение "заражало" и остальных стейкхолдеров и членов команды.
Если вы сумели выполнить все эти задачи (или хотя бы честно постарались приложить максимум усилий), то аплодирую вам стоя. Вы тот самый руководитель проектов, о котором потом будут говорить: "...ОН СМОГ...".
Только после этого можно переходить к понятной всем фазе "Планирования проекта".
Дзен №5: "Честно определи для себя, к какому типу руководителей проектов ты относишься? Твое планирование проекта будет строиться в зависимости от этого."
Поговорим о том, какие бывают типы руководителей проектов и как это влияет на проекты:
Администратор (или Координатор) проекта - как правило плохо разбирается в предметной области (или вообще ее не знает). При этом также плохо разбирается в принципах технической реализации своего проекта и в принципах организации проектной работы. Он словно "плывет по волнам" в надежде, что кто-то подскажет: что именно и когда именно нужно сделать. Основная его задача - "шедулировать" встречи, необходимость которых озвучивает команда (а не он сам). Для такого типа характерны частые проблемы "на ровном месте". Когда они возникают, то "администратор проекта" делает шаг назад (уходит в тень) и ждет, пока кто-то предложит вых��д из этих проблем. Решение проблем начинается после того, как они возникли. Отсутствуют или плохо выражены задачи управления рисками и превентивного анализа возможных проблем с подготовкой к их решению.
Классический РП - как правило также не достаточно хорошо разбирается в предметных областях. Но в отличие от администратора, он хорошо понимает как управлять рисками и задачами на проекте. При этом прилагает максимум усилий к планированию узкопрофильных встреч на своем проекте. Четко разделяет команды и зоны ответственности каждого участника. Превентивно назначает встречи для контроля и управления движением проекта, рисками и соблюдением сроков. При необходимости погружается в технические детали проекта, чтобы понимать проблематику до того, как выстрелит сама проблема. Для него характерна черта искать выходы из сложившихся проблем путем регулярных личных консультаций с профильными специалистами. Это помогает проводить общие встречи более эффективно, поскольку он приходит на них уже подготовленным и технически подкованным.
Профильный РП - детально разбирается в предметной области, в которой он реализует свои проекты. Вплоть до изучения технических деталей проектирования и разработки. Он отлично понимает суть бизнес-требований, а также отлично понимает какими средствами и как именно они могут быть реализованы. Причем зачастую он владеет как знаниями бизнес-аналитика (понимая с полуслова потребности Заказчика), так и знаниями архитектора (понимая какие модули, интеграции и стек технологий нужно для этого использовать). Часто таких людей называют "человек-оркестр". Наличие такого РП на проекте - это большая помощь всей команде, поскольку он может сразу грамотно определить с чего нужно начинать. А также вовремя подскажет и поправит участников своей команды, если видит, что проект свернул не туда (или разработка не поняла суть требований).
Я не утверждаю, что плохо быть администратором. Судьба может так распорядится, что вам дадут проект, в котором вы вообще не разбираетесь. При этом условия и культура проектного управления в каждой компании настолько индивидуальны, что они, например, не позволяют вырасти из администратора выше в принципе. Одни компании осознанно формируют в своем проектном офисе только "Классических РП", чтобы все были универса��ьными солдатами, которых можно направить на любой проект. Другие компании напротив, осознанно разделяют менеджеров проектов по направлениям, выращивая редких "Профильных РП".
Так или иначе нужно честно для себя определить к какому типу вы относитесь. Для чего? Для того, чтобы сразу определить, какой экспертизы вам не хватает и возложить эту экспертизу на членов своей команды. Иногда, может оказаться, что подходящих кандидатов просто нет. Как быть в этой ситуации? Выходом может стать найм необходимых специалистов на внешнем рынке. Или брать их на аутсорсинг у подрядчиков, с которыми вы работаете.
Итак, какие же советы к планированию можно дать разным типам руководителей проектов:
Если вы оцениваете себя как "Администратор проекта", то попросите дать вам в помощь на короткий срок "Профильного РП", который на старте проекта поможет вам с грамотным планированием проекта, ресурсов и его рисков, исходя из понимания специфики этого направления. Обратитесь к подрядчикам, которые участвовали ранее в подобных проектах - они тоже могут с этим помочь. Учитесь у них тому, какие этапы они выделяют, как распределяют ответственность, как формируют рабочие группы и т.д. Подумайте прежде всего над тем, как организовать превентивный анализ возможных проблем и рисков проекта. Вам нужно сформировать внутри команды центры экспертизы, которые будут планировать свои зоны ответственности. Вы должны стремиться делегировать все всплывающие проблемы и мониторинг потенциальных проблем на эти центры экспертизы. Чтобы они заранее сигнализировали о возможной проблеме, которая может возникнуть. Со стороны конечно это может выглядеть как полное перекладывание задач на плечи других. Да, часто так оно и есть. Но другого способа нет. Вы должны сделать это в самом начале проекта, чтобы минимизировать возможные проблемы. Используйте этот проект для того, чтобы на его примере научиться и постараться вырасти до уровня "Классического РП" или даже "Профильного РП".
Если вы оценили себя как "Классический РП", значит проблем с формированием команд, планированием работ, ресурсов и контролем рисков у вас нет. Вам нужно сделать акцент на погружение в бизнес-специфику. Идите к Заказчикам, которые формировали требования. Общайтесь с ними, пытайтесь выяснить какие проекты в этом же направлении они уже делали ранее, какие требования предъявляли, и как они были реализованы. Изучайте специфику предметной области вашего проекта и то, как она уже была автоматизирована до вас. С какими проблемами столкнулся Заказчик и как они решались. Наматывайте "на ус" пройденный до вас путь. Если есть возможность пообщаться с "Профильным РП", то сделайте это без колебаний. Даже если вы считаете себя "профи со стажем", консультация с профессионалом в этом направлении не помешает.
Если вы оценили себя как "Профильный РП" (или человек-оркестр), значит вы находитесь там, где вы должны быть. Поздравляю - вы тот редкий вид РП, за которыми охотятся все компании и все Заказчики. Лучше вас никто никакие рекомендации не сформулирует. Даже если вас критикуют, то это всего лишь проявление человеческой психологии. Занимайтесь теоретическим развитием: если есть возможность, то проходите профильные курсы. Получайте сертификаты и повышайте свою ценность - это мой совет.
В этой статье я хотел подсветить те моменты, которые вы не найдете в PMBOOK и других похожих источниках. Так сказать "лайфхаки", которые позволяют облегчить путь запуска проекта. Больше лайфхаков и других идей про "Психологию в ИТ" читайте на моем канале https://t.me/step_to_it
Третья часть уже доступна по ссылке. В ней я постарался описать "лайфхаки", которые помогут вам спланировать работы, сформировать команды и управл��ть ими немного лучше, чем те, кто делает это "по-классике".
P.S. Прошу не критиковать за возможные грамматические ошибки, пишу во внерабочее время и без редактора.
Зачем я это делаю? Я не гонюсь за рейтингом (кто-то набирает его хейтерской критикой - так быстрее конечно, но это не мое). Я искренне надеюсь помочь тем, кому предстоит ступить на этот непростой путь. А еще я хочу собрать обратную связь от тех, кому довелось столкнуться с похожими проблемами. Или они видят, что вот-вот столкнутся с ними и хотят знать где еще "подстелить соломку".
Если какие-то идеи "зацепили" или показались интересным в процессе прочтения, то напишите об этом в комментариях. А еще лучше, если вы подкинете свои мысли, какие еще проблемы могли "подкосить" проект или привели к особенно жестокой схватке или неприятным последствиям. Я их постараюсь разобрать и описать в следующих постах. Или просто поделитесь этой статьей со своими знакомыми - кто знает, может именно это спасет их проект или даже сделает их будущими героями моих статей (мир тесен) :)
