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

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

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

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

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

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

И она всё ещё думала и думала. Так прошел день, а на закате вернулся хозяин и запер дверь клетки.

Итак, она предпочла безопасность свободе.

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

И помните наш рост начинается только там, где заканчивается зона комфорта (часто это и есть — зона безопасности).

Правильного Вам выбора !!!

В предыдущих постах были рассмотрены вопросы постановки целей, формирования команды проекта, управление конфликтами, распределение ответственности внутри команды. Сегодня предлагаю перейти к инструментам планирования проекта и рассмотреть один из таких инструментов — 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) Сотрудничество

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

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

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

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

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

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

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

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

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

Старая, но очень хорошая притча, задумайтесь на минутку о ее сути.

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

Они окружали его со всех сторон, берег был буквально усеян ими.
— Зачем ты бросаешь эти морские звезды в воду?
спросил человек, подходя ближе.
— Если они останутся на берегу до завтрашнего утра, когда начнется отлив, то погибнут, ответил мальчик, не прекращая своего занятия.
— Но это просто глупо! — закричал человек.
— Оглянись! Здесь миллионы морских звезд, берег просто усеян ими.
Твои попытки ничего не изменят!
Мальчик поднял следующую морскую звезду, на мгновение задумался, бросил ее в море и сказал:
— Нет, мои попытки изменят очень много
… для этой звезды.

Делайте мир лучше вокруг себя! 

Пусть понемногу, пусть это будет просто улыбка, подаренная прохожему, пусть это будет слово поддержки или благодарности, пусть это будут дополнительные 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 — много, то тяжело найти того, кто реально ответственен за данную задачу.

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

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

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

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

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

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

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

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