«2014г. Об авторе Андрей Борисович Толстов • Один из самых успешных российских консультантов и бизнес-тренеров в области управления проектами, программами и портфелями • Автор популярных тренингов: Управление командой ...»

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

Строго говоря, подобные задачи не являются проектами в классическом понимании, а представляют собой по сути те же операционные задачи, которые управляются по проектной методологии.

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

Помимо этого в любой организации присутствуют также «настоящие» проекты, с которыми компания никогда не сталкивалась и не имеет представления относительно сроков, ресурсов, бюджета, рисков и реализуемости проекта в принципе. Это может быть вывод на рынок нового продукта или услуги, открытие филиальной сети, проведение корпоративной конференции, переезд головного офиса и проч.

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

Поделиться книгой Итак, мы разобрались, что такое проект и в чём его отличие от операционной деятельности.

Теперь нам необходимо понять: а зачем проектами как-то специально управлять?

Ведь у нас с Вами нет задачи управлять проектами просто ради того, чтобы управлять проектами, верно?

Что Вы думаете по этому поводу?

Зачем Вашей компании проектное управление?

Каких целей позволяет достичь методика управления проектами?

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

На самом деле всё проще, чем кажется.

Проектное управление используется для достижения следующих целей:

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

Чтобы не быть голословными, обратимся к исследованию PwC Insights and Trends: Current Portfolio, Programme, and Project Management Practices, согласно которому:

Согласно прогнозу Industry Growth Forecast 2010- Американского института управления проектами PMI к 2020 году мировой рынок проектного управления вырастет на $6,61 триллион, а спрос на квалифицированных руководителей проектов вырастет в среднем на 44%. При этом в данном секторе будет создано около миллионов новых рабочих мест, а доход компаний от проектного управления составит порядка $18,2 триллионов.

Сегодня ведущие мировые компании используют проектное управление для эффективной реализации своей бизнес-стратегии. Это даёт им весомое преимущество в напряженной рыночной конкурентной борьбе.

Поделиться книгой Руководитель проекта Ну, вот мы и добрались, наконец, до нашего героя – менеджера проектов.

Сейчас я попрошу Вас, не переходя к следующей странице, подумать несколько минут о том, кто такой руководитель проекта и что он должен делать.

Я любезно упрощу Вам задачу, сказав, что нужно выделить только 1 компетенцию, которой должен профессионально владеть проектный менеджер и ровно этим он должен заниматься большую часть своего времени.

Кто такой руководитель проекта и какой одной задачей он должен заниматься большую часть своего времени ?

Поделиться книгой Роль менеджера проектов Согласно определению PMI:

Менеджер проекта – это лицо, назначаемое исполняющей организацией для управления проектной командой, отвечающей за достижение целей проекта.

Я целиком и полностью согласен с каждым словом данного определения.

В нем совершенно четко прослеживается значение слова «Manager» в определении роли руководителя проекта, к которому мы так привыкли.

Собственно руководитель проекта – это человек, который управляет проектной командой. Т.е. это такой же менеджер как и все остальные.

При этом я рекомендую проектным менеджерам, которые регулярно проходят обучение на моих тренингах, сконцентрироваться в своей практике исключительно на управлении участниками проекта и перестать самостоятельно «ручками» выполнять задачи по проекту (программировать, разрабатывать архитектуру, писать документацию, делать прототипы, рисовать дизайн и проч.) Управление проектами – это отдельная профессия, основа которой заключается в умении эффективно управлять Вашей проектной командой.

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

Итак, чтобы стать классным менеджером проектов – Вам необходимо научиться управлять проектной командой!

Поделиться книгой Компетенции менеджера Если взглянуть на Pulse of the Professionтм, то можно заметить, что новое поколение проектных менеджеров для того, чтобы быть успешными согласно PMI, должны развиваться в трех направлениях:

1. Техники управления проектами 3. Стратегическое управление и менеджмент Мне лично такой подход очень близок, т.к. я всегда считал, что хороший руководитель проектов должен быть в значительной степени ориентирован на бизнес, чем на непосредственно изготовление самого продукта проекта.

Поделиться книгой Как стать менеджером Ко мне на тренинги часто приходят люди, которые раз за разом задают один и тот же вопрос: «Я сейчас работаю исполнителем, но я хочу быть руководителем проектов. Как мне им стать?»

Как Вы понимаете сложно дать однозначный ответ на этот вопрос.

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

Далее специалисты становятся помощниками руководителей проектов. Затем они начинают самостоятельно руководить небольшими проектами. Потом им доверяют более крупные и ответственные проекты. Далее специалист может вырасти в руководителя программ проектов или портфеля проектов, а потом и до руководителя Проектного офиса недалеко.

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

В моём понимании управление проектной командой – это и есть проектный менеджмент.

Поделиться книгой 10 навыков руководителя Меня часто спрашивают: какими основными навыками должен обладать классный проектный менеджер.

Вот 10 ключевых компетенций, которыми, на мой взгляд, должен обладать любой профессиональный руководитель проектов:

Техника проведения собеседований Техника постановки целей Техника работы с психотипами сотрудников Техника выговора Техника похвалы Ситуационное лидерство Техника проведения презентаций\публичного выступления Техника проведения совещаний\Техника фасилитации Техника переговоров 10. Техника продаж Только овладев этими приемами и техниками, Вы станете понастоящему звездой проектного управления!

Поделиться книгой Итак, мы с Вами выяснили, что менеджер проектов руководит проектной командой и отвечает за достижение целей проекта.

Теперь нам необходимо понять: а что это собственно за цели проекта такие?

Я сделаю Вам подсказку! У любого проекта, любой компании и любой отрасли всегда есть только 3 цели проекта! Какие?

Выполнить проект с минимальным отклонением от расписания Выполнить проект с минимальным отклонением от бюджета Выполнить проект в соответствии с требованиями заказчика Иными словами руководитель проекта отвечает за то, чтобы сделать проект максимально быстро, максимально дёшево и максимально качественно.

Вот и вся премудрость проектной работы. Ничего лишнего, никакой путаницы, никаких «сферических коней в вакууме», никаких 15- запутанных целей, никакой «воды».

Всегда помните про эти 3 цели и прилагайте все усилия для их достижения.

Ведь именно этого и ждут от Вас заказчики Ваших проектов!

Поделиться книгой В отличие от операционной деятельности, где заказчик задач и бизнес-процессов не всегда понятен, проекты всегда предпринимаются по чьему-то заказу.

В проектном управлении принято разделять понятия: заказчик проекта и спонсор проекта.

Заказчик проекта – это лицо, которое будет пользоваться продуктом, услугой или результатом, произведенным в рамках проекта.

Спонсор проекта – это лицо, обеспечивающее финансирование проекта и ожидающее получить доход от вложенных средств.

Давайте рассмотрим в качестве примера проект по внедрению, скажем, системы бухгалтерского учета в крупном холдинге.

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

Спонсором же данного проекта может быть например финансовый директор, который непосредственно сам не будет пользоваться системой в качестве пользователя, но ожидает получить определенный прирост производительности своего подразделения за счет внедрения автоматизированной систему бух.учета. Из бюджета его же подразделения и будет осуществляться финансирование проекта по внедрению данной системы.

На практике очень часто роль заказчика и спонсора выполняет одно и то же лицо. Я рекомендую по-возможности всё же разделять ответственность заказчика и от ответственности спонсора, т.к. по большому счету это две разные роли, смешение воедино которых снижает эффективность реализации проектов.

Бизнес-цели проекта Если менеджер проекта отвечает за 3 цели проекта, то тогда за что отвечает заказчик?

Заказчик же отвечает за бизнес-цели проекта.

Давайте подумаем, какие бизнес-цели может преследовать проект?

На самом деле любой проект может быть предпринят для достижения только 2х целей!

Все остальные цели являются производными от этих двух.

Поэтому по-возможности необходимо формулировать бизнес-цели проекта максимально близко к двум базовым целям.

К примеру, инфраструктурный проект по внедрению системы электронного документооборота преследует цель сокращения времени выполнения сотрудниками определенных операций. Что влечет за собой сокращение затрат компании на выполнении задач.

Проект по открытию филиала или представительства компании направлен на увеличение объема продаж в конкретном регионе.

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

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

Для обеспечения соответствия целей проекта целям компании применяется так называемое дерево целей.

Данное дерево разрабатывается для всей организации на 3-5 лет и в нем отображаются основные стратегические цели компании с привязкой к показателям их достижения.

Дерево целей может быть разработано с использованием различных методологий, к примеру с помощью хорошо известной Сбалансированной Системы Показателей (Balanced Scorecard) Нортона и Каплана.

Согласно этой методологии все цели компании распределяются по четырем перспективам:

Финансовые Внутренние бизнес-процессы Обучение и развитие сотрудников Пример дерево целей можно посмотреть здесь>> Таким образом, если в организации внедрено управление по целям, то каждый проект должен быть направлен на достижение хотя бы одной из них.

В противном случае управление проектами станет лишь затратами для Вашей компании и не приведет к желаемому результату.

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

В современном мире компании уже не могут позволить себе держать руководителя проекта «ремесленника». Сегодня бизнесу нужны менеджеры проектов, способные обеспечивать бизнес-результат, т.е.

зарабатывать деньги для компании.

В силу этого для профессионального проектного менеджера критически важно понимать бизнес-цели проекта и прилагать все усилия для их достижения.

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

Такой подход очень часто пугает начинающих руководителей проектов, которые привыкли быть человеком «с лопатой» и не отвечать за бизнес-показатели своих проектов.

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

В идеальном случае вся Ваша команда проекта должна быть предельно сфокусирована на достижении бизнес-целей. Только в этом случае Вы будете успешным проектным менеджером.

Поделиться книгой В настоящий момент зрелые, с точки зрения проектного управления компании, уже давно не управляют отдельными проектами.

Управление ведется на уровне портфеля проектов.

Портфель проектов - это совокупность проектов, программ и операционной деятельности, которая управляется скоординировано для достижения целей компании.

Это позволяет извлечь максимальную выгоду из методологии проектного управления.

Портфель проектов как правило состоит из нескольких программ и отдельных проектов, сгруппированных по бизнес-целям.

Например, Программа проектов, направленная на увеличение продаж Программа проектов, направленная на сокращение затрат Программа проектов, направленная на разработку новых продуктов Поделиться книгой Откуда берутся проекты?

Прежде чем двигаться дальше, необходимо понять: откуда появляются проекты в любой компании.

До момента своего появления портфель проектов проходит ранние этапы согласования на верхних уровнях организации.

В основе всего лежит Видение компании. Видение диктует будущее компании, то куда мы как бизнес должны придти в конечном итоге.

Это некая мечта о том, зачем создавалась компания и куда она идет.

Миссия компания – это причина того, зачем компания существует на рынке.

В качестве хорошего примера миссии компания можно привести следующие, на наш взгляд, удачные примеры:

«To make people happy» - Disneyland «Leverage people, technology and resources to build collective knowledge and enable action to improve communities throughout the world» - Salesforce «HubSpot aims to help its customers make marketing that people actually love» HubSpot На уровне Видения и Миссии работает как правило собственники компании, а также высшее руководство во главе с Советом Директоров.

Далее из Видения и Миссии рождаются Стратегические цели организации на 1,3,5, 10 или даже 20 лет в зависимости от принятого горизонта планирования в конкретной компании.

Стратегические цели уже в конкретных цифрах выражают ожидания акционеров компании от топ-менеджмента компании.

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

Для понимания мирового опыта использования управления портфелем проектов, давайте взглянем на исследование PMI Portfolio Management: In-Depth Report.

управления портфелем Итак, мы с Вами поняли, что управлять проектами по отдельности невыгодно.

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

Для того, чтобы внедрить в организации полноценное управление портфелем проектов, необходимо переосмыслить процесс бизнеспланирования и разделить бизнес-план компании на 2 составные части:

операции (задачи) и портфель проектов.

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

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

Таким подразделением в большинстве организаций служит Проектный офис, о котором и поговорим в следующем разделе.

Поделиться книгой А в Вашей компании внедрен Проектный офис?

Грубо говоря, зачем он нужен Вашей компании?

После многолетнего опыта управления Проектным офисом, я могу сказать, что единственная цель Проектного офиса – это выполнить портфель проектов в срок, в бюджет и с надлежащим качеством.

Проектный офис – это структурное подразделение компании, которое отвечает за реализацию портфеля проектов.

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

Я выделяю 9 основных задач Проектного офиса, которые, на мой взгляд, являются основными для данного подразделения:

Бизнес-планирование\Формирование портфеля проектов Управление ресурсами Управление портфелем проектов Управление ключевыми проектами Накопление лучших практик\lessons learned Разработка и улучшение методологии управления проектами Подбор руководителей проектов Обучение руководителей проектов Внедрение инструментов управления проектами (PPM) Поделиться книгой Согласно исследованию PM Solutions The State of the PMO организации всех размеров и отраслей имеют в своем составе Проектный офис:

Кому должны подчиняться На моих тренингах по эффективному внедрению и управлению Проектным офисом слушатели очень часть задают мне вопрос: «Должны ли руководители проектов подчиняться Проектному офису или эффективнее, чтобы они находились в структурных подразделениях?»

На этот вопрос сложно ответить однозначно. Всё зависит от специфики конкретной организации.

Обычно на практике встречается 3 варианта:

Руководители проектов сконцентрированы только в функциональных подразделениях.

Руководители проектов сконцентрированы только в Проектном офисе.

Руководители проектов примерно поровну распределены между Проектным офисом и функциональными подразделениями.

Если отвечать на этот вопрос «в лоб», то я бы сказал, что более эффективно, когда все менеджеры проектов находятся в Проектном офисе и работают по единой методологии, процессам и стандартам. Это позволяет постоянно улучшать процессы проектного управления, тем самым повышая эффективность реализации проектов.

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

Поделиться книгой В проектном управлении есть такое понятие как факторы среды организации.

Давайте разберемся с этим вопросом более детально.

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

• Организационная структура компании • Корпоративная культура компании • Инфраструктура компании • Государственные отраслевые стандарты • Требования регуляторов • Конкурентное окружение Соответственно, каждый профессиональный руководитель проектов прежде, чем приступить к работе над проектом, в первую очередь анализирует данные факторы среды и выстраивает свою работу таким образом, чтобы минимизировать негативное влияние факторов среды на успех проекта, а по возможности использовать их на благо своего проекта.

Среди факторов среды особое внимание стоит обратить на организационную структуру компании, о которой мы сейчас и поговорим.

Поделиться книгой Одним из ключевых условий эффективного использования проектного управления в организации является переход от функциональной организационной структуры к матричной организационной структуре.

Во время консалтинговых проектов по внедрению проектного управления для наших заказчиков, мы всегда уделяем этому моменту пристальное внимание.

Дело в том, что управление проектами в функциональной структуре работает крайне неэффективно.

Что такое функциональная организационная структура?

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

Поделиться книгой организационная структура Матричная организационная структура предполагает:

• Наличие горизонтальных связей между отделами • Наличие самой роли – менеджер проекта • Управление ресурсами должно быть в руках менеджера проекта • Бюджет, выделенный на проект находится в руках менеджера проекта • Как правило наличие Проектного офиса Схематически это выглядит вот так:

Поделиться книгой Взаимосвязь проектной и операционной деятельности Мне очень часто как консультанту и бизнес-тренеру приходится слышать следующий вопрос: «А как устранить противоречия между проектной и операционной деятельностью?»

На мой взгляд, противоречия как такового не существует.

Если говорить о внутренних проектах компании, то операционная деятельность почти всегда выступает заказчиком для проектной деятельности.

Например, директор по маркетингу заказывает в Проектном офисе компании внедрение нового корпоративного сайта. Или директор по продажам заказывает внедрение CRM-системы. В данном случае Проектный офис выступает как внутренний подрядчик, а заказчиком является представитель операционной деятельности.

Соответственно и взаимоотношения между этими двумя сторонами строятся по принципу партнерских взаимоотношений с подписанием внутренних контрактов, переговорами и прочими атрибутами.

Если проводить военную аналогию, то операционная деятельность - это фронт, который заказывает в тылу (проектная деятельность) новые типы вооружения, которые позволят более эффективно уничтожать противника (зарабатывать деньги).

Проект – это временное предприятие, предназначенное для создания Поделиться книгой Теперь рассмотрим ещё одно ключевое понятие, применяемое в проектном управление. Оно носит название активы процессов организации.

Здесь речь идет о том, что выполняя проект для конкретной организации, менеджер проекта не может не учитывать бизнес-процессы, регламенты, правила и процедуры принятые в данной организации.

Среди классических примеров активов процессов можно привести следующие:

• Корпоративный стандарт управления проектами • Шаблоны проектных документов • Правила взаимодействия участников проектов • Политика привлечения ресурсов в проекты • Политика премирования участников проектов • Правила проведения рабочих групп • Различные кадровые политики и процедуры • Шаблоны контрактов и договоров • Принципы бухгалтерского учета Соответственно, во время реализации проектов руководителю проекта необходимо управлять проектом в соответствии с принятыми в данной компании регламентами.

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

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

Возьмем за основу модель жизненного цикла организации, которую предлагает И.Адизес в своей книге «Управление жизненным циклом корпорации»

Согласно этой модели каждая компания проходит через стадий жизненного цикла: Выхаживание, Младенчество, «Давай-давай», Юность, Расцвет, Стабильность, Аристократизм, Ранняя бюрократизация, Бюрократизация и Смерть.

Давайте посмотрим, как на каждой стадии развития организации выглядит проектное управление.

Поделиться книгой Проектное управление На стадии Выхаживание ещё бизнеса компании нет как такового. Поэтому говорить о проектном управлении здесь не приходится.

На стадии Младенчество вся организация представляет собой один большой проект. Операционной деятельности как таковой ещё не существует. Поэтому в start-up’ах в общем-то можно говорить о проектном управлении.

На стадии «Давай-давай» вся компания занимается только проектами, а операционной деятельности отводится минимум внимания. На данном этапе проектное управление в полном объеме не применимо, т.к.

только замедлит и сделает более дорогой всю деятельность компании.

Стадия Юности характеризуется наличием небольшого штата специалистов. Операционная деятельность начинает формироваться, но проекты по-прежнему играют основную роль в развитии компании.

Стадия Расцвета предполагает формализацию бизнеспроцессов, стабилизацию деятельности компании и постановки процессов управления проектами на более системном уровне. На этой стадии самое время задуматься о внедрении и использовании проектного управления.

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

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

На стадиях Ранней бюрократизации и Бюрократизации процессы проектного управления носят формальный бюрократический характер, как впрочем и все остальные процессы компании.

На стадии Смерти…А впрочем не будем о грустном.

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

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

Поделиться книгой Заключение 1ой части Итак, мы с Вами разобрали основные понятия и определения проектного управления:

Операционная деятельность Критерии проекта Цели проекта и бизнес-цели Методологии управления проектами Сертификация в области управления проектами Цель проектного управления Роль руководителя проекта Основные компетенции и навыки руководителя проектов Роль заказчика и спонсора проекта Факторы среды и активы процессов организации Портфель проектов Функциональная и матричная организационная структура Проектное управление на разных стадиях жизненного цикла В следующий части книги мы поговорим об основных процессах управления проектами.

Поделиться книгой Поделиться книгой Процессы управления В этом разделе я по шагам разберу основные процессы, которые применяются для управления практически любыми проектами.

В зависимости от типа, размера и специфики конкретного проекта данные процессы могут меняться: что-то может добавляться, что-то может не использоваться, но общая канва остаётся той же самой.

Если Вы начинающий руководитель проекта, то я бы рекомендовал Вам на данном этапе не сильно вдаваться в детали отдельных процессов, а постараться ухватить общую логику и общий алгоритм управления типовым проектом.

Поделиться книгой Процессы управления Любой проект состоит из 5ти групп процессов управления:

Группа процессов инициации проекта Группа процессов планирования проекта Группа процессов исполнения проекта Группа процессов завершения проекта Группа процессов мониторинга и контроля проекта проекта документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать ресурсы организации в операциях проекта Мониторинг и Инициация Планирование Исполнение Каждая из этих групп процессов состоит в свою очередь из подпроцессов.

В разных методологиях описывается разное количество процессов. Например, в стандарте PMBOK4 содержится описание процессов управления проектами, а в стандарте PMBOK5 их 47.

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

Здесь нет универсальной «таблетки», которая бы одинаково хорошо работала во всех компаниях. Каждая организация должна сконфигурировать свои процессы самостоятельно, либо привлекая консалтинговую компанию, специализирующуюся на постановке процессов проектного управления.

Как правило каждая организация, в которой внедрено проектное управление имеет в своём активе процессов документ, который называется Корпоративный Стандарт Управления Проектами (КСУП).

В этом документе как раз и описываются процессы управления проектами, применяемые в данной организации.

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

Также это зависит от того, какую методологию управления проектами применяет организация в своей практике. Если это PMBOK, то набор процессов будет один, если это SCRUM, то набор процессов будет другой, а если это PRINCE2, то третий и т.д.

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

Идея состоит в том, что любой проект независимо от отрасли и размеров компании проходит один и тот же набор стадий жизненного цикла.

Как правило типовой жизненный цикл проекта состоит из шести этапов:

1. Начало проекта (запуск проекта) 2. Подготовка проекта\Сбор требований 4. Выполнение работ по проекту 5. Внедрение продукта проекта\Развертывание 6. Завершение проекта\Передача в операционную деятельность Поделиться книгой Необходимо понимать разницу между жизненным циклом продукта и жизненным циклом проекта.

Жизненный цикл продукта - это более широкое понятие. Он как правило состоит из следующих стадий:

• Маркетинговые исследования • Проектирование\Прототипирование продукта • Планирование и разработка процесса управления • Закупка необходимых ресурсов для создания продукта • Проверка\Контроль качества продукта • Упаковка и хранение продукта • Поставка, монтаж и наладка продукта • Техническая поддержка и обслуживание продукта • Послепродажное сопровождение продукта • Утилизация и(или) переработка продукта Соответственно для каждой стадии жизненного цикла продукта может быть инициирован отдельный проект, который протекает по своему жизненному циклу проекта.

Скажем мы разрабатываем смартфон нового поколения. В рамках жизненного цикла продукта у нас предусмотрен этап анализа спроса. Этот этап будет отдельным проектом со своим собственным жизненным циклом.

Давайте теперь познакомимся с ещё одним ключевым понятием проектного управления – фазами проекта.

Существует 2 подхода к выполнению проекта. Мы можем выполнять процессы последовательно для всего проекта целиком, либо «фазировать», т.е. выполнять все процессы, но для каждого этапа проекта.

Фазирование обычно применяется для тех проектов, требования которых либо отсутствуют вовсе, либо плохо прописаны.

Идея фазирования легла в основу концепции итерационной разработки проекта спринтами, применяемая в методологии Agile.

Поделиться книгой Стадия Инициации проекта, как правило состоит из одного процесса:

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

На данном этапе определяется заказчик проекта и назначается руководитель проекта, а также определяются бизнес-цели проекта.

На этой стадии неопределенность проекта максимальна, т.е.

ещё непонятно: ни сроки реализации проекта, ни затраты, ни кто будет в проектной команде, ни что получится в конечном итоге и какие риски повлечет за собой данный проект.

В ходе этапа Инициации неопределенность снижается примерно до +200% от конечных данных.

В ходе этапа планирования неопределенность проекта должна быть уменьшена до +10-15% в терминах затрат, сроков и качества.

Поделиться книгой Любой проект начинается с разработки так называемого Устава проекта.

Устав проекта - документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать ресурсы организации в операциях проекта Устав проекта представляет собой документ, в котором описываются следующие моменты:

Экономическое обоснование проекта Описание основных требований к проекту Что остается за рамками проекта Предварительные сроки реализации проекта Предварительный бюджет проекта Данный документ как правило разрабатывается проектным менеджером и подписывается заказчиком проекта. Этот шаг является скреплением договоренностей между руководителем проекта и заказчиком об основных моментах будущего проекта.

В некоторых организациях Устав проекта также называется Заявкой на запуск проекта, что в общем-то отражает предназначение данного документа.

Поделиться книгой Важно помнить, что в соответствии с ведущими методологиями управления проектами, а также существующей практикой, инициация проектов производится внешним по отношению к проекту лицом или лицами.

То есть проект не может быть запущен решением заказчика проекта или проектным менеджером самостоятельно.

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

Как правило такой орган называется Проектный комитет, хотя также широко употребимы названия: Инвестиционный комитет, Steering Committee, Управляющий комитет и проч.

В состав данного коллегиального органа должны входить представители всех ключевых подразделений компании, таких как:

маркетинг, продажи, производство, ИТ, финансы и проч.

Только после защиты Устава на Проектном комитете проект считается запущенным и переходит на стадию планирования.

Как правило защиту Устава проекта производит проектный менеджер совместно с заказчиком проекта. Иногда защита проекта на Проектном комитете производится без участия проектного менеджера.

После утверждения Устава проекта на Проектном комитете выпускается приказ о запуске проекта, который публикуется на уровне всей компании. Устав проекта - документ, выпущенный инициатором или спонсором проекта, который формально узаконивает Поделиться книгой существование Теперь я предложу Вам выполнить упражнение, которое я даю на своём базовом тренинге по основам управления проектами по стандарту PMI PMBOK5.

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

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

того, как устав готов, Вам было бы необходимо защитить его перед остальными участниками курса, которые выступают в роли Проектного комитета.

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

Защита Устава проекта иногда приходит довольно непросто, нервозно и представляет собой весьма стрессовую ситуацию для начинающего руководителя проекта.

Для того, чтобы стать по-настоящему первоклассным проектным менеджером, Вам необходимо как можно чаще посещать Проектный комитет с целью защиты Устава проекта. Это поможет Вам отработать навык презентации, который является критически необходимым в арсенале любого профессионального руководителя Поделиться книгой Стадия планирования проектов состоит как правило из следующих процессов:

Определение заинтересованных сторон проекта Сбор требований Разработка технического задания Разработка Иерархической Структуры Работ (ИСР) Разработка расписания проекта Разработка бюджета проекта Разработка плана управления рисками Подготовка плана управления проектом То есть проект не может быть запущен решением заказчика проекта или проектным менеджером самостоятельно.

Устав проекта - документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование Поделиться книгой В проектном управлении широко распространено понятие:

«Заинтересованная сторона проекта (Stakeholder)».

Давайте разберемся с этим моментом более детально.

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

В качестве примеров заинтересованных сторон можно выделить:

• Пользователей продукта • Руководители функциональных подразделений • Подрядчики\контрагенты • Регулирующие органы Поделиться книгой Заинтересованные компании, Реестр заинтересованных В результате процесса идентификации заинтересованных сторон проекта рождается так называемый реестр заинтересованных сторон проекта.

В данном документе как правило отражаются следующие моменты:

ID заинтересованной стороны ФИО заинтересованный стороны Подразделение\компания, в котором(ой) работает заинтересованная Должность заинтересованной стороны Контактная информация Тип: внешняя или внутренняя Предпочтительный канал коммуникаций и их периодичность Требования данной заинтересованный стороны к проекту и продукту Основные риски, которые заинтересованная сторона видит в проекте По опыту могу сказать, что количество заинтересованных сторон в реальном проекте может доходить до нескольких сотен и даже тысяч.

У проектного менеджера нет ни желания, ни возможности управлять абсолютно всеми заинтересованными сторонами.

Для успешного выполнения проектами необходимо управлять заинтересованными сторонами с наивысшей властью и интересом к проекту.

Поделиться книгой Следующий процесс, который нам предстоит изучить – это сбор требований к проекту и продукту.

Требование (Requirement) - определенные условия или характеристики, которым должны соответствовать или которые должны иметь система, продукт, услуга, результат или элемент в соответствии с контрактом, стандартами, характеристиками или другими формальными предписывающими документами.

Самый главный момент, который стоит запомнить начинающему руководителю проектов:

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

Это является одной из самых распространенных ошибок, которую Вам ни в коем случае нельзя допускать!

Требования необходимо тщательным образом собирать со всех заинтересованных сторон проекта, которых мы идентифицировали на предыдущем шаге..

Поделиться книгой На практике прежде чем приступать к сбору требований по проекту разрабатывается так называемый план коммуникаций.

Этот документ позволяет значительно повысить эффективность коммуникаций, число которых как мы знаем составляет:

где N – количество участников команды проекта Таким образом если в Вашей команде 10 человек работает над проектом, то количество коммуникаций между ними в единицу времени может составлять 45.

Для того, чтобы как-то упорядочить и систематизировать данные информационные потоки применяется, план управления коммуникациями.

Данный план как правило содержит следующую информацию:

Кто передает информацию (Отправитель) Кому передает (Получатель) Как часто (ежедневно, еженедельно и проч.) Каким способом (email, телефон, skype, телеконференция и проч.) В каком формате (отчет в Excel, презентация в PowerPoint и проч.) Пример плана коммуникаций можно посмотреть здесь>> Поделиться книгой После того, как все требования собраны, настаёт черед разработки документа, который почти во всех компаниях и отраслях носит название техническое задание (ТЗ) В данном документе самым детальным образом прописываются все требования и характеристики будущего продукта до мельчайших подробностей.

Объем данного документа довольно значительный и на практике составляет от 100 страница и более. Для крупных проектов объем данного документа может доходить до нескольких тысяч страниц.

Как Вы понимаете, читать данный документ заказчику не очень удобно в силу его громоздкости и технической направленности.

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

Необходимо отметить, что этап написания всеобъемлющего ТЗ для продукта целиком характерно только для классических waterfall’льных методологий, таких как PMMBOK. Современные методологии гибкой разработки, такие как SCRUM, не предполагают написание ТЗ для всего продукта целиком. Вместо этого пишется краткое ТЗ на 1-2 ближайших цикла разработки проекта (спринта), которые хочет видеть заказчик.

После того, как первые результаты будут достигнуты пишется ТЗ на следующие итерации проекта и т.д. которые должны иметь система, продукт, услуга, результат или элемент в соответствии с контрактом, стандартами, характеристиками Поделиться книгой Иерархическая Структура Иерархическая Структура Работ (Work Breakdown Structure) – это ориентированная на результаты (предметы поставки) иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и получения необходимых результатов.

Как правило ИСР представляет собой графическую схему, на которой отображаются результаты, из которых будет состоять продукт проекта.

Пример ИСР для разработки программного продукта может выглядеть так:

или которые должны иметь система, продукт, услуга, результат или элемент в соответствии с контрактом, стандартами, характеристиками или другими формальными предписывающими документами.

Для разработки ИСР я рекомендую пользоваться следующими программами: MS Visio, бесплатной ARIS Express или модными ныне MindManager’ами.

Составление плана работ Составление плана работ любого проекта состоит как правило из пяти шагов:

• Шаг 1. Определение операций • Шаг 2. Определение последовательности операций • Шаг 3. Определение ресурсов для выполнения операций • Шаг 4. Определение длительности операций • Шаг 5. Составление расписания проекта Давайте более детально разберем каждый шаг.

Поделиться книгой Определение операций После того, как ТЗ и ИРС утверждены заказчиком можно приступать к разработке плана проекта.

Для этого мы должны разбить атомарные части ИСР, которые называются пакеты работ, на составные части – операции.

То есть для каждого «квадратика» ИСР мы пишем несколько операций, направленных на получение данного результата. Операции формулируются в отглагольных оборотах: «Сделать», «Разработать», «Подготовить» и проч.

Для примера возьмем пакет работ «Требования» из нашего предыдущего примера.

Список операций для данного пакета работа будет выглядеть следующим образом:

Встретиться с заказчиком Обсудить требования Подготовить черновик с описанием требований Отправить заказчику на согласование Оформить финальный документ с требованиями Все эти операции мы заносим в информационную систему управления проектами, которую мы используем в нашем проекте. Скажем это может быть классический MS Project.

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

последовательности операций Как Вы наверное догадываетесь, не все операции в проекте выполняются одновременно. Часть операций выполняется в определенной последовательности.

Для определения последовательностей операций принято использовать так называемые связи, которые бывают четырех типов:

Окончание-начало Начало-окончание Начало-начало Окончание-окончание На практике самым используемым типом связей является Окончание-Начало. Эта связь означает, что операция B не может начаться пока не закончилась операция А.

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

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

В проектном управлении принято выделять три типа ресурсов:

Материальные Трудовые ресурсы – это то количество человеко-часов определенных специалистов, которые нам потребуются для выполнения задач. Трудовые ресурсы как правило измеряются в часах, хотя для некоторых проектов используется измерение в днях или неделях.

Материальные ресурсы – это количества материалов (кирпич, цемент, бетон, брус, сервера и проч.), которое нам потребуется для выполнения задач по проекту.

Финансовые ресурсы – это то количество денежных средств (в рублях, долларах или другой валюте), которое нам потребуется для выполнения задач по проекту.

Например для создание информационной системы нам потребуется 30ч. дизайнера, 50ч. аналитика, 150ч. программиста, 40ч.

тестировщика, 50 часов администратора, 2 сервера и $30 000.

Поделиться книгой Определение длительности На этом этапе мы должны определить длительность выполнения каждой операции.

Длительность операций как правило измеряется в днях.

Существует несколько основных методов, с помощью которых рассчитывается длительности операций:

Параметрическая оценка Оценки по трем точкам (PERT) К сожалению, в рамках данной книги у меня нет возможности подробно разобрать каждый метод в отдельности.

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

Такая оценка в силу ряда причин, почти всегда бывает слишком оптимистичной и заниженной, что приводит в итоге к срыву сроков проекта.

Поделиться книгой Календарный план проекта как правило составляется в виде так называемой диаграммы Ганта. Пример плана проекта может выглядеть как показано на рисунке ниже.

Необходимо не забывать про так называемые вехи проекта.

Вехи на диаграмме Ганта обозначаются ромбиком.

Контрольное событие (Веха) - важный момент или событие, завершающее каждый этап проекта Поделиться книгой Теперь когда Вы изучили 5ти шаговый алгоритм составления плана проекта, возьмите свой реальный проект, запустите MS Project или другую автоматизированную систему управления проектами и разработайте расписание для своего настоящего проекта.

Перед тем, как разрабатывать расписание в MS Project неплохо бы иметь под рукой WBS Вашего проекта. Поэтому начните планирование своего проекта с разработки WBS. В дальнейшем это существенно облегчит Вам задачу построения эффективного плана проекта.

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

100 операций – это некий ориентир. Дело в том, что согласно моему опыту, расписание реального проекта должно состоять минимум из 100 операций. Если у Вас получается меньше, это означает, что либо Вы взяли маленький «ненастоящий» проект, либо Вы что-то неправильно спланировали.

Участники моих тренингов успешно справляются с этой задачей после того, как изучат алгоритм составления плана проекта, который я Вам описал.

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

Бюджет проекта определяется исходя из стоимости ресурсов, необходимых для выполнения операций проекта.

К примеру мы определили, что для реализации нашего проекта нам потребуется следующие трудовые ресурсы:

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

В итоге у нас должно получиться примерно следующее:

Поделиться книгой Как правило затраты проекта делятся на прямые и косвенные.

Прямые затраты – это те затраты, которые направлены на создание непосредственно самого продукта, услуги или результата проекта.

Примером таких затрат может служить: заработная плата сотрудников, закупка товаров или услуг в рамках проекта, работа подрядчиков, аренда помещения, премии проектной команде и проч.

Косвенные затраты – это те затраты, которые направлены на сопровождение процесса получения продукта, услуги или результата проекта.

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

Также в проектном управлении есть такое понятие как совокупная стоимость владения (Total Cost of Ownership, TCO).

Совокупная стоимость владения – это общая сумма затрат, которую будет нести заказчик проекта на эксплуатацию продукта проекта после окончания проекта.

Т.е. это все те издержки, направленные на сопровождение и эксплуатацию продукта, услуги или результата проекта.

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

Теперь нам необходимо подготовить план управления рисками и заложить в план проекта резервы по срокам и стоимости.

Риск – это неопределенное событие или условие, которое, в случае наступления, влияет хотя бы на одну цель проекта Примерами рисков проекта могут служить:

Поломка оборудования Увольнение ключевого сотрудника Землетрясение вблизи объекта Смена заказчика Срыв сроков подрядчиком На данном этапе мы должны выявить все угрозы, способные повлиять на цели нашего проекта и спланировать действия, необходимые для предотвращения наступления данных событий и\или минимизации воздействия данных событий на цели проекта.

резервы, размер которых относительно общего бюджета и длительности проекта должен составлять порядка 10-15%.

– это неопределенное событие или условие, которое, в случае наступления, влияет хотя бы на одну цель проекта Поделиться книгой Итак, мы с Вами подходим к концу стадии планирования.

Выходом данной стадии является документ, который носит название план управления проектом.

Этот документ является агрегирующим и как правило включает в себя следующие элементы:

Данный документ, также как и Устав проекта, защищается на В итоге данный документ подписывает заказчик проекта и только после этого мы можем перейти на стадию исполнения Поделиться книгой В рамках процессов исполнения проекта менеджер проекта должен обеспечить получение результатов, обозначенных на ИСР в рамках срока и бюджета, закрепленного в плане управления проектом, утверждённого заказчиком.

Именно на этом этапе происходит набор проектной команды и заключение договоров с подрядчиками.

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

Риск – это неопределенное событие или условие, которое, в случае наступления, влияет хотя бы на одну цель проекта Поделиться книгой Формирование команды проекта осуществляется на этапе исполнения после того, как заказчик утвердил план управления проектом.

В ходе процесса набора команды определяются требования к компетенциям каждой роли, участвующей в нашем проекте.

В зависимости от того, какого уровня специалисты нам нужны в проектную команду, будет зависеть итоговая стоимость проекта, а также сроки его реализации.

Для планирования и набора проектной команды как правило используются следующие методы:

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

Данный процесс позволяет на раннем этапе выявить несоответствия между требованиями, которые были зафиксированы в ТЗ и тем, что получается в результате исполнения.

Для этого применяются следующие инструменты:

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

Все эти инструменты позволяют произвести в итоге именно те результаты, которые ожидает получить заказчик.

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

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

Изменение – это корректировка утвержденных требований или их отдельных характеристик, а также добавление новых требований в проект.

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

Риск новой «фичи», которую он хочет, чтобы Вы включили в случае наступления, влияетплан уже на одну цель проекта При этом хотя бы утвержден, сроки и затраты спланированы, команда сформирована, ресурсы распределены. Что делать в такой ситуации?

Отказать заказчику? Взять в работу новое требование?

Вещь №1, которую Вы должны четко понимать – это то, что изменение – это неотъемлемая часть любого проекта. Т.е. изменение – это нормально.

Вещь №2, которую следует запомнить начинающему руководителю проектов – Ваш процесс управления проектом должен быть выстроен таким образом, чтобы заказчику проекта было максимально комфортно вносить изменения в проект.

Для этого на этапе планирования Вам необходимо разработать и согласовать с заказчиком процесс управления изменениями для Вашего проекта.

Этот процесс должен быть предельно понятен и прозрачен всем участникам проекта: начиная от заказчика и заканчивая рядовым членом проектной команды., Поделиться книгой Я дам Вам готовый процесс, который отлично зарекомендовал себя на практике, чтобы Вы могли сразу же использовать его и не изобретали велосипед.

Итак, я рекомендую использовать процесс управления изменениями, состоящий из восьми простых шагов.

Оформить запрос на изменение Уточнить требование Сообщить о своих действиях заказчику Проанализировать с командой влияние на сроки и затраты Если влияет, то рассчитать новые сроки и затраты Если не влияет, то принять в работу и сохранить новый Согласовать решение с заказчиком Согласовать решение на Комитете по изменениям (если Используя данный алгоритм, Вы всегда будете уверены в том, что содержание Вашего проекта находится под контролем и что заказчик останется доволен Вашей работой!

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

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

В случае внутреннего проекта бизнес-внедрение как правило осуществляет проектная команда под руководством менеджера проекта.

С случае с внешним проектом готовый продукт передается заказчику и он уже сам на своей стороне осуществляет его развертывание и полноценное внедрение в бизнес-процессы компании.

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

Я рекомендую в обязательном порядке писать план внедрения и отката продукта. Перед внедрением необходимо продумать не только позитивный сценарий, но и действия, которые необходимо будет предпринять в случае если внедрение проекта окажется неудачным и придется в спешном порядке производить «откат» всех действий. Т.е. у Вас как у профессионального проектного менеджера всегда должен быть «план Б», который вступит в силу в случае форс-мажоров.

План развертывания и отката обычно содержит следующие элементы:

Кто и в какой момент выполняет ту или иную операцию по развертыванию Тайминг каждой операции Последовательность выполнения Действия на случай неудачного внедрения Поделиться книгой Информационные системы управления проектами Управление проектами уже давно ведется с использованием современных автоматизированных информационных систем, которые позволяют составлять диаграмму Ганта, разрабатывать бюджет, управлять ресурсами, осуществлять коммуникацию с членами команды, управлять рисками, отслеживать исполнение плана проекта, строить отчеты по проекту и многое-многое другое.

Самым классическим решением для автоматизации проектного управления является «старина» MS Project.

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

Теперь управление проектами, программами и портфелями ведется в так называемых PPM-системах.

Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals while honouring constraints imposed by customers, strategic objectives, or external real-world factors.

Давайте взглянем на представителей лучших в своём классе PPM-систем… Поделиться книгой Для этого давайте взглянем на соответствующий Gartner Magic Quadrant:

Риск – это неопределенное событие или условие, которое, в случае наступления, влияет хотя бы на одну цель проекта Как мы видим, лидерами в данной категории программного обеспечения на сегодняшний день являются: Innotas, Instantis, Daptiv и AtTask.

Я хотел бы рассказать Вам чуть поподробнее об AtTask… Поделиться книгой Впервые я познакомился с этой системой когда руководил Проектным офисом в одной крупной международной финансовой компании.

Мы тогда использовали «старый добрый» MS Project. Однако в один прекрасный момент я осознал потребность в единой системе, которая позволяла бы мне и руководству компании эффективно управлять не только отдельными проектами, но и всем портфелем проектов целиком.

Функционал управления портфелями и программами почти никак не реализован в MS Project, даже с использованием связки MS Project Server+MS SharePoint. Поэтому мы начали смотреть на другие более современные облачные системы, которые позволяли бы нам добиться своей цели.

Нами были проанализированы порядка 15 самых различных PPM-систем и наш выбор пал на систему AtTask.

Наши самые смелые ожидания оправдались сполна! Мы получили современную систему, в которой в одном месте можно управлять всем портфелем, планировать и назначать ресурсы не только на отдельные проекты, но и на весь портфель целиком. Также в системе мы нашли удобный интерфейс, работу через веб, удобную систему хранения документов и коммуникации а-ля «Facebook», потрясающую систему отчетности и дашбордов, великолепные модули управления финансами, рисками и проблемами и многое-многое другое.

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

Группа процессов завершения проекта состоит как правило из следующих процессов:

Передача проекта заказчику\в операционную деятельность Подписание Акта приемки проекта Закрытие договоров, подписанных в рамках проекта Освобождение ресурсов, занятых на проекте Закрытие проекта Риск – это неопределенное событие или условие, которое, в случае наступления, влияет хотя бы на одну цель проекта Поделиться книгой Одним из основных документов, которые необходимо подготовить в рамках процесса завершения проекта, является акт приемки.

В этом документе детально описываются те результаты, которые были произведены в рамках проекта и которые будут переданы заказчику проекта.

Помимо результатов также в акте необходимо указать перечень пользовательской и технической документации, которая также передается заказчику.

Проект принимает как правило не один заказчик, а целая приемная комиссия, состоящая из ключевых заинтересованных сторон проекта.

В результате приемки проекта приемочная комиссия может вынести три варианта вердикта:

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

Акт приемки как правило подписывает заказчик проекта и все члены приемочной комиссии.

Поделиться книгой В конце проекта заказчик подписывает отчет о завершении проекта, в котором в обязательном порядке указываются следующие моменты:

Фактическое значение критериев успешности проекта План\факт по срокам План\факт по бюджету План\факт по рискам План\факт по содержанию Отчет после внедрения проекта Только после подписание заказчиком данного отчета проект считается закрытым.

Данный отчет как правило также выносится на рассмотрение на Проектный комитет, который производит оценку успешности выполненного проекта.

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

Поделиться книгой Самым последним процессом управления проектом является закрытие договоров с подрядчиками и поставщиками услуг.

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

В ходе данного процесса производится следующие действия:

Подписание актов получения товаров\оказания услуг Получение счетов-фактур Окончательный расчет с контрагентами в соответствии с договорами Проведение итоговой встречи с вендорами Архивирование контрактной документации Данную работу может выполнять как непосредственно руководитель проекта, так и заказчик проекта, которому передан продукт к эксплуатацию и сопровождение.

Поделиться книгой В проектном управлении есть такое понятие как усвоенные уроки проекта (lessons learned).

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

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

В базе lessons learned как правило содержится следующая информация:

Какие действия были предприняты для устранения проблемы Насколько это решение было эффективным Эта база знаний позволяет не наступать на те же «грабли» и значительно повышать эффективность управления каждым последующим проектом.

Если в Вашей компании внедрен данный инструмент и Вы только приступаете к управлению проектами, то я бы настоятельно рекомендовал Вам самым тщательным образом изучить всю информацию, которая содержится в базе знаний с усвоенными уроками.

Поделиться книгой Эффективность процесса управления проектами Хочется сказать здесь несколько слов об измерении эффективности процесса управления проектами.

Меня часто спрашивают руководители проектов и директора Проектных офисов по поводу того, как можно измерить эффективность процесса управления проектами? Какие KPI выбрать?

Я бы рекомендовал на первом шаге начать замерять три следующих показателя:

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

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

Поделиться книгой Чтобы эффективно управлять проектами, необходимо чётко понимать причины провала проектов.

Согласно статистике, приведенной в исследовании PwC Insights and Trends: Current Portfolio, Programme, and Project Management Practices, проекты завершаются неудачей по следующим причинам:

Поделиться книгой Поделиться книгой Советы по подготовке к Почти на каждом своём тренинге я получаю с десяток вопросов, касающихся подготовки к экзамену на получение сертификата PMP.

В этом блоке я постараюсь ответить на самые распространённые из них.

Итак, «Сколько лет опыта и PDU нужно иметь, чтобы получить допуск на экзамен?»

Все формальные требования к кандидату подробнейшим образом изложены в PMP Handbook.

«Сколько по времени нужно готовиться к экзамену?»

В обычном режиме подготовки, т.е. если совмещать её с работой и общением с родными и близкими, подготовка должна занять у Вас примерно 3 месяца. При этом лучше заниматься по 15 минут каждый день, чем по часа один раз в неделю.

«Чему необходимо уделить повышенное внимание при подготовке к экзамену?»

Освоению методики расчета коэффициентов по методу освоенного объема (EVM). Дело в том, что на практике данный метод почти не используется, а на экзамене Вам придется производить расчеты, используя заученные формулы освоенного объема.

«Какова вероятность, что моя заявка попадёт на аудит?»

Низкая.

Советы по подготовке к «Какие дополнительные источники Вы бы порекомендовали для подготовки?»

Прочитать PMBOK5 как минимум 2 раза: первый раз на русском, а второй раз на английском.

Книгу Rita Mulcahy PMP Exam Prep Сайт pm-prepare.com или pmstudy.com В большинстве случаев этого достаточно, чтобы сдать экзамен.

Также полезно изучить следующие сайты:

http://www.helpfulpm.com/ http://www.pmi.ru/certificates/ «Что нужно выучить, чтобы сдать экзамен?»

Все приведенные в PMBOK формулы, а также все входы, выходы и инструменты всех 47 процессов.

«Как PMI будет проверять данные о моём опыте, которые я указал при подаче заявки на экзамен?»

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

«А если человек, контакты которого я указал, не говорит поанглийски?»

Тогда PMI должны будут потрудиться, чтобы уточнить у него интересующую их информацию.

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

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

«Как часто необходимо продлять сертификат PMP?»

1 раз в 3 года.

«Имеет ли смысл получить в начале сертификат CAPM, а уже потом сдавать на PMP?»

На мой взгляд, в этом нет смысла, т.к. в России этот сертификат почти не известен и ни одному работодателю он ничего не скажет. Поэтому я бы рекомендовал сдавать сразу на PMP.

«Где в Москве можно сдать экзамен на PMP?»

В PROMETRIC центре, расположенном недалеко от м. Октябрьская «Что такое PDU и как их получать?»

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

«Каков срок действия PDU? Если я получил PDU в прошлом году, я могу зачесть их при подаче заявки в этом году?»

Да, можете. PDU не имеют срока действия.

Советы по подготовке к «О чем вообще говорит сертификат PMP? Ведь не обязательно быть сертифицированным PMPшником, чтобы классно руководить проектами!»

Совершенно верно. Можно руководить проектами и без сертификата PMP.

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

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

«Есть ли перевод экзамена на русский? Т.е. можно ли сдавать экзамен на русском?»

Да, есть, но перевод «кривоват». Тем не менее лучше всё-таки заказать перевод на русский – лишним на экзамене не будет.