Методы = [функции, или области управления, или процессы] =? Опишем…

Методы = [функции, или области управления, или процессы] =?

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

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

Наряду с этим, существуют разные уровни использования терминов:

• уровень теории;

* уровень корпоративной системы управления проектами;

* уровень отдельного проекта;

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

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

По возможности, в тексте корпоративной системы следует отказать­ся от использования специально определяемых терминов. Текст корпо­ративной системы должен напоминать армейский устав, с его просты­ми и недвусмысленными формулировками.

Совершенно иная ситуация появляется при проведении аудита всей корпоративной системы. Здесь использование специальных терминов является необходимым условием.

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

При построении корпоративной системы управления проектами конструктор вправе пользоваться любым из четырех слов. При исполь­зовании термина необходимо:

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

• обеспечить понимаемость терминов для персонала.

Продюсирование проекта

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

Проект может рождаться множеством способов: в кому-то из руководства компании пришла в голову идея: благо­даря административным возможностям идея получила быстрое продвижение;

• кто-то из специалистов обратился к руководству компании с иници­ативным предложением;

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

• проект скопирован у родственных компаний или конкурентов;

• маркетинговая служба нашла клиента;

• клиент самостоятельно обратился в компанию;

• проект родился в результате плановой работы, например, програм­ма стратегического развития, программа НИОКР.

После появления первой идеи или стартового импульса должно пройти какое-то обсуждение и принятие проекта.

Ключевая роль в рождении проекта принадлежит все-таки не орга­низациям, а людям, которые называются инициаторами или продюсе­рами проекта. Трактовка слова "инициатор" не предполагает, что ини­циатор должен произвести какую-то работу, инициатору достаточно дать первый импульс, подать идею. Термин producer ^производитель, генератор, источник), напротив, предполагает работу, производство и точно соответствует функциям этой ключевой роли:

• самому предложить идею или воспользоваться предложением дру­гого лица; переход идеи к продюсеру может происходить:

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

• сформулировать плановые цели и результаты проекта;

• интегрировать ресурсы, необходимые для достижения целей и результатов:

О процесс интеграции состоит как в определении необходимых ре­сурсов, так и в проведении первичных переговоров с собствен­никами ресурсов, в частности с персоналом или партнерами; о если необходимый пул ресурсов интегрировать не удается, пе­реформулировать цели и результаты под доступные ресурсы;

• обозначить окружение проекта и его соучастников;

• предложить организационную схему проекта;

• найти кандидатуры основных менеджеров проекта:

О продюсер может сам предложить свою кандидатуру на роль ме­неджера проекта;

• разработать первую версию плана проекта:

О первая версия может быть совсем небольшого объема и быть весьма грубой по точности расчетов

• обеспечить утверждение плана проекта.

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

Будет большой ошибкой, если в компании функции продюси - рования всегда возлагаются только на менеджера проекта! Совмещение функций продюсера и менеджера проекта воз­можно только при небольшом количестве работников в ком­пании или при предпринимательской модели бизнеса.

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

В качестве инструментов анализа прогнозируемой эффективности могут использоваться:

* методы дисконтируемых расчетов;

* бюджеты доходов и расходов;

* бюджеты движения денежных средств (cache-flow).

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

Установление управленческих и продуктовых фаз

Разбиение проекта на управленческие и продуктовые этапы произ­водится в соответствии с корпоративной моделью проектного бизнеса. На практике в компании должны существовать шаблоны управленчес­ких и продуктовых этапов.

Динамическое планирование

Динамическое планирование уже упоминалось выше. В управлении проектами именно динамическое планирование становится основой всей проектной деятельности.

Следует отметить, что в западных руководствах по управлению проектами слова "динамическое планирование" упоминаются ред­ко. Не использование этих слов не означает отсутствие понимания о динамичности проектных планов. Исторически сложилось так, что в западных руководствах динамическое планирование представляется в виде двух независимых блоков: собственно планирование и управле­ние изменениями. К сожалению, часто при переносе этих двух блоков в российскую практику второй блок (изменения) просто пропадает. Следствием пропажи становится бессмысленность проектного управ­ления — практически невозможно успешно выполнить проект только на основании первичного плана.

Также необходимо отметить, что современная методика проектного менеджмента выросла из двух источников: из возникших в 50-х годах прошлого века проектных инструментов (сетевое планирование, дис­контированные расчеты) и из идеи циклического постоянного улучше­ния. Так, цикл Деминга появился независимо от управления проектами. Лишь в последнее десятилетие цикличность проникла и в управление проектами. При трансляции западных методов в российскую практику лучше сразу применять самые передовые идеи и объединить два блока (планирование + изменения) в единое динамическое планирование.

9

Идея проекта

Выполнить, коррекцию

І Произошло! отклонение! от Плана

Инициировать проект

Подготовить Ппдн проекта

[ Мониторинг1 1 (1) прогресса проекта 12) отклонении от Плана

Г

Закрып

Проект j

Щель I достигнута

Проект закрыт|

V

Рисунок 35. Статическая схема управления проектом

Методы

Рисунок 36. Динамическое управление проектом

Графическое пояснение разницы между статическим и динамичес­ким планированием дано на рисунках 35 и 36.

При статическом плане проектная команда при наступлении от­клонений предпринимает корректирующие действия по ликвидации отклонений.

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

1. Возникло предложение об улучшении проекта;

2. Наступила предусмотренная календарная дата очередного уточне­ния плана проекта;

3. Прогнозируется существенное отклонение от плана проекта;

4. Возникла чрезвычайная ситуация.

С практической точки зрения, динамическое планирование сводится к следующим простым внутрикорпоративным нормам:

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

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

• в компании должен существовать утвержденный перечень собы­тий, вызывающих пересмотр плана проекта.

Управление закупками и контрактами

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

1. планирование дат осуществления закупок, заключения и выполне­ния контрактов;

2. установление требований к поставляемой продукции;

3. поиск поставщиков и контракторов;

4. проведение отбора (конкурсов, торгов) среди поставщиков или контракторов;

5. осуществление поставок и выполнение контрактов.

Методы поиска контрагентов, условия их отбора должны быть уста­новлены на уровне компании, независимо от отдельных проектов.

Управление качеством проекта

Термин качество проекта понимается в двух смыслах:

1. качество управления проектом (иногда применяется простая ком­бинация "качество проекта");

2. качество продукта проекта.

5*

В свою очередь, качество управления проектами может рассматри­ваться на двух уровнях:

• на уровне компании;

• на уровне проекта.

На уровне компании качество управления проектами достигается через проведение аудита корпоративной системы управления проекта­ми и принятие соответствующих мер по результатам аудита. На уровне проекта качество проекта управляется через:

• систему контроля и отчетности;

• систему постоянного улучшения.

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

Чрезвычайно важным является наличие обратной связи между отче­тами проектной команды и соответствующей реакцией руководителей организации.

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

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

Управление событиями и рисками проект а

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

Необходимоотмегить, чтотсмауііравленпярисками(гІ8к management) сама по себе является широкой сферой управленческой технологии со своими методами и инструментами. В зависимости от типа и объема проекта могут применяться различные инст рументы.

Кроме того, при описании корпоративной модели проектного биз­неса компания должна сделать выбор: какие страховые мероприятия приемлемы, а какие нет.

Применительно к управлению проектами управление событиями за­ключается в следующих действиях:

6-Мишин

• установление перечня возможных событий;

• ранжирование событий, выделение ключевых событий;

• манипулирование событиями, выстраивание их в выгодной для ро­дительской организации последовательности;

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

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

• создание резервов для компенсации непредвиденных негативных событий.

Метод превентивных действий

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

Метод превентивных действий относится к управленческой траек­тории жизненного цикла. Примеры превентивных действий приведе­ны в таблице 26.

Таблица 26. Превентивные действия для различных событий

Запланированное событие

Возможные превентивные действия

Начало работ, выполняемых новым участником (субподрядчиком)

Включение персонала участника в рабо­ту проектной команды за 2-5 недель до реального начала работ участником

Получение административного' согласования

Проведение предварительных лобби­рующих мероприятий, установление контактов, поиск рекомендателей

Прогнозирование негативных событий

Выстраивание защиты, поиск необхо­димых ресурсов, участников, экспертов, юристов и т. д.

Проведение испытаний

Выбор методики испытаний, подбор организации, проводящей испытания

На практике метод превентивных действий заключается:

• после составления календарного плана и контрольного списка ме­неджер проекта должен проверить каждую позицию на предмет включения необходимых превентивных действий;

• в рамках корпоративной модели может действовать правило о включении в календарный план и контрольный список специаль­ного раздела "превентивные действия".

Управление ритмом

(управление ритмом описано выше, в подразделе "Базовые характе­ристики и принципы")

Текущее управление

Методы текущего управления относятся к числу главных секретов проектной технологии. Этот секрет ни от кого не скрывается, но его мсто кто видит.

Общее описание проблемы текущего управления и главного инстру­мента текущего управления, контрольных списков приведено выше, в главе "Мифы в проектном бизнесе".

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

Контрольный список близок к перечню работ (иерархическая струк­тура работ) и календарному плану. Между ними есть отличия:

• контрольный список включает только те действия, которые выпол­няет непосредственно менеджер проекта или подчиненная ему ко­манда проекта:

О так, работа "построить здание" не включается в контрольный список, а работы "подготовить контракт на строительство", "со­гласовать контракт" "провести осмотр объекта строительства", "написать отчет" — включаются;

• в отличие от перечня работ, имеющего иерархический характер, контрольный список имеет простую линейную структуру, соот­ветствующую линейному ходу времени.

• контрольные списки должны быть более подробными, чем перечни работ:

О предел детализации перечня работ определяется заранее задан­ной точностью расчетов сроков проекта и бюджета проекта (из­лишняя детализация вредна); о детализация контрольного списка должна соответствовать ежедневной наполняемости работы менеджера проекта и его команды.

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

Кроме простейшей формы контрольного списка могут существовать и более сложные форматы. Например:

• общий контрольный список на проект;

• список действий менеджера проекта;

• список члена проектной команды;

• список на конкретный календарный период (как правило, от месяца и выше);

• список на отдельный проектный этап.

Выбор формата контрольных списков должен быть установлен в корпоративной системе управления проектами.

Контроль выполнения проекта

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

Контроль выполнения проекта осуществляется на двух уровнях:

• уровень компании;

• уровень проекта.

На уровне компании контроль проекта выполняет специально назна­ченный контролер проекта. На уровне компании в течение проектного цикла контролируется:

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

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

• выполнение основных проектных показателей (утвержденных показателей).

Контролер проекта должен иметь право потребовать от проектной команды дополнительные материалы для изучения или потребовать составить специальный промежуточный отчет при наличии у него на это оснований.

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

• при возникновении отклонений предпринять корректирующие воздействия;

• проводить анализ прогноза конечных показателей проекта;

• составлять сводные отчеты для руководства;

• разрабатывать предложения о коррекции плана проекта, прежде всего, об улучшении проекта;

• немедленно извещать руководство при возникновении таких кри­зисных событий, по которым проектная команда прогнозирует не­достаток своих ресурсов для ликвидации кризисных явлений или последствий.

Закрытие проекта

Закрытие проекта является чисто управленческим методом и всег­да осуществляется после завершения работ по производству продукта

Проекта.

Закрытие проекта включает в себя операции:

1. завершение расчетов с контрагентами и выполнение прочих обязательств;

2. инвентаризация документации проекта, передача документации в архив;

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

4. проведение финального контрольного анализа результатов проекта контролером проекта или контрольной службой компании;

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

6. выплата премий членам проектной команды;

7. роспуск проектной команды, оказание содействия в трудоустройс­тве членов проектной команды.

Комментарии закрыты.