Преобразование социально-экономических систем (бизнес, организации, общество…)

Мир ускоряется, становится цифровым, постоянно меняется. Начиная с 80-х (а на постсоветском пространстве после «периода застоя» начиная с 90-х), мир стремительно менялся с ускоряющейся динамикой в нарастающих темпах.

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

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

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

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

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

Но когда Вам понадобятся радикальные улучшения – без проектного подхода не обойтись. И тогда Вы запустите проект, целью которого будут изменения в операционной деятельности (повышение эффективности, оптимизация затрат, скорость, объемы и пропускная способность и т.д.). А уже результаты этого проекта (со всеми полученными выгодами и преимуществами) «перетекут» в операционную деятельность и станут частью обычной повседневной жизни компании.

Причем выгоды от проекта могут быть не только материальными (деньги, доля рынка, оборудование и т.д.), а и нематериальными (начиная от узнаваемости бренда до просто соответствия системы управления заявленной стратегии). И в проектах преобразований социально-экономических систем чаще нематериальные выгоды выходят на первый план с точки зрения именно результата проекта – а материальные идут скорее, как их следствие; как то, ради чего затевалась получение результата проекта.

Но у самого менеджера по управлению проектами преобразований фокус именно на конкретном результате конкретного проекта – а не на каких-то итоговых верхнеуровневых бизнес-выгодах (которые зачастую отражены в бизнес-кейсе и в целом в трансформационной программе).

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

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

Стандарты и «сертификаторы»

В разговорах о проектном управлении всегда подымается тема сертификаций и сопутствующих их стандартов. Вот и я начну книгу с этого.

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

Тем не менее о некоторых сертификациях немного расскажу. Есть множество разных сертификаций PMP\PMI, IPMA, PRINCE, модные Agile (Scrum, Kanban и т.д.) … Писать, что какая-то из них лучше других бессмысленно в принципе – ведь каждая решает имеет свои преимущества, недостатки и ограничения. Но чтобы кто не говорил, самыми двумя классическими почитаемыми на сегодня в бизнес-среде является IPMA и PMP (PMI).

Если в практическом русле рассматривать то, как проходят эти сертификации, то с «моей колокольни» разница следующая:

· Сертификация от PMI больше похожа на сдачу ЭГЕ: ответы на тесты. Процесс сертификации построен на формальных признаках: (а) подтверждение «часов налета» по проектному управлению с перечнем конкретных вещей, которые Вы применяли от инициации до завершения проекта; (б) результаты теста. И тест проводится по всему миру по одинаковым вопросам.

· IPMA больше похож на устный экзамен в школе / ВУЗе, который большинство рожденных в СССР проходили. Он требует перечня проектов, в которых принимал участие сертифицируемый, а также и детального описания одного из проектов, которым он персонально руководил. Помимо этого, в рамках данной сертификации предполагается собеседование с оценщиком или местной коллегией экспертов. А поскольку основой для IPMA является стандарт, который описывает, что должен знать кандидат и какими навыками обладать, то упор больше на роль и личный опыт менеджера проектов, его мысли и выводы, переосмысление опыта в целом.

С моей точки зрения, PMI легче сдавать тем, у кого поменьше опыта ввиду его сильной стадартизированности и тестового формата. Эксперту с реальным опытом сама сдача IPMA будет полезнее – да и базировалась она изначально на основе компетенций менеджера проектов ICB.

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

К примеру, длительность IPMA – 5 лет, а сертификатов PMI (самыми популярные PMP и CAMP) – 3 года.

А каждая повторная ресертификация требует определенных формально подтвержденных наработок. Например, для продления РМI-сертификата (PMP) потребуется насобирать за 3 года не менее 60 так называемых PDU (professional development units) для продления. Но для САМР этих РDU не требуется.

Причем в практической проектной деятельности или делясь своим опытом (проводя вебинары, курсы, читая лекции, ведя блоги, написав статьи или даже книгу, выступая в компании, работая менеджером проекта на волонтерских началах и т.д.) Вы можете собрать максимум 25 PDU (да, такое ограничение – все, что набрано свыше просто «сгорает» ввиду того, что ты просто делишься или используешь свой опыт, не обогащаясь).

А в обучении у других (чтение книг, прохождение курсов, посещение конференций, работа с наставником, профдискуссии и т.д.) – есть минимальное требование от 35 PDU. Но тут еще и все должно быть официально подтверждено (сертификатами, видео- или аудиозаписью, официальными регистрациями, чеками, конспектом и т.д.).

У IPMA для низшего уровня D также есть похожие единицы под названием «CPD-часы» (continuous professional development) – их для ресертификации необходимо насобирать не менее 175 за 5 лет (причем минимум 35 в год). Для более высоких уровней требования посложнее и критериями становятся не менее 30 месяцев работы менеджером проекта, сложность, управление людьми и т.д..

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

Все стандарты, на которых базируются сертификации, в чем-то повторяют, а в чем-то дополняют друг друга. Но PMI создан стандарт PMBoK (Project Management Body of Knowledge – Свод Знаний по Управлению Проектами). И невзирая поклонником какого подхода Вы являетесь, я настоятельно рекомендую почитать PMBoK, хотя бы обзорные статьи.

Но предупреждаю новичков в проектном управлении: простое заучивание процессов и областей знаний любого стандарта ни к чему хорошему не приведет. А особенно подменяя зачастую смысл и дух проектного управления написанием формальных бумажек (как бы соблюдая «букву закона» согласно стандартам).

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

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

А любая сертификация – показатель того, что человек что-то знает об управлении проектами. А вот в дополнении к весомому опыту она уже становится хорошим «пропускным билетом» на солидные проекты в солидные компании.

Ведь успех проекта и мастерство менеджера проектов в большей мере обеспечиваются практически реализованными проектами (как успешными, так и не успешными – «за одного битого двух небитых дают»), а не только знаниями и наличия сертификата.

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

На этом о «проектных сертификациях» в рамках книги все.

Что такое проект (а заодно программа) и управление ими

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

Проект – это временное (т.е., имеющее начало и осязаемое окончание) предприятие, направленное на создание уникального продукта, услуги или результата.

Классически проект для объяснения представляют в виде «проектного треугольника», но для понимания полноты проекта (в т.ч. с учетом особенностей проектов преобразований) я использую представление в виде квадрата. Уникальный результат в ограничении ресурсами (люди и материалы), временем, качеством и бюджетами (рис.1.1).

Рис. 1.1. Традиционное и расширенное представление проекта

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

Почему целесообразно выделять ресурсы отдельно? Есть ряд проектов: от опытно-исследовательских в прикладных инженерно-естественных науках до системообразующих в социально-экономических системах – и, в частности, к ним относятся трансформационные проекты / проекты преобразований. И вот тут появляется необходимость доступа к уникальным знаниям, компетенциям (часто даже на стыке дисциплин) и ресурсам, которые так просто не достать.

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

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

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

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

Хочу развенчать один миф: многие менеджеры думают, что управление программами это почти то же, что управление несколькими проектами. И многие преподаватели, инструкторы и тренера поддерживают эту веру.

Но это не так. Вспомните фразу Канта о том, что количество перерастает в качество. Пустыня Сахара и детская песочница отличаются только объемами песка. Равно как стакан воды и океан объемами воды. Но по мере увеличения количества они приобретают совершенно иных качеств.

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

Отличия между проектами и программами есть на лицо даже поверху (рис.1.2):

Рис. 1.2. Отличия между проектами и программами

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

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

И когда Вам будут говорить: «Нет разницы между управление одним и управлением несколькими связанными проектами» – вспоминайте Канта с его мыслью о том, что количество перерастает в качество. Пустыня и песочница тоже отличаются только объемами песка. Равно как отличаются только объемами H2O стакан воды и океан. Но с увеличением количества (песка или воды) приобретают совершенно иных качеств.

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

Жизненный цикл проекта

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

Если брать аналогию из биологии, то это цикл от яйца до гусеницы и бабочки.

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

В классике проектного менеджмента Вы увидите что-то такое (рис.1.3):

Рис.1.3. Классический жизненный цикл проекта

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

Например, вот так классический 4-фазный жизненный цикл может стать 6-фазным или более (рис.1.4):

Рис.1.4. Преобразование 4-фазного жизненного цикла в 6-фазный

Вокруг стадий жизненного цикла очень удобно привязывать результаты (или работы, или документы или другие моменты) которые должны быть сделаны в проекте. Результаты Вы показываете заказчику, документы держите для себя, работы предоставляете в разные службы (закупки, исполнители) и т. д. Пример «привязки» документов к фазам на рис.1.5.

Рис.1.5. «Привязка» проектных документов к фазам

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

1. Дизайна/проектирования

2. Внедрения.

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

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

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

Но есть еще один жизненный цикл, которым издавна пользуются практики (и в последней версии РМВоК его наконец-то удосужились канонизировать наравне с Waterfall) – это адаптивный жизненный цикл. Это тот самый модный Agile (гибкие методологии управления проектами).

Адаптивный жизненный цикл используется практиками уже давно (я сам с необходимостью его использования столкнулся еще в 2005 году, хотя никто из проектной команды ничего не слышал о Agile-методологиях как Scrum или Kanban). Но умело «вписывались» ими в предиктивный (последовательный) жизненный цикл ввиду его каноничности в проектном менеджменте.

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

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

В итеративном подходе в отличии от предиктивного (waterfall) мы не делаем планирование вначале, а осуществляем планирование в течение всего проекта. Мы начинаем что-то делать – и если вдруг что-либо сделали не так или поменялась ситуация – мы приводим все в соответствие.