Бесплатный фрагмент - Трансформация: особенности управления проектами преобразований

__________

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

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

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

На сегодня интенсивность изменений настолько стремительна, что одномоментно меняются не только страны и рынки, а и перестраиваются целые отрасли. Пачками появляются новые и исчезают старые компании. Многие уходят с рынка. Некоторые выживают. Из тех некоторых выживших только 1—3 компании процветают…

Изменения — это неотъемлемая часть современных социально-экономических систем. Изменения нельзя просто переждать: они только накапливаются как снежный ком. Поэтому эффективное управление организационными преобразованиями в настоящее время становится одним из важнейших факторов успеха.

Но просто объявить идею преобразования («Работать эффективнее», «Быть лучше», «Зарабатывать больше» и т.д.), выделить строчкой в Excel (или корпоративной ERP) бюджет и ресурсы и ожидать, что все само исполнится — как минимум наивно.

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

И основным способом эффективно воплотить изменения / преобразования / трансформации в жизнь является проектная деятельность.

Но ни в коем случае проектная деятельность не «таблетка от всех болезней»: как только проект закончен — его результат (процесс, услуга, оборудование и т.д.) начинает жить внутри процессов организации. Потому нельзя ставить вопрос «Проекты ИЛИ процессы?». Любой организации или обществу для долгосрочного успеха важно И справиться с требованиями текущей реальности и условий, И не упустить будущие возможности и адекватно ответить вызовы. Своевременные успешные проекты преобразований позволяют организации оставаться на плаву.

Автор данной книги — управленческий консультант с 20-летним опытом ведения проектов для крупнейших компаний по всему миру. Ведущий русскоязычный инструктор по инструментам ведения бизнеса и менеджменту на международной платформе UDEMY (https://www.udemy.com/user/nikita-sergeev-2/).

В основу книги положены самые современные материалы, которые использовались в разных проектах и читались на специализированных МВА программах.

Отметим, что в книгу вошли в том числе и материалы специализированного русскоязычного курса по управлению проектами преобразований на международной платформе онлайн образования UDEMY, который внесен в премиум-подборку корпоративных тренингов UDEMY for Business.

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

От автора

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

Тем не менее, у некоторых еще остается мнение, что это какая-то совсем новая дисциплина. Но на самом деле наука управлять проектами была развита у нас в России и СССР. Большинству «современных» методов проектного управления (сетевые диаграммы, критические пути, календарные планы и т.д.) обучали в Союзе даже студентов 1—2 курса дисциплин управления производственными процессами.

Найдите в Интернет видео ВУЗФИЛЬМа 1970-х годов, и поищите отличия в демонстрируемых там методах с современными (кроме того, что обходились на то время без компьютеров).

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

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

Некоторые студенты старших курсов и слушатели МВА скептически относятся к «советскому наследию». Причем искреннее считают, что масштабнейшие «стройки века», станция «МИР», космические корабли «Союз», полет Юрия Алексеевича в космос, ядерная программа, бурное социально-техническое и социально-экономическое развитие… это благодаря героизму и гению отдельных личностей, а не профессионализму и проектному управлению.

Но в книге не об истории проектного менеджмента. И не о сравнении русского и западного подходов.

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

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

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

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

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

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

Естественно, инструменты проектного управления применимы и работают для всех типов проектов. Но для трансформационных проектов есть отдельные критические вещи. Более того, для ряда, казалось бы, классических проектных моментов, в трансформационных проектах они имеют свои особенности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://www.udemy.com/course/transformational_project_management/?couponCode=LECTOR-80

А если Вы просто взяли полистать эту книгу любопытства ради, но управление проектами не из области Вашего интереса — то книга все-равно попала в Ваши руки не зря. Наверняка у Вас есть коллеги, друзья или знакомые, которым она будет полезной — поделитесь с ними информацией об этой книге.

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

Мир ускоряется, становится цифровым, постоянно меняется. Начиная с 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.2):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принципиальное отличие и значение этого подхода от Waterfall в том, что мы:

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

· Во-вторых, постоянно контролируем нет ли изменений и делаем при необходимости перепланировку проекта

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

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

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

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

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

Проектная документация

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

Даже тот же РМВoК описывает требования и содержание документов, но не дает шаблонов.

Каждая организация имеет свои стандарты и требования. Если их нет — то менеджер проекта волен руководствоваться здоровой логикой и целесообразностью документации. Вообще задайте в поисковике «шаблоны проектных документов» — и выбирайте в свободном доступе любой формат и варианты. Но Вы все равно будете адаптировать их под себя, организацию или проект.

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

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

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

Далее в нескольких последующих пунктах прицельно пройдемся по каждому из этих документов.

Устав проекта

Устав проекта — это документ, который обычно готовит руководитель проекта после получения вводных о проекте. Это будет Вашей Альфа и Омегой весь проект. Это то, о чем Вы договариваетесь «на берегу».

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

В уставе обычно включаются (рис.1.6)

· Предпосылки (бэкграунд, исходная ситуация, проблематика, которая привела к инициации проекта)

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

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

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

· Ключевые требования и метрики (если такие есть), по которым будут приниматься результаты проекта

· Любые предположения, ограничения и риски. Тут остановлюсь поподробнее, потому что из моего опыта даже опытные менеджеры проектов опускают эти моменты (рис. 1.7).

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

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

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

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

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

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

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

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

И вообще вопрос детализации устава очень часто возникает ку слушателей: нет стандартов к объему устава, зависит от проекта и компании, от длительности и прошлого опыта сотрудничества с организацией…

Устав вообще может выглядеть брифом на 1 страничку (рис.1.8).

Но в любом случае Вы должны ощущать достаточность детализации для управления.

Содержание проекта

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

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

На самом деле в реальности у Вас никогда не получится сделать идеальное содержание с первого раза — оно будет потом уточняться и дополняться (даже видоизменяться) по ходу проекта.

В содержании обычно находится 3 детализированных пункта устава проекта (рис.1.9):

· Описание ожидаемых результатов

· Критерии приемки (требования и метрики), по которым будут принимать результаты проекта

· Границы проекта — и что входит, и обязательно что точно ни при каких раскладах в проект не входит. Второе даже важнее чем первое.

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

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

Более того, если Вы опишите детальное содержание — Вам будет не только проще достичь результата (ибо он станет понятнее). Плюс Вы сразу из него получите перечень работ для подготовки плана проекта, как указано на рис.1.9.

План проекта

Вроде простая штука (ну кто же не сталкивался с календарным планом или не видел диаграмму Ганта даже не будучи менеджером проекта?), но пару слов о нем скажу.

План проекта — это главный документ, по которому Вы будете управлять проектом и вокруг которого будете применять различные методы для «разруливания» его отклонений.

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

В плане все работы выписываются и связываются между собой так, чтобы было понятна (рис.1.10):

а) Их последовательность (что может делать параллельно/ одновременно, а что только после завершения какой-то работы или нескольких работ)

б) Необходимые ресурсы (навыки/компетенции (неважно сотрудников организации или внешних поставщиков), материалы, оборудование, деньги…)

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

Если это все было сделано в специализированном ПО (например, MS Project или Primavera), то уже задав начало проекта — Вы получите сразу и календарный план с датами, и план финансирования/стоимости проекта, и ресурсы и т. д.

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

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

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

(Не) проектная документация: бизнес-кейс

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

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

Почему-то внутри компаний принято на все крупные инвестиционные проекты (даже простые по своей природе, например, когда 99% огромного бюджета составляют материалы и стандартное оборудование) готовить и рьяно обсуждать бизнес-кейсы. А на порядок сложнее проекты, но не выражающиеся прямо в денежных величинах — никто «не заморачивается»…

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

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

Несомненно, для инициации проекта бизнес-кейс, конечно, штука незаменимая, а вроде как для управления проектом уже и не нужна….

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

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

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

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

Интересный документ, о котором стоит знать…

Последняя версия РМВоК в сравнении с предыдущими намного больше внимания уделила бизнес-вопросам проектного управления (предыдущие более технически и процессно-ориентированы).

И помимо отдельного прицельного фокуса на бизнес-кейсе в РМВоК ввели понятие нового документа — «ПЛАН УПРАВЛЕНИЯ ВЫГОДАМИ ПРОЕКТА».

Аргументация необходимости этого документа в том, что после завершения проекта возникают ситуации, когда полученные результаты не используются или используются не так, как задумано. Соответственно компания не имеет выгод, ради достижения которых запустили и реализовали проект. При этом высшее руководство не знает об этом, т.к. после завершения проекта бывает о истинном назначении результатов все забывают, в том числе и Спонсор, и Заказчик. А бывает забывают (или видоизменяют) специально…

Как с этим явлением борются из того, что я встречал на практике. Здесь мне нравится метод и подход некоторых системных консалтинговых компаний в Москве (правда в основном их просят клиенты-заказчики уровня набсоветов или акционеры — от них «ноги растут»). Они предлагают в качестве услуги не только дизайн проекта, а и периодические аудиты внедрения и использования результатов проекта (Внедрили ли то, что согласовали или по ходу внедрения «нагенерировали отсебятину»? Используются\функционируют ли результаты проекта как предписано проектом?).

Я сам участвовал в нескольких таких пост-проектных аудитах: в одной компании внедрили электронный документооборот — а по факту функционировал параллельно бумажный; в другой должны были передать на аутсорсинг ночные развозки операторов Call Center автобусами по домам — оказалось никто даже не провел эту работу; в третьей — должны были отстроить сегментно-ориентированную структуру, а по факту получился «компромиссный гибрид», созданный под отдельных людей…

PBMоK же рекомендует для решения проблемы использования результатов проекта «по назначению и как предписано проектом» создавать «План управления выгодами проекта».

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

Это документ, который:

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

· связь между проектом и целями организации;

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

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

А для консультантов наличие такого документа может стать подспорьем для: (а) проведения пост-проектных аудитов; (б) четкого ответа на вопрос-претензию заказчика «Ну мы же сделали проект с Вами — почему не работает?»

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

Заинтересованные стороны — это широкий круг лиц, которые заинтересованы в проекте или кого проект просто затрагивает: от команды проекта с подрядчиками — и до сотрудников/менеджеров тех предприятий или подразделений, кого напрямую коснутся результаты проекта или которые выделяют ресурсы (особенно подчинённых) для реализации проекта (рис.1.11).

В трансформационных проектах важно выделять членов высшего руководства компании (ТОР-менеджмент) — особенно тех, кого изменения могут коснуться так, что после преобразования они потеряют власть, разделят с кем-то полномочия, уменьшатся их ресурсы, бюджеты и т. д.

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

Особенно часто внутри организации встречается конфликт на уровне руководитель корпоративного РМО (офиса по управлению проектами) и менеджер проекта из какой-то функции, который ему по ряду причин не нравится.

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

В одной крупной промышленной компании на трансформационном комитете обсуждали статус ТОР-10 трансформационных проектов.

Был проект, который дважды переносили, трех менеджеров сменили — а он никак не двигался. Спросили есть ли вообще по моему мнению кто-то внутри компании, кто мог бы его сделать? Зная компанию, я назвал одно ФИО.

И тут вскочила директор по персоналу с репликой «Он не может быть менеджером проектом». На вопрос «Почему?» Ответ: «Харизмы ему не хватает, говорит все время сложно — как он выступать будет?».

Но невзирая на ее реплику, СЕО с операционным директором прислушались к ФИО — и назначили этого человека. Под его руководством проект таки был успешно реализован. Правда, как мне потом рассказывали, HRD настолько «прониклась проектом», как будто она лично за него отвечала. В т.ч. принудила одного из своих HR-менеджеров быть в курсе «что творится на этом проекте и как он там управляет». А на каждом комитете пыталась придраться к любым мелочам. Правда длилось это недолго: когда на очередном комитете она придралась к очевидно выдающемуся прогрессу и результату с формулировкой «не, ну вы посмотрите: выполнение задачи на целых 2 дня задержали…», операционный директор и СЕО не выдержали и сказали ей сфокусироваться на вакансиях и оформлении бумаги «и вот там и считай сроки закрытия вакансий и оформления отпусков в днях».

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

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

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

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

Из всех заинтересованных сторон отдельно выделю сильно влиятельных: Спонсора, Заказчика и Управляющий комитет (или как еще его называют «трансформационный комитет», когда речь о проектах преобразований) — рис.1.13.

· Спонсор — это покровитель проекта из высоких эшелонов власти организации. Именно его в первую очередь интересует бизнес-эффект и успех проекта. Это «тяжелая артиллерия», которая решает всю проблематику проекта. Проблематику не в части управления проектом (чтобы сделать вовремя и эффективно — за это отвечает менеджер проекта), а в части всех организационных проблем и особенно «поставить на место» влиятельных врагов проекта или его менеджера.

· Заказчик — это тот, кто будет пользоваться результатами проекта. Он определяет (с него надо, по сути, истребовать) результат проекта, критерии / метрики, условия приемки — именно он скажет «ок» или «не ок» результат проекта.

Зачастую Заказчиком и Спонсором трансформационных проектов является одно лицо. Но если роли разделены, то Заказчик скорее всего не будет вдаваться в подробности проекта — будет довольствоваться сухими отчетными данными, чтобы понимать сроки «пришествия» результатов проекта.

· Управляющий комитет (или часто в бизнесе говорят, где Стеринг, где Стиринг Комитет от англ. Steering Committee) — это самый главный орган управления проектом. Да именно он, а не Спонсор-Заказчик или менеджер проекта.

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

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

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

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

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

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

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

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

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

Рассматривайте отчёт на управляющем комитете как возможности порешать проектные вопросы (только не забываем, что «вываливать» комитету нужно не все вопросы, а только те, которые не может решить ни менеджер, ни Спонсор проекта).

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

И всегда готовьтесь к управляющему комитету (рис.1.15).

На этом главу закончим. В ней мы рассмотрели заинтересованных сторон и прошлись по трем самым влиятельным сторонам.

КЕЙС: Побеждая влиятельных людей

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

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

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

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

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

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

Причем не рекомендую Вам самим «лезть на рожон», будучи внутренним проектным менеджером. Вам может быть намного лучше, если проект поставят «на холд» (приостановят) или вообще отменят, чем «пасть в борьбе за правое дело». Тем более, это работа Спонсора и Заказчика — ломать внутриорганизационные барьеры, а также «бороть ветряные мельницы» высших эшелонов власти.

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

Теперь расскажу сам кейс: ИСТОРИЮ ОДНОЙ ПОБЕДЫ... В холдинге запустили проект преобразований телекоммуникационного подразделения (выделенное предприятие связи, обслуживающее другие предприятия холдинга).

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

И у финансового директора с момента прихода в компанию было видение «слить» это предприятие с подчиненным ему ИТ-департаментом.

Но операционный директор видел трансформацию по-другому — и запустил проект с изменения процессов и технологий, а также использования аутсорсинга. Т.е., не подразумевающий просто «слияния».

Менеджер проекта (девушка-технарь, 33 лет) взялась за дело и начала двигать проект. Чувствуя покровительство Спонсора, она двигала проект, невзирая на все нападки. Она умело и профессионально «ставила на место». В частности, демонстрировала некомпетентность финдира в технических вопросах и по проекту в целом. А финдир, как назло, все больше и больше пытался влезть и разобраться — но получалось у нее это из ряда вон плохо.

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

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

Но через 7 месяцев у Спонсор принял предложение о работе в другой компании в другой стране. И после его ухода менеджер проекта не могла работать нормально: и финансовый, и HR директор «рьяно взялись» как за нее, так и ее подразделение. Грамотно, монотонно, рутинно создавая ей ежедневные проблемы на ровном месте.

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

А после ее ухода финдир в конце концов все равно получила свое — предприятие связи вошло в состав подчиненного ей ИТ-департамента. Но это уже совсем другая история и не о проектном менеджменте.

Программное обеспечение для управления проектами

Многие уповают на важность программного обеспечения. Но программы — это просто инструментарий. С ним Вы можете более или менее эффективно управлять проектом. Т.е., какую программу использовать это одно из двух:

А) корпоративное требование;

Б) вопрос Ваших персональных профессиональных предпочтений.

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

Я, например начинал с Primavera и через какое-то время мне легко «зашел» MS Project Office (при разработке ПО для внутреннего CRM одного из банков). С некоторыми заказчиками работал также во Wrike в онлайне — таковы были условия проекта.

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

Для реального управления трансформационными проектами непосредственно менеджерам проектов в большинстве случаев достаточно мощностей Excel и Power Point — ведь не хранилище ядерных отходов, ядерную АЭС или ультрасовременную подлодку собираем…

Главное из PMBoK за 5 минут

Я ранее уже упоминал РМВоК и говорил, что это не методология — это свод знаний (типа справочник) об управлении проектами. А также рекомендовал обязательно его почитать.

На самом деле в нем нет ничего сложного, а есть важные два блока (рис.1.16):

· 5 групп (категорий) процессов в проектном менеджменте

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

Вот эти два блока мы бегло и рассмотрим. Я сделаю фокус на 6 версию РМВоК (последнюю, которую я читал на момент написания данной книги).

Начнем с категорий процессов. РМВоК рассматривается 5 групп (категорий) проектных процессов, которые и на уровне здравого смысла используются в менеджменте как таковом.

Инициация — это все о начале проекта. От подготовки Устава до определения заинтересованных сторон. В трансформационных проектах я персонально еще отношу к инициации формирование проектной команды (как минимум требований к ней), но РМВоК не об этом.

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

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

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

Завершение — сдача-приемка результата, закрытие проекта и всех работ и контрактов по нему.

Тут вроде все просто. Главное не подумайте, что процессы = фазы жизненного цикла проекта. Это ПРОЦЕССЫ и они неизменны в отличии от фаз проекта, которые можно определять под каждый конкретный проект.

Теперь об областях знаний.

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

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

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

Управление качеством — процессы обеспечения и контроля качества в проекте.

Управление ресурсами — при чем в последней нотации PMBoK именно управление ресурсами: всеми — от физических, людских, оборудования, материалов, активов и т.д.. В отличии от предыдущих версий РМВоК, где фокус этого раздела был на людских ресурсах — от планирования количества и качества персонала, подбора и развития — и до ежедневного управления командой проекта. Это изменение реально толковое — по факту мы давно уже с коллегами обсуждали, что реально в проектах менеджер управляет всеми ресурсами.

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

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

Управление закупками проекта — планирование закупок, осуществление и контроль закупок.

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

Отдельную оговорку сделаю о международных проектах (когда проекты по разным временным поясам + межкультурные + межязыковой барьер). Вспоминая участие в проектах в ОАЕ и Норвегии, могу сказать, что сложность коммуникации может создавать много проблем на ровном месте. С языковым барьером думаю понятно (чего только необходимость перевода документов и трактований/разъяснений стоит), а в культурных особенностях запоминаются такие вещи как:

· дистанция власти — на Востоке очень боятся наделенных властными полномочиями. Боятся слово сказать вразрез. На Западе — нормально так пройдутся, покритикуют, повозмущаются если что.

· Восприятие полов — ну не привыкли на Востоке к женщинам как главным или даже равноправным. И это в проектах остро чувствуется.

· Даже такие вещи как праздники и обычаи. Например, у нас майские праздники и с Днем Победы — это святое, а для норвегов — будние рабочие дни и им ничего не стоило назначить ключевое совещание и групповую работу по проекту с 1 по 10 мая — ребята из Россия и других стран СНГ были крайне возмущены.

Управление заинтересованными сторонами (как их еще называют с англ. стейкхолдерами) — на них я уже отдельно останавливался. А данная группа процессов в РМВоК рассказывает, как определить, оценить влияние, вовлечь и отслеживать вовлеченность заинтересованных сторон в проекте.

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

Что мне кажется странным в РМВоК — что нет такой области знаний как управление изменениями. Но я не об управлении изменениями по сути проекта (внесение изменений по характеристикам, описанию результата, целям, бюджетам, срокам и т.п.), а управления изменениями, которые вызывает проект и его результаты. Речь о тех самых проектах преобразований/трансформаций социально-экономической системы (компании, государства, общества и т.д.). Мне в любом случае кажется, что эта область в современном мире полезна для любого проектного менеджера — ведь серьезные даже инженерные\технические проекты уже давно не живут в рафинированной собственной среде, а затрагивают социально-экономические системы в комплексе.

На момент публикации данной книги готовится новая 7 версия РМВоК. Отлично то, что в ней PMI вплотную подошел к тому, чтобы «накрыть» все процессы и области знаний 12 принципами.

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

Но собрать воедино опыт многих практикующих менеджеров проектов — это достойная цели. И 12 принципов PMBoK дали возможность прокомментировать международному РМ-сообществу. Я также их внимательно перечитал и предоставил проектной группе PMI, разрабатывающей эти принципы, все свои замечания и комментарии (не забыв упомянуть и об управлении изменениями). Посмотрим, что из этого получится.

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

То, чего нет в стандартах, но полезно в проектах преобразований

Многие сертифицированные и опытные менеджеры могут подумать, что автор окончательно ополоумел, раз о таком пишет — но в преобразовании социально-экономической реальности этот момент здорово помогает: Название/Имя проекта.

В технической реальности привыкли называть проекты «жесткими цифровыми идентификаторами» (изделие№3527). Или здоровенным названием, включающим и цель, и описание, и заказчика, и пользователя, и адрес прописки проекта («Проект постройки современного луна-парка на 3 Га между улицей Казачьей и промзоной», «Проектирование эффективной системы закачки рабочего агента в пласт для нужд цеха добычи сырья» или «Проект разработки ИТ-системы внутреннего CRM для улучшения взаимодействия и повышения клиенториентированности между департаментами Банка»).

Но в социально-экономической реальности название проекта имеет весомое значение.

Во-первых, люди любят красивые названия.

Персонально я, в том числе как бывший военный, поработавший в свое время с «секретками», стараюсь использовать:

· или ключевое слово из проекта (например, «Грейдинг», «OpMod» и т.д.)

· или запоминающуюся звучную аббревиатуру (например, TLDP или IRMT, iCRM). К примеру, знаете ли Вы, что у нас в СССР предлагалось еще Китовым внедрить единую госсеть вычислительных центров, а его последователем Глушковым — общегосударственную автоматизированную систему от госплана до цеха? Запомнили эти оба проекта с первого раза? А проектное название первого было ЕГСВЦ, а второго ОГАС… Думаю как минимум название ОГАС большинство слушателей не забудет.

· или какое-то интересно-заманчивое название (например «Скрепка», «Реактор», «Энштейн»). Кстати, проект ЕГСВЦ имел название «Красная книга».

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

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

Например, я когда-то реализовал для одной транснациональной компании проект TLDP — и когда его результаты перешли в процесс Performance Management, люди еще года три его TLDP называли. Но важно не то что его долго еще так называли — важно то, что при управлении проектом название уменьшает необходимость лишней коммуникации и объяснений «а о каком именно проекте идет речь?» — все все сразу схватывают.

Вот такая-вот нестандартная штука (имя / название проекта), но очень полезная для проектов преобразования социально-экономических систем.

Методологии управления проектами

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

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

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

И еще замечу, что упомянутый в предыдущей главе РМВоК (как и любой стандарт, справочник или каталог) это не методология — это свод знаний об управлении проектами.

А методологий в практике на сегодня выделяют две (если привязаться к РМВоК, то в их основе лежат уже упоминаемые ранее предиктивный и адаптивный жизненные циклы):

· Waterfall (каскад, водопад)

· Agile (гибкий, проворный, адаптивный)

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

WATERFALL — это последовательно-каскадная методология. Она предполагает, что все этапы проекта осуществляются последовательно, четко следуя плану.

Описание — Планирование — Разработка -Внедрение — и т.д….. — как изображено на рис. 1.17.

Закончив один этап — переходите ко второму, т.е. планомерно, от этапа к этапу двигаясь к результату проекта.

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

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

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

Особенно это критично для социально-экономических систем, когда и заказчик может за период реализации «вырасти» и понять, что ему не это нужно; и социальная часть изменится; или экономически станет нерентабельным…

Приведу простенький изменения среды. После M&A (слияние и поглощение) в одной из стран СНГ 5 юрлиц стали единой компанией. Но поскольку антимонопольный комитет не дал разрешение на слияние — они де-юре остались 5 юрлицами, но де-факто уже стали единой компанией с единым менеджментом.

Сотрудники, доходы и бюджеты оставались числиться во всех 5 юрлицах в своих учетных системах: причем в конкретно взятом отделе руководитель отдела с 3 подчиненными мог быть в одном юрлице, еще 2 подчиненных в другом, еще один в третьем и т. д. И сводить людей, бюджеты, доходы по такой структуре в детализированном виде естественно было невозможно.

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

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

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

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

Итерации могут касаться этапов — тогда имеем дело с итеративным жизненным циклом (рис.1.18).

Или они могут касаться продукта\результата проекта, который делается «по-кусочку» (инкремент за инкрементом) — тогда имеем дело с инкрементным жизненным циклом (рис.1.19).

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

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

На практике обычно эти оба цикла используются вместе (я уже об этом писал ранее в главе о жизненном цикле проекта), поэтому в среде практиков можно просто говорить об адаптивном жизненном цикле (Agile-методологии) как таковом.

Очевидное преимущество Agile — это учет изменений как требований клиента, так и среды. Т.е., Agile наиболее подходит для проектов с нечеткими, вариативными, высоконеопределенными требованиями и\или средой.

С моей т.з. лучше всего эту Agile-методологию (адаптивный цикл) в ее практическом виде олицетворяет SCRUM (СКРАМ) — визуализация на рис.1.19.1.

В Скраме:

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

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

— Ежедневный контроль с отчетностью перед всей командой;

— При реализации каждого спринта готовится свой результат / инкремент (или доращивается функциональность);

— Завершается спринт демонстрацией заказчику. И если все Ок, то запускается следующий спринт (со своим инкрементом\результатом). Если инкремент не удовлетворил Заказчика, то происходит итерация этапа (спринта) для доработки инкремента.

Многие считают, что итерационные гибкие методологии (Agile) что-то появившееся совсем недавно и в недрах ИТ. На самом деле все методы (да и вся методология) применялись давно на практике, просто не назывались такими красивыми словами. И начинали их применять далеко не в ИТ среде.

Я сам персонально еще в 2004 году управлял проектом, в котором 3-летка должна быть сделана за 6 месяцев. Необходимо было на одном локальном активе международного телекомоператора развернуть процесс Performance Management. Так вот проект был реализован именно итерационными циклами (да и исходя из поставленных задач его вообще по-другому сделать было нереально).

Хотя никто из участников проекта тогда не слышал и не знал ничего про Agile — просто посидели подумали и поняли, что по-другому не сделать (ну и получить вознаграждение трехлетнее через полгода уж очень хотелось). Сейчас я с высоты прожитых лет понимаю, как нам тогда конечно повезло, что был «зеленый свет» на «внедрение любой ценой» — иначе плыли бы мы Waterfall’ом перенося сроки сдачи проекта из года в год в течение 3 лет….

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

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

Выбор методологии

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

Я лично использую «трехмерку» с такими параметрами (рис.1.20), крайние значения которых (окончания стрелок) — высочайший уровень неопределенности.

Но многим (особенно новичкам, для которых предназначен раздел) «не заходят» объяснения с трехмерными системами координат, потому для упрощения разобьем на «двумерки» (рис.1.21).

Вот по этим матрицам и находите наивероятнее подходящую под Ваш проект.

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

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

Краткие итоги раздела

Итак, в текущем разделе мы:

· Затронули всех волнующий момент: сертификации по проектному управлению

· Прошлись по основным понятиям — проект, программа, жизненный цикл и фазы проекта

· Затронули такую сакрально-секретную штуку как проектная документация (за которой все охотятся и спрашивают друг у друга «а покажи как у тебя?», «а вышли шаблончик/примерчик/образец»…) с фокусом на устав, описание содержания, план проекта + бизнес-кейс. Ну и о таком интересном документе как «План управления выгодами» не забыли

· Остановились на заинтересованных сторонах проекта, выделили наиболее влиятельные

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

· За 5 минут пробежались по 5 группам (категориям) процессов и основным областям знаний стандарта РМВоК.

· Узнали, что крупно есть 2 подхода /методологии / модели (их вот так по-разному Вы услышите в бизнес-среде) в управлении проектами: Waterfall и Agile. Поняли, как определить наиболее подходящую для Вашего проекта

По большому счету весь этот раздел предназначался для новичков. Но опытным менеджерам проектов возможно также послужил хорошим повтором.

Отправные точки особенностей управления трансформационными проектами в бизнесе

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

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

В основном читатели книги будут управлять проектами по преобразованию полностью или частично такой социально-экономической системы как БИЗНЕС. Поэтому, важно разобрать что такое бизнес — какой моделью можно его представить.

Далее стоит упомянуть о предпосылках к особенностям управления проектами по преобразованиям в социально-экономических системах.

Потом немного «нырнуть» в область знания «Изменения»: поговорить об изменениях, сопротивлениям изменениям, а также их поддержке.

И наконец увязать все эти знания воедино и соединив с управлением проектами, чтобы перейти к 10 основным моментам-особенностям управления проектами преобразований.

Зачем это все? Возможно, просто прихоть «обожающего теоретизировать профессора», с его навязчивой идеей, что область знаний «Управление изменениями» необходима в стандартах управления проектами?

Сами ответите на эти и любые другие возникшие вопросы, дочитав раздел.

Бизнес- и операционная модели

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

Вот и начну с обычно широко трактуемого и часто непонятного слова «МОДЕЛЬ».

Многие из бизнеса, услышав слово «модель», говорят, что это «теоретико-философская научная муть».

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

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

На рис.2.1 в качестве объясняющего примера изображены некоторые известные модели — Солнечная система, ДНК, молекула.

Естественно, на объективную реальность (сам окружающий мир, явление, протекающие процессы и т.д.) модель никоим образом не влияет. Зато она влияет на наше понимание и отношение к этой реальности. Только модель любого объекта позволяет нам описать, измерить и спрогнозировать его поведение\развитие.

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

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

На рис.2.2 изображены 3 оси, формирующие ту самую модель Абеля, олицетворяющую бизнес.

Бизнес — это всегда:

· ЧТО Вы предлагаете (продукт \ услуга \ решение во всей красе, с 4Р и Уникальным Торговым Предложением — нацеленные на потребности \ проблемы клиента)

· КОМУ Вы предлагаете (клиенты и их сегменты, за которых Вы будете воевать с конкурентами)

· КАК и какими КОМПЕТЕНЦИЯМИ (ТЕХНОЛОГИЯ, РЕСУРСЫ…) вы то самое «что» получаете\производите.

Итого, три шкалы ЧТО, КТО и КАК формируют в модели Абеля три плоскости, которые являются КОММЕРЧЕСКОЙ, ОПЕРАЦИОННОЙ и ЭКОНОМИЧЕСКОЙ моделями любого бизнеса.

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

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

Операционная модель состоит из 4 главных элементов — Оргдизайн, Люди, Процессы и Поставщики. Именно они лежат в сердце операционной деятельности любого бизнеса. Если кто сейчас задался вопросом «А как же технологии?» — то они внутри элемента «Процессы».

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

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

Так, например, если вернуться ко всем известной модели Солнечной системы, то из школьной программы наверняка помните разницу моделей Птолемея (каноническую для святой инквизиции) и Коперника (той за которую Дж. Бруно сожгли на костре, а Галилея инквизиция заставила отречься от своего учения)? Элементы в их моделях устройства Солнечной системы были одинаковыми — но компоненты и взаимосвязи совершенно отличались…

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

Естественно, эти 4 категории (элементы) создающие операционную модель, существуют в неразрывной связи с внешней рыночной и внутренней организационной средой (рис.2.4).

Внешняя среда отражается в таком организационном порождении как СТРАТЕГИЯ.

Внутренняя среда имеет свои два порождения «Корпоративная культура» и «Системы управления». К системам управление относятся, например, целеполагание, планирование, управление вознаграждением, управление информацией и коммуникациями и т.д..

И эти 3 не-элемента операционной модели (стратегия, корпкультура и системы управления) имеют на нее очень существенное влияние.

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

И вот когда мы определили, что именно мы хотим менять \ преобразовывать (какой элемент или компонент), разворачивается набор проектов и программ по преобразованию операционной модели (рис.2.5).