Comments 31
А не много ли вы ему обязаностей приписали?
Что делает — понятно, а где «что нужно, чтобы им стать»?
Управление проектами, как и любая другая профессиональная деятельность, требует получения профессиональных знаний.
Их получение не составляет большого труда, ведь рынок сейчас дает большое количество предложений по обучению руководителей проектов. Начинать нужно именно с этого.
Выбирая тренинговый центр, нужно понимать, что большинство из них предлагает лишь получение академических знаний, основанных на одной из наиболее популярных и часто применяемых методологий (PMI, PRINCE2, Agile, Scrum и пр.). Если вы начинающий ПМ, и ваша текущая должность подразумевает только администрирование проектов без принятия управленческих решений, этого обычно бывает достаточно, чтобы «втянуться» в профессию. На рынке есть и более продвинутые тренинги, которые помимо погружения в методологию, основываются на практикумах и тренировке необходимых навыков. Некоторые центры предлагают даже специальные образовательные проекты, построенные на использовании бизнес-симуляторов для формирования/развития компетенции проектного управления. С одним из таких центров мы дружим и обмениваемся опытом — STS-VostoK (www.stsvostok.ru) Тут, как говориться, на вкус и цвет…
Стоит помнить, что любая методология — это всего лишь набор инструментов и описание правил по их применению: «отвертка — чтобы закручивать шурупы», «молоток — чтобы забивать гвозди». И это только часть решаемой задачи по выращиванию профессионального ПМ'а. Чтобы управлять большими комплексными проектами, нужна практика, опыт и навыки, полученные в реальных проектах.
Умение взвешенно принимать самостоятельные управленческие решения и нести за них ответственность — основное отличие руководителя проекта от администратора.
Вообще для профессионального ПМ'а обучение это процесс непрерывный. Оно помогает не только получать новые знания, но и систематизировать/улучшать полученные ранее.
Его можно сравнить с профессиональным хирургом, который владеет множеством инструментов и техник, но в конкретном случает применяет именно ту, которая спасет пациенту жизнь).
Их получение не составляет большого труда, ведь рынок сейчас дает большое количество предложений по обучению руководителей проектов. Начинать нужно именно с этого.
Выбирая тренинговый центр, нужно понимать, что большинство из них предлагает лишь получение академических знаний, основанных на одной из наиболее популярных и часто применяемых методологий (PMI, PRINCE2, Agile, Scrum и пр.). Если вы начинающий ПМ, и ваша текущая должность подразумевает только администрирование проектов без принятия управленческих решений, этого обычно бывает достаточно, чтобы «втянуться» в профессию. На рынке есть и более продвинутые тренинги, которые помимо погружения в методологию, основываются на практикумах и тренировке необходимых навыков. Некоторые центры предлагают даже специальные образовательные проекты, построенные на использовании бизнес-симуляторов для формирования/развития компетенции проектного управления. С одним из таких центров мы дружим и обмениваемся опытом — STS-VostoK (www.stsvostok.ru) Тут, как говориться, на вкус и цвет…
Стоит помнить, что любая методология — это всего лишь набор инструментов и описание правил по их применению: «отвертка — чтобы закручивать шурупы», «молоток — чтобы забивать гвозди». И это только часть решаемой задачи по выращиванию профессионального ПМ'а. Чтобы управлять большими комплексными проектами, нужна практика, опыт и навыки, полученные в реальных проектах.
Умение взвешенно принимать самостоятельные управленческие решения и нести за них ответственность — основное отличие руководителя проекта от администратора.
Вообще для профессионального ПМ'а обучение это процесс непрерывный. Оно помогает не только получать новые знания, но и систематизировать/улучшать полученные ранее.
Его можно сравнить с профессиональным хирургом, который владеет множеством инструментов и техник, но в конкретном случает применяет именно ту, которая спасет пациенту жизнь).
Я бы наверное идеальный путь ПМа описал так:
0. Выбор области, где человек хочет работать — хочет ли делать проекты по строительству ракет, или домов, или софта.
1. Хороший университет, который дает хорошую управленческую базу, а так же формирует критическое мышление и правильное видение бизнеса вообще (и проектного бизнеса, как подможества). Минутка рекламы — в регионе, откуда я родом это СУ — там же нам давали знания о проектном менеджменте (как частном случае менеджмента, вообще).
2. На 2-3-4 курсе университета — работа по специальности в области, где ты хочешь работать (например, если хочешь руководить проектами в разработке софта, желательно иметь представление о процессах разработки, внедрения, тестирования и т.д. — для чего можно пойти в компанию на джуниора — аналитика, разраба, тестера, внедренца и т.д.). Компания нужна не абы какая, а с хорошо (или неплохо) поставленными процессами управления проектами — Ланит, Астерос, Неткрекер, Наумен, АйТеко, СМС-ИТ.
3. Далее — через 1-2 года, когда будешь чувствовать себя уверенно на этом месте — попросить дополнительно загрузить работой администратора проекта (вести протоколы, вносить данные в систему управления проектам, низкоуровнево планировать ресурсы в проджект-сервере и т.д.).
4. Далее — брать на себя роль ПМа в проекте, где ты был аналитиком/тестировщиком/программистом и т.д. Как правило, свой проект/продукт знаешь уже хорошо, много общался с заказчиком (особенно если ты аналитик), знаешь все процессы в организации, людей, и т.д. и т.п.
А просто пройти курсы по ПМству — надо обязательно (например, сразу после универа), но только в паре с реальным опытом, без опыта — они бесполезны.
P.S. Прям статью написать захотелось, о том, что нужно запланировать, для того что бы пойти в ПМы )))
0. Выбор области, где человек хочет работать — хочет ли делать проекты по строительству ракет, или домов, или софта.
1. Хороший университет, который дает хорошую управленческую базу, а так же формирует критическое мышление и правильное видение бизнеса вообще (и проектного бизнеса, как подможества). Минутка рекламы — в регионе, откуда я родом это СУ — там же нам давали знания о проектном менеджменте (как частном случае менеджмента, вообще).
2. На 2-3-4 курсе университета — работа по специальности в области, где ты хочешь работать (например, если хочешь руководить проектами в разработке софта, желательно иметь представление о процессах разработки, внедрения, тестирования и т.д. — для чего можно пойти в компанию на джуниора — аналитика, разраба, тестера, внедренца и т.д.). Компания нужна не абы какая, а с хорошо (или неплохо) поставленными процессами управления проектами — Ланит, Астерос, Неткрекер, Наумен, АйТеко, СМС-ИТ.
3. Далее — через 1-2 года, когда будешь чувствовать себя уверенно на этом месте — попросить дополнительно загрузить работой администратора проекта (вести протоколы, вносить данные в систему управления проектам, низкоуровнево планировать ресурсы в проджект-сервере и т.д.).
4. Далее — брать на себя роль ПМа в проекте, где ты был аналитиком/тестировщиком/программистом и т.д. Как правило, свой проект/продукт знаешь уже хорошо, много общался с заказчиком (особенно если ты аналитик), знаешь все процессы в организации, людей, и т.д. и т.п.
А просто пройти курсы по ПМству — надо обязательно (например, сразу после универа), но только в паре с реальным опытом, без опыта — они бесполезны.
P.S. Прям статью написать захотелось, о том, что нужно запланировать, для того что бы пойти в ПМы )))
По какой-то причине, в статье сделан упор на работу с чем угодно, но не с собственно командой, с людьми, которые делают основную работу по проекту. Сколько раз приходилось сталкиваться с ситуацией, что за проект берётся вроде бы грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам — должны делать то-то и то-то, по процессу. Может это где-то и работает, но обычно от руководителя проекта требуется тесный контакт с командой и не только на уровне постановки задач и не только с лидами. Команду нужно мотивировать, знать, чем она живёт, отслеживать внутрикомандные риски, планировать состав и качество команды, объяснять ей что за проект мы делаем. Скажем, если говорить о проектах из линейки «Безопасный город», то энтузиазма и осознанности в своих действиях у команды будет гораздо больше, если они будут понимать, что результатом их работы будет система, которая будет спасать человеческие жизни, нежели чем просто выполнение плана по прибыли для акционеров своей компании или формальные кипиаи. И по 12 часов будут работать с другим пониманием, а не из-под палки. Да, всё, что приведено в статье, безусловно, важно, но если руководитель проекта не установит хорошего контакта со своей командой и команда не увидит в нём лидера, за которым хочется идти, то всё остальное будет иметь мало смысла.
Вы, разумеется, правы — от команды очень многое зависит, умение договориться и замотивировать — обязательная компетенция ПМ'а. И любая часть работы — и управление рисками, и управление качеством, и бюджетом — так или иначе в команду упирается.
А то, что вы описали — «грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики. Поэтому на специфику я и сделал упор. Работа с командой — огромная тема, которая тянет на отдельный пост.
А то, что вы описали — «грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики. Поэтому на специфику я и сделал упор. Работа с командой — огромная тема, которая тянет на отдельный пост.
умение договориться и замотивировать — обязательная компетенция ПМ'а
А если команда уже замотивирована по самое нехочу? Как показывает опыт, в таких случаях ПМ'а может проглючить очень сильно.
но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики
Самое смешное, когда ПМ, работавший с ресурсами, приходит в команду высококвалифицированных спецов и пытается общаться с ними как в детском саду. «Мотивировать» человека, который сеньор и так уже на 100%+ отдаётся проекту, но просто не хочет манагерским буллшитом ещё себе голову забивать.
Думаю, стоит ещё один пункт дописать: понимание, где надо управлять, а где лучше не лезть :)
ПМ вообще людьми не командует — у них есть функциональный руководитель. Как правило, из команды ПМу напрямую никто не подчиняется, и уж в 100% случаев ПМ не может приказывать заказчикам.
У вас на проекте есть цели (например внедрить систему электронного документооборота за 6 месяце, в бюджете 10 млн рублей, соответствующую текущим БП предприятия) и есть люди (например команда из 5 человек с какими-либо скиллами — БА, СД, QA и т.д., а так же заказчик и его команда).
Для того что бы обеспечить достижение целей данными людьми, ПМ должен применить лидерство — обеспечить готовность, желание, намерения людей достигать целей некоторым способом (чем их мотивировать это каждый раз отдельный вопрос).
Если ваш ПМ не лидер, если он не умеет мотивировать людей, не умеет управлять командой и заказчиком, — это не настоящий ПМ, пусть идет в функциональные руководители и там командует.
У вас на проекте есть цели (например внедрить систему электронного документооборота за 6 месяце, в бюджете 10 млн рублей, соответствующую текущим БП предприятия) и есть люди (например команда из 5 человек с какими-либо скиллами — БА, СД, QA и т.д., а так же заказчик и его команда).
Для того что бы обеспечить достижение целей данными людьми, ПМ должен применить лидерство — обеспечить готовность, желание, намерения людей достигать целей некоторым способом (чем их мотивировать это каждый раз отдельный вопрос).
Если ваш ПМ не лидер, если он не умеет мотивировать людей, не умеет управлять командой и заказчиком, — это не настоящий ПМ, пусть идет в функциональные руководители и там командует.
Понравилось «Это не религия, это инструменты».
Что-то в статье совершенно не отражен момент, что надо бы выяснять, в первую очередь, какую проблему решает проект, а уже потом что и как. И очень много ошибок именно из-за отсутствия понимания проблематики клиента. Даже сам клиент, часто, не может сформулировать проблему.
И да, как заметили выше, менеджер это сначала работа с людьми, а потом уже методологии. Если в команде много народу, то менеджер не может с каждым тесно взаимодействовать, но в этом случае он должен транслировать принцип «люди важнее всего» вниз по иерархии.
И да, как заметили выше, менеджер это сначала работа с людьми, а потом уже методологии. Если в команде много народу, то менеджер не может с каждым тесно взаимодействовать, но в этом случае он должен транслировать принцип «люди важнее всего» вниз по иерархии.
Специфика «Техносерва» в том, что у нас за уровень «какую проблему решает проект», все-таки отвечает не столько ПМ, сколько архитектор. Про его работу мой коллега недавно подробно писал — habrahabr.ru/company/technoserv/blog/344702. На самом деле этот вопрос отражен в разделе по управлению качеством (требования и ожидания). Решение данного вопроса мы делегируем системному архитектору, поскольку именно он отвечает за то, чтобы техническая реализация проекта отвечала требованиям заказчика, в том числе, решала его бизнесовую и функциональную проблематику.
Т.е. архитектор решает бизнес проблемы заказчика?
В моем понимании — архитектор подключается на этапе пресейла, смотрит что из предполагаемого скоупа проекта (требований заказчика) реализуется стандартный функционалом ПО (при условии, что это ПО вообще есть, и у него есть стандартный ф-л), а что требует доработки (или если разработка идет с нуля, определяет как надо доработать — какие методы и технологии использовать).
Далее — заказчику показывается некий прайс с гэп анализом, и заказчик далее проводит функционально-стоимостной анализ каждой фичи в проекте.
Например:
Проект: Внедрение MS Excel в компании ООО «Вектор».
Требование 1: Создание электронных таблиц. Стандартный функционал. Доплата не требуется.
Требование 1: Загрузка данных о отпусках участников ликвидации Чернобыльской аварии в таблицы из самописной ERP. Не стандартный функционал. 90 тыс. рублей.
Далее, заказчик думает и выбирает — надо ли ему эти отпуска за 90 тысяч реализовывать, или он их руками забьет (может у него одни ликвидаторы работают). И так по каждому требованию пользователей (конечно, верхнеуровнево, мы же в пресейле еще).
Ну и плюс тут архитектор должен ограничения грамотно написать, например если предполагается миграция данных сколько данных мигрируется (не более 1 млн записей например), кто отвечает за валидацию, какими средствами происходит миграция и т.д. и т.п.
Это позволяет рамки проекта определить правильно, а ПМ это не всегда может сделать, на сложных проектах — скорее никогда.
Далее — заказчику показывается некий прайс с гэп анализом, и заказчик далее проводит функционально-стоимостной анализ каждой фичи в проекте.
Например:
Проект: Внедрение MS Excel в компании ООО «Вектор».
Требование 1: Создание электронных таблиц. Стандартный функционал. Доплата не требуется.
Требование 1: Загрузка данных о отпусках участников ликвидации Чернобыльской аварии в таблицы из самописной ERP. Не стандартный функционал. 90 тыс. рублей.
Далее, заказчик думает и выбирает — надо ли ему эти отпуска за 90 тысяч реализовывать, или он их руками забьет (может у него одни ликвидаторы работают). И так по каждому требованию пользователей (конечно, верхнеуровнево, мы же в пресейле еще).
Ну и плюс тут архитектор должен ограничения грамотно написать, например если предполагается миграция данных сколько данных мигрируется (не более 1 млн записей например), кто отвечает за валидацию, какими средствами происходит миграция и т.д. и т.п.
Это позволяет рамки проекта определить правильно, а ПМ это не всегда может сделать, на сложных проектах — скорее никогда.
Указанное, вполне, в рамках компетенции архитектора, но это не бизнес проблема. Бизнес проблемой тут, может быть отсутствие учета ликвидаторов и непрозрачность (или невозможность) учета выплат.
Ага, все верно.
У заказчика есть проблема — учет ликвидаторов ведется неверно. Это у него болит, и он хочет это исправить. Он звонит интегратору и озвучивает свою проблему.
Тот присылает проектную команду, проводит анализ и предлагает заказчику несколько вариантов решений, с их стоимостью, например:
0. Уволить ликвидаторов (бесплатно, но есть риски, которые заказчик не готов взять на себя — затем то он и позвонил нам!). Не рассматриваем.
1. Учитывать ликвидаторов в эксцеле (100к + 3 часа работы пользователя в месяц).
2. Поставить SAP и учитывать все автоматически (90 млн. рублей).
Конечно, представляет это не арх, а ПМ\пресейл, но именно арх ответственный за то, что бы правильно понять бизнес-проблему заказчика и предложить ее решение с помощью имеющихся средств (или несколько альтернатив).
У заказчика есть проблема — учет ликвидаторов ведется неверно. Это у него болит, и он хочет это исправить. Он звонит интегратору и озвучивает свою проблему.
Тот присылает проектную команду, проводит анализ и предлагает заказчику несколько вариантов решений, с их стоимостью, например:
0. Уволить ликвидаторов (бесплатно, но есть риски, которые заказчик не готов взять на себя — затем то он и позвонил нам!). Не рассматриваем.
1. Учитывать ликвидаторов в эксцеле (100к + 3 часа работы пользователя в месяц).
2. Поставить SAP и учитывать все автоматически (90 млн. рублей).
Конечно, представляет это не арх, а ПМ\пресейл, но именно арх ответственный за то, что бы правильно понять бизнес-проблему заказчика и предложить ее решение с помощью имеющихся средств (или несколько альтернатив).
Как определяете сколько проектов потянет ПМ или сколько ПМ нужно на проект?
Решение принимается всегда индивидуально. Все зависит от организационной сложности проекта и его территориально распределенности. Например, если это региональный проект, то часто назначают одного РП в Москве и одного в регионе, иногда в этом нет необходимости. У меня бывали случаи, когда в одном проекте участвовало 12 РП (он состоял из 800 объектов по всей России, работы велись параллельно), и было в точности наоборот — один РП вел 12 небольших проектов.
Я работаю в комапании, которая сейчас активно встает на рельсы скрама. И по процессу у нас нет никакого PM. И непонятно, в чем его роль может заключаться в нашей команде. Причем у нас не доконца скрам, потому что бюджетом владеет не Product Owner, а мой линейный менеджер. Если бы было совсем по канону, то линейный менеджер был бы вообще не нежен (сейчас мы у него согласуем отпуска и прочую административку, видим его раз в месяц на стендапе).
В связи с этим бытует мнение, что PM это умирающий вид, рудимент в современном IT. Понятно, что не во всех областях, там где не обойтись без Waterfall, PM — важная роль в команде.
В связи с этим бытует мнение, что PM это умирающий вид, рудимент в современном IT. Понятно, что не во всех областях, там где не обойтись без Waterfall, PM — важная роль в команде.
Пиэм отвечает за результат проекта. Кто у вас отвечает за результат?
Откуда понятие результат в Scrum? Главное же чтобы без ПМ
Команда целиком. Мы коммитимся на результат, постоянно даем обратную связь по выполнению, меняем подход, если что-то меняется внутри или снаружи. Продукт оунер в курсе ситуации всегда, а это человек из бизнеса.
profyclub.ru/uploads/3/45/0a88936c1bac2f5f14a5948694db3.png
Такую картинку предлагаю вам рассмотреть.
Но там РМ — это програм менеджер, а не проджект )
Вам ПМ может быть и не нужен, но это сильно от процессов зависит, о которых данных не достаточно.
Кто то же поставляет вам эпики, кто то считает бюджет, кто то считает TCO, экономические эффекты, курирует нагрузку команды и планирует использование людей и средств, рисует роадмэпы и показывает их топам и т.д. и т.п. Если это все делает скрам-мастер — это и есть ваш ПМ ))
Знаю крупный банк, где скрам и более 10 скрам команд пилит один продукт, а ПМ координирует эти команды и управляет сверху результатом, который они выдают.
Такую картинку предлагаю вам рассмотреть.
Но там РМ — это програм менеджер, а не проджект )
Вам ПМ может быть и не нужен, но это сильно от процессов зависит, о которых данных не достаточно.
Кто то же поставляет вам эпики, кто то считает бюджет, кто то считает TCO, экономические эффекты, курирует нагрузку команды и планирует использование людей и средств, рисует роадмэпы и показывает их топам и т.д. и т.п. Если это все делает скрам-мастер — это и есть ваш ПМ ))
Знаю крупный банк, где скрам и более 10 скрам команд пилит один продукт, а ПМ координирует эти команды и управляет сверху результатом, который они выдают.
У вас, видимо, продуктовая компания. А если бы заказ был на доработку продукта заказчика? Менеджер продукта у них свой, если повезет. И ваш ПМ бегал бы по ихним стекхолдерам и шлифовал (своими штанами) на совещаниях треугольник проекта. Это достаточно специфичная роль, чтобы ее играл линейный руководитель.
В пределе получается сильная матрица, когда все бюджеты в проектном департаменте. А линейный руководитель занимается развитием персонала и выделением его на проекты (за долю из бюджетов).
В пределе получается сильная матрица, когда все бюджеты в проектном департаменте. А линейный руководитель занимается развитием персонала и выделением его на проекты (за долю из бюджетов).
Понятно то всех вопросов в одном посте не раскрыть, поэтому есть вопросы.
А именно, как организовать четкое распределение задач и ответственных в проектах, затрагивающих несколько подразделений компании? При этом инициатор проекта из сферы продаж, а для остальных этот проект — новая головная боль. Высшее руководство в текущем уровне коммуникации между подразделениями проблему не видит (соответственно куратора не предвидится).
Я больше 5-ти лет работаю в сфере продаж в крупной, вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин. Есть огромная заинтересованность в развитии проектного мышления, отсюда необходимость попробовать себя в управлении проектами внутри текущего работодателя. Есть большие опасения, что добиться положительного итога не получится. Что посоветуете?
А именно, как организовать четкое распределение задач и ответственных в проектах, затрагивающих несколько подразделений компании? При этом инициатор проекта из сферы продаж, а для остальных этот проект — новая головная боль. Высшее руководство в текущем уровне коммуникации между подразделениями проблему не видит (соответственно куратора не предвидится).
Я больше 5-ти лет работаю в сфере продаж в крупной, вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин. Есть огромная заинтересованность в развитии проектного мышления, отсюда необходимость попробовать себя в управлении проектами внутри текущего работодателя. Есть большие опасения, что добиться положительного итога не получится. Что посоветуете?
Мимо проходил, и увидел ваш комментарий, попробую ответить что подсказыват мой опыт ПМства.
Поскольку терминология гуляет от методологии к методологии, буду приводить объяснения по ходу рассуждений.
У вас у проекта есть инициатор, и есть спонсор (часто это одно и то же лицо, но не всегда).
Для вас главное спонсор — пусть для вас это ваш заказчик проекта (и не важно, он инициатор или нет).
Задача спонсора в этом проекте — организовать ресурсы для проекта в нужном количестве.
Задача ПМа — предоставить спонсору данные о ресурсах, необходимых в компании.
Для этого ПМ составляет план проекта, в которых входит план управления ресурсами. Последний (в вашем случае) должен отвечать на следующие вопросы:
— кто нужен?
— зачем нужен?
— когда нужен?
— на сколько нужен?
Предположим вам нужна уборщица тетя Глаша, для того что бы прибрать кабинет после того как айтишники насверлили там дырок для сети. Тета Глаша вам (и ПМу если это еще не вы) не подчиняется.
Так вот, вы включаете ее в план управления ресурсов, исходя из плана работ, который вы составили.
В плане работ вы видите, что айтишники будут тянуть сеть с 1 по 10 июля (± 1 день). Убирать за ними надо по вашим экспертным оценкам 2 дня.
Итого — в плане управления ресурсами вы пишете — «Тетя Глаша, с 10 по 12 июля, в объеме 16 часов».
После этого вы показываете план управления спонсору проекта, который либо соглашается с ним, либо вносит в него правки (например пишет, что может выделить тетю Глашу вместо 10-12 июля на 10-14 июля, но в объеме 4 часа в день — вы соглашаетесь, но объясняете спонсору что эта работа стоит на критическом пути проекта и следовательно срок всего проекта увеличивается на 2 дня (либо у вас есть запас по времени для этой работы)).
Итого, спонсор проекта (как правило это один из топ-менеджеров) подписывает вам план управления ресурсами, и согласно этому плану — ресурсы должны быть выделены.
Что происходит, например если тетя Глаша 10 июля вместо того что бы убирать кабинет после айтишников, уходит убирать цех по приему стеклотары (несмотря на все ваши напоминания об этой работе)? Вы пишете письмо ее руководителю, с копией на спонсора — который становится ответственным за задержку проекта на 1 день — а далее в соответствии с уставом проекта и внутренними регламентами к нему применяются санкции — например штрафы, лишение премии, и т.д.
Но, естественно, если ПМ в начале проекта тетю Глашу не попросил на 2 дня или не внес это в план управления ресурсами — ее руководитель имеет полное право отказать в предоставлении — и это значит что ПМ очень плохо планирует ресурсы.
Конечно, есть и изменения — например тетя Глаша заболела. Но у хорошего ПМа всегда есть 10% сроков — заложенных на риски, и это как раз тот самый (± 1 день) про который речь шла выше.
Ну или как то так. Если у вас серьезные проблемы с организацией проектной деятельности — наймите хорошего ПМа со стороны, который придет, все организует, найдет ответственных, сделает разумный план проекта, организует управляющие комитеты, объяснит людям их роли на проекте, зафиксирует ответственных за работы, заложится на риски, и т.д. и т.п. После этого у вас работы встанут на проектные рельсы. Самим это делать может быть и дешевле, но долго — 2-3 года в среднем проходит от идеи «хотим делать проекты правильно» до «делаем проекты успешно».
Поскольку терминология гуляет от методологии к методологии, буду приводить объяснения по ходу рассуждений.
У вас у проекта есть инициатор, и есть спонсор (часто это одно и то же лицо, но не всегда).
Для вас главное спонсор — пусть для вас это ваш заказчик проекта (и не важно, он инициатор или нет).
Задача спонсора в этом проекте — организовать ресурсы для проекта в нужном количестве.
Задача ПМа — предоставить спонсору данные о ресурсах, необходимых в компании.
Для этого ПМ составляет план проекта, в которых входит план управления ресурсами. Последний (в вашем случае) должен отвечать на следующие вопросы:
— кто нужен?
— зачем нужен?
— когда нужен?
— на сколько нужен?
Предположим вам нужна уборщица тетя Глаша, для того что бы прибрать кабинет после того как айтишники насверлили там дырок для сети. Тета Глаша вам (и ПМу если это еще не вы) не подчиняется.
Так вот, вы включаете ее в план управления ресурсов, исходя из плана работ, который вы составили.
В плане работ вы видите, что айтишники будут тянуть сеть с 1 по 10 июля (± 1 день). Убирать за ними надо по вашим экспертным оценкам 2 дня.
Итого — в плане управления ресурсами вы пишете — «Тетя Глаша, с 10 по 12 июля, в объеме 16 часов».
После этого вы показываете план управления спонсору проекта, который либо соглашается с ним, либо вносит в него правки (например пишет, что может выделить тетю Глашу вместо 10-12 июля на 10-14 июля, но в объеме 4 часа в день — вы соглашаетесь, но объясняете спонсору что эта работа стоит на критическом пути проекта и следовательно срок всего проекта увеличивается на 2 дня (либо у вас есть запас по времени для этой работы)).
Итого, спонсор проекта (как правило это один из топ-менеджеров) подписывает вам план управления ресурсами, и согласно этому плану — ресурсы должны быть выделены.
Что происходит, например если тетя Глаша 10 июля вместо того что бы убирать кабинет после айтишников, уходит убирать цех по приему стеклотары (несмотря на все ваши напоминания об этой работе)? Вы пишете письмо ее руководителю, с копией на спонсора — который становится ответственным за задержку проекта на 1 день — а далее в соответствии с уставом проекта и внутренними регламентами к нему применяются санкции — например штрафы, лишение премии, и т.д.
Но, естественно, если ПМ в начале проекта тетю Глашу не попросил на 2 дня или не внес это в план управления ресурсами — ее руководитель имеет полное право отказать в предоставлении — и это значит что ПМ очень плохо планирует ресурсы.
Конечно, есть и изменения — например тетя Глаша заболела. Но у хорошего ПМа всегда есть 10% сроков — заложенных на риски, и это как раз тот самый (± 1 день) про который речь шла выше.
Ну или как то так. Если у вас серьезные проблемы с организацией проектной деятельности — наймите хорошего ПМа со стороны, который придет, все организует, найдет ответственных, сделает разумный план проекта, организует управляющие комитеты, объяснит людям их роли на проекте, зафиксирует ответственных за работы, заложится на риски, и т.д. и т.п. После этого у вас работы встанут на проектные рельсы. Самим это делать может быть и дешевле, но долго — 2-3 года в среднем проходит от идеи «хотим делать проекты правильно» до «делаем проекты успешно».
Сложно дать конкретный совет без понимания специфики компании и самого проекта (организационная структура, модель бизнеса, устоявшиеся бизнес-процессы и т.д.).
Тем не менее, начать нужно со следующих вещей:
1. Определить цели проекта
Зачем он нужен в принципе, какие задачи/проблемы бизнеса решает, какой результат ожидают заинтересованные стейкхолдеры, если они вообще есть. Любой заинтересованный VIP — ваш потенциальный союзник в преодолении бюрократических барьеров.
2. Определить ролевую модель проектной команды
Она будет зависеть от специфики самого проекта. Если это верхняя часть пирамиды (бизнес-процессы, разработка ПО) — она будет одна, если инфраструктурный проект — другая, стройка и инженерные системы — третья. Из этого будет понятно, какие подразделения необходимо будет привлечь для выполнения поставленных задач. Возможно, окажется так, что требуемых компетенций внутри компании не окажется, придется искать их на рынки (подрядчики, срочные трудовые договора и т.д.).
В любом случае, вам понадобятся ключевые участники команды:
Системный архитектор — будет отвечать за всю технологическую часть, чтобы результат проекта соответствовал требованиям и решал поставленную задачу. По сути за качество в проекте(соответствие заданным параметрам). Он должен декомпозировать глобальную задачу на составные части, определить численность и квалификацию необходимых для реализации ресурсов, и при их наборе поставить частные задачи каждому исполнителю.
ПМ — будет отвечать за всю организационную часть проекта (комментарии излишне, собственно об этом статья)
Специалисты по направлениям — например, проектировщики, аналитики. Кол-во и компетенции будут сильно зависеть от самого проекта.
3. Закрепление проектной команды
Если в компании "… вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин..." пишите и протаскивайте через руководство приказ о старте проекта с назначением ответственных исполнителей (согласно ролевой модели), а также Устав проекта, где должны быть описаны ответственность и полномочия каждого исполнителя. Это поможет персонализировать ответственность, как за результат в целом, так и за отдельные его части между исполнителями.
ВАЖНО! В описанной вами ситуации, если вы не найдете заинтересованных союзников среди ТОП-менеджеров, взаимодействие с горизонтальными подразделениями превратится в позиционно-осадную борьбу. Результат будет низким, а его достижение долгим. Должен быть арбитр данного взаимодействия.
Основная проблема, как я понял, что культура проектной деятельности в компании отсутствует, либо находится в крайне зачаточном состоянии.
Если в вашей компании проекты — это не мероприятия носящие разовый характер, нужен диалог с руководством о создании проектного офиса и внедрения процессов проектной деятельности на системной уровне. В противном случае, каждый старт и реализация нового проекта будет «как в первый раз».
Желаю вам удачи! Надеюсь все получится!
Тем не менее, начать нужно со следующих вещей:
1. Определить цели проекта
Зачем он нужен в принципе, какие задачи/проблемы бизнеса решает, какой результат ожидают заинтересованные стейкхолдеры, если они вообще есть. Любой заинтересованный VIP — ваш потенциальный союзник в преодолении бюрократических барьеров.
2. Определить ролевую модель проектной команды
Она будет зависеть от специфики самого проекта. Если это верхняя часть пирамиды (бизнес-процессы, разработка ПО) — она будет одна, если инфраструктурный проект — другая, стройка и инженерные системы — третья. Из этого будет понятно, какие подразделения необходимо будет привлечь для выполнения поставленных задач. Возможно, окажется так, что требуемых компетенций внутри компании не окажется, придется искать их на рынки (подрядчики, срочные трудовые договора и т.д.).
В любом случае, вам понадобятся ключевые участники команды:
Системный архитектор — будет отвечать за всю технологическую часть, чтобы результат проекта соответствовал требованиям и решал поставленную задачу. По сути за качество в проекте(соответствие заданным параметрам). Он должен декомпозировать глобальную задачу на составные части, определить численность и квалификацию необходимых для реализации ресурсов, и при их наборе поставить частные задачи каждому исполнителю.
ПМ — будет отвечать за всю организационную часть проекта (комментарии излишне, собственно об этом статья)
Специалисты по направлениям — например, проектировщики, аналитики. Кол-во и компетенции будут сильно зависеть от самого проекта.
3. Закрепление проектной команды
Если в компании "… вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин..." пишите и протаскивайте через руководство приказ о старте проекта с назначением ответственных исполнителей (согласно ролевой модели), а также Устав проекта, где должны быть описаны ответственность и полномочия каждого исполнителя. Это поможет персонализировать ответственность, как за результат в целом, так и за отдельные его части между исполнителями.
ВАЖНО! В описанной вами ситуации, если вы не найдете заинтересованных союзников среди ТОП-менеджеров, взаимодействие с горизонтальными подразделениями превратится в позиционно-осадную борьбу. Результат будет низким, а его достижение долгим. Должен быть арбитр данного взаимодействия.
Основная проблема, как я понял, что культура проектной деятельности в компании отсутствует, либо находится в крайне зачаточном состоянии.
Если в вашей компании проекты — это не мероприятия носящие разовый характер, нужен диалог с руководством о создании проектного офиса и внедрения процессов проектной деятельности на системной уровне. В противном случае, каждый старт и реализация нового проекта будет «как в первый раз».
Желаю вам удачи! Надеюсь все получится!
>> Например, строительство электростанции и разработка софта — кардинально разные проекты. Разная методология управления (PMI, Agile, Scrum…)…
PMI — Project Management Institute, а не методология.
PMBOK — свод знаний, об управлении проектами, разработанный PMI — а не методология (и это явно в нем прописано).
AGILE — философия, объединяющая в себе методы управления проектами, а не методология. Agile подходы так же включены в последнюю версию PMBOK, пруфлинк — www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
SCRUM — управленческий фреймворк (в крайнем случае набор принципов для построения процессов) применяемый для управления проектными командами, а не методология.
Правильнее было бы просто написать — разная методология управления, или методология управления построенная на разных принципах (гибкий и классический подходы).
Может быть я чего то не знаю, и какой то скрытый смысл за этим лежит?
Потому что сейчас в моих глазах это выглядит как закидывание в статью модных терминов (и аббревиатур).
PMI — Project Management Institute, а не методология.
PMBOK — свод знаний, об управлении проектами, разработанный PMI — а не методология (и это явно в нем прописано).
AGILE — философия, объединяющая в себе методы управления проектами, а не методология. Agile подходы так же включены в последнюю версию PMBOK, пруфлинк — www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
SCRUM — управленческий фреймворк (в крайнем случае набор принципов для построения процессов) применяемый для управления проектными командами, а не методология.
Правильнее было бы просто написать — разная методология управления, или методология управления построенная на разных принципах (гибкий и классический подходы).
Может быть я чего то не знаю, и какой то скрытый смысл за этим лежит?
Потому что сейчас в моих глазах это выглядит как закидывание в статью модных терминов (и аббревиатур).
Приветствую!
Большинство согласно, что 80% времени работы PM — коммуникации (а то и все 90)! Коммуникации с командой, с заказчиками, с другими стейкхолдерами проекта. А основные задачи в ходе проекта — управление рисками (намерено упустил этап подготовки)! Если рисков нет то и PM нам без надобности…
Как в Техносерве расставляют приоритеты для управления рисками проекта? Какие инструменты используют? Вот, собственно, что хотелось бы услышать.)
Большинство согласно, что 80% времени работы PM — коммуникации (а то и все 90)! Коммуникации с командой, с заказчиками, с другими стейкхолдерами проекта. А основные задачи в ходе проекта — управление рисками (намерено упустил этап подготовки)! Если рисков нет то и PM нам без надобности…
Как в Техносерве расставляют приоритеты для управления рисками проекта? Какие инструменты используют? Вот, собственно, что хотелось бы услышать.)
Я бы не делал особый уклон в сторону управления рисками, РП должен управлять всеми областями знаний. Просто в одном проекте особое внимание надо уделить именно рискам, в другом, например, срокам, в третьем — содержанию. Поэтому РП необходим даже в том проекте, где риски понятные и управляемые либо минимальные.
Теперь по существу вопроса. В Техносерв управление рисками осуществляется на всем жизненном цикле проекта — от пресейла до полного исполнения обязательств.
Так, на этапе пресейла и конкурса риски оцениваются не только руководителем проекта и архитектором/ГИПом, но и юристами, финансистами, бухгалтерией, договорным отделом. Составляется сводный реестр рисков и принимается решение go/no go.
На этапе исполнения проекта ответственный за управление рисками — РП, который ведет реестр рисков со следующими минимальными атрибутами: наименование риска, вероятность наступления, возможные последствия, меры противодействия. Такого реестра достаточно для поставочных проектов. Для более сложных проектов набор атрибутов шире. Добавляются причины возникновения риска, тактика работы с риском (принятие, снижение, уклонение, передача и разделение), степень влияния, оценка риска в деньгах. Рискам, которые имеют высокую степень наступления и влияния присваивается максимальный вес и уделяется особое внимание. В задачи РП входит регулярная актуализация реестра рисков.
Теперь по существу вопроса. В Техносерв управление рисками осуществляется на всем жизненном цикле проекта — от пресейла до полного исполнения обязательств.
Так, на этапе пресейла и конкурса риски оцениваются не только руководителем проекта и архитектором/ГИПом, но и юристами, финансистами, бухгалтерией, договорным отделом. Составляется сводный реестр рисков и принимается решение go/no go.
На этапе исполнения проекта ответственный за управление рисками — РП, который ведет реестр рисков со следующими минимальными атрибутами: наименование риска, вероятность наступления, возможные последствия, меры противодействия. Такого реестра достаточно для поставочных проектов. Для более сложных проектов набор атрибутов шире. Добавляются причины возникновения риска, тактика работы с риском (принятие, снижение, уклонение, передача и разделение), степень влияния, оценка риска в деньгах. Рискам, которые имеют высокую степень наступления и влияния присваивается максимальный вес и уделяется особое внимание. В задачи РП входит регулярная актуализация реестра рисков.
Sign up to leave a comment.
Правда ли, что ПМ делает что-то полезное и что нужно, чтобы им стать