Пять ошибок руководителя проекта на удалёнке
Идея подборки пришла на одном из проектов. Ошибки, на мой взгляд, частые, и не обязательно возникают вместе. Эти ошибки могут проявиться и в очной работе, но при удаленной работе их последствия более критичны.
Ошибок возникает больше, выбрал только некоторые. Если у читателей будет интерес к теме, можно будет выпустить продолжение.
Пренебрежение вводной встречей с рабочей группой
Рабочая группа проекта это не просто ресурс руководителя проекта для достижения стоящих перед ним задач. Это своего рода оперативный штаб с мозговым центром. И этому штабу нужны вводные данные по стратегии и тактике, чтобы он сформировал для себя направления мысли. Как правило, команду проекта собирают из специалистов разного профиля. И совсем не факт, что они раньше уже работали вместе.
Цель вводной встречи рабочей группы — сформировать команду, которая будет работать на цели проекта. За одну встречу при удаленном режиме работы достичь этой цели вряд ли удастся. Тут многое определяется лидерскими качествами руководителя проекта. Однако, положить начало стоит обязательно.
Необходимо первыми задачами вводной встречи обозначить знакомство участников друг с другом, объяснение роль каждого в проекте, представление ключевых специалистов, которые могут оказывать поддержку другим участникам. Обязательным для первой встречи команды является доведение до неё целей и задач проекта, методологии (методов управления), которой будет придерживаться руководитель проекта, базового плана работ и распределение задач проекта по участникам рабочей группы. Если со стороны заказчика сформирована рабочая группа, руководитель проекта должен, как минимум, довести до участников своей команды роль каждого представителя заказчика в работе по проекту.
Отступления от методологии управления проектами
Опытный руководитель проектов со временем вырабатывает свои собственные подходы в организации и контроле управления проектами. Важно при этом оставаться в рамках той методологии, которая была выбрана в качестве основной.
Методология управления проектами, будь то PMI PMBoK или Agile Scrum, является концентратом мировой практики управления проектами. Эта методология сложилась и вобрала в себя наилучшие правила организации работ с гарантией достижения целей проекта эффективным способом. При этом совокупность процессов управления любой методологии не догма. Руководитель проекта вправе выбрать из них лишь некоторые. Однако методология управления проектами устанавливает обязательные процессы и порядок их следования. Исключение их из личной практики снижает вероятность эффективно достичь цели проекта.
Если руководитель проекта всё же отошел в базовых принципах от методологии, лучшим способом следовать своим подходам будет доведение их до команды. Иначе в команде может возникнуть недопонимание от расхождения известных им методологических правил с фактической организацией работ. Недопонимание приведет к снижению активности в проекте.
Недельный контроль вместо ежедневного
Контроль хода работ по неделям не подходит для большинства ИТ-проектов. Если же говорить о проектах внедрения программных решений, то отсутствие ежедневного контроля это предпосылка к провалу.
Запланированные работы проектов, в которых предполагается представлять результаты заказчику уже в первые месяцы после старта, должны контролироваться в ежедневном формате. Проекты с более долгим периодом отчетности перед заказчиком должны разбиваться на внутренние этапы проекта с контролем промежуточных результатов. И здесь уже возникнут более короткие интервалы контроля.
Ежедневная «контрольная точка» позволит руководителю проекта получать точное и однозначное представление ситуации по всем работам, переоценивать риски проекта (ведь план управления рисками уже есть?), понимать степень выгорания участников и заблаговременно предотвращать снижение эффективности их работы, проактивно перепланировать работы при отклонении от плана проекта.
Не надо доводить ежедневный контроль до абсурда с подготовкой отчетов и планов. Это короткое по времени мероприятие для общего понимания текущей ситуации.
При переходе на ежедневный контроль обязателен отказ от всех прочих периодических (еженедельных, ежемесячных) отчётных мероприятий. Достаточен контроль сдачи результатов работ.
Совершенно не обязательно проводить ежедневные контрольные мероприятия утром. Время выбирается с учётом обычной загрузки участников проекта и может восприниматься как отвлечение внимания или короткий перерыв в работе.
Скрывать проблемы проекта от команды
Кажется очевидным, что руководитель проекта должен делиться со своей командой всеми проблемами, которые возникают по его ходу. Некоторые руководители ошибочно думают, что озвучивание проблем каким-то образом снижает их авторитет или делает их менее компетентными.
Проектов без проблем не бывает. Потому и начинают проекты, что есть неопределенность в получении результатов в рамках обычной (операционной) деятельности. Пожалуй, одним из ключевых навыков руководителя проекта является умение находить решения проблемам. Никто не говорит, что руководитель проекта должен делать это путем личных умственных усилий.
Команда проекта это коллектив профессионалов. Некоторые из них могут иметь большой опыт участия в сложных проектах. Озвучить проблему перед командой и попросить подумать над её решением — это не проявление слабости. Это поведение лидера, доверяющего своей команде и уважающего мнение каждого.
Узурпация власти
К сожалению, приходилось наблюдать поведение руководителя проекта как начальника с подчиненными. Такие руководители проекта не совсем корректно понимают свою роль. Заблуждение подпитывают некорректные схемы управления, в которых квадратик с названием «Команда проекта» показан под квадратиком с названием «Руководитель проекта».
Управление проектами организуется по матричной модели. «Руководитель проекта» это роль в матрице с определенным набором обязанностей и полномочий. Да, их больше, чем у других участников. Но это не делает его выше других в административной иерархии.
Иерархии в проектных командах вообще нет. Руководитель проекта должен быть лидером команды. Если личных качеств для лидерства не хватает, то руководителю проекта нужно развивать в себе навыки дипломата для организации слаженной работы команды.
Хотя «включать начальника» иногда приходится, эта практика не должна быть системной.
