• постановка задачи, возникающей в проекте, не конкретному исполнителю, а руководителю функционального подразделения.
Первый вариант сложен с точки зрения реализации, поскольку он требует разработки схем оплаты труда сотрудников, однако он же наиболее близок к самой идее проектного управления. Второй вариант может оказаться неэффективным из-за недозагруженности сотрудников. Поэтому чаще всего используется третий вариант, когда общая структура управления в проекте становится менее мобильной, однако полностью отсутствует двойное подчинение сотрудников, которое обычно и вызывает максимум проблем. К достоинствам этого способа также относится свобода функционального руководителя в использовании ресурсов подразделения для решения поставленной задачи.
Этап 2. Разработка нормативной документации
В стандартах управления проектами конкретной компании необходимо предельно конкретно описать: кто, когда и что должен делать для функционирования СУП. Этот документ должен включать следующие пункты:
• политика компании в области управления проектами;
• классификация проектов и критерии выделения отдельных начинаний в проект;
• описание бизнес-процесса прохождения проекта в организации (каким образом проект начинается, утверждается и реализуется, и кто за это отвечает).
Степень детализации стандарта зависит от сложности и количества проектов компании, а также от числа вовлеченных в процесс сотрудников. Политика компании в области проектной деятельности описывает место проектного управления в общем менеджменте компании. Она включает правила отделения основной деятельности от проектной и правила их взаимодействия, распределение ответственности за проектную деятельность, ее руководителей и исполнителей. Так в отдельный проект могут выделяться начинания, имеющие бюджет, превышающий определенную сумму. Другим критерием может быть сфера охвата проекта. Если начинание не требует больших вложений и охватывает деятельность двух подразделений компании, в отдельный проект оно не выделяется, если же затрагивает три и больше подразделений, – то выделяется. Примером может быть проект реструктуризации компании, автоматизации, внедрения новой системы мотивации и т. д.
Несмотря на то, что проекты являются уникальными начинаниями, классификация позволяет использовать имеющиеся наработки и статистику для похожих проектов. В зависимости от целей существуют проекты по:
• развитию ассортимента;
• развитию каналов сбыта;
• развитию производства;
• развитию обеспечивающих подразделений;
• повышению качества управления;
• диверсификации бизнеса.
Классификация также может быть иерархической (сначала по сфере приложения, потом по содержанию): а) сбытовые:
• развитие ассортимента;
• развитие сбытовой сети;
• развитие способов продвижения;
• развитие логистики; б) производственные:
• модернизация существующих производств;
• создание новых производственных площадок;
• улучшение производственного процесса; в) обеспечивающие:
• автоматизация процессов управления;
• реорганизация бизнес-процессов;
• повышение эффективности работы вспомогательных подразделений.
Для каждого из выделенных типов проектов должны быть описаны типовые последовательности работ, потребности в ресурсах, времени, стоимости работ, возможные проблемы и т. д. Кроме того, может описываться принцип назначения куратора и менеджера проекта. По мере реализации проектов в компании стандарт может меняться.
Следующим шагом является описание бизнес-процесса прохождения проекта в компании. Пример схематичного представления бизнес-процесса приведен на рис. 1.1.3.
Общая структура бизнес-процесса может детализироваться и усложняться, вплоть до описания отдельных действий конкретных сотрудников.
Решение создать СУП означает наличие у компании нескольких одновременно реализующихся проектов, то есть портфеля проектов. Чаще всего проекты в компании ведутся параллельно текущей деятельности. Правила согласования текущей и проектной деятельности также прописываются в стандарте.
Управление портфелем проектов обычно строится на конкурентной основе. Создать конкуренцию между проектами внутри портфеля можно с помощью присвоения им статуса и приоритета. Например, статус может принимать значения:
• в разработке;
• к запуску;
• запущенный;
• приостановленный;
• завершенный;
• отклоненный;
• отложенный.
Рис. 5.1.3.. Упрощенный пример описания бизнес-процесса прохождения проекта
Изменение статуса проекта происходит после рассмотрения его на инвестиционном комитете на основании принятых в компании граничных условий. Например, к исполнению принимается проект, срок окупаемости которого не менее трех лет, значение IRR – не ниже 25 % и т. д. Если показатели проекта значительно превосходят указанные, то ему присваивается статус «к запуску», если они близки к граничным или меньше их, то статус – «отложенный», если проект был отклонен, то он передается в архив со статусом «отклоненный», а в случае отправки проекта на доработку статус не меняется.
Помимо статуса проектам присваивается приоритет. Например, по умолчанию приоритет устанавливается равным трем. Для проектов, которые имеют большую важность с точки зрения стратегических целей компании или более высокую доходность, приоритет повышается до двух или единицы, для других он может быть понижен до четырех или пяти. Кроме того, приоритет проектов может меняться в ходе их реализации. Это способствует более эффективной работе менеджеров проектов, побуждает их к конкуренции.
Этап 3. Автоматизация
Несмотря на то, что выбору программного продукта для автоматизации СУП посвящено огромное количество статей, на практике следует руководствоваться реальными потребностями компании. Так для крупной строительной организации, которой необходим полноценный учет материалов, посменная работа и т. п., нужна система профессионального уровня (Primavera Enterprise, Spider Project). Для компании поменьше подойдут Microsoft Project и OpenPlan Pro. Они обладают богатыми возможностями групповой работы: создание единого пула ресурсов, доступ к проектам через web-интерфейс, интеграция с почтовыми и учетными программами. В России также существуют системы, реализующие функции бюджетирования и управленческого учета по проектам и автоматизирующие документооборот (ТУ «Управление проектами» на базе «1С:Пред-приятие 8.0»). Однако они не являются полноценной заменой автоматизированной СУП, так как не предназначены для оптимизации расписаний проектов и управления ресурсами по проектам.
Минимальные требования, которым должна удовлетворять автоматизированная система управления проектами (включая адаптированный для этой цели MS Excel), следующие:
• возможность декомпозиции работ, планирование их длительности и связей между ними;
• возможность планирования ресурсов, необходимых для выполнения работ;
• оптимизация полученного плана-графика работ с учетом и без учета ограничений по ресурсам;
• оценка рисков изменения плана-графика работ;
• отслеживание исполнения подготовленного плана работ;
• подготовка отчетов на основе планов и фактов работ.