Метка: Менеджер проекта

Как общаться с адовым клиентом

Всем привет.

Клиент, он же Заказчик, он же Stakeholder  — он же тот, кто платит деньги за успешный проект.

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

LABA подготовила статью, «Как общаться с Адовым Клиентом» .

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

Начало статьи здесь:

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

Заказчик сразу проблемный, если он:

не может четко сформулировать, чего хочет

занимает позицию, что всегда прав

не хочет отвечать на уточняющие вопросы по проекту.

Мы воссоздали ситуации, когда уже все завертелось и надо тушить пожары. В этих переписках проджект-менеджеры все делают правильно. Учитесь у них. Комментирует переписки наш лектор Евгений Камашев — сертифицированный директор проектов, преподаватель курса Project Management программы MBA Эдинбургской бизнес-школы.

Продолжение статьи читайте на сайте LABA

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

 

 

Хороший менеджер – ленивый менеджер

Вот наткнулся недавно на статью, которая описывает разницу между ленивым и «деятельным» менеджерами проектов и как эти характеристики влияют на проекты :-). Надеюсь Вам понравится 🙂

Случалось ли вам наблюдать, как руководитель проекта с самого его начала постоянно занимается пожаротушением, полностью погружен в борьбу с неотложными проблемами, темп поступления которых превышает скорость их решения. Все задачи, которые получает команда проекта, имеют наивысший приоритет и срочность: «Это надо было сделать еще вчера!» Трудовой героизм. Постоянные сверхурочные. Субботники. Авралы. Обучение, анализ, планирование, проектирование, тестирование, рефакторинг – «это все потом!».

Знакомо?

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

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

Потому, что он

 

Имеет свои цели

Выполнить проект в срок, в бюджете и с требуемым качеством – это не цель, это работа. Работать работу ленивому менеджеру лень. У него, как правило, есть личные цели. Они могут быть материальные — повышение оклада или должности. Могут быть идеальные — познать новое, сделать то, что до него никто не делал или, наконец, осчастливить все человечество. Но они есть.

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

Управляет приоритетами

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

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

Делегирует

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

Точит пилу

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

Строит отношения

Ленивый менеджер скорее добрый, чем злой. Злым быть хлопотно…

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

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

«Что посеешь, то и пожнешь». Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложив в людей часть своей души, получаешь сторицей.

Билл Гейтс говорил:

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

Как-то, так…

А вы что думаете по этому поводу ?

Удачных Вам проектов и легких путей их реализации 🙂

Оригинал по адресу: http://habrahabr.ru/post/238209/

 

Об управлении проектами на 4 листах флипчарта :-)

19 марта передо мной стояла задачка за 20 минут показать всю глубину и широту дисциплины Управление проектами для будущих студентов одного из ВУЗ-ов Киева.

Судя по отзывам участников, у меня получилось 🙂 и для этого мне понадобилось ровно 20 минут и 4 листа для флипчарта.

И сейчас я постараюсь воспроизвести кратко основную суть своего «выступления».

И так начнем 🙂

1) Вспоминаем что такое проект и какие его ключевые особенности и отличия от процесса.

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

Т.е. у проекта есть:

— Цель;

— Ограничения по срокам;

— Ограничения по ресурсам;

— Уникальность.

Говоря об ограничениях проекта мы плавно переходим к «треугольнику проекта», а именно к ключевым ограничениям, присутствующих в любом проекте:

— длительностьТреугольник проекта

— стоимость

— качество

(есть несколько интерпретаций треугольника, я показывал этот вариант, хотя суть это не меняет)

И получается, то если мы хотим (от нас требует заказчик/заинтересованные стороны) изменить в какую либо сторону одну из составляющих (т.е. например существующее качество нас не устраивает и нам надо его улучшить, т.е. Из точки А переместиться по оси качества (Q0 ->Q1)), то у нас есть три варианта:

— увеличить длительность, оставив стоимость проекта на прежнем уровне (не всегда так получается, но в модели вполне может быть) — Точка А2

— увеличить стоимость, оставив длительность на том же уровне — Точка А1

— увеличит и стоимость и длительность (наиболее применимый вариант)

Т.е. в итоге мы переходим из точки А в точку В.

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

2) Немного отвлечемся от самого проекта и поговорим на тему, а ЗАЧЕМ компании реализовывают проекты?

Варианты которые я получил от присутствующих:

— запуск нового продукта

— увеличение доли рынка

— внедрение нового ПО

— уменьшение затрат

— увеличение прибыли….

Однако некоторые из этих вариантов противоречивы как цели организации в один и тот же момент времени.

Поэтому настало время вспомнить о таких понятиях, как ВИДЕНИЕ, МИССИЯ, СТРАТЕГИЯ.Стратегия

Т.е. организация рождается начиная от ВИДЕНИЯ, постепенно прорабатывается МИССИЯ и после этого Руководство компании должно разработать стратегию как воплотить в жизнь ВИДЕНИЕ и МИССИЮ.

В процессе определенной работы СТРАТЕГИЯ компании разбивается на комплекс ЗАДАЧ (или ПРОЕКТОВ), реализация которых позволяет компании в целом реализовать СТРАТЕГИЮ.

Вот тут мы и подходим к ответу на ВОПРОС, а ЗАЧЕМ компании реализовывать проекты ?

В идеальной картине мира — ответ прост — для РЕАЛИЗАЦИИ СТРАТЕГИИ.

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

и Здесь не обойтись без ПОРТФЕЛЬНОГО УПРАВЛЕНИЯ, как элемента проектного управления на стратегическом уровне.

3) Если теперь посмотреть на все что писалось выше сквозь призму участников, то переходим к вопросу Заинтересованных сторон проекта/ов, которые оказывают непосредственное влияние на реализацию проекта.матрица заинтересованных сторон

Более детально можно посмотреть соответствующий пост (Заинтересованные стороны проекта).

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

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

4) В итоге (а это 4-й листок ФЛИПЧАРТА 🙂 ) получаем следующую картинку:

— Треугольник проекта и цели проекта

— Стратегия компании и портфель проекта

— Множество заинтересованных сторон со своими интересами и влиянием

Добавляем сюда непосредственно Жизненный Цикл Проекта и все что связано с непосредственным управлением проектом

и инструментарием менеджера проекта (WBS, матрица рисков, контрольные точки и т.д….)

И пытаемся ответить на вопрос, что же связывает эти все составляющие ?

Ответ прост — МЕНЕДЖЕР ПРОЕКТА, которые отвечает непосредственно за реализацию проекта и достижение поставленных целей.

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

 

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

И глубина глубин и широта широт этой дисциплины намного глубже и шире, чем было изображено на 4 листах флипчарта.

Вообщем получилось вот такое вот выступление.

А как ВЫ думаете, насколько удалось раскрыть суть проектного управления и глубину данной дисциплины ?

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

 

 

 

 

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

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

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

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

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

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) Потенциальные возможности использования Синергии командной работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постановка целей в проектах

цель

Сегодня поговорим о целях и том, какие цели бывают.

Ни один проект не обходится без определения целей проекта.

И от того, насколько четко и качественно сформулированы ЦЕЛИ, напрямую зависит  успешность данного проекта.

Ведь если цели нет, то как определить, что мы пришли именно туда, куда планировали ?

Сразу вспоминается эпизод из «Алиса в стране чудес«, где она говорит с котом:

— Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
— А куда ты хочешь попасть? — ответил Кот.Цель

— Мне все равно… — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— …только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.

 

Так и в проектах, если достаточно долго что то делать, то обязательно что то сделаешь, только вот то ли это, что от тебя ЖДУТ ? А это уже вопрос.

И так какие цели бывают:

1) Четкие цели. Это когда мы знает достаточное число критериев успешности. И описание самой цели не вызывает затруднений. Зачастую такие цели формулируются с использование SMART критериев. Я не буду останавливаться здесь на том, что такое SMART — в интернете достаточно информации на эту тему. Скажу только одно, что достижение таких целей намного проще. К тому же все участники команды проекта ПОНИМАЮТ, а это немаловажно, куда надо прийти…

2) Так называемые «Расплывчатые цели».  Это когда мы не можем по SMARTу четко сформулировать ЦЕЛЬ.  Это конечно не тот случай, как в фрагменте с Алисой, но очень похож.

В случае с расплывчатыми целями мы понимаем ВЕКТОР движения и у нас есть определенные «Очертания» цели.  Что же делать менеджеру проекта  и проектной команде?

Расплывчатые цели

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

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

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

К таким рекомендациям относятся НАЛИЧИЕ ТРЕХ СОСТАВЛЯЮЩИХ :

1) Наличие СИЛЬНОЙ эмоциональной  составляющей. 

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

2) Наличие Сенсорной составляющей.

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

3) Наличие Прогрессивной составляющей.

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

Более детально  тему постановки цели, SMART критерии  и работу с расплывчатыми целями мы обсуждаем на тренинге Управление проектами: «Просто о сложном».

А на сегодня, пока хватит 🙂 Ждите продолжение.

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