Основные инструменты и методы управления проектами

Итак, сталкиваясь с проблемой, которую ранее в компании с функциональной структурой (жесткая иерархия, выделенная по принципу специализации) не решали (например, открытие филиала, внедрение системы автоматизации и т.п.), руководство такой компании имеет как минимум два варианта.

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

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

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

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

Для того, чтобы придать официальный статус проекту, как мероприятию, имеющему целью решение некоторой задачи, многие компании используют документ «Устав проекта». В Уставе проекта обычно описываются цели проекта, результаты, которые должны быть получены по окончанию проекта, требования к результатам, ограничения по срокам реализации проекта и бюджету. После утверждения Устава проекта руководитель проекта официально утверждается в своей роли (некоторые компании еще издают Приказ о старте проекта) и начинает формирование рабочей группы.

По одной из теорий, жизненный цикл команды (а по сути рабочая группа – это команда) выглядит так:

1. Формирование

2. Срабатывание

3. Нормализация

4. Нормальное функционирование

5. Реорганизация

6. Расформирование

Стадия формирования — это стадия изучения, характеризующаяся периодом нервического возбуждения. Люди будут задавать вопросы: “Чего от меня ожидают?”, “Подойду ли я?”, “Что мне предстоит делать?” и “Каковы правила игры?”.

Руководителю проекта нужно сделать следующие шаги:

• помочь членам команды познакомиться друг с другом;

• дать команде четкое направление и ясную цель;

• вовлечь членов команды в разработку планов, уточнение ролей и определение способов совместной работы;

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

Чтобы успешно преодолеть эту стадию, руководителю проекта следует:

•    решить вопросы власти и полномочий;

•    разработать и реализовать соглашения о порядке принятия решений и о том, кто принимает решения;

•    изучить сильные и слабые стороны каждого члена команды

•    поощрять членов команды принимать на себя все большую ответственность и новые обязательства.

На стадии нормирования команда вырабатывает некоторые основные правила (или нормы), регулирующие совместную работу. Возникает чувство коллективной общности, выражаемое понятием “мы”, люди начинают сотрудничать, открываются каналы общения, крепнет доверие. Для того чтобы провести команду через стадию нормализации, руководителю проекта следует:

•    в полной мере использовать навыки, знания и опыт членов команды;

•    поощрять людей уважать друг друга и отвечать уважением на уважение;

•    призывать людей засучить рукава и сотрудничать.

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

На этой стадии руководителю проекта предлагается следующее:

•    помочь команде понять способы управления изменениями;

•    выступать представителем и защитником команды в отношениях с другими группами и посторонними людьми;

•    отслеживать ход работы и отмечать успехи.

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

На этапе старта проекта руководителю очень важно учесть роли, которые, как считается, должны выполняться в эффективной рабочей группе. О ролях в команде проекта можно почитать в книге М. Белбина. Кроме того, важно подобрать на каждую роль  человека, с соответствующим психотипом. А в этом руководителю проекта поможет, например, методика типирования MBTI.

Параллельно с формированием группы руководителю проекта нужно рассчитать для высшего руководства сроки решения задачи и бюджет. Но до этого очень важно определиться с продуктами (результатами) проекта и требованиями к ним. Для этого руководитель рабочей группы должен уточнить у высшего руководства, кто является Заказчиком проекта, который будет принимать продукты проекта. Именно Заказчик проекта должен предъявлять требования к продуктам проекта, а задача руководителя проекта - собрать и проанализировать требования к продуктам проекта. И вот тут, по опыту, начинаются самые серьезные сложности. Как сказал собственник одной компании: «В нашей компании очень серьезная проблема с тем, что внутренний Заказчик не адекватен и не может грамотно сформулировать требования к продуктам проекта». А ведь от полноты требований к продуктам проекта зависит то,  сколько раз его придется переделывать по ходу проекта. Вот и приходится руководителю проекта  находить баланс между сбором подробных требований и временем, затрачиваемым на эту задачу. В моей практике нередки случаи, когда руководителю проекта приходилось разрабатывать требования к продуктам проекта за Заказчика, а потом согласовывать с ним.

Итак, первое, что надо сделать после подписания Устава проекта, оформить содержание проекта в виде документа Техническое задание, Требования или что-то подобное.

После того, как требования согласованы, начинаем разрабатывать содержание проекта в виде иерархии работ для создания продуктов проекта. Некоторые неопытные руководители проекта пропускают этот этап по разным причинам, но я не рекомендую Вам делать это. В разработке структуры работ проекта будет полезно использовать такой метод как создание Иерархической структуры работ (ИСР, или в английской терминологии WBS). Назначение ИСР – очертить рамки проекта и не забыть какую-либо работу. Потому что любая, не учтенная в плане работ работа, – это дополнительные сроки на ее реализацию и дополнительные затраты для проекта.

  Рисунок 4 – ИСР проекта

Далее, все работы нижнего уровня ИСР объединяются в сетевой график. Для каждой операции сетевого графика устанавливается длительность, операции-предшественники (кроме стартующей операции, у нее предшественника нет) и операции-последователи (кроме финиширующей операции, у нее последователя нет). Используя еще один метод управления проектами – метод критического пути, можно рассчитать длительность всего проекта, резервы по времени для каждой операции и критический путь, на котором лежат операции, не имеющие резерва. Что это дает руководителю проекта? Во-первых, более-менее реалистичные сроки реализации всех работ по проекту, во-вторых, сфокусированность на операциях критического пути, в-третьих – модель сроков проекта, на которой можно проигрывать сценарии типа: «а что, если исполнитель сорвет сроки операции Х, что будет с длительностью всего проекта»?

 

Рисунок 5 - Сетевой график проекта

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

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

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

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

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

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

1.    Правил внесения изменений в проект (процедуры)

2.    Программного продукта, для учета изменений

3.    Организационных единиц, для принятия решений по изменениям.

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