Почему системы управления проектами не работают? Как организовать системное и гибкое управление проектами?
- Почему системы управления проектами не работают и как их адаптировать под особенности проектов и организаций, создавая гибридные методологии под разные типы проектов
- Как использовать рабочие сессии, и какие решения появились именно благодаря сессионному формату
- Почему нужны вложения не только в систему, но и в людей, и какие подходы эффективного формирования компетенций применяют сегодня лидеры рынка
Управляющий партнер ГК «Проектная ПРАКТИКА»,
Председатель Правления Ассоциации управления проектами СОВНЕТ,
Представитель России в международном комитете по стандартизации в области управления проектами ISO TC 258 Project, Program and Portfolio Management
Генеральный директор компании «Проектный Персонал»,
Член экспертного совета Центра оценки и развития проектного управления,
Представитель РФ в техническом комитете TCISO 258 по разработке стандарта серии «Проектный менеджмент» — «Управление портфелем проектов»,
PMP, IPMA B, ПМ СТАНДАРТ СРП-1
Генеральный директор Центра оцени и развития проектного управления
представитель России в техническом комитете TCISO 258 по разработке стандарта серии «Проектный менеджмент» — «Управление программами проектов».
IPMA D, PRINCE2® Foundation, ПМ СТАНДАРТ СРП-2
Источник
Основные проблемы проектного менеджера и как с ними бороться
Постарался расставить проблемы, с которыми сталкиваемся, по степени их влияния на исход проекта. К некоторым болезням проектного менеджмента удалось найти лекарства, но некоторые по-прежнему дают большие риски, которые съедают бюджеты и ресурсы.
Хочу попросить не отсылать к известным методологиям PMI, PRINCE2 и т.д. Так как в них указаны диапазоны бюджетов, в которых применимость их будет давать эффект больший чем затраты на саму методологию — это от 50 000 $ USA. Интересуют решения для проектов бюджетами от 5 000 до 30 000 $ USA.
1. Неправильная оценка проекта. Почти все заказчики хотят fix-cost. И это правильно с их точки зрения, только имея понимание об этом, они принимают решение запускать или не запускать проект.
Как лечится: выделение консалтинга в отдельный проект. По результатам имеем концепт проекта, ТЗ, ИСР, бюджет, календарь.
2. Противодействие или отсутствие действий со стороны персонала заказчика на этапе внедрения. На проект деньги еще выделяют, а зарплатный фонд никто не увеличивает на работы во время переходного процесса, например когда на предприятии работают две системы учета, или на обучение.
Как лечится: обучение заказчика, создание у него центра компетенции.
3. Ошибки при проработке требований заказчика. Все требования вроде как и фиксируются, систематизируются, но требования исходят от разных отделов и людей. Люди меняются и к моменту, когда есть результат, на месте внедрения оказываются уже другие люди с другими взглядами. Никто не отслеживает кто и как меняется, и нет процедуры чтобы вызвать инициативные изменения требований со стороны Заказчика.
Как лечится: управление требованиями, утвержденная процедура изменения требований.
4. Учет изменений на проекте и документация особенностей. Реализация идет с согласованными отклонениями от постановки, и это нормально, но когда проект уже запущен и летит, никто не занимается документацией этих отклонений и «фич». В итоге, если приходит новый человек на проект или его в дальнейшем надо сопровождать, то чтобы ввести его в курс дела, ничего нет кроме как первоначального устаревшего ТЗ и спецификаций. Проект изменился, он уже другой. Денег на исправление нет никогда. Такой проект становится кошмаром для support.
Как лечится: фиксировать все изменения в концепте проекта, хотя это ресурсозатратно.
5. Недостаточная обеспеченность проекта ресурсами. Сюда можно включить все разнообразие:
a. Людей не выделяют в нужном количестве и нужной квалификации
b. Людей забирают в середине проекта на тушение пожаров
c. Людей забирают в середине проекта на support их прошлых проектов
d. Неадекватная замена исполнителей
e. Текучка на проекте – уходят те, кто «в теме», а набирают тех, кого найдут
Лекарства пока нет. Видимо такова специфика отрасли – «овертаймить» и проваливать сроки.
6. Замыкание многих процессов на самых компетентных и перегрузка их работой. Нет делегирования. Всегда на проекте те кто знает и делает и те кто делает только если скажут. Ответственные и компетентные люди не всегда используют делегирование или этому не способствует обстановка в команде.
Лекарства пока нет. Видимо такова специфика отрасли IT. Хорошие инженеры и программисты по своей природе интраверты. Все говорят о Agile team building как лекарстве, но пока не получилось. Так как этот процесс утянет и так ограниченные ресурсы и деньги, понадобится компетентный и недешевый HR. Если у кого есть идеи, посоветуйте.
7. Много средств требует поддержка инфраструктуры и управление ей. Сколько не пиши правила где девелопим, как деплоим где тестируем, как выливаем релизы — в PMI это называется «Концепция проекта», — все же постоянно нужно проверять, разъяснять наказывать, и в итоге ПМ берет на себя все больше и больше участков работы.
Как лечится. Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.
8. Сложность постановки процесса разработки под конкретный проект. Тут как не унифицируй, но каждый проект уникален в плане какие сервера, где стоят какой к ним доступ. Как пример — есть заказчики, которые выделяют к себе только узкий VPN через которые должны все ходить.
Как лечится. Выделение ресурса на процесс планирование и прямое отражение этой статьи в затратах.
9. Отсутствие итерационности в проекте. Заказчику нужно показывать и давать оценивать промежуточные результаты, чтобы понимать, что мы не сбились с пути. А у заказчика не всегда есть время на оценку. А надо лететь дальше, так как заказчику нужны сроки, а не оправдания и не дай бог его потыкать носом в не отвеченные запросы.
Как лечится. Введение в проект роли «аккаунт менеджер» который постоянно на связи с заказчиком и выдергивает из него все необходимое.
10. Плохое использование прошедшего опыта разработок и отсутствие условий его накопления и использования в будущем. Когда проект «горит» никто не думает о формирований библиотек или модулей для использовании в будущем. В итоге постоянное изобретение велосипедов вместо производства.
Лекарства пока нет. Если есть опыт посоветуйте, как замотивировать ПМ и разработчиков на выполнение этого процесса?
Источник
Почему не работают Уставы и Планы управления проектом?
Мы приходим к Заказчику и говорим ему: вот так мы будем планировать проект, вот так будем управлять изменениями, вот так будем управлять рисками, вот так будем проводить совещания, вот так будем эскалировать проблемы и принимать решения, вот такие сроки будут у нас на согласование, вот такая периодичность будет статусных совещаний и т.д. И приносим ему это в виде объемного документа этак страниц на 30-50 регламентирующего текста. Заказчик смотрит на это «широко закрытыми глазами» и говорит: «Круто!». То, что не соотносится с практикой, принятой у Заказчика, он предложит исправить, но в остальном документ будет принят.
А дальше началась жизнь и процессы прошли своим путем, принятия решений своим путем, а документ остался на полке. Иногда РП достает его чтобы показать, что Заказчик не соблюдает установленные сроки, либо нарушает другие договоренности. Но это делается, когда на проекте нарастает напряжение и сторонам нужно защищаться. Есть ситуации, когда РП пытается актуализировать процессы, но часто на него смотрят «косо» как на бюрократа, который вместо результата занимается «бумажками».
В итоге такой документ выполняет функцию защиты РП-ника или Подрядчика, либо маркетинговую функцию для Подрядчика: «Круто! Вы работаете по проектной технологии!». А хотелось бы, чтобы документ работал.
Во-первых, давайте разберемся с понятиями. В отрасли ИТ-проектов, я часто наблюдаю как два документа Устав и План управления проектом объединяют в один документ, называя его «Устав проекта». Наверное, в этом нет ничего страшного, особенно когда этот «Устав», созданный в начале проекта, больше не используют при выполнении проекта. Но если надо получить работающие документы, то надо обратиться к истокам.
Согласно PMBoK: «Устав проекта — это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать.» «План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. Он интегрирует и консолидирует все вспомогательные и базовые планы, полученные в результате процессов планирования.»
Итак, Устав проекта более статичен, чем План управления проектом. Он определяет суть самого проекта, он есть распоряжение от Заказчика (или Спонсора) к Руководителю проекта (далее «РП»): необходимо сделать проект вот в таких определенных рамках. Если необходимо изменить зафиксированное в Уставе, значит для РП или Исполнителя это повод к пересмотру договорных отношений с Заказчиком. Соответственно этот документ делает Заказчик или Спонсор, а не РП или Исполнитель. Это важно! Не будем акцентировать внимание на том, что План управления проектом — это не план-график, как некоторые его воспринимают. Тут, наверное, сказывается история использования слова «план» в русском языке. План управления проектом говорит о том, как РП и команда проекта будут исполнять и контролировать этот проект, чтобы добиться результатов в границах и параметрах, описанных в Уставе. Этот документ более динамичен, он изменчив по ходу проекта, так как сразу определить все процессы не удастся.
Проект — это уникальное предприятие, а соответственно он имеет уникальный набор процессов. Можно в начале проекта предположить, спланировать одни варианты процессов, но походу проекта будут выявляться нюансы корректирующие их и это нормально. Как говорил Дуайт Эйзенхауэр: «План — ничто, планирование – все. Любой план устаревает в тот момент, когда вы завершили его разработку. Но в процессе планирования вы и ваши подчиненные приобретаете один взгляд на ситуацию и критерии принятия решения, следовательно, в момент неожиданности они выберут правильное решение». Поэтому на схеме процессов PMBoK План управления проектом является выходом нескольких различных процессов, чего не происходит с Уставом проекта. Таким образом, первая причина разнесения этих двух документов — их различное назначение. Вторая причина — динамика их изменений. Если вы управляете изменения, то поймете важность этой причины. Есть еще третья причина. В момент инициации проекта невозможно достаточно точно определить то как будет исполняться проект. После назначения (с помощью Устава) РП надо сформировать команду, определить подрядчиков, выстроить орг структуру проекта, декомпозировать содержание, продумать эффективные процессы. На это могут уходить иногда месяцы. Поэтому План управления проектом рождается позже Устава.
После того как разобрались с понятиями, поговорим почему не работают Планы управления проектами, которые многие называют «Уставами». Я много видел таких «Уставов», которые создавались в начале проекта, некоторые были очень объемными, были даже красивые, с четким содержанием, описанием процессов, но большинство процессов на проекте так и не выполнялись. И это не значило что на проекте все плохо! Просто фактические процессы на проекте не соответствовали формализованным в документе. Я не сторонник этого расхождения, но проекты ведь идут и результаты на таких проектах получаются.
Почему так происходит?
Надо понимать, если у Заказчика не выстроено проектное управление, вы не можете взять и сходу его внедрить, начать делать свой проект красиво, в соответствии с проектной технологией. Проектное управление — это отдельный подход к управлению, отличающийся от регулярного. На внедрение его процессов требуется значительное время, а часто целый отдельный масштабный проект по реинжинирингу. Поэтому существует такое понятие как уровень зрелости проектного управления в компании. Т.е. компания (Заказчик) зреет поэтапно, последовательно. Так просто с одного уровня на следующий Заказчик не перепрыгнет и не надо мечтать. Переходы могут длиться годами.
Существует несколько стандартов, описывающих модели зрелости проектного управления.
Самые известные из них это:
- P3M3 — Portfolio, Programme and Project Management Maturity Model — Модель зрелости управления портфелями, программами и проектами;
- OPM3 — Organizational Project Management Maturity Model — Модель зрелости организационного управления проектами.
Ознакомьтесь, например, с таблицей «Система измерения уровня зрелости управления» в Википедии, там представлены типовые уровни зрелости и их признаки.
Мы видим, что только на 2 уровне ««Управляемый» («Повторяемый»)» появляется проектный подход в начальном виде. Поэтому если вы хотите чтобы ваши действия на бумаге соответствовали вашим реальным действиям на проекте, оцените уровень зрелости проектного управления Заказчика, перед тем как составлять План управления проектом. Мои рекомендации при этом следующие:
- Для уровня 0 «Отсутствующий». Нет смысла делать План управления проектом, его никто не будет выполнять. Сделайте Устав, занесите в него основные параметры проекта: Спонсор, Заказчик, РП, цели, задачи, критерии успешности, основные этапы и их результаты, состав рабочей группы. Если вы Подрядчик, то отразите это прямо в договоре или приложении.
- Для уровня 1 «Начальный». Кроме Устава, у вас появятся зачатки Плана управления проектом: можно прописать Организационную структуру проекта, правила документооборота на проекте со сроками согласования документов.
- Для уровня 2 «Управляемый» («Повторяемый»). Скорей всего у Заказчика есть уже некий пример регламентирующего документа, который он применял на других проектах. Желательно понять насколько он выполняется на этих других проектах. Можно посетить их и проанализировать. Удалите сразу, что не выполняется и возьмите этот документ за основу. Но точно нет смысла на этом уровне описывать процессы управления рисками, управления коммуникациями, управления содержанием.
- Для Уровня 3 «Определяемый» («Стандартизуемый»). Скорей всего у Заказчика есть уже некий формат Плана управления проектом. Также желательно понять насколько он выполняется на примере других проектов. Но точно нет смысла на этом уровне описывать процессы управления рисками.
- Для Уровня 4 «Измеряемый» и 5 «Оптимизируемый». На этом уровне зрелости у Заказчика в принципе есть все процессы для полноценного управления проектами и их рисками. План управления проектом будет полным. Сотрудники уже работают в соответствии с прописанными процессами и наработали необходимые навыки.
В принципе, ничего страшного нет, если делать полноценный План управления проектом, который не работает. Он кроме описанных выше применений (защиты и маркетинга) посеет семена проектного управления у Заказчика, его сотрудники будут знать, что вот так бывает, задумаются, и возможно взрастят их со временем.
Источник