Управление проектами как инструмент осуществления изменений
М. Якубович
Методы и инструменты дисциплины
Управления проектами в том или ином виде используются, как правило, в тех компаниях, которые относятся к проектно-ориентированным (разработка ПО, медиа-бизнес, строительство, внедрение IT-технологий). В этих компаниях основные бизнес-процессы, приносящие добавленную стоимость, реализуются в виде проектов. В последнее время появились мнения экспертов в области управления проектами о том, что использование методов и инструментов управления проектами наибольшую выгоду потенциально может принести в тех компаниях, которые не относятся к проектно-ориентированным. Почему? Да потому, что компании, сталкиваясь с проблемами роста, осознают необходимость изменяться, но не знают с какой стороны подступиться к организации мероприятий по изменениям и действуют по старинке: назначить ответственного, поставить ему задачу и пусть действует. Но ответственный исполнитель сталкивается со следующими проблемами: как получить нужных ему людей, напрямую ему не подчиненных, на работы проекта, как их мотивировать, как рассчитать сроки и бюджет мероприятия и т.д.?
В настоящее время многие компании в Беларуси столкнулись с кризисом роста – выросли, а методы и инструменты управления компанией остались те же, так же, как и организационная структура. Когда-то, на стадии зарождения бизнеса (когда в компании было 10-20 человек) хорошо работали инструменты устного управления, потом количество персонала росло, возник кризис руководства, который характеризовался нехваткой знаний у «отцов – основателей». Для решения кризиса собственники стали нанимать профессионалов в своей функциональной области, которые создавали под реализацию своих функций отделы. Так возникла функциональная структура и четкое иерархическое подчинение с соблюдением принципа единоначалия, где хорошо работали инструменты бумажного управления (докладные, приказы, распоряжения). Но компания продолжала свой рост, который выражался как в росте персонала внутри одной бизнес-единицы, так, возможно, в росте количества самих бизнес-единиц. И вот тут, собственники бизнеса и наемные управляющие столкнулись с новым кризисом – кризисом координации, который выражался в том, что интересы и нужды функциональных подразделений превалировали над интересами и нуждами бизнеса. Высшие руководители начали кричать о перегруженности и авралах. И стало понятно, что вроде бы надо перестраивать бизнес-систему. Но как? Кто-то пошел по пути внедрения процессного подхода, кто-то начал дробить свою компанию на несколько мелких компаний и выделять централизованные процессы для группы компаний, создавать управляющую компанию. Понятно, что внедрение изменений в бизнес-системе связано с использованием специальных инструментов управления, одним из которых является управление проектами.
В этой статье я попробую ответить на вопрос: « КАК внедрять изменения?», а вопрос «Какие изменения внедрять» оставлю специалистам по созданию структур холдингового типа и внедрению процессного подхода.
Сталкиваясь с проблемой, которую ранее в компании с функциональной структурой (жесткая иерархия, выделенная по принципу специализации) не решали (например, открытие филиала, внедрение системы автоматизации и т.п.), директор такой компании имеет как минимум два варианта.
Первый - решение этой проблемы надо поставить как задачу руководителю одного из функциональных подразделений. Второй - решать проблему в рабочей группе из специалистов разных отделов. Если задача не требует компетенций сотрудников из разных функциональных областей, то ее решит руководитель того отдела, к чьей специализации относится данная задача. Если же задача требует взаимодействия специалистов нескольких специальностей, подчиненных руководителям разных отделов, находящихся на одном уровне иерархии, то ее лучше решать в рабочей группе.
Скорее всего, при данном варианте для работы рабочей группе потребуются несколько другие инструменты управления, нежели те, которые использовали в рамках функциональной структуры руководители отделов.
Почему? Во-первых, рабочая группа создается на время, только для решения данной задачи, а после ее решения должна быть расформирована. В рабочей группе будут работать сотрудники разных специализаций и координировать их деятельность сложнее, нежели специалистов своего отдела. Во-вторых, нужны инструменты, позволяющие сформулировать проблему, которая стоит перед рабочей группой, найти альтернативы решения проблемы, превратить выбранную альтернативу в мероприятие с четкими сроками реализации и бюджетом, декомпозировать мероприятие на составные части и т.д. В-третьих, в ходе работы рабочей группы, возможно, будут часто изменяться требования к результатам работы (если они вообще есть), уточняться цели, либо высшее руководство будет менять сроки или бюджет, выделенный на получение результатов. И для управления этими изменениями рабочей группе тоже нужны инструменты новые управления.
О том, какие именно инструменты управления проектами могут помочь, и пойдет речь дальше.
Для решения уникальной задачи нам, прежде всего, надо открыть проект, назначить руководителя проекта и поручить ему сформировать рабочую группу.
Для того, чтобы придать официальный статус проекту, как мероприятию, имеющему целью решение некоторой задачи, многие компании используют документ «Устав проекта». В Уставе проекта обычно описываются цели проекта, результаты, которые должны быть получены по окончанию проекта, требования к результатам, ограничения по срокам реализации проекта и бюджету. После утверждения Устава проекта руководитель проекта официально утверждается в своей роли (некоторые компании еще издают Приказ о старте проекта) и начинает формирование рабочей группы.
По одной из теорий, жизненный цикл команды (а по сути рабочая группа – это команда) выглядит так:
1. Формирование
2. Срабатывание
3. Нормализация
4. Нормальное функционирование
5. Реорганизация
6. Расформирование
Стадия формирования — это стадия изучения, характеризующаяся периодом нервического возбуждения. Люди будут задавать вопросы: “Чего от меня ожидают?”, “Подойду ли я?”, “Что мне предстоит делать?” и “Каковы правила игры?”.
Руководителю рабочей проекта нужно сделать следующие шаги:
помочь членам команды познакомиться друг с другом;
дать команде четкое направление и ясную цель;
вовлечь членов команды в разработку планов, уточнение ролей и определение способов совместной работы;
предоставить команде информацию, необходимую для начала работы
На стадии срабатывания возникает впечатление, что дела идут все хуже и хуже. Члены группы теряют терпение из-за отсутствия успехов и стремятся работать, но не знают, как добиться результатов. Команда борется за определение своей миссии, своих целей, ролей, исполняемых членами команды, и соглашений относительно того, как совместно работать.
Чтобы успешно преодолеть эту стадию, руководителю проекта следует:
решить вопросы власти и полномочий
разработать и реализовать соглашения о порядке принятия решений и о том, кто принимает решения
изучить сильные и слабые стороны каждого члена команды
поощрять членов команды принимать на себя все большую ответственность и новые обязательства.
На стадии нормирования команда вырабатывает некоторые основные правила (или нормы), регулирующие совместную работу. Возникает чувство коллекти
в полной мере использовать навыки, знания и опыт членов команды;
поощрять людей уважать друг друга и отвечать уважением на уважение;
призывать людей засучить рукава и сотрудничать.
Стадия нормального функционирования характеризуется тем, что команда обретает уверенность в своих возможностях. Люди достигают согласия в вопросах о том, что такое команда и чего она пытается достичь, члены команды свободно и продуктивно обмениваются информацией и мнениями, конфликты направляются в конструктивное русло, а проблемы, связанные с работой, решаются творчески. Команда начинает гордиться своими достижениями.
На этой стадии руководителю проекта предлагается следующее:
помочь команде понять способы управления изменениями;
выступать представителем и защитником команды в отношениях с другими группами и посторонними людьми;
отслеживать ход работы и отмечать успехи.
На стадии расформирования уровни мотивирования членов группы могут снижаться по мере того как приближается момент получения результата: ведь группа сработалась и многим понравилось работать в этой группе, решая новую для себя задачу. А сейчас придется снова вернуться к своим обязанностям и лишь в курилке вспоминать о былых совместных подвигах. Но ведь это подходящий момент для того, чтобы начать реализацию новых сложных задач и возобновить стадию формирования в развитии группы!
На этапе старта проекта руководителю очень важно сформировать рабочую группу из правильных людей. Как подбирать правильных людей? Об этом можно почитать в книге М. Белбина, а также в литературе по типированию людей по методике MBTI.
Параллельно с формированием группы руководителю проекта нужно рассчитать для высшего руководства сроки решения задачи и бюджет. Но до этого очень важно определиться с продуктами (результатами) проекта и требованиями к ним. Для этого руководитель рабочей группы должен уточнить у высшего руководства, кто является Заказчиком проекта, который будет принимать продукты проекта. Именно Заказчик проекта должен предъявлять требования к продуктам проекта, а задача руководителя проекта - собрать и проанализировать требования к продуктам проекта. И вот тут, по опыту, начинаются самые серьезные сложности. Как сказал собственник одной компании, столкнувшейся с кризисом координации: «В нашей компании очень серьезная проблема с тем, что внутренний Заказчик не адекватен и не может грамотно сформулировать требования к продуктам проекта». А ведь от полноты требований к продуктам проекта зависит то, сколько раз его придется переделывать по ходу проекта. Вот и приходится руководителю проекта находить баланс между сбором подробных требованием и временем, затрачиваемым на эту задачу. В моей практике нередки случаи, когда руководителю проекта приходилось разрабатывать требования к продуктам проекта за Заказчика, а потом согласовывать с ним.
Итак, первое, что надо сделать после подписания Устава проекта, оформить содержание проекта в виде документа Техническое задание, Требования или что-то подобное.
После того, как требования согласованы, начинаем разрабатывать содержание проекта в виде иерархии работ для создания продуктов проекта. Некоторые неопытные руководители проекта пропускают этот этап по разным причинам, но я не рекомендую Вам делать это. В разработке структуры работ проекта будет полезно использовать такой метод как создание Иерархической структуры работ (или в английской терминологии WBS). Назначение ИСР – очертить рамки проекта и не забыть какую - либо работу. Потому что любая, не учтенная в плане работ работа, – это дополнительные сроки на ее реализацию и дополнительные затраты для проекта.
Далее, все работы нижнего уровня ИСР объединяются в сетевой график. Для каждой операции сетевого графика устанавливается длительность, операции-предшественники (кроме стартующей операции, у нее предшественника нет) и операции-последователи (кроме финиширующей операции, у нее последователя нет). Используя еще один метод управления проектами – метод критического пути, можно рассчитать длительность всего проекта, резервы по времени для каждой операции и критический путь, на котором лежат операции, не имеющие резерва. Что это дает руководителю проекта? Во-первых, более-менее реалистичные сроки реализации всех работ по проекту, во-вторых, сфокусированность на операциях критического пути, в-третьих – модель сроков проекта, на которой можно проигрывать сценарии типа: «а что, если исполнитель сорвет сроки операции Х, что будет с длительностью всего проекта»?
Рисунок 1- Сетевой график проекта
Но, сроки проекта, полученные с учетом только параметра длительности операций, могут быть неточными, т.к. не учитывается загрузка ресурсов на проекте. Поэтому руководитель проекта должен назначить исполнителей на каждую задачу, установить загрузку исполнителей и пересчитать параметры сетевого графика. В решении этой трудоемкой задачи может помочь специализированное ПО типа MS Project.
Следующая задача – определение бюджета проекта. В простейшем случае, стоимость проекта рассчитывается как стоимость всех работ, из которых состоит проект.
Итак, после проделанной работы руководитель проекта может заявлять высшему руководству сроки и бюджет решения задачи.
Вот в этот момент проект, для которого высшее руководство получило представление о сроках и стоимости, может быть остановлен: слишком долго или слишком дорого. Но это решение обосновано, а не основано на интуиции или сборе мнений. И иногда лучше потратить время на расчет сроков и бюджета проекта, чем начать проект, а потом, вложив в него огромные деньги, понять, что продукт проекта уже никому не нужен.
Но если проект все же решили отпустить на стадию реализации, то не сомневайтесь: обязательно по ходу проекта возникнут уточнения в требованиях, либо желание сократить сроки или выстрелят неучтенные риски, которые повлияют на сроки и стоимость работ.
Для внесения в проект изменений должна быть разработана система управления изменениями, которая в простейшем случае состоит из:
1. Правил внесения изменений в проект (процедуры)
2. Программного продукта, для учета изменений
3. Организационных единиц, для принятия решений по изменениям.
В одной из компаний, в которой автор внедрял управление проектами, проекты по выводу нового продукта на рынок вместо запланированного года длились два. Проанализировав причины, руководство пришло к выводу о том, что основной причиной является огромное количество изменений в требованиях, которые вносили внутренние Заказчики. При этом, изменения не влекли за собой анализ того, а как реализация данных требований скажется на сроках и бюджете проекта. После внедрения системы управления изменениями картина резко изменилась: фактические сроки проекта незначительно отличались от запланированных, и по каждому предложению изменить требования проводился серьезный анализ влияния изменения на сроки и бюджет.
В данной статье я рассмотрел управление проектами, как инструмент для решения уникальных для компании задач, связанных с ее развитием и требующих организации команды из межфункциональных специалистов.
Список литературы
М. Белбин. Типы ролей в командах менеджеров. Издательство: HIPPO. Год издания: 2004 г., 220 стр.
Отто Крегер, Дженет Тьюсон. Типы людей и бизнес. Издательство: Астрель, 2006 г., 464 cтр.