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

Притча: Дверь

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

Обратите внимание на советы в конце притчи, мне кажется их стоит взять на вооружение!

Я надеюсь она Вам понравится 🙂

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

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

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

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

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

Мудрец нашел себе преемника. Он повернулся к остальным ученикам и произнес следующие слова:

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

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

Во-вторых, не делайте поспешных и потому неправильных выводов.

В-третьих, будьте достаточно смелы, чтобы принять решение.

В-четвертых, приняв его, действуйте уверенно и без сомнений.

В-пятых, сосредоточьтесь и вложите в это действие всю вашу силу и энергию.

И, наконец, не бойтесь совершить ошибку

Удачи Вам во всех Ваших начинаниях и мудрости при принятии решений!!!

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

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

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

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

И так начнем 🙂

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

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

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

— Цель;

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

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

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

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

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

— стоимость

— качество

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

 

 

 

Виды организационных структур

Вот и закончились Новогодние праздники 🙂

Всех с Наступившим Новым 2014 Годом. Пусть он будет успешным во всех отношениях !!!

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

Итак, какие же основные типы организационных структур бывают в компаниях?

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

К основным функциям (так называемой цепочке создания ценности) чаще всего относятся:

1) Производство;

2) Исходящая логистика;

3) Входящая логистика;

4) Маркетинг и продажи

5) Сервис

К дополнительным функциям относятся:

1)  Закупки

2) НИОКР

3) HR (Управление человеческими ресурсами)

4) Системы управления.

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

К достоинствам функциональной структуры относятся :

— Низкие административные расходы, отсутствие дублирования функций;

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

— Эффективное решение стандартных профессиональных задач;

— Централизованный контроль важнейших решений руководством компании;

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

К недостаткам можно отнести:

— Возможна чрезмерная фрагментация стратегически важных процессов;

— Проблемы межфункциональной координации;

— Замедленность реакции на изменения внешней среды;

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

— Отсутствие у менеджеров системного подхода к решению проблем организации.

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

Дивизональная структура

 

К достоинствам дивизиональной структуры относятся:

— Корпоративное руководство освобождается от оперативных функций и может сосредоточиться на стратегиях;

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

— Организационная гибкость;

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

К недостаткам относятся:

— Возможный разрыв между стратегическим и оперативным управлением;

— Проблема согласования интересов корпорации и входящих в нее дивизионов;

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

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

3) Проектная структура — Это структура организаций, которые занимаются в основном проектной деятельностью. К ним относятся Конструкторские бюро, Строительные организации, и т.д. Фактически ключевой персонал выделяяется на проект 100 % и подчиняется менеджеру проекта.

Проектная структура

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

К достоинствам относятся:

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

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

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

— Комплексный подход к реализации проекта и решению проблем;

— Концентрация всех усилий на решение одной задачи — выполнения проекта;

— Большая гибкость

— Усиление личной ответственности конкретного руководителя как за проект в целом так и за его элементы.

К недостаткам можно отнести:

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

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

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

— Дублирование существующих в организации функциональных служб.

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

Бывает три типа матричных структур:

— Слабая матрица;

— Сбалансированная матрица;

— Сильная матрица.

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

Слабая матрица

 

Слабая матрица

 

 

 

 

Сбалансированная матрица

 

 

Сбалансированная матрица

 

 

 

Сильная матрица

 

Сильная матрица

 

 

 

 

К достоинствам матричной структуры относятся:

— Возможность реализации сразу двух стратегических направлений развития компании;

— Поддерживает инновационную деятельность (междисциплинарный подход к  решению нестандартных задач);

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

— Хорошая координация деятельности функциональных специалистов за счет введения позиции руководителя проекта.

Недостатки:

— Подрыв принципа единоначалия, борьба за власть и склонность к анархии, конфликтность структуры;

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

— Рост управленческого аппарата (у каждого специалиста два начальника);

— Удлинение сроков принятия решений из-за необходимости многочисленных согласований.

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

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

Какая же структура лучше ?

Я думаю что Вы знаете ответ на этот вопрос. Он очень простой:

— Та, которая обеспечивает максимально эффективное достижение целей компании 🙂 .

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

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

Правильного Вам выбора и Удачных проектов !!!

Подведение итогов года

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

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

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

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

Кратко о SCRUM-е (взято с книги: «Kunban и Scrum: выжимаем максимум»)
1) Разделите Вашу организацию на маленькие, кросс-функциональные, самоорганизующиеся команды.
2) Разделите Вашу работу на маленькие, конкретные компоненты. Отсортируйте этот список  по приоритетам ии оцените объем работ по каждому элементу.
3) Разделите время на короткие итерации фиксированной длины (обычно 1-4 недели) так, что бы после каждой итерации проводилась демонстрация потенциально готового к использованию кода.
4) Оптимизируйте план релиза и корректируйте приоритеты совместно с клиентом, основываясь на данных, получаемых при рассмотрении релиза после каждой итерации.
5) Оптимизируйте процесс с помощью проведения ретроспективы после каждой итерации.
 Кратко о Kanban-e (взято с книги: «Kunban и Scrum: выжимаем максимум»)
1) Визуализируйте поток работ:
— Разбейте работу на части, выпишите каждый пункт на карточку и прикрепите к стене
— Подпишите столбцы, что ы видеть на какой стадии находится каждое задание
2) Ограничьте НЗР (Не завершенная работа) — определите возможное количесво незавершенных пунктов на каждой стадии рабочего процесса
3) Измеряйте время выполнения задачи. — оптимизируйте процесс, что бы свести время выполнения задачи к минимуму и сделать его настолько прогнозируемым, насколько возможно.
Т.е. в каждом случае у нас есть список работ который надо сделать, детализированный до такой степени, до которой мы можем прогнозировать время выполнения работы и иметь конечный результат.
Так же есть самоорганизующаяся команда, которая должна выполнить весь объем работ, отчитываясь каждую неделю (2-3 недели, в зависимости от длины спринта) Заказчику и корректируя следующие шаги.
Руководит самоорганизующейся командой — SCRUM MASTER.
Участники команды — универсальны, и фактически деление на роли отсутствует.
Product Owner ставит для команды приоритеты с точки зрения Бизнес потребностей Заказчика.
Для того что бы «мониторить» ход работы, команда собирается каждый день возле «доски»  на 15 минутный митинг для обсуждения, Что сделано, что планируется, где есть проблемы.
Таким образом и движется работ от Спринта к Спринту.
Ниже показаны примеры «Досок» проектов:
kanban_1
1311500094_doska_backlog_3
kanban-3f_2
Если все это обобщить получим-
Ключевые подходы «гибкого УП»:
— Длина СПРИНТА (1-3) недели;
— Еженедельные/дневные встречи по Спринтам;
— Проведение ретроспектив;
— Небольшие команды (5-8 человек);
— Product Owner (Спонсор) – установка приоритетов;
— Scrum Master (Менеджер проекта) – организация работы команды;
— Постоянная коммуникация с Заказчиком.

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

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

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

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

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

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

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

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

 

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

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

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

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

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

Всем привет.

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

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

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

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

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

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) Сотрудничество

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

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

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

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

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

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

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

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

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

 

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