«Систематическая ошибка выжившего» или как избежать основных ошибок PM

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

В нашей статье мы хотим рассказать, на какие ошибки в Project management’e вам стоит обратить внимание, чтобы их НЕ делать и стать гораздо более эффективными менеджерами проектов. 

1.    Ошибка: «Я САМ»

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

Данная ситуация может выглядеть некритичной для небольших компаний, которые делают 10–15 проектов в год. Когда же мы выходим на уровень портфеля проектов, который содержит 100–120 проектов в год, то руководителю проектов приходится управлять 3–4 проектами одновременно.

Очевидно, чтобы эффективно управлять несколькими проектами одновременно, менеджеру проекта необходимо «вытащить» себя из системы и начать фокусировать своё внимание на управлении проектными командами, которые выполняют задачи по проектам.

Как НЕ допустить этого?

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

2.    Ошибка: плохое вводное планирование

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

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

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

Как НЕ допустить этого?

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

3.    Ошибка: не использовать устав проекта

Устав проекта – это документ, формально авторизующий проект. Он скрепляет договоренности между менеджером проекта и заказчиком проекта.

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

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

Как НЕ допустить этого? 

Обращаться к уставу проекта. Всегда.

4.    Ошибка: не использовать Иерархическую Структуру Работ (WBS)

Иерархическая Структура Работ (Work Breakdown Structure) проекта является сердцем и ядром методологии PMI PMBOK.

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

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

Пример WBS для ИТ-проекта может выглядеть так:

2.jpg

5.    Ошибка: недостаточное понимание процесса оценки проекта

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

Причина таких неконтролируемых процессов – неумение и недостаточное понимание процесса оценки проекта.

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

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

Как НЕ допустить этого?

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

6.    Ошибка: не использует матрицу ответственности

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

Данная матрица пришла в управление проектами из операционного управления и в крупных компаниях используется на верхнем уровне предприятия.

Типовая матрица ответственности выглядит так: 

3.jpg

7.    Ошибка: не использует метрики качества

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

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

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

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

Как НЕ допустить этого?

Задача менеджера проектов как можно тщательнее прописывать в ТЗ метрики качества, чтобы снизить риски неудачи проекта и максимально сгладить процесс приемки проекта.

8.    Ошибка: попадание в ловушку «scope creep»

Ни один проект не обходится без изменений, т.к. они – неотъемлемая часть любого проекта и с этим необходимо смириться.

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

Как НЕ допустить этого?

Лекарством от «scope creep» является процесс управления изменениями. Ключом к правильному использованию процесса является журнал изменений, в котором должны фиксироваться все запросы на изменения, которые поступают со стороны заказчики и резолюции по ним.

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

Задача менеджера проектов – максимально ответственно отнестись к процессу управления изменениями и ведению журнала изменений.

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

А для того, чтобы ускорить процесс становления вас как профессионала в области управления проектами, Институт IBA приглашает вас на курсы Project Management.