Работа в команде – главное условие успеха, поэтому руководитель проекта является ключевым элементом в структуре любой организации. Проектная деятельность присутствует практически во всех областях, и неважно, разрабатываем ли мы новую обувь или компьютерную программу, деятельность по разработке и созданию данных продуктов будет реализована через проект. Люди, занимающие пост руководителя проекта, играют роль особенную и стратегически важную. Поэтому для каждого сотрудника, который возложил на свои плечи эту интересную и одновременно сложную ношу, будут полезны данные рекомендации. Они помогут вам на первом этапе не совершать крупных ошибок.
1. Семь раз отмерь – один раз отрежь
Данная поговорка показывает основное правило проектной деятельности. Прежде чем с головой окунуться в проект, необходимо все очень хорошо спланировать. В будущем это избавит вас от различного рода переделок и изменений, которые потребуют дополнительных затрат. Поэтому опытный менеджер понимает, что время, потраченное на подготовку и тщательное планирование, обязательно принесет свои дивиденды.
2. Без стандарта никуда
Как и любая деятельность организации, проектная деятельность должна быть стандартизирована. Положение или регламент по организации проектной работы – это один из основных документов вашей компании. Он определяет ключевые роли, в том числе: заказчика, исполнителя, руководителя проекта, спонсора проекта и т.д. Этот документ является общим для всей организации. Он обеспечивает единство подходов, понимание целей и результатов, закладывает основу для всестороннего сотрудничества и сводит к минимуму организационные проблемы, на всех этапах реализации проекта.
3. У каждого своя роль
Для успешной реализации проекта вы должны максимально вовлечь все заинтересованные стороны. Чтобы правильно определить всех участников, нарисуйте небольшую схему или структуру всех заинтересованных сторон, с обозначением границ ответственности, основного функционала и ресурсов каждой стороны. После этого обязательно проведите личные встречи с каждым задействованным участником и обсудите тот вклад, который он внесет в общее дело.
4. Эффективные коммуникации
Поддержка и еще раз поддержка сотрудников, которые входят в состав рабочей группы проекта. Не стройте иллюзий по поводу успешной реализации проекта лишь только потому, что вы выпустили приказ о начале проекта и утвердили состав рабочей группы. Для выстраивания эффективных коммуникаций внутри команды поддержка необходима всем участникам. Не каждый сотрудник умеет выстраивать доверительные взаимоотношения в коллективе. Ваша задача – помочь сделать это быстро и без лишних негативных эмоций. Вы должны помочь каждому участнику понять свою роль, задачу, функционал и при необходимости дать обратную связь. А также вы должны понимать общие проблемы группы, и уметь вовремя их решить.
5. Береженого Бог бережет
Всегда оценивайте риск. Каждый руководитель проекта понимает, что риск есть в каждом деле. Поэтому никогда не останавливайте работу по оценке рисков и своевременной подготовке превентивных мер. Вы должны быть всегда готовы к тому, что что-то пойдет не так. В этом случае у вас должны быть разработаны несколько вариантов решения возникших проблем. Только в этом случае вы сэкономите и нервы, и деньги.
6. Будьте гибкими
Единых подходов к управлению проектами не существует, как не существует и абсолютно одинаковых проектов. Выбор методики зависит от целого ряда факторов, таких как характер проекта, опыт, навыки и образование участников группы, сфера деятельности компании, ее масштаб... Поэтому опытные руководители проектов выбирают тот путь, который применим в конкретных условиях и в конкретное время. Мотивируйте и поощряйте сотрудника, который предлагает и применяет различные подходы в своей деятельности. Предоставляйте возможность самостоятельно принимать то решение, которое подходит для проекта именно сегодня.
7. Помогать, но не делать
Роль руководителя проекта – руководить. Руководитель несет полную ответственность за результат, устанавливает требования, обучает, устанавливает доверительные отношения в команде, но только не делает работу за участников команды. Всегда помните это.
8. Отчеты бывают разные
Только необходимая отчетность. На определенных этапах проектной деятельности возникает необходимость подготовки отчетности по результатам деятельности проектной команды. Сведите к минимуму частоту и объем отчетной информации. Лучшее заранее определить контрольные точки и своевременно производить оценку состояния проекта, с привлечением всех заинтересованных сторон. Так вы сэкономите время, затрачиваемое для подготовки отчетности, которую никто не читает и которая не имеет целевого предназначения.
Это лишь основные советы, применяя которые вы повысите эффективность не только своего проекта, но и всей компании в целом.
По коммуникации да, бывает такое, что дал указание и продолжил заниматься своими делами. А подчинённые в свою очередь не информируют вовремя, пока не начнёт гореть в одном месте. Так что лучше контролировать самостоятельно
Один из наших плодовитых авторов забил все другие дискуссии своим жутким набором глупостей. А вот интересные статьи остались пропущенными.
Сергею мой уважение!
Во-первых, отличный стиль. Без новояза. И даже обошёлся без стейкхолдеров - "заинтересованные стороны". Не примите мои слов за иронию. Сергей пишет не для зубров в проектах, а для начинающих и пишет всё верно. Ну я бы сместил приоритеты в перечне, я бы всё-таки "4. Эффективные коммуникации" поставил на первое место. Без налаживания, отстраивания коммуникаций, без их постоянной проверки и поддержания в рабочем состоянии сложно будет исполнить проект.
И про отчётность согласен. При этом очень частая ошибка - отчёт ради отчёта. Есть отчёт, значит, типа, работа идёт. Это не так. Отчёт должен быть полезен и руководителю и исполнителю. Он должен быть прозрачен. Ведь очень часто руководители высокого ранга начинают увлекаться интерактивными инструментами типа канбана, ввводят кучу ограничений, потом принцип этих огрничений быстро забывается, приходят новые люди, до которых они не доводятся и вся подобная отчётность в удобном инструменте превращается в жутчайшую компьютеризированную бюрократию. Не ленитесь поднимать вопросы отчётности, обновлять и ревизовать её правила, безжалостно убирать лишнее!
Работа руководителя проекта напоминает работу гроссмейстера - правила известны, результата нужно добиваться, каждая фигура имеет свои доступные ходы и силу, а общее поле видит только гроссмейстер.
Хорошая попытка!
Осталось уточнить, для кого, собственно, этот текст написан.
Совершенно верно. В определении проекта есть упоминание уникальности. Понятно, чем это вызвано, и почему это важно.
Опытные руководители это знают и используют, хорошо понимая ограничения стандартов и рекомендаций. В частности, очень важна отраслевая специфика.
Но начинающий руководитель проекта должен такие вещи прочувствовать и пропустить через себя. Практика и опыт коллег в помощь. Несколько проектов с понятными результатами и их честным и детальным обсуждением сделают из начинающего менеджера проекта подготовленного.
Далеко не так просто и требует специальных знаний и инструментов. Но входит в большинство стандартов PM с достаточно детальными рекомендациями.
Остаётся уточнить, нужен ли в конкретном проекте выделенный Project Risk Manager. Для больших и сложных проектов это необходимо. Работа PRM начинается до официального старта проекта и заканчивается через заранее определённый период в зависимости от рисков и контрактных обязательств. Но руку нужно держать на пульсе, других вариантов нет.
Для IT по многолетней статистике проблемы с коммуникациями на уровне проекта - внешними и внутренними - одна из двух главных причин провала проекта, причем тем чаще, чем проект больше и сложнее.
Эти проблемы трудно переоценить. И, еще раз, опытный PM об это хорошо знает и вдумчиво работает над планом коммуникаций как важной частью согласованной проектной документации. Начинающему PM всему такому нужно научиться. Это снова 100% практическое упражнение.
Абсолютно с Вами согласен! Это то, на чём спотыкаются абсолютное большинстов, на мой взгляд, руководителей проектов. И чем больше проект, тем чаще встречаются ошибки в налаживании и поддержании коммуникаций. Очень часто это сводится к локальному обмену информацией и пространным совещаниям.
Заранее прошу прощения за своё брюзжание.
Цитата: "Поэтому опытный менеджер понимает, что время, потраченное на подготовку и тщательное планирование, обязательно принесет свои дивиденды".
Как руководитель проектов со стороны Заказчика различных модернизаций, реконструкций и строительства у меня сложилось своё представление о последовательности действий руководителя проекта. Но первое, это не планирование. Первым действием происходит оценка имеющейся проектно-сметной документции или просто материалов в рамках проекта, если это не строительство. Первым этапом должно быть - исследование свойств предмета проекта. Даже если его детали Вам вручили готовенькими.
Второй и третий пункты очень хороши.
Цитата: "Не каждый сотрудник умеет выстраивать доверительные взаимоотношения в коллективе. Ваша задача – помочь сделать это быстро и без лишних негативных эмоций."
Предлагаете систему Макаренко? Воспитание дело хорошее, но можно обойтись и без него. Особенно если у Вас тысячи подчинённых. Преподавателей не хватит. Попробуйте наладить ответственность за результат. Регулярные совещания с раздачей задач и отслеживанием выполнения будут куда как эффективней душещипательных бесед и увещеваний. Можно наотмашь и рублём ударить. А обратная связь всегда будет, когда очередному танцору придётся объяснять что его так заякорило на пути к результату. Хотите воспитательной работы? Пожалуйста. Проведите собрание трудового коллектива и спросите у менеджера почему он так халатно относится к порученным задачам, что это может отразиться на остальных. Вам и делать то возможно ничего не придётся. Порвут на ленточки.
Пятый пункт тоже не плох. Но чтобы снизить риски, необходимо иметь максимально актуальную информацию, достаточную для принятия взвешенных решений при возникновении непредвиденных обстоятельств. Управленческий учёт и отчётность большое в этом подспорье. Плюс информация извне внутренней среды предприятия.
Цитата : "Единых подходов к управлению проектами не существует, как не существует и абсолютно одинаковых проектов".
А вот тут с Вами не согласится кибернетика. Знаете, есть такая наука управления. Или что, коту под хвост теории функциональных и организационных систем?
Цитата: "Мотивируйте и поощряйте сотрудника, который предлагает и применяет различные подходы в своей деятельности".
Если Вы системно подойдёте к управлению проектами, то мотивация сотрудников будет лишь фоном для эффективного управления, хотя и немаловажным. Но Вы же говорите о второстепенном как об основном.
Цитата: "Предоставляйте возможность самостоятельно принимать то решение, которое подходит для проекта именно сегодня".
Вот Вы легко так - "предоставляйте". Делегирование права решать может быть осуществлено, если у Вам налажен контроль принимаемых не Вами решений и никак иначе. Никакого доверия. Это для детских сказок.
По пунктам семь и восемь тоже здорово. Могу только добавить, что отчёты, это информация необходимая для принятия решений. Большинство, к которому Вы не относитесь, не правильно понимает суть отчётов. По Анохину, создателю теории функциональных систем, не всё можно считать информацией. Та информация, которая не участвует в принятии решений, информацией не является. Так же как не каждая взаимосвязь, которая выглядит как система, не является системой, если нет бенефициара.
А в целом, однозначный лайк.
Это, по сути, очень важная - начальная - часть планирования - погружение в материал, его анализ и уточнение всех деталей. Вы назвали это оценкой, почему нет.
План проекта не строится на песке. И без этой работы дальнейшее невозможно.
Всё же лучше не обобщать. От замысла до реализации, всё можно назвать планированием. Но любой проект состоит из этапов реализации. Не просто так первым этапом я называю - исследование свойств предмета проекта. И даже этот этап имеет свой план действий. Просто планирование, само по себе, выделять не имеет. Это выжнейшая часть работы, это результат анализа добытой информации, но не этап работы. Тут как проверочное слово в грамматике - планирование не заканчивается составлением графиков. Живая работа будет вносить коррективы до самого конца. И даже после.
Вы прямо таки вторите PMBOC 7 ознаменовавшим "тихую революцию" в проектном менеджменте (переход от процессов к принципам, от Waterfall, к Agile). Например, в принципе "Заинтересованные стороны" подчеркивается не дотошность в деталях, а умение договариваться (agile по сути в отношениях заинтересованных лиц). Или в принципе "Ценность" - в хорошем варианте разработчики помогают заказчикам разобраться, что же им (заказчикам) нужно на самом деле. И т.д. и т.п.
Совершенно неверно. Существуют международные (PMBOC только один из них) своды лучших практик и стандартов по управлению проектами, так и отечественные ГОСТы. Проекты разные, но стандарты и практики не просто так отбираются - это драгоценный опыт. Можно и без этого, это даже интересно - вместо изучения, осмысления и применения сделанного не самыми отсталыми людьми изобратать очередной велосипед, зато "свой". Это увлекательно, особенно если акционеры это поощряют (это же за их счет идет строительство велосипедов). Даже интересно почитать об очередных "открытиях" по теме.
Не вполне понятно - с чем именно Вы не согласны? И при чём здесь PMBoK? Никто в здравом уме не против стандартов, но разделим государственные стандарты и нормы и все остальные документы и продукты.
К примеру, PMI - коммерческая организация, новая редакция PMBoK выходит раз в 4 года. С каждым разом они всё толще, и никакая не гарантирует успех проекта - от авторов это не зависит. Какой опыт авторы учли, а какой нет - мы не знаем. Как не знаем и то, что войдет в следующую версию.
Но велик шанс, что, пока менеджер работает в большом и сложном многоэтапном проекте, некий коллектив авторов выпустит очередную версию PMBoK. Начинаем проект заново, потому что мы его неправильно делали? Или остановим, пока поклонники PMBoK его не прочитают, не осмыслят, не подготовятся должным образом, не сдадут новые экзамены и не потренируются в других проектах? Вряд ли. В проекте важен только результат, то есть соответствие критериям успеха.
А выбор инструментов и методологии в зоне ответственности менеджера проекта, если нет специальных требований заказчика. Выбор между PMBoK, PRINCE2, APM, ISO, JPM .., даже не говоря о версиях, отраслевой специфике и отраслевых стандартах, не так принципиален, если менеджер проекта действительно понимает, что нужно делать.
Вы, Эрнст, судите по отдельным фразам. На самом деле Agile создаёт ощущение революции как необычная концепция, но не в практической плоскости. Очень узкое применение. На промпредприятиях вообще не представляю как использовать при реализации крупных инвестиционных проектов. На мой взгляд, концепция призвана реанимировать интерес к малоэффективным инструментам повышения эффективности работ второго порядка. Возможно адаптировать имеющиеся методологии к разработке IT продуктов.
Если говорить о революции как явлении, то это должно быть действие обеспечивающее результат даже в условиях жёсткого противодействия (контрреволюции). В таком случае умение договариваться важно, но можно реализовывать проект и не договорившись, что особенно важно в среде с разнонаправленными интересами. Буду нескромным. Мои системы контроля обеспечивают условия для революции эффективности, а Agile только даёт рекомендации.