Реферат: Управление проектами как инструмент осуществления изменений

Управление проектами как инструмент осуществления изменений

М. Якубович

Методы и инструменты дисциплины

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

В настоящее время многие компании в Беларуси столкнулись с кризисом роста – выросли, а методы и инструменты управления компанией остались те же, так же, как и организационная структура. Когда-то, на стадии зарождения бизнеса (когда в компании было 10-20 человек) хорошо работали инструменты устного управления, потом количество персонала росло, возник кризис руководства, который характеризовался нехваткой знаний у «отцов – основателей». Для решения кризиса собственники стали нанимать профессионалов в своей функциональной области, которые создавали под реализацию своих функций отделы. Так возникла функциональная структура и четкое иерархическое подчинение с соблюдением принципа единоначалия, где хорошо работали инструменты бумажного управления (докладные, приказы, распоряжения). Но компания продолжала свой рост, который выражался как в росте персонала внутри одной бизнес-единицы, так, возможно, в росте количества самих бизнес-единиц. И вот тут, собственники бизнеса и наемные управляющие столкнулись с новым кризисом – кризисом координации, который выражался в том, что интересы и нужды функциональных подразделений превалировали над интересами и нуждами бизнеса. Высшие руководители начали кричать о перегруженности и авралах. И стало понятно, что вроде бы надо перестраивать бизнес-систему. Но как? Кто-то пошел по пути внедрения процессного подхода, кто-то начал дробить свою компанию на несколько мелких компаний и выделять централизованные процессы для группы компаний, создавать управляющую компанию. Понятно, что внедрение изменений в бизнес-системе связано с использованием специальных инструментов управления, одним из которых является управление проектами.

В этой статье я попробую ответить на вопрос: « КАК внедрять изменения?», а вопрос «Какие изменения внедрять» оставлю специалистам по созданию структур холдингового типа и внедрению процессного подхода.

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

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

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

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

О том, какие именно инструменты управления проектами могут помочь, и пойдет речь дальше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список литературы

М. Белбин. Типы ролей в командах менеджеров. Издательство: HIPPO. Год издания: 2004 г., 220 стр.

Отто Крегер, Дженет Тьюсон. Типы людей и бизнес. Издательство: Астрель, 2006 г., 464 cтр.