non progredi regredi est
Проектное управление:
Do & Don't
Менеджмент-контент Марины Корсаковой
www.marinakorsakova.ru
Внедрение проектного управления в компании - это сложно. Объёмно, долго, глубоко. А как иначе, речь ведь не об отдельном навыке - о целом "институте", то есть, совокупности правил, образа мыслей, разрешенных и запрещенных действий, способов реагировать на стимулы... ох.

Но есть и хорошая новость: восемьдесят процентов ваших fuck-up'ов обусловлено двадцатью процентами ошибок, которые вы совершаете. О них и поговорим. Сумеете избежать их - справитесь лучше других.
ОШИБКА № 1: ДЕЛАТЬ ВСЁ
ПО PMBOK
Стремление припасть к первоисточнику знаний можно только приветствовать. Отправили своих специалистов учиться и сертифицироваться на PMP? Бог вам судья, - то есть, я хочу сказать, правильно сделали.

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

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

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

Так отправлять ли учиться "правильному Project Management" вашего будущего корпоративного "внедренца"? Обязательно.

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

ОШИБКА № 2:
ПРЕНЕБРЕГАТЬ
ГИБРИДАМИ
...Как там было, у классиков? "Бриан - это голова!.." Так вот, "водопад" - это голова! И agile - это "голова"! А, проще говоря, у любой философии-методологии проектного управления есть свои сильные стороны.

На своих тренингах по проектному управлению я провожу очень простое упражнение: fight!! А ну, кто за каскадное проектное управление, бросьте в этих гибких негодяев каким-нибудь... аргументом! А вы теперь им навстречу - пли!! И, знаете что? Обоснований невероятной полезности и того и другого подхода у обеих сторон находится предостаточно!

Потому что это правда.

Чувствительность к изменениям, которую дает итеративность - это хорошо. Низкая "цена за вход", которую дает большое количество шаблонов - это прекрасно.
А есть ли вообще в мире хотя бы одно, более или менее сложное явление, которое не представляло бы собой гибрид? Было бы в чистом виде полярным? Я так не думаю.
...И уж точно, скажу вам, не таковы эффективные корпоративные проектные стандарты. "Смотри пункт первый" - "форма" организационного "лица" у всех компаний неодинаковая. Значит, и микс прописанности, нечеткости, последованности, параллельности, письменной и устной коммуникации, формальных и неформальных процедур управления для каждой компании подходит разный.

Если в ваш корпоративный штаб внедрения проектного управления пробрались экстремисты, которые по любому поводу кричат "Ноги вашего agile'а здесь не будет!" или "Бюрократию разводить вам не дадим!", то их под каким-то предлогом нужно из штаба вывести (или вынести). Потому что в целом гибкий стиль может в каком-то месте удачно подклеиваться самой что ни на есть классической "водопадной" матрицей, а в целом жесткий стандарт может в каком-то месте обеспечивать дополнительную юзабилити, заимствуя такие agile-инструменты как "диаграмма сгорания задач" или "проектный покер".

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

Fight хорош только как тренинговое упражнение.
ОШИБКА № 3: НЕ УДЕЛЯТЬ ДОСТАТОЧНОГО
ВНИМАНИЯ
НАЧАЛУ И КОНЦУ
Сейчас скажу страшную в своей простоте вещь. БОльшая часть ваших проблем появляется из-за того, что вы плохо начинаете. А никогда не решаются эти проблемы потом из-за того, что вы плохо заканчиваете.

Я очень люблю один, периодически повторяющийся момент на тренингах - кого-то из участников вдруг "инсайтит", и он произносит: "А мы ведь даже не замечаем, когда у нас в компании появляется ПРОЕКТ!!"

...Конечно.

Первое, что должно случиться с проектом в начале - это вот этот всеобщий "чпок" в голове, что он - ЕСТЬ. Что он - ПРОЕКТ. Что он получает некий универсальный идентификатор - название, номер, паспорт. Что информация о его существовании/содержании, регистрационная запись, отправляется в некий реестр.

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

Как это могло бы выглядеть практически?

Договоренность номер один: как мы начинаем

  • Создаем "Паспорт проекта" (3-7 характеристик);
  • Обсуждаем его в составе заявленной в паспорте команды управления проектом и вносим коррекцию;
  • Вносим проект в реестр.

Договоренность номер два: как мы заканчиваем

  • Обсуждаем проект в составе команды управления проектом;
  • Записываем уроки; договариваемся, что в работе, исходя из полученных уроков, изменим; договариваемся, где их (уроки), чтобы было легко к ним вернуться, храним.

Всё. Попробуйте полгода соблюдать эти две договоренности, и вы окажетесь в другом мире. Четкие процедуры начала и конца как будто сами по себе уже немало оздоровляют то, что происходит в середине.
ОШИБКА № 4: ВООБЩЕ-ТО ИХ ЗДЕСЬ И ЕСТЬ ЧЕТЫРЕ
Но, допустим, вы всё сделали правильно. Не стали заниматься бездумным копированием, написали уникальный стандарт, заимствовали лучшие инструменты "каскада", agile'а, а также эльфов и друидов, сосредоточились на процедурах начала и конца.

А есть что-то, что можно сделать еще лучше/от чего можно защититься еще надежнее?

Да.

Вот вам еще несколько хороших советов.
Не пожалейте времени и оргресурса на то, чтобы "продать" новый институт исполнителям.
Рабочие сессии с вовлечением всех и вся, круглые столы, конкурсы, банк лучших идей: всё, что способствует сращиванию людей с новым институтом, - это НАДО. Иногда хорошая вещь долго пробивает себе дорогу и теряет тонус только потому, что воспринимается как навязанная извне, чужая. Спрашивайте людей. Тем более, что в таких вещах они обычно говорят много полезного.
Не стремитесь с самого начала сделать структуру ведения проектов сложной.
Сложная структура - сложности в обслуживании. Сложности в обслуживании - плохо получается. Плохо получается - демотивирует и не хочется. Лучше начать с самой простой структуры (как я вам привела в примере, всего-то начало и конец), а потом, с накоплением навыков, усложнять. "Хорошо и не сделано" - это никому не надо.
Поговорите начистоту с первым лицом или лицами.
Многие из них, к сожалению, воспринимают любые системные управленческие институты как "звонок на урок - для вас, звонок с урока - для учителя". В смысле, "проектный стандарт, коллеги, описывает ваши обязанности" - да нет, коллега, проектный стандарт описывает и ваши права. Если проектный стандарт учит, например, моделировать ход проекта в плане управления по вехам, но все знают, что у директора лампочка в голове будет загораться в случайные дни, и именно в них будет происходить вся головомойка, то, понятно, почему авторитет проектного стандарта несколько девальвируется, правда?

Запомните (и это не только проектного менеджмента касается): любой управленческий институт - дорога с двухсторонним движением. Обе стороны могут вносит свои предложения по коррекции правил движения, но нарушать их "в ручном порядке" значит... возвращать компанию к управлению в ручном порядке. А ведь именно от этого хотелось уйти.
Проектируйте не узко.
Иногда компании легко понять, что проектным правилам должна подчиняться какие-то техническая часть, ТЗ, или какая-то продуктовая часть - материальная, но сложнее уложить в голове идею, что любой проект организационных изменений/процессных инноваций - тоже... проект. Не попадайтесь!
Например, проект "Внедрение CRM" проектируется не только в части IT-решения, но и в части подготовки общественного мнения, обучения и т.д.
ОШИБКА № 5: НЕ УПРАВЛЯТЬ ЗРЕЛОСТЬЮ
И последнее: вы собираетесь заняться внедрением проектного управления? Отлично. Начиная с этого момента, разметьте в своем еженедельнике, в матрице своих регулярных операционных процессов, - уверена, у вас есть такая, - ежемесячный или ежеквартальный (а лучше и то, и другое) кружок управления качеством ведения проектов.

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

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

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

Удачи вам во всем!
ОБЪЯВЛЕНИЕ. В ноябре-2019 я проведу вебинары по темам "Project Management Booster", "Проведи стратсессию, создай стратегию" и "Из специалистов - в менеджеры!", буду рада видеть вас в числе участников. Подробнее о других моих программах - здесь.