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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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