Когда мы только начинаем управлять проектами, то неизбежно совершаем массу ошибок, которые на первых порах нас очень огорчают, но которые дают столь необходимый практический опыт и сильнейший толчок в развитии.
Однако начинающему руководителю проектов не обязательно наступать на те же «грабли», на которые уже не раз наступили тысячи менеджеров проектов. Разбору основных ошибок начинающего руководителя проектов посвящена данная статья.
Делает всё сам
Начинающий руководитель проектов, как правило, вырастает из хорошего исполнителя, и данный поведенческий паттерн сохраняется в его привычках и модели поведения. Такой менеджер проектов продолжает активно вмешиваться в задачи проекта и даже самостоятельно выполняет часть из них.
Данная ситуация может выглядеть некритичной для небольших компаний, которые делают 10–15 проектов в год. Когда же мы выходим на уровень портфеля проектов, который содержит 100–120 проектов в год, то руководителю проектов приходится управлять 3–4 проектами одновременно. Очевидно, чтобы эффективно управлять несколькими проектами одновременно, менеджеру проекта необходимо «вытащить» себя из системы и начать фокусировать своё внимание на управлении проектными командами, которые выполняют задачи по проектам.
Итак, если вы начинающий руководитель проектов, то вам необходимо как можно раньше перестать самостоятельно выполнять задачи по проекту. Вместо этого ваш фокус должен быть направлен целиком и полностью на формировании, мотивации, кристаллизации и управлении проектной командой.
Фокусируется только на целях проекта
Начинающего менеджера проекта, как правило, заботят только то, успеет ли он выполнить проект в срок, не превысит ли он бюджет и примет ли заказчик его работу.
При этом руководитель проекта забывает о том, что у заказчика есть определенные бизнес-цели, ради которых создается продукт проекта. Как правило, эти цели связанны с прибылью, которую заказчик хочет получить от реализации данного проекта.
Наша практика показывает, что чем тщательнее менеджер проекта вникает в суть бизнес-потребностей заказчика, тем более успешным оказывается проект.
Поэтому начинающему крайне необходимо очень скрупулёзно интервьюировать заказчика на предмет бизнес-целей, которые он перед собой ставит для того, чтобы сфокусировать все усилия команды на достижении данных целей.
Не использует устав проекта
Устав проекта – это документ, формально авторизующий проект. Он скрепляетдоговоренности между менеджером проекта и заказчиком проекта.
Одним из самых важных разделов устава является как раз бизнес-цели проекта, о которых шла речь выше. Помимо бизнес-целей в уставе содержится масса полезной информации,с помощью которой руководитель проекта может быстро узнать основную информациюо проекте и понять для себя суть предстоящего проекта.
Неопытный менеджер проектов пропускает данный шаг и сразу переходит к сбору требований проекта, что приводит к тому, что проект не соответствует бизнес-целям компании ив результате делается совсем не то, что ожидал получить заказчик.
Собирает требования только с заказчика проекта
Очень распространенная ошибка начинающего руководителя проекта состоит в том, что он фокусируется исключительно на требованиях заказчика, забывая о том, что помимо заказчика требования к проекту предъявляют все заинтересованные стороны проекта.
Эта ошибка приводит к тому, что требования ключевых лиц проекта не учитываются ина приемке проекта менеджера проекта ждет серьёзное испытание.
Чтобы избежать риска провала проекта, необходимо собирать требования не толькос заказчика проекта, но и со всех заинтересованных сторон проекта.
Об этом не следует забывать как начинающему, так и профессиональному руководителю проектов.
Не использует ИСР
Иерархическая Структура Работ (Work Breakdown Structure) проекта является сердцем и ядромметодологии PMI PMBOK.
Если вы управляете проектами в соответствии с данным стандартом, то вы должны использовать данный инструмент, так как он позволяет путем декомпозиции представить основные результаты проекта, которые должны быть произведены в рамках проекта.
Большинство начинающих руководителей проекта не используют данный полезнейший артефакт, а между тем он сильно облегчает жизнь менеджеру проекта при разработке расписания и бюджета проекта.
Пример WBS для ИТ-проекта может выглядеть так:
Не включает резервы в план проекта
Начинающий руководитель проектов почему-то считает, что закладывать достаточные резервы по срокам и затратам в проект означает обманывать себя и заказчика. Профессиональный менеджер проектов знает, что управлять проектом без резервов сродни самоубийству.
Резервы на проект возникают вследствие процесса управления рисками и должны составлятьне менее 15-20% об общей длительности и бюджета проектов.
Иначе вы рискуете серьёзным образом сорвать сроки проекта и превысить его бюджет.
Не использует матрицу ответственности
Матрица ответственности (RACI-матрица) – это эффективный инструмент управления коммуникациями внутри команды проекта.
Используя данную матрицу можно очень четко прописать, кто и за что отвечает в проекте, чтобы в будущем избежать неожиданностей в ходе исполнения проекта.
Данная матрица пришла в управление проектами из операционного управления и в крупныхкомпаниях используется на верхнем уровне предприятия.
Типовая матрица ответственности выглядит так:
Не использует метрики качества
Для того, чтобы успешно пройти приёмку и сдать продукт заказчику, необходимо на стадиипланирования договориться с заказчиком о тех характеристиках, которые должен иметь конечный продукт проекта.
Подобные характеристики называются метриками качества.
Это набор характеристики, которые необходимо закрепить в техническом задании, чтобы всем участникам проекта было понятно, каких именно результатов ожидает заказчик.
Метрики качества могут быть выражены в самых разных параметрах, таких как: размер, ширина, высота, цвет, быстродействие, частота отказов и проч. В зависимости от конкретной отрасли метрики качества могут быть разные. Начинающий руководитель проекта как правило забывает детально прописывать метрики качества, руководствуясь тем, что ему кажется очевидным те или иные вещи.
Трюк заключается в том, что видение менеджера проекта и видение заказчика зачастуюне совпадают, поэтому нужны объективные критерии оценки завершенности проекта.
Если вы только начинаете управлять проектами, вам необходимо как можно тщательнее прописывать в ТЗ метрики качества, чтобы снизить риски неудачи проекта и максимально сгладить процесс приемки проекта.
Попадает в ловушку «scope creep»
Ни один проект не обходится без изменений. Они неотъемлемая часть любого проекта ис этим необходимо смириться.
Но одного смирения мало – менеджер проекта обязан выстроить процесс управления изменениями таким образом, чтобы избежать так называемого «расползания» содержания, при котором изменения выходят из под контроля и никто уже не понимает в проекте, а что на самом деле происходит, какая актуальная дата сдачи проекта и какой фактический бюджет будет у нашего проекта.
Лекарством от «scope creep» является процесс управления имениями.
Ключом к правильному использованию процесса является журнал изменений, в котором должны фиксироваться все запросы на изменения, которые поступают со стороны заказчики и резолюции по ним.
Только в этом случае вы сможете удержать под контролем то обилие изменений, которое присутствует в каждом проекте.
Итак, если вы начинающий руководитель проекта, Вам необходимо максимально ответственно отнестись к процессу управления изменениями и ведению журнала изменений.