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

Но есть и хорошая новость: восемьдесят процентов ваших fuck-up'ов обусловлено двадцатью процентами ошибок, которые вы совершаете. О них и поговорим. Сумеете избежать их - справитесь лучше других.

Стремление припасть к первоисточнику знаний можно только приветствовать. Отправили своих специалистов учиться и сертифицироваться на PMP? Бог вам судья, - то есть, я хочу сказать, правильно сделали.

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

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

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

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

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

...Как там было, у классиков? "Бриан - это голова!.." Так вот, "водопад" - это голова! И agile - это "голова"! А, проще говоря, у любой философии-методологии проектного управления есть свои сильные стороны.

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

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

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

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

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

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

Fight хорош только как тренинговое упражнение.

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

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

...Конечно.

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

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

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

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

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

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

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

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

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

Но, допустим, вы всё сделали правильно. Не стали заниматься бездумным копированием, написали уникальный стандарт, заимствовали лучшие инструменты "каскада", agile'а, а также эльфов и друидов, сосредоточились на процедурах начала и конца.

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

Да.

Вот вам еще несколько хороших советов.

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

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

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

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

Удачи вам во всем!