Рубрика: О проектах

Планирование проекта

Всем привет.

На текущий момент времени, мы рассмотрели такие вопросы как:

Цели проекта;

Заинтересованные стороны проекта;

Команда проекта;

Управление конфликтами и распределение ответственности;

WBS проекта

Сегодня хотел перейти к вопросу плана проекта.

И рассмотренный в прошлый раз инструмент WBS — хорошая основа для составления Плана проекта.

И так что такое План проекта ?

Есть несколько трактовок, две из них приведу ниже:

1) Документ/Ы описывающие основные составляющие проекта:
— Цели, задачи проекта;
— Вехи проекта;
— Ресурсы;
— Управление содержанием/рисками/изменениями/качеством….
2) Графическое представления последовательности работ по проекту.

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

Gantt-Chart-001a2

 

Наиболее распространенным графическим отображением последовательности работ по проекту выступают, так называемые Диаграммы Ганта. Думаю многим из вас они знакомы. При этом не важно где их рисовать: На бумаге, в Excel или в специализированном программном обеспечении, таком как MS Project.

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

 

И так, ключевые правила составления плана:

1) За основу берите составленную WBS и группируйте работы как вы делали это ранее.

Во первых вы уже проделали огромную работу, составляя WBS;

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

2) Проставьте последовательности работ и зависимость друг от друга.

Какие есть зависимости:

Финиш – старт. Инициация следующей задачи зависит от завершения предыдущей

Финиш-финиш. Завершение следующей задачи зависит от завершения предыдущей задачи

Старт- старт. Инициация следующей задачи зависит от инициации предыдущей задачи

Старт-финиш. Завершение следующей задачи зависит от завершения предыдущей задачи.

3) Определите длительность работ и необходимые ресурсы для их выполнения.

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

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

4) Определите критический путь Вашего Плана работ.

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

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

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

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

Почему пишу БАЗОВЫЙ, да потому что, ПЛАН — живой инструмент, который в процессе реализации проекта может меняться.

Какие причины изменения плана:

1) Не учли  какие то активности при первичном планировании;

2) На реализацию потребовалось больше/меньше времени, чем планировали;

3) Запланированные ранее ресурсы, оказались недоступны;

4) Подрядчики не выдержали сроки;

5) Изменились требования Заказчика;

и т.д.

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

Базовый же План необходим для того, что бы «мониторить» отклонения и оценивать влияние на проект вносимых изменений. И в конце проекта более четко провести оценку и извлечь УРОКИ проекта.

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

Список контрольных точек —  определяет ключевые события проекта, их даты и результаты, которые должны быть получены по состоянию на эти даты.
Этот тип плана очень удобен для мониторинга проекта Заказчиком/Инвестором, так как в нем отражены основные события, влияющие на реализацию проекта и даты планируемые и фактические. Т.е. сразу видно что сделано, в плане или нет и на сколько идет сдвиг по проекту.

Процесс создания плана контрольных точекПлан контрольных тоек

1) Установить объем работ по проекту;
2) Согласовать контрольные точки проекта;
3) Определить критерии, по которым будут оцениваться достижение контрольных точек;
4) Спланировать действия по достижению каждой из контрольных точек;
5) Согласовать даты наступления событий по достижению контрольных точек.

Преимущества плана контрольных точек:

— Простота
— Хорошо видны цели проекта
— Отчетливо видна структура проекта
— Позволяет мобилизовать ресурсы для решения конкретных задач
Планирование очень важная составляющая проекта, и как говорится  в одном детском мультике: «Лучше день потерять — потом за 5 минут долететь».
Поэтому уделяйте планированию столько времени, сколько действительно необходимо.
На сегодня это все. Мы рассмотрели стандартный, так называемый водопадный подход к планированию. В следующий раз планирую рассказать про составление Планов проектов с использованием Гибких технологий.
Удачных Вам проектов!!!

WBS — инструмент менеджера проекта

В предыдущих постах были рассмотрены вопросы постановки целей, формирования команды проекта, управление конфликтами, распределение ответственности внутри команды. Сегодня предлагаю перейти к инструментам планирования проекта и рассмотреть один из таких инструментов — WBS (Work Breakdown Structure) — или иерархическая структура работ по проекту.

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

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

Основная цель  — определить и структурировать все содержание проекта. Другими словами WBS должна содержать ВСЕ работы, запланированные в проекте. Прежде чем перейдем к правилам построения WBS, хочу остановиться на двух аспектах

1) WBS не является:

  • Графиком реализации проекта;
  • Документом, заменяющий ПЛАН реализации проекта;
  • Перечнем действий или вех.

Об этом аспекте не стоит забывать и пытаться подменить понятия, направленность WBS определить структуру работ проекта и уже на основании этой структуры строить ПЛАН проекта и График реализации.

Следующий аспект о котором стоит упомянуть — это:

2) Важные требования к составляющим WBS изображенные на рисунке ниже:

WBS

 

 

 

 

 

 

 

 

Теперь можно перейти и к алгоритму составления WBS.

Алгоритм номер 1:

  1. Начните с целей проекта (используя определение области охвата проекта);
  2. Перечислите исходные результаты, необходимые для достижения целей — расположите их горизонтально;
  3. Для каждого исходного результата определите ключевые блоки или работы, необходимые для их обеспечения (учитывайте требования, описанные выше);
  4. Детализируйте в столбцах до необходимого уровня детальности;
  5. Обеспечьте вовлечение команды проекта и ключевых заинтересованных сторон проекта или разработайте WBS совместно с ними.

Алгоритм номер 2 (используя стикеры и флипчарт):

  1. Задать участникам вопрос: «Что нужно сделать для реализации проекта ?»;
  2. Участники команды записывают  свои ответы на стикеры; (время необходимое для этого зависит от размера проекта);
  3. Близкие по смыслу Задача группируются по столбцам/стопкам;
  4. Задачи, не попадающие ни в одну стопку, клеятся отдельно;
  5. После это придумываем название Категории (столбцу/стопке), записываем на флипчарт и под каждой категорией клеим стикеры.

Таким образом получаем WBS, пример которой изображен ниже

(приведен именно пример, для того, что бы отобразить суть инструмента. Данная WBS не является полной для реализации проекта CRM):

WBS

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

Это использование инструментов Mind Mapping, и так называемых карт мышления. Этот инструмент хорошо подходит для творческих людей, для которых важна визуализация и красота картинки :-).

Ниже одна из интернет картинок, отображающих суть инструмента. Надеюсь смысл понятен 🙂

WBS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

На сегодня все.

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

Удачных Вам проектов!!!

Притча Барин и приказчик

Интересная и познавательная Притча. Очень хорошо ложится в тему: «Заинтересованные стороны проекта» 🙂

ПритчаНанял барин двух приказчиков – Василия и Петра. Через месяц выдает им плату: Василию – 5 рублей, а Петру – 3 рубля.

 Возмутился Петр:
 — Я и моложе, и выше, и проворнее, чем Василий. Да и семья у меня больше. Так почему же мне меньше платите?
 Ухмыльнулся барин:
 — Видишь обоз за околицей? Узнай, кто такие.
 Быстро вернулся Петр:
 — Из Рязани будут…
 — А куда направляются?
 Снова быстро вернулся Петр:
 — В Саратов едут…
 — А что везут? – интересуется барин
 Вернувшись, Петр доложил:
 — Рожь и пшеницу.
 Позвал барин Василия:
 — Там обоз идет, узнай, кто такие.
 Возвращается Василий:
 — Это, хозяин, обоз рязанский будет. В Саратов на базар везут рожь и пшеницу. Есть еще и овес. Собираются продавать там по сорок копеек за пуд. Я с ними сторговался по тридцать. Будем покупать, или пусть далее едут?
 Барин многозначительно посмотрел на Петра.

Каждый сам дальше делает выводы и придумывает стратегию поведения в том или ином случае.

Но не забывайте, чем более четко Вы будете понимать ПОТРЕБНОСТИ заказчика и окружающих, тем больше шансов на успех 🙂

Удачи Вам и хороших выходных!!! 

 

Управление конфликтами в проектах

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

Управление конфликтами

Что же такое конфликт ? Дам два определения.

Конфликт — это: 

1. Антагонистическое взаимодействие сторон или отсутствие согласия между сторонами.
2. Процесс взаимодействия между сторонами, в котором одна из сторон воспринимает другую, как ту что негативно влияет (или пытается влиять) на то что важно  для первой стороны.
Т.е. у нас есть несколько участников конфликта, рассматриваемая ситуация и различность взглядов каждой из сторон на данную ситуацию. Хорошо это или плохо ?
Существует два взгляда на Конфликт:

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

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

С момента инициации проекта и до его завершения, менеджер проекта и проектная команда постоянно находятся в «конфликтном окружении», несмотря на то как воспринимается сам конфликт, как зло или как благо.

Поэтому важно понимать какие основные источники конфликтов в проектах существуют.

К основным относятся:

1) Конфликт через приоритеты — связан с тем, что мысли участников проекта про последовательность выполнения работ и задач различаются;

2) Конфликты через административные процедуры — связаны с теми нормативно-регулятивными правилами которые регламентируют то, как управлять проектом, какие документы должны создаваться и в каком формате;

3) Конфликты через технические решения — связаны с техническими вопросами в процессе реализации проекта;

4) Конфликты через человеческие ресурсы — постоянный конфликт проекта :-), связан с набором персонала в команду проекта из функциональных подразделений компании;

5) Конфликты через стоимость — связаны с вопросами выделения дополнительных бюджетов, расценкой на работы, оплатой работы подрядчикам и т.д.;

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

7) Межличностные конфликты — связаны с несогласием между участниками на личностном уровне.

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

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

Таких моделей пять:

1) Избегание:

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

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

2) Приспособление:

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

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

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

Или когда силы конфликта не равны и ущерб от «борьбы» может быть достаточно сильный.

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

3) Принуждение

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

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

4) Компромисс

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

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

5) Сотрудничество

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

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

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

Управление конфликтами

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

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

Надеюсь информация была Вам полезна.

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

И удачных проектов !!! 

 

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

Команда проекта

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

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

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

И в первую очередь КОМАНДА УПРАВЛЕНИЯ ПРОЕКТОМ, т.е те люди, кто совместно с Менеджером проекта осуществляют операционное управление реализацией проекта.

Поэтому менеджеру проекта приходится отвечать на следующие три вопроса:

1) Кто необходим для реализации проекта ?

2) Какие функции он будет выполнять ?

3) Где я могу найти этого специалиста?

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

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

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

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

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

Ведь главной ЦЕЛЬЮ команды является именно реализация проекта и достижение его целей.

Что же влияет на эффективность команды проекта?

1) Количество участников команды

2) Ясность и согласованность целей

3) Четкое и понятное распределение функций и задач

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

однако исходя из исследований, наиболее комфортным для всех участников команды и менеджера команды является число 7+-2. т.е. команда составом от 5 до 9 человек.

Команды большого размера могу обладать такими недостатками, как

— групповое мышление;

— давление на участников команды;

— «отсиживание времени» некоторыми участниками.

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

Что касается ясности и согласованности целей, то здесь я бы отметил ТРИ уровня целей, которые должны быть в идеале согласованы друг с другом:

1) Цели компании;

2) Цели проекта/Цели команды;

3) Личные цели участников.

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

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

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

Ключевыми же показателями эффективной команды являются:

1) Четкие цели и задания внутри команды;

2) Понимание взаимозависимости всех членов команды;

3) Сплоченность;

4) Доверие;

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

Таким образом КОМАНДА УПРАВЛЕНИЯ ПРОЕКТОМ — это КЛЮЧЕВОЕ ЗВЕНО всего проекта и недостаточное внимание к этой части проектного управления переводит  проект в неустойчивое положение с определенной долей риска.

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

Эффективных и сплоченных команд и успешных проектов !!!

Ролик про силу командной работы >>

RASCI диаграмма — инструмент менеджера проекта

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

Достаточно часто, проводя консультации, тренинги я слышу, что одной из причин НЕУДАЧНЫХ проектов является нечеткое распределение функций внутри проектной команды, а так же то, что не всегда понятно а что ожидают члены команды и менеджер проекта от меня лично.

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

Если поискать в интернете, то можно найти несколько разных подходов и аббревиатур: RACI, RACI-VS, DACI и ряд других, включая русские варианты.

Мне лично больше всего нравится именно RASCI.

Как составить такую матрицу ?

Все просто:

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

2) В верхней строчке пишите РОЛИ участников команды управления проектом (если между ними надо распределить работу) или участников какой либо группы.  Иногда по горизонтали можно писать и конкретные фамилии участников, однако более эффективно использовать роли.

3) На пересечении функции/задачи и Роли ставим букву или несколько из RASCI.

Итак что же значат буквы в названии диаграммы:

RResponsable — Кто является ОТВЕТСТВЕННЫМ за выполнение указанной функции/задачи;

AApprove  — Кто должен утвердить результаты выполнения функции/задачи;

SSupport — Кто помогает ответственному выполнять функцию/задачу;

C Consulted — У кого можно получить консультацию по выполнению функции/задачи;

IInformed — Кого необходимо проинформировать по результатам выполнения функции/задачи.

RASCI

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

Если много букв А, то может быть затянуто согласование и принятие финального решения.

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

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

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

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

А на сегодня все.

Пробуйте !!! Применяйте !!! Экспериментируйте !!!

Успешных Вам проектов !!!

«Не ошибается тот кто ничего не делает» или как я нарушил ключевые правила проектного управления :-)

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

Сначала опишу ситуацию, потом буду раскладывать ее по полочкам 🙂

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

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

Презентацию подготовил, проговорил, тайминг просчитал, площадку проверил. Форму регистрации на сайте повесил. Технически все отлично !!!

И вот  день вебинара —  волнуюсь, в первый раз все таки. Народу оказалось немного, человек 19, но для первого раза, как по мне — отлично. Участники вебинара  на вопросы старались отвечать, свои задавать, т.е. какой то интерактив все таки был.

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

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

Сказать, что я расстроился — значит ничего не сказать, расстроился я с самого начала достаточно сильно.

Но потом посидел, подумал и начал разбираться почему так получилось и все стало на свои места 🙂

Итак ошибки номер 1 и 2 :
Не достаточно четко проговорил с Заказчиком (компанией которая предложила провести вебинар) целевую аудиторию и ее потребности. Т.е., говоря языком проектного управления:
— не провел анализ заинтересованных сторон;
— не уточнил ЦЕЛИ.

Ошибка номер 3:
Перед вебинаром (после того как подготовил план вебинара и его наполнение) не проговорил с заказчиком контент презентации и вебинара, в результате контент не оправдал ожидания Заказчика и большей части аудитории, что была привлечена Заказчиком;

Ошибка номер 4:
Понадеялся на то, что Заказчик, так же как и я, заинтересован в результате вебинара и нашем сотрудничестве и должен подсказать что и как делать или «сонаправить» при подготовке. Ошибка практически та же что и в первом случае —
не прояснил ожидания Заказчика и его видение реализации.

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

Однако, вспомнив все то, что ВАЖНО в проектном управлении я не стал допускать еще одной ошибки, а именно — постарался при Завершении этого небольшого проекта извлечь УРОКИ, которые получил, что собственно и сделал в этом посту.

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

1) Я провел свой первый вебинар и теперь более четко имею картинку многих нюансов подготовки и проведения таких мероприятий;
2) Я осознал свои ошибки и теперь, в случае похожего сотрудничества, уже знаю где лежат грабли (конечно же есть и другие грабли, на которые я просто не успел наступить, но их уже стало меньше 🙂 )
3) Я не потерял энтузиазма и буду продолжать, как и обещал, готовить и проводить серию вебинаров по проектному управлению;
4) Я верю, что НУЖНАЯ Целевая аудитория, которой будет полезно то о чем я говорил на вебинаре и то о чем я дальше буду говорить обязательно найдет меня и прослушает мои вебинары.

А Вам желаю, как всегда: Успешных проектов!!!
И не забывайте извлекать уроки из ВСЕХ своих проектов.

А тем кто все таки хочет прослушать мой первый опыт проведения вебинара, то вот ссылка на запись: https://www.youtube.com/watch?v=0UJVYjRfw80&feature=player_detailpage Комментарии и обратная связь, что мне необходимо улучшить в следующих вебинарах — ПРИВЕТСТВУЮТСЯ…

Удачи Вам !!!

Притча о гребцах

Сегодня пятница, впереди выходные.
Кто то подводит итоги недели, кто то планирует как отдохнуть.
А я предлагаю Вам немного подумать над вопросом, который идет после притчи 🙂
И так притча:
Жила-была одна команда гребцов. И решила она посоревноваться с другой  командой гребцов. В каждую команду вошло по 8 человек.
притча о гребцахОбе команды  усиленно тренировались и ко дню соревнования были в одинаковой кондиции.
Но в итоге команда соперников обошла их на километр.
Настроение у проигравшей команды было хуже некуда.
Высшее руководство задумалось. И решило нанять группу аналитиков, чтобы те оценили ситуацию и дали рекомендации, как выиграть в следующий раз.

 

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

Консультанты решили, что в команде было слишком много капитанов и слишком мало гребцов и рекомендовали перестроить команду. Теперь в  команде стало всего четыре капитана, два менеджера, один топ-менеджер и  один гребец. С гребцом консультанты посоветовали активно работать, дабы мотивировать его на достижение победы.

На следующих соревнованиях  команда соперников ушла вперед на два километра.
Высшее руководство уволило гребца, так как оказалось недовольно результатами его работы. Все остальные члены команды получили бонусы за достижение высоких результатов в процессе мотивации.
Аналитики снова сели за расчеты и выдали причину поражения:
— Стратегия была хорошая,
— мотивация — отличная,
— менеджеры высшего класса- превосходные,
— а вот средства реализации идеи были плохие…
К следующим соревнованиям проигравшая команда проектирует новую лодку…

команда проекта

А вот и обещанный вопрос/ы:
— А из кого состоит ваша команда проекта ?
— «Гребцов» хватает ?
— Или может надо что то поменять ?

Хороших всем выходных!!!

Навыки менеджера проекта

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

Кто он ? Зачем он нужен? Какими компетенциям и навыками должен обладать ?

Менеджер проекта — это тот, кто отвечает за успех проекта перед Заказчиком.

На картинке ниже —  Ключевые Области Проектного управления и основные Ограничения проекта, именно то ЧЕМ должен управлять в процессе реализации проекта, его руководитель/менеджер.

управление проектами

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

так и лидерские и управленческие  качества. Все таки Проект — это прежде всего ЛЮДИ, благодаря которым он  и реализуется.

Ниже я попытался перечислить основные качества, которыми должен обладать Менеджер проекта.

Личные, управленческие и лидерские качества:

— Быть гибким и уметь приспосабливаться;
— Уметь одновременно концентрироваться на нескольких вопросах;
— Проявлять инициативу;
— Быть убедительным;
— Обладать хорошей коммуникабельностью;
— Держать в поле зрения несколько целей и находить баланс между ними;
— Обладать навыками планирования и реализации;
— Быть стрессоустойчивым и обладать навыками «разруливания» конфликтов;
— Обладать способностью выявлять проблемы, находить решения и обеспечивать их выполнение;
— Хорошо управлять временем;
— Уметь убеждать и владеть навыками переговорщика;
— Быть дипломатичным…
Технические и деловые навыки:
— Понимание, как организовать рабочую группу и управлять ее работой;
— Способность разрабатывать сложные планы, основанные на сроках и стоимости;
— Понимание вопросов, связанных с контрактами, материально-техническими обеспечением, закупками, а так же кадровые вопросы;
— Понимание технологий, играющей главную роль в обеспечении успешности проекта;
— Способность перенести бизнес стратегию на цели проекта;
— Понимание предметной области;
— ….
И это далеко не полный перечень, ведь каждый проект по своему уникален и может потребовать от Менеджера проекта дополнительных компетенций.
Развитие же этих компетенций — достаточно серьезная работа над собой. Именно поэтому руководить проектом должен профессионал. И если он назначен руководителем проекта, то он НЕ ДОЛЖЕН выполнять роль аналитика, главного инженера  или разработчика. Так как это — абсолютно разные задачи и зачастую взаимоисключающие друг друга.
Исключения конечно есть из этого правила, но в больших и крупных проектах такие исключения ведут часто к провалу проекта.
Объясню почему:
— проект — это множество взаимосвязей, за которыми надо смотреть постоянно, так как только отвлекся — надо «тушить пожар», а если сработал эффект «домино», то одной пожарной машиной не обойдешься :-);
— работа же конкретной направленности, такой как аналитика, программирование, тестирование, …. требует 100% вовлечение в то, что ты делаешь;
— А быть вовлеченным в выполнение конкретной задачи и одновременно с этим находиться «НАД» проектом и видеть ВСЕ происходящее — НЕ ВОЗМОЖНО...

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

Однако, иногда, менеджеру проекта требуется поддержка, так как часто ПРОЕКТ=СТРЕСС.

И такую поддержку могут оказывать:

— Непосредственный руководитель;

— Профессиональные сообщества;

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

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

Если у вас есть конкретные вопросы, ответы на которые необходимо будет осветить на страницах сайта, то задавайте их, используя форму обратной связи или напрямую на e-mail.

Ну а на сегодня все.

Удачных Вам проектов !!!!

Заинтересованные стороны проекта

Про цели проекта говорили на прошлой неделе.

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

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

Вот и поговорим о том, какие действия ОБЯЗАТЕЛЬНО необходимо выполнить менеджеру проекта и его команде.

И так, простой, но рабочий алгоритм:

1) Необходимо идентифицировать заинтересованные стороны, т.е ответить на вопрос: «Кому из ближнего/дальнего окружения проекта интересна реализация проекта ?».

2) Определить степень влияния идентифицированных сторон на проект. Т.е. ответить на вопрос: «Могут ли повлиять и насколько сильно заинтересованные стороны на ход реализации проекта?»

3) Определить степень заинтересованности в проекте/результате проекта. Т.е. ответить на вопрос: «Какие цели/интерес заинтересованного лица в проекте ? »

4) Составить матрицу 2/2 по Вертикале которой будет матрица заинтересованных сторон сила Власти/влияния на проект. а по горизонтали будет Заинтересованность в проекте.

Дальше размещаем все идентифицированные стороны по четырем квадрантам.

Ключевой квадрант  —  это те заинтересованные стороны, которые имеют большую власть и большую заинтересованность в проекте. Эта категория заинтересованных сторон требует АКТИВНОГО управления.

5) Для всех заинтересованных сторон и в первую очередь для квадранта «Активного Управления»  прорабатываем стратегию работы  с заинтересованными сторонами. Т.е. определяем:

— способы коммуникации;

— формат и частоту предоставляемой информации;

— какие цели будут достигнуты в рамках проекта;

— какие цели не будут достигнуты в рамках проекта;

— какие цели могут быть достигнуты в рамках проекта;

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

Все это заносим в табличку:

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

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

На этом пока все.

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

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

Успешных Вам проектов !!!