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

Пожелания всех участников документируются и некоторые приходиться отклонить. Почему это происходит?
1. Иногда эти пожелания абсолютно «не в кассу» и не имеют ничего общего с целью проекта;
2. Пожелания могут быть настолько «мощными», что для них необходимо «затевать» еще проект, а то и не один;
3. Пожелания исходят от участников, влияние которых на ход и результаты проекта очень низка.

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

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

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

Ограничения и требования должны быть хорошо задокументированы. А иначе, получим картинку, приведенную ниже. Картинка эта в разных вариантах есть в интернете. Найти ее можно по ключевым словам «Чего хочет Заказчик».

Верно сказал сатирик: «Если б я над этим не смеялся, я б над этим заплакал»! Задокументированные ограничения и требования позволяют менеджеру проекта зафиксировать содержание проекта. Содержание проекта (Project Scope) - Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.

от
Алексей Ким

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

Прежде всего хочу сказать, что мы ведем документ усвоенные уроки в течении всего проекта и постоянно, т.е. примерно так же, как и журнал вопросов. Это значит, что для того, чтобы занести какой-то пример в изученные уроки мне нет необходимости ждать встречи с командой проекта. Я просто беру и записываю его. Это позволяет не потерять идею, зафиксировать то, что должно быть зафиксировано в lessons learned. Все свои записи мы ведем в Excel файле, выложенном на сервере проектов. У нас используется Microsoft Project Server. В сервере проектов для каждого проекта можно создать рабочую область на Microsoft Sharepoint Services. Плюс данного решения состоит в том, что у вас сразу есть контроль версий и коллективная работа с одним документом. В самом файле у нас есть всего шесть полей:
- Проект
- Номер записи
- Наименование записи
- Ситуация
- Вывод
- Автор
Думаю, стоит еще добавить поле «Дата записи».

Обычно, наши lessons learned отвечают на один или несколько вопросов из списка, приведенного ниже:
- Что было сделано правильно, а что нет
- Какие ошибки были допущены?
- Что можно было сделать лучше?
- Что бы вы сделали иначе?
- Какие уроки можно почерпнуть на будущее?
- Упущенные возможности

Источником изученных уроков, часто становятся встречи, в общем-то, предназначенные для других целей. Например, во время обсуждения рисков могут возникнуть идеи, которые проверяются и фиксируются в изученных уроках. Я их записываю себе в ежедневник, а после проверки переношу в файл.
Разумеется, используются и традиционные способы пополнения изученных уроков. Встреча с командой управления проектом и разбор, что сделано хорошо, что могло быть сделано лучше и т.д.
По поводу мотивации руководителя проекта писать или изучать lessons learned могу сказать следующее: тот, кто один раз прочитал грамотно написанные изученные уроки, впоследствии всегда будет их читать, т.к. польза от них очень чувствительна. И никаких дополнительных действий для мотивирования руководителя проекта читать lessons learned не требуется. Молодых руководителей проекта, можно обязать вписывать наименования проектов, по которым были прочитаны изученные уроки в один из документов при инициации проекта. Ну, а обязать написать lessons learned – вообще просто. Достаточно установить правило, что руководитель проекта не может закрыть проект до тех пор, пока lessons learned не будут написаны. Вот, наверное, и все, что я хотел сказать.

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

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

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

*

Будет ли он затрагивать интересы большого количества людей или, хуже того, всей Вашей компании?
*

Повлечет ли он изменение корпоративной культуры или порядка, в котором сотрудники выполняют свою работу?
*

Заставит ли Ваш проект людей беспокоиться? Например, не приведет ли он к повышению продуктивности труда, что позволит выполнять ту же работу меньшим числом сотрудников?

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

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

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

*

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

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

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

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

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

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

Что такое внутренний и внешний проекты? Внутренний проект – проект, выполняемый внутри компании, самостоятельно и для себя. Внешний проект – проект, выполняемый для заказчика из другой компании (или частного лица). Многие из нас сталкивались как с управлением внешним, так и с управлением внутренним проектом. Есть ли различия между управлением внутренним и внешним проектом? Различия в процессах, используемых техниках? Думаю, сейчас я могу ответить на этот вопрос, хотя бы частично. В данном случае, я рассматриваю вариант выполнения проекта собственными силами и вариант найма компании-консультанта и передачи функций управления проектом ей.
Различие однозначно есть. Причем это различие проявляется практически во всем. Разные проблемы, разные риски. Нет, я не утверждаю, что нет ничего схожего, но все-таки различия настолько существенны, что о них стоит написать если не статью, то заметку.
Во-первых, разницу ощущает на себе руководитель проекта. Если проект внешний, то его влияние в компании, как правило, ощутимо больше. Ведь каждый час работы внешнего руководителя (обычно, контракты T&M) проекта стоит денег, причем, как правило, больших, чем час работы внутреннего руководителя проекта. С другой стороны, внутренний руководитель проекта может иметь в компании значительный авторитет, основанный на его качествах эксперта. Отсюда и разные методы коммуникаций и разрешения проблем. Внутренний руководитель проекта гораздо чаще использует экспертную технику воздействия (expert power), в отличие от внешнего руководителя проекта которому, особенно в начале проекта чаще приходится ссылаться на руководителя компании заказчика (referent power).
Во-вторых, разница ощущается в ведении проекта. Если на проект приглашена известная фирма, то документы, создаваемые ею, не подлежат обсуждению. Участники проекта и заинтересованные стороны заранее признают правильность методологии (конечно, бывают исключения). В то же самое время, при внутреннем проекте многие проектные документы могут восприниматься со стороны участников проекта (не со стороны команды управления проектом) как бюрократизация проекта и компании.
В- третьих, подрядчик приглашается на проект, который внутренними силами не реализовать, а это дорогие и сложные проекты с высоким приоритетом для компании. Соответственно, мотивация команды, как правило, выше на внешних проектах и это значительная разница. Программист, работающий над разработкой программы, которая, по его мнению, не очень нужна компании будет на порядок менее производителен, чем когда он работает над чем-то нужным и полезным.
В-четвертых, внутренние проекты, как правило, имеют менее жесткое расписание. Когда фирме приходится платить внешнему подрядчику за каждый час работы, то сроки работ стремятся сократить. В то же время, по неизвестной мне причине редкие компании отслеживают стоимость и эффективность работ собственных сотрудников. Часто вводят отчетность по отработанному времени, без измерения эффективности работы.
Ну и наконец, в-пятых, стоимость проектов, на которые нанимают внешнего подрядчика для руководства проектом обычно выше, больше ответственность и более пристальное внимание руководства к проекту.

от: Алексей Ким

от
Алексей Ким

Все мы много раз слышали, насколько важны коммуникации при ведении проекта. В принципе, в последнее время из всех областей знаний по управлению проектами внимание общественности сосредоточено на трех областях: управление рисками, управление персоналом и управление коммуникациями. Управление коммуникациями, разумеется, тесно переплетено с управлением командой проекта, тем не менее, это разные области знаний. Управление персоналом уделяет основное внимание набору сотрудников на проект, созданию команды, мотивации и управлению командой, в то время как управление коммуникациями ставит на первое место определение потребности в информации, управление ее распространением и управление ожиданиями участников проекта. Гуру управления проектами разделились на два противоположных лагеря. Девиз первого лагеря, приверженцев управления рисками – “Управляй рисками и проект будет успешен”. Второй лагерь придерживается взгляда – “Найми правильных людей и они вытянут проект из любой ситуации”. На мой взгляд, обе точки зрения имеют право на существование, но при этом немного идеализированы. Возможно, подобные подходы хорошо подойдут для использования на крупных, или высокоприоритетных проектах, когда у вас есть возможность выбирать себе команду, но не очень подходят для проектов среднего размера/приоритета и уж тем более не подходят для небольших проектов. Сейчас поясню почему.

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

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

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

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

Возьмем, например, набор команды. Сотрудников для работы на проекте выделяют, как правило, ограниченное количество и список, из которого их можно их выбрать, также ограничен. Вам на проект выделены люди и других у вас нет. Однако это не означает, что вокруг вас нет сотрудников, более подходящих для работы на проекте, которых при правильном управлении коммуникациями вы можете задействовать. Постарайтесь определить, кто из сотрудников, не задействованных на проекте может вам помочь сейчас и в будущем. Например, если у вас не хватает экспертов в проектной команде, но они есть в компании в принципе, вы можете договориться с ними (как формально, так и не формально), чтобы они просматривали ваш отчет о статусе проекта и прочую информацию высылаемую вами. Таким образом, эксперты будут в курсе хода проекта, хотя он их и не будет затрагивать напрямую, и усилий им это будет стоить минимум. Это поможет вам избежать ошибок, которые возникают в их экспертных областях, но которые вы могли просто упустить из-за недостатка экспертных знаний. Разумеется, вам придется приложить усилия, чтобы обеспечить их внимание к проекту, но ведь это ваша работа.
Используйте push и pull коммуникации. Если вы не уверены, что ваше письмо будет прочитано – проконтролируйте. Позвоните, или просто подойдите к адресату и уточните, прочитал ли он ваше письмо. Постарайтесь писать кратко, но точно. Это поможет вашим коллегам не тратить много времени на ваше письмо и при этом получать информацию. Если у вас несколько адресатов разного уровня понимания, до которых нужно донести информацию, используйте разные письма. Передайте информацию каждому из них доступным для его понимания языком. Это займет много времени, но это также ваша работа. Встречи для решения проблем часто бывают эффективны. Не забывайте про них. Если вы находитесь в сильном затруднении и не знаете как решить проблему, попробуйте собрать экспертов на встречу, очень вероятно, результат встречи превзойдет ожидания.

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

1. Договаривайтесь с потенциально необходимыми вам сотрудниками о прочтении вашего отчета о статусе проекта и прочей проектной информации.
Вам нет необходимости убеждать их в том, что они должны полностью погрузиться в проект. Достаточно если они будут, хотя бы представлять себе что происходит на проекте.
2. Используйте и push и pull коммуникации.
Обычно, когда человек не заинтересован в получении информации, используются только push коммуникации. Заинтересуйте нужных вам людей, если это возможно. Pull коммуникации намного более эффективны.
3. Контролируйте доставку, получение и понимание переданной информации.
Вам необходимо доставлять информацию до адресата. Не доставленная или не усвоенная информация сегодня может обернуться проблемами завтра.
4. Пишите кратко и точно.
Если вы хотите, чтобы сотрудники, напрямую не заинтересованные в коммуникациях по проекту читали ваши письма – пишите кратко. Если вы хотите, чтобы ваши письма доносили до адресата информацию в том виде, в котором вы ее понимаете – пишите точно.
5. Персонализируйте передаваемые сообщения.
Персонализация письма под уровень понимания каждого участника значительно повышает качество коммуникаций. Любой сотрудник более охотно читает письма, которые написаны на его языке, и понятные ему с полуслова, чем те, над которыми ему приходится думать.
6. Определяйте точно, кому и какая информация необходима.
Не допускайте, чтобы сотрудники, которые потенциально могут быть задействованы на проекте оказались не информированы по нему. Отслеживайте изменения в заинтересованных сторонах проекта.
7. Организовывайте встречи для решения проблем
Для решения проблем бывают очень эффективны встречи. Организовывайте их. Выбирайте для встречи тех участников, которые потенциально могут помочь вам. Незачем впустую тратить время других участников.

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

Большинство руководителей проекта рано или поздно (обычно, все-таки рано) сталкиваются с руководством низкоприоритетным проектом. В чем же особенность управления проектами с низким приоритетом по сравнению с управлением проектами с высоким приоритетом? Попробуем разобраться. Прежде всего, руководитель низкоприоритетного проекта сталкивается с нехваткой ресурсов. Особенно людских ресурсов. Ведь никто не хочет ни работать, ни выделять сотрудников для выполнения работы, которая никому не нужна (как обычно считают). Эскалация проблемы на руководство не поможет, ведь это низкоприоритетный проект и руководство просто проигнорирует проблему. Выстраивая логическую цепочку, получаем низкую мотивацию проектной команды. Члены проектной команды предпочтут заниматься чем-то другим, более нужным, полезным и интересным по их мнению. Из низкой мотивации мы получаем низкую производительность проектной команды. Далее следует срыв сроков и снижение качества. После того как летят сроки, и тестирование показывает отвратительное качество продукта, мы получаем превышение бюджета за счет переделок того, что уже сделано и оплаты дополнительно потраченного времени. Ну как результат? Не все так плохо. Давайте попробуем решить все эти проблемы.
Для начала поймем, у нас все завязано на людей. Руководство компании, проектная команда, функциональные менеджеры (при матричной структуре), все они в первую очередь люди, а уже потом должностные лица. Вот и попробуем работать с ними как с людьми. Возьмем руководство. Вы назначаете встречи, на которые руководство не является? Нет ответа на письма? Не разрешаются конфликты? Выхода три: терминировать проект, уйти с проекта (если позволят) или смирить свою гордость и продолжить работу. Руководитель не является на встречу? Подкараульте его в приемной, договоритесь с секретарем, позвоните ему и договоритесь о выделение всего десяти минут. Спланируйте встречу заранее. Придите с уже распечатанными проблемами и вариантами решения, что бы оставалось только поставить галочки и подпись. В общем, постарайтесь сделать так, чтобы накопившиеся проблемы можно было решить за 10 минут. Сделали? Отлично. Если вам это удалось один раз – удастся и в другой раз. Вот и получили тот же самый статус митинг, только экспресс вариант.
Проектная команда. Отсутствие мотивации, низкая производительность, лень, все это излечимо. Постарайтесь придать вес проекту в глазах команды. Проводите совещания. Общайтесь с командой. Установите внутреннюю отчетность, в общем, ведите проект так, как если бы это был приоритетный проект компании, не расслабляйтесь сами. Собранность менеджера проекта всегда положительно влияет на команду проекта. Мотивируйте команду своим примером, станьте ее вдохновителем.
Функциональные руководители. Это, наверное, будет самое сложное. Убедить функционального руководителя выделить вам ресурсы будет тяжело. Но, используйте личностные навыки. Постарайтесь просто с ним договориться. Помните, он ведь тоже человек. Пусть он выделит вам ресурсы хотя бы тогда, когда ему удобно. Измените план так, чтобы выделенные ресурсы использовались наиболее эффективно. Ну и наконец, общайтесь, общайтесь и еще раз общайтесь! Коммуникации – ключ к успеху. Ну, вот, наверное, и все.

Используйте встренный процесс управления документами

(6.2.1.P1)

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

Правильно распорядитесь документами по завершению проекта

(6.2.1.P2)

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

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

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

(6.2.1.P3)

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

Собирайте отзывы на документ в сводку

(6.2.1.P4)

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

* Раздел, пункт документа
* Автор отзыва
* Содержание отзыва
* Комментарий автора документа.

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

[u]Качественный анализ рисков

(7.1.1.P1)

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

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

Таблица "Высокий / Средний / Низкий"

(7.1.1.P2)

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

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

Цветовая диаграмма "Высокий / Средний / Низкий"

(7.1.1.1.P3)

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

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

Таблица вероятности рисков

(7.1.1.1.P4)

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

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

1, Слабое влияние (или нет влияния) на график и бюджет

2, Возможно влияние на график или бюджет в размере 2%-4%

3, Возможно влияние на график или бюджет в размере 5%-7%

4, Возможно влияние на график или бюджет в размере 8%-10%

5, Возможно высокое влияние на график или бюджет более 10%.

После создания шкал, наподобие приведенных выше, Вам все еще понадобится определить, как интерпретировать результаты оценивания. Например, Вы можете решить, что уровни риска 1 и 2 могут игнорироваться, а уровни 4 и 5 - управляться. Уровень 3 будет представлять риски, требующие индивидуального рассмотрения.

Ожидаемый денежный результат (EMV)

(7.2.2.P1)

Ожидаемый денежный результат (Expected monetary value, EMV) является приемом управления рисками, который широко используется, чтобы количественно характеризовать и сравнить различные риски проекта. Применение EMV относится к количественным методам, поскольку для его определния необходимы более конкретные числовые характеристики вероятности и последствий риска, чем простые оценки Высокий / Средний / Низкий.

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

Pr – вероятность проявления риска

I – воздействие риска на проект в случае его проявления. Далее воздействие можно детализировать на Ic (воздействие на бюджет), Is (воздействие на график) и Ie (воздействие на трудозатраты).

Бюджет страхования рисков

(7.2.2.P2)

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

Исходя из Ваших оценок, потенциальный ущерб для стоимости Вашего проекта может составить $118,000. Но Вас не поймут, если Вы запросите такой объем денег для страхования рисков. Такая сумма может потребоваться только в том случае, если все шесть идентифицированных рисков проявятся, что достаточно маловероятно. К тому же, если Вы собираетесь эффективно управлять рисками, то принятые Вами меры должны делать такое стечение обстоятельств практически невозможным. А страховой бюджет должен отражать как возможные потери, так и вероятность их понесения. Такая оценка в виде Ожидаемой денежной стоимости отражена в последней колонки таблицы.

Обратите внимание, что общая сумма, которую следует зарезервировать для страхования рисков, составляет всего $33,500, что гораздо меньше суммарной стоимости потерь. Если проявятся риски C и F, то резерва хватит на покрытие ущерба с лихвой. В то же время суммы резерва не хватит на покрытие ущерба от риска D. Но у риска D всего 10% шансов проявиться, что позволяет команде проекта сосредоточиться на этом риске и эффективно ему противодействовать. В любом случае, наличие страхового бюджета и усилия команды сделают исход проекта менее чувствительным к воздействию рисков.

Диверсификация (Spreading) рисков

(7.2.2.P3)

Бюджет страхования рисков эффективен только в том случае, если он распространяется на множество рисков. Чем больше рисков идентифицирует команда, тем больший страховой бюджет будет распределен среди этих многих рисков. В приведенном выше примере наличие шести рисков помогает концентрировать достаточный резерв, чтобы довольно эффективно подстраховаться от рисков. Если же страховой бюджет рассчитывать только исходя из одного или двух рисков, то Вы не добъетесь эффективного страхования. Например, предположим, что Вы идентифицировали и оценили только один существенный риск, подобный риску D в примере выше. Соответственно, Вы запросили страховой бюджет $4,000. Заручившись такой суммой, Вы окажетесь в ситуации "все или ничего". Если риск не проявится, проект не пострадает. В противном же случае, Ваш бюджет в $4,000 вряд ли окажется существенным подспорьем на фоне потерь в $40,000. Это вовсе не значит, что страховой бюджет малоэффективное решение, просто он хорошо помогает проекту только при достаточно большом количестве учтенных рисков.

Страхование неизвестных рисков

(7.2.2.P4)

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

Источник: Алексей Ким. Написание устава проекта.
Управление проектами - №4 (17) 2009 - с. 16. Публикуется с разрешения редакции.

pmmagazine Всем известно, что устав проекта – начало всем проектным работам. Именно с него начинается старт проекта и именно он формально объявляет о существовании проекта в компании. Однако, часто менеджеры проектов совершают одну ошибку при написании устава. Уделяют ему слишком много внимания, стараясь впихнуть в документ то, для чего он не предназначен. Рассмотрим на примере подобную ситуацию.

В одной небольшой компании, назовем ее традиционно, “Рога и Копыта” решили вести управленческий учет по центрам финансовой ответственности (ЦФО). Хотя подобным учетом финансовый директор занимался на предыдущем месте работы, постановка управленческого учета по ЦФО на предприятии была для него неизведанной областью. В компании, в управлении информационных технологий работал менеджер проектов, не очень опытный, но и не сказать что уж совсем без опыта. И решили они инициировать проект. Финансовому директору было удобно, что менеджер проекта возьмет на себя всю организационную часть работы, а менеджеру проектов идея была интересна, хотя и не в новинку. Сказано – сделано. Провели совещание, определили заинтересованные стороны, риски и, даже определились с объемом работ по проекту и этапами, на которые он будет подроблен. Заинтересованных сторон оказалось не так уж и мало, целых семь: генеральный директор, который представлял отчетность акционерам и был ответственным за работу компании, финансовый директор, который отвечал за подготовку управленческой отчетности и контроль расходов подразделений, молодой специалист в отделе финансового планирования и контроля, выполняющий работу по подготовке отчетности, главный бухгалтер, предоставляющий данные для отчетности, глава продающего подразделения и директор управления информационных технологий, на работе которых должны были сказаться нововведения.

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

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

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

(7.2.3.P1)

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

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

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

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

*

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

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

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

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

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

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

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

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

*

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

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

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

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

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

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