Вот и заканчивается 2013 год.

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

Я хотел бы подвести итоги Года уходящего и поделиться Планами на год следующий  — 2014 :-).

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

И так, что у меня получилось сделать за этот год (точнее за пол года).

1) Полная реанимация сайта. Здесь хочу сказать отдельное спасибо Виктору Серобаба, благодаря которому собственно и появилась новая версия сайта;

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

3)  Провел первый Webinar, об этом я уже писал отдельный пост, поэтому повторяться не буду. Опыт же буду использовать в дальнейшем :-). Здесь, несмотря на то, что пока наше сотрудничество дальше не пошло, хочу сказать спасибо Светлане Матейчук — основателя компании МиМ.

4) Познакомился и стал Партнером консалтинговой компании Civitta, которая открыла свой офис в Украине. Основной вектор деятельности компании — Управленческий Консалтинг. Компания представлена в странах Балтии, Белоруссии и теперь в Украине. Поэтому по вопросам, связанным с деятельностью компании Civitta Вы также можете обращаться ко мне.

А вопросы могут быть весьма разными и в том числе связанными с  поиском партнеров  в странах Балтии и Белоруссии :-).

5) Так как второе направление моего развитие — это тренинги и обучение, то здесь тоже есть движение — я стал Тренером Швейцарской компании Siegel. И сейчас с командой Siegel в Украине мы активно работаем над развитием как продуктов Siegel (а здесь есть достаточно интересные тренинги), так и над созданием новых обучающих продуктов для рынка СНГ и Украины.

Опять же если заинтересуют какие либо тренинги этой компании, можете обращаться прямо ко мне 🙂

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

7) Я не только учил других, но и учился сам. В этом семестре я изучил еще два предмета в Эдинбургской Бизнес Школе, на программе МБА.  Это были Финансы и Стратегическое планирования. Отдельное спасибо хочу сказать тьюторам Бизнес Школы — Ивану Компану и Тимуру Сарбаеву.

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

— Аудит процесса продаж. (Был проведен аудит существующего процесса продаж, подготовлены рекомендации по оптимизации, разработаны матрицы ответственности и ролевые инструкции по ключевым функциям)

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

— Аудит процесса управления проектами. (Проведен аудит текущего процесса управления проектами. Разработаны рекомендации по его улучшению и повышению эффективности. Это был первый этап. Следующим этапом будет непосредственно реализация рекомендаций, что были приняты компанией);

— Стратегическая сессия. (Была проведена стратегическая сессия для компании, что только начинает свою активную деятельность. Проработаны сильные и слабые стороны, определены Факторы успеха. Разработаны основная стратегия, а так же серия тактических мероприятий…)

И еще раз хочу сказать слова Благодарности ВСЕМ, с кем мои пути в 2013 году пересекались и не важно на сколько на 1 час или на весь год. Благодаря Вам я не стою на месте и развиваюсь и надеюсь, что с каждым днем, с каждой встречей, становлюсь лучше и лучше  :-).

Теперь немного о Планах следующего года:

Тренинговые программы:

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

Тогда же и начну ее проводить :-).

2) Идет разработка совместно с компанией Siegel Школы управления Проектами. Здесь процесс более длительный.  Поэтому закончить ее планируем только к осени. Должно быть интересно и полезно 🙂

3) Так же планируем совместно с компанией Siegel запустить дистанционные тренинги по основным тематикам компании.

4) Планирую вернуться к тематике Webinar-ов по проектному управлению.

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

Консалтинг (Здесь планировать намного сложнее, поэтому укажу только вектора в которых я буду двигаться):

1) Продолжать развивать направление Project Management в компании Civitta, постепенно подключая и другие сервисы;

2) Проработать новые консалтинговые продукты, связанные с разработкой стратегии, критическим факторам успеха;

3)  Получить степень МБА и активно использовать знания, полученные в Эдинбургской Бизнес Школе в консалтинговых проектах.

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

Ну и основное, что планирую в Новом 2014 Году — Это быть счастливым и получать удовольствие от жизни во всех ее проявлениях.

Чего и Вам искренне желаю.

С НОВЫМ ГОДОМ !!!!

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

Начну с определения (Википедия):

Организационная структура (англ. Organizational structure) — совокупность способов, посредством которых процесс труда сначала разделяется на отдельные рабочие задачи, а затем достигается координация действий по решению задач (Генри Минцберг, «Структура в кулаке»). По сути дела, организационная структура определяет распределение ответственности и полномочий внутри организации. Как правило, она отображается в виде органиграммы (англ. organigram) — графической схемы, элементами которой являются иерархически упорядоченные организационные единицы (подразделения, должностные позиции).

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

Зачем же нам организационная структура ?

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

Т.е. нам необходимо построить такую СИСТЕМУ, которая бы наиболее эффективным образом позволила реализовать стратегию компании.

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

Как объединить должностные позиции в организационные единицы?

Сколько сотрудников должно быть подчинено одному руководителю?

Как далеко можно делегировать полномочия?

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

…

Какие же есть основные признаки эффективной структуры компании:

1) Структура соответствует стратегии организации;

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

2) Структура соответствует среде функционирования организации;

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

3) Отсутствие противоречии между элементами организационной структуры.

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

Какие же есть правила «ПРАВИЛЬНОГО» формирования организационной структуры компании?

Правило №1

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

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

Правило №2

При изменении стратегии корректируется и организационная структура.

Правило №3

Проанализируйте возможность Аутсорсинга.

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

Правило №4

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

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

Правило №5

Связанные виды деятельности должны выполняться скоординировано.

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

К таким инструментам относятся:

— прямой контроль,

— стандартизация бизнес-процессов,

— стандартизация знаний и навыков,

— стандартизация выпуска,

— взаимные согласования

и ряд других.

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

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

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

Всем привет

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

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

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

Теперь, учитывая данные ключевые подходы, можно обсудить когда и как их лучше применять (Кроме ИТ сферы, так как там эти подходы во всю применяются :-)).

Так как команды небольшие, желательно что бы размещались в одном месте и имели доступ до «ДОСКИ«, то это один из эффективных подходов для StartUP-проектов, где ключевым является повышенная вовлеченность всех участников в проект, чему способствуют ежедневные встречи по Спринтам.

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

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

В каких случаях применение гибких технологий проблематично:

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

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

Сложно использовать в проектах с фиксированной ценой, так как гибкие технологии, больше предполагают подход «Time&Materials«.

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

Более подробно про гибкие технологии можно прочитать на соответствующих сайтах или поискать детали в интернете. Могу так же рекомендовать книги на русском языке, где просто и доступно описаны ключевые принципы этого подхода, с примерами из ИТ отрасли. Книга называется: » Kunban и Scrum: выжимаем максимум» и «Scrum и XP: заметки с передовой«.

Ну и на этом сегодня все.

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

Всем привет.

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

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

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

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

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

WBS проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 диаграмма или матрица.

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

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

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

Все просто:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи Вам !!!