[ «ПРОЕКТНЫЙ МЕНЕДЖМЕНТ В ПРОЕКТНОЙ ОРГАНИЗАЦИИ (вторая редакция) Москва 2013 Проектный менеджмент в проектной организации СОДЕРЖАНИЕ 1. ВВЕДЕНИЕ 2. ОСОБЕННОСТИ ПРОЦЕССА РАЗРАБОТКИ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ. 8 3. ОСОБЕННОСТИ ...»
Фактическое выполнение процесса управления исполнением портфеля состоит прежде всего в формировании отчетности по нему. Этот процесс во втором издании стандарта входил в группу процессов «Мониторинг и контроль»; в третьем издании он в явном виде не представлен. Надо полагать, что процесс «Управление ценностью портфеля» (п.6.1.6) включает оценку текущего состояния портфеля, а следовательно – основан на отчетности по портфелю. Кроме того, отчетность косвенно присутствует в процессе «Оптимизация портфеля», который выполнять просто невозможно без знания о текущем состоянии портфеля, т.е. отчетности по нему. Он присутствует косвенно и в процессе управления рисками (п.6.1.5), которые невозможно оценить без знания о текущем состоянии портфеля.
Отчетность по портфелю должна формироваться периодически. Попытки формировать отчетность непрерывно наталкиваются на высокую трудоемкость такого формирования при отсутствии достаточно надежных и легко оцениваемых измерителей текущего состояния проектов. Период отчетности должен быть не слишком коротким (ввиду той же трудоемкости), но и не слишком длинным (ввиду возможного запаздывания реакций на отклонения, повышающего опасность рисков). С учетом текущего состояния технологии проектирования нормальным периодом является месяц. С одной стороны, он хорошо сочетается с распространенной периодичностью оплаты труда; с другой – удачно сопоставим со средней длительностью этапов разработки проектной документации.
6.1.4. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ КОММУНИКАЦИЯМИ ПОРТФЕЛЯ.
УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ ПОРТФЕЛЯ
Процесс «Разработка плана управления коммуникациями портфеля» выполняется вместе с предыдущим («Разработка плана управления выполнением портфеля»), во многом – как его важная часть. По существу способы, техника и порядок осуществления коммуникаций в рамках портфеля определены изначально. Главным положением управления коммуникациями в современных условиях является обязательное наличие базы данных управления портфелем, в которой в унифицированном виде хранятся данные всех входящих в портфель проектов и которая обеспечивает получение выборок данных в требуемом виде.Среди используемых средств коммуникации могут быть портал, электронная почта, интернет-сервисы и т.д. С точки зрения содержания данных необходимо обеспечивать ограничение и дифференциацию доступа к данным по уровням и принадлежности проектов.
Процесс «Управление информацией портфеля» является реализацией предыдущего процесса («Отчетность по портфелю») в ходе управления портфелем. Процесс состоит в реализации различных процедур в рамках управления базой данных и средствами коммуникации.
Проектный менеджмент в проектной организации
6.1.5. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ РИСКАМИ ПОРТФЕЛЯ. УПРАВЛЕНИЕ
РИСКАМИ ПОРТФЕЛЯ
Процесс «Разработка плана управления рисками портфеля» устанавливает порядок действий, необходимых при анализе возможных рисков и реакциях на них. Среди главных рисков – нарушения графиков выполнения работ, перегрузка отдельных специальностей (т.е. нехватка ресурсов), отсутствие или запаздывание необходимой информации, а также внутренние и внешние форс-мажорные обстоятельства. Процесс определяет в частности, общие для всего портфеля принципы идентификации рисков и уровень принятия решений.Процесс «Управление рисками портфеля» представляет собой реализацию процедур, разработанных в рамках предыдущего процесса, в ходе управления портфелем.
6.1.6. УПРАВЛЕНИЕ СПРОСОМ И ПРЕДЛОЖЕНИЕМ. УПРАВЛЕНИЕ
ЦЕННОСТЬЮ ПОРТФЕЛЯ
Процесс «Управление спросом и предложением» в нашем случае выходит за пределы управления портфелем проектов как основной деятельности организации. Он относится к процессам маркетинга и вопросам стратегии организации в условиях рынка.Процесс «Управление ценностью портфеля» включает оценку состояния портфеля и является важным элементом отчетности по портфелю (см. п. 6.1.4).
6.1.7. ПРОЦЕССЫ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ПРОЕКТОВ В ПРОЕКТНОЙ
ОРГАНИЗАЦИИ
Мы рассмотрели процессы управления портфелем, относящиеся к двум группам по классификации стандарта PMI. Из этого анализа выявились взаимосвязи между процессами и их роль в управлении портфелем проектов в проектной организации.Поскольку мы рассматриваем портфель проектов как основную деятельность организации, то сразу обращает на себя внимание группа процессов, которые в условиях инвестиционного портфеля определяли бы некие общие правила управления, характерные для данного конкретного портфеля. В нашем случае эти процессы направлены на создание корпоративных стандартов управления портфелем и не являются постоянно выполняемыми в ходе управления нашим портфелем проектов. Их влияние на портфель выражается через другие процессы, которые входят в группу «Выравнивание» и которые действительно играют основную роль в управлении портфелем проектов.
Учет масштаба проектов, входящих в портфель, как и всего портфеля в целом, позволяет рассматривать процессы из стандарта PMI как отдельные процедуры более крупных процессов в проектной организации. Получается, что процессы двух рассмотренных групп в нашем случае образуют два процесса управления портфелем. Это процессы «Планирования портфеля» и «Отчетность по портфелю». Им в соответствии с нашей буквенной индексацией присвоены индексы В и С соответственно (табл. 6.2 и рис.
6.3).
Сущность процесса планирования в управлении портфелем проектов состоит в нахождении компромисса между требованием безусловного и своевременного выполнения всех входящих в портфель проектов (при том, что время появления, масштаб и характер этих проектов во многом случайны), и настоятельной необходимостью избегать пиковых нагрузок на отдельные виды ресурсов, что влечет за собой экономические потери.
Проектный менеджмент в проектной организации Процессы «Планирование портфеля» (В) и «Отчетность по портфелю» (С) № Процессы групп «Определение» и Решения в процессах управления п/п «Выравнивание» стандарта PMI портфелем проектов в проектной 1 Определение стратегического плана портфеля Разработка и изменение корпораРазработка устава портфеля тивных стандартов управления 3 Разработка дорожной карты 4 Управление стратегическими Изменение корпоративных стандартов 5 Разработка плана управления Разработка и изменение корпорапортфелем тивных стандартов управления 7 Оптимизация портфеля Процесс «Планирование портфеля» (В) 8 Разработка плана управления Разработка и изменение корпораисполнением портфеля тивных стандартов управления предложением 10 Управление ценностью портфеля Процесс «Отчетность по портфелю»
11 Разработка плана управления Разработка и изменение корпоракоммуникациями портфеля тивных стандартов управления 12 Управление информацией Процессы «Планирование портфеля»
13 Разработка плана управления Разработка и изменение корпорарисками портфеля тивных стандартов управления 14 Управление рисками портфеля Процесс «Планирование портфеля» (В) Процесс планирования проектных работ находится на перекрестке практически всех функций проектного менеджмента. Он является одним из средств управления рисками – от качества планирования существенно зависят риски срыва сроков выполнения работ. Он является важнейшим средством управления ресурсами – непосредственно, поскольку определяет расходование ресурсов в процессе выполнения работ. Не в последнюю очередь он является средством управления финансами – поскольку от качественного планирования зависит необходимость и стоимость привлечения дополнительных ресурсов (временных работников, субподрядчиков).
Процесс планирования призван решать две взаимосвязанные задачи (рис.6.4):
1) Формирование плановых документов разнообразного вида;
2) Контроль потребности в ресурсах, иначе говоря – контроль загрузки производственных подразделений.
Планирование делится на два вида: перспективное (или стратегическое), определяющее набор работ и степень загрузки подразделений на длительный период, и оперативное, которое определяет конкретные объемы работ по конкретным работам на относительно короткий период.
Проектный менеджмент в проектной организации В условиях проектной организации обычно периодом перспективного планирования является год. Результатом такого планирования является тематический план на год, включающий все работы, которые должны выполняться в течение года.
Использовать более длительный период для перспективного планирования обычно нереально: потенциальные заказчики не известят заранее организацию о намерении заказать ей разработку проектной документации даже в следующем году, не говоря уже о более далеких планах. Тем более нереально прогнозировать выигрыш разнообразных конкурсов, в которых может принять участие проектная организация. Несколько иная ситуация только в проектных организациях, входящих в крупные холдинги и выполняющих работы преимущественно для нужд этого холдинга. Здесь перспектива загрузки определяется инвестиционными планами холдинга и может быть известна на более длительный период. Тем не менее все равно сколько-нибудь определенные черты тематический план принимает только лишь в начале текущего года. Поэтому говорить о более длительном периоде перспективного планирования вряд ли имеет смысл.
Оперативное планирование имеет своей целью определить конкретные значения планируемых показателей на ближайший период для каждого подразделения по каждой работе. Периодом оперативного планирования, в соответствии с уровнем иерархии, является уже не год, а квартал или месяц. Появлению и распространению месячного планирования способствовали революционные изменения в технологии проектирования, которые привели к сокращению сроков разработки документации, и возросшая конкуренция на рынке проектных работ, потребовавшая более жесткого внутреннего планирования.
Один из первых и очень важных вопросов, которые связаны с планированием проектных работ – это уровень планирования. Планируемый ресурс – рабочее время сотрудников производственных подразделений. В то же время внутри подразделений, как правило, находятся сотрудники разных специальностей, чей ресурс не является взаимозаменяемым. Поэтому планирование на верхнем уровне подразделений не в состоянии выявить моменты перегрузки или отсутствия работ для тех или иных специальностей, а значит – увеличиваются риски срывов. Следовательно, целесообразно вести планирование на уровне отдельных специальностей, в то же время получая сводные показатели на уровне отделов или мастерских. Однако поддерживать два уровня планирования – задача намного более трудоемкая, и при отсутствии средств автоматизации это практически нереально.
Наоборот, наличие средств автоматизации побуждает некоторых руководителей проектных организаций не останавливаться на уровне специальностей, а вести планирование на еще более низком, третьем уровне – на уровне каждого сотрудника производственного отдела. Если речь идет о небольшой проектной мастерской численностью в 15 – 20 сотрудников-проектировщиков, то такое планирование вполне осуществимо и разумно. Однако при такой численности это все равно лишь второй уровень, ведь практически каждая специальность представлена 1 - 2 сотрудниками, количество одновременно выполняемых проектов также сильно ограничено. Но если речь идет о более крупной организации, то в ней неизбежно возникает внутренняя иерархия – деление на отделы, секторы, группы, а значит – появляются руководители этих подразделений. Если не они будут планировать работу своих сотрудников, то ситуация станет неуправляемой, тем более, что вряд ли высший руководитель достаточно компетентен во всех участвующих в проекте специальностях, чтобы формировать планы работ всех сотрудников и, главное, принимать от них результаты с соответствующей оценкой. Кроме того, учитывая сравнительно высокую вероятность невозможности выполнения своих функций отдельными сотрудниками (заболевание, семейные обстоятельства, увольнение и т.д.), разумный период такого планирования работ становится очень коротким (1 – 2 недели). Отсюда следует, что перегрузку, которая Проектный менеджмент в проектной организации может возникнуть через 1 - 2 месяца, при таком планировании предвидеть невозможно, а это существенно повышает степень риска проектной деятельности.
Поэтому глубина планирования существенно зависит от уровня иерархии (рис.6.5).
Другой важный вопрос планирования - выбор количественного измерителя процесса. Поскольку речь идет о планировании использования основных ресурсов – рабочего времени сотрудников производственных подразделений, то естественным измерителем является само рабочее время. Это означает, что для каждой включенного в план проекта необходимо определить потребные трудозатраты на выполнение работ по каждой из участвующих специальностей и, по возможности, распределение этих трудозатрат по времени.
Оценка потребных ресурсов должна основываться на некоторых нормативах, которые опираются на параметры проектируемых объектов, причем такие, которые известны до начала проектирования. Иначе можно будет оценить потребность в ресурсах задним числом, а не на предстоящий период. Однако таких нормативов трудозатрат на сегодняшний день нет. Более того, даже если бы такие нормативы были, им вряд ли можно было бы доверять, поскольку сама технология автоматизированного проектирования очень разнообразна и для каждой специальности существенно зависит от располагаемого технического и программного обеспечения. Иначе говоря, любые такие нормативы, на каком бы уровне они ни были разработаны и утверждены, требуют тщательной адаптации в каждой конкретной проектной организации.
В этой ситуации помочь может только статистика. Надо накапливать данные о количестве человеко-часов, затраченных на разработку проектной документации по тем или иным объектам. В дальнейшем появятся объекты-аналоги, которые будут являться ориентирами на начальной стадии планирования по трудозатратам. Возможно, накопив статистику, можно будет создать внутренние нормативы. Период накопления будет тем короче, чем более узкой является тематика проектов.
При отсутствии нормативов и аналогов по трудозатратам единственным возможным измерителем остается рубль. Есть четыре денежных показателя, которые могут быть использованы в планировании:
1) Объем. Этот показатель позволяет выражать степень готовности результатов работы. На основе интуитивных оценок или по имеющимся внутренним Проектный менеджмент в проектной организации нормативам определяется необходимая на этот период доля основного ресурса – трудозатрат участвующих в непосредственном выполнении работы специалистов.
Эта доля, соотнесенная с договорной ценой, представляет собой объем, который должен быть выполнен к концу планируемого периода, а значит, за вычетом объема, выполненного, согласно отчетности, к началу планируемого периода, – объем, который должен быть выполнен за планируемый период.
2) Отгрузка. Этот показатель определяется как договорная цена работы, результаты которой должны быть выпущены в течение планируемого периода, но не обязательно приняты заказчиком. Это – основной показатель налогообложения, поэтому организации, в которых проектному менеджменту не уделяется должного внимания, ведут по нему планирование особенно охотно. Этот показатель является частным случаем объема – это тот же объем, который планируется только полностью на тот период, когда по календарному плану предстоит завершение 3) Проектная продукция. Этот показатель представляет собой объем работ, который как предполагается, будет принят заказчиком в планируемый период.
4) Реализация – показатель, характеризующий не только сданный, но и оплаченный заказчиком в планируемый период объем работ. Сюда, конечно, может входить и объем работ, принятый заказчиком в более ранние периоды и подлежащий оплате.
Выбop показателя планирования существенным образом влияет на документооборот. Природа этого влияния состоит в том, где находится источник информации в процессе «Отчетность» (рис. 6.6).
Проектный менеджмент в проектной организации Если основным плановым показателем являются объем работ или трудозатраты, то сведения о состоянии работ исходят из производственного подразделения. Их сбор может быть в той или иной мере автоматизирован (например, источником сведений о потраченном рабочем времени специалистов производственных подразделений может быть Timesheet), в оценке состояния работ может принимать участие ГИП (как это обычно бывает при планировании по объему), но офис управления портфелем проектов получает информацию от производственных подразделений.
Напротив, при планировании по отгрузке, проектной продукции или реализации источником информации является офис управления портфелем (в лице плановопроизводственного подразделения в случае отгрузки или проектной продукции, в лице бухгалтерии – в случае реализации); получателями в этом случае являются руководители производственных подразделений. Как видно, направление движения информации между производственными подразделениями и офисом управления портфелем меняется на противоположное, что приводит к полному изменению всей схемы управленческого документооборота как в отчетности, так и в планировании.
Показатели планирования и решаемые на их основе задачи приведены в таблице 6.3. Из таблицы видно, что наиболее широкие возможности предоставляет планирование по трудозатратам. Оно может быть успешно реализовано на всех уровнях, позволяет эффективно учитывать потери рабочего времени (в частности, график отпусков, участие во внеплановых работах и т.д.). Однако проблема – в отсутствии нормативов.
Трудозатраты чел.-час Организация Оценка рентабельности, Если невозможно планировать по трудозатратам, хорошие результаты сулит планирование по объему. Недостатки планирования по этому показателю – некоторая Проектный менеджмент в проектной организации неадекватность оценки загрузки подразделений ввиду разброса договорных цен, а также субъективность оценок состояния работ. Большой опыт и разнообразие подходов к оценке объемов работ позволили несколько нивелировать эти недостатки путем применения достаточно изощренных инструментов.
Например, в некоторых организациях сложилась практика использования переменных коэффициентов фонда оплаты труда для разных договоров. Это позволяет несколько снизить влияние разброса договорных цен и тем самым получить более объективную оценку загрузки подразделений. Однако сам процесс назначения этих коэффициентов носит достаточно субъективный характер.
Остальные показатели, по существу, не позволяют оценивать загрузку подразделений и потому не могут быть признаны исчерпывающими для полноценного планирования работ. Тем не менее существуют искусственные приемы, позволяющие вести оценку загрузки подразделений и при этих показателях. Кроме того, ничто не мешает использовать более чем один показатель. Важно только ясно отдавать себе отчет о цели такого параллельного планирования. Например, организация может вести два показателя – объем и проектную продукцию. При этом оплата работ производственным подразделениям производится по подписанным актам, т.е. по проектной продукции.
Параллельное ведение планирования по объему используется для анализа загрузки подразделений, что снижает риск перегрузок, и позволяет уточнить важные для бухгалтерской отчетности оценки объема незавершенных работ.
Если основным показателем для планирования работы производственных подразделений являются трудозатраты, то обычно используется также и один из денежных показателей, причем, как правило, это не объем. Этот показатель нужен для экономических прогнозов, причем он используется только на верхнем уровне – уровне организации в целом.
Схема процесса. На рис. 6.7 приведен пример схемы процесса «Планирование». В этом процессе в качестве показателя планирования на уровне используются трудозатраты.
Период оперативного планирования - месяц. Исходными данными являются таблицы бюджетного использования (ТБИ), содержащие для каждой работы выделенное количество человеко-часов по подразделениям и их распределение по месяцам, и данные отчетности, из которых известно количество человеко-часов, фактически затраченных каждым подразделением-участником к моменту начала планируемого периода.
Верхний ряд процедур представляет собой действия, относящиеся к перспективному планированию. Создается тематический план на весь текущий год, который периодически корректируется и переутверждается, по мере появления новых работ и возникновения изменений в текущих.
Рассмотрим основные процедуры процесса «Планирование портфеля», касающиеся оперативного планирования.
Определение плановых значений показателей на период. Для того, чтобы сформировать плановые документы, необходимо по каждому показателю, используемому на уровне подразделений, для каждого подразделения определить значение показателя.
Будем для краткости называть это значение суммой плана. Строго говоря, эта процедура должна быть выполнена на уровне управления конкретным проектом. Однако в условиях портфеля проектов она вполне может быть централизована в офисе управления портфелем и, более того, во многих случаях автоматизирована.
Понятно, что если срок завершения конкретного проекта укладывается в планируемый период (и тем более – если этот срок относится к более ранним периодам, но завершения проекта к моменту начала планируемого периода по тем или иным причинам не произошло), то сумма плана должна быть равна Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации R – объем соответствующего показателя на весь проект для данного подразделения (выделенные трудозатраты по таблице бюджетного использования или объем работ в денежном выражении);
SNP – состояние этого показателя на начало планируемого периода. Это значение определяется в процессе «Периодическая отчетность».
Если планируемым показателем являются трудозатраты или объем, то сумма плана равна остатку неиспользованных трудозатрат или невыполненного объема соответственно. Если планируемым показателем являются отгрузка, проектная продукция или реализация и не было промежуточной отгрузки, актирования или оплаты, то SNP=0, и тогда SP=R.
Если проект должен закончиться позже, чем конец планируемого периода, то при таких планируемых показателях, как отгрузка, проектная продукция или реализация, значение суммы плана будет равно 0. Если планируемые показатели – трудозатраты или объем, то сумму плана определить намного труднее. Для этого требуется эрудиция и опыт плановика или ГИПа, хорошо знающих особенности технологии проектирования в организации. Или соответствующим образом настроенные автоматизированные инструменты.
Расчет загрузки подразделений. Определив значения сумм плана для данного подразделения по всем проектам, входящим в портфель, можно путем прямого суммирования определить значение планируемого показателя в целом за период и оценить его.
Если планируемый показатель – трудозатраты или объем, то полученный результат нужно сопоставить с возможностью подразделения выполнить его. При планируемых трудозатратах сравнение производится с фондом рабочего времени, причем это сравнение можно произвести с учетом, например, графика отпусков и статистикой заболеваемости сотрудников. При планировании объемов для такого сравнения берется показатель, называемый производственной мощностью подразделения. Это величина объема работ, которую подразделение способно выполнить без существенных перегрузок и без периодов простоя.
При планируемом показателе отгрузки, проектной продукции или реализации такого рода расчет вовсе не показывает реальную картину загрузки подразделения.
Очевидно, что работы, выпуск (и тем более – подписание акта или получение оплаты) которых предполагается в планируемый период, в значительной мере или даже полностью были выполнены раньше. Поэтому расчет загрузки подразделений, который показывал бы реальную потребность в ресурсе данной специальности, и не только на планируемый период, а на более далекую перспективу, надо вести иным способом, и такие способы существуют.
Балансировка (выравнивание). Если расчет загрузки показывает критическую перегрузку подразделения, необходимо принимать меры. Они могут быть различными – передача части работ на субподряд, привлечение дополнительных работников на временную работу по договорам подряда. Эти меры не всегда экономически эффективны и, как правило, представляют собой меньшее из зол. В некоторых случаях можно обойтись без них, если по некоторым работам имеется запас времени или возможны договоренности с заказчиками о сдвиге сроков выпуска. В таком изменении размещения одной или нескольких работ на временной оси и состоит балансировка – процедура, выполняемая офисом управления портфелем проектов и предназначенная для приведения в соответствие потребности в ресурсах во времени с их располагаемым наличием.
При выполнении этой функции необходимо иметь в виду, что невозможно смещать работы только по одному подразделению. Поскольку участники проекта связаны между собой через обмены информацией, смещение работ одного из участников влечет за собой изменение сроков для других и может вызвать у них пиковую перегрузку. Поэтому такое Проектный менеджмент в проектной организации смещение необходимо производить для всех участников работы и следить за их загрузкой.
Однако на практике перегрузка обычно может грозить только 2 – 3 наиболее загруженным подразделениям; их загрузку и необходимо контролировать в процессе балансировки.
Представление данных. Процедура не показана на схеме, но ее содержание очевидно. Полученные в результате выполнения описанных выше процедур значения сумм плана и загрузки подразделений должны быть представлены всем участникам портфеля проектов – руководству (прежде всего – главному менеджеру офиса управления портфелем проектов), главным инженерам проектов, руководителям подразделений. База данных, поддерживающая управленческие процессы портфеля, должна позволять представление планов и сведений о загрузке в различных разрезах, с разной степенью подробности для специалистов, выполняющих различные роли в офисе управления портфелем проектов и руководящих выполнением отдельных проектов.
Утверждение планов. Документы плана должны быть утверждены руководством офиса управления портфелем проектов. В процессе утверждения руководством могут быть внесены некоторые замечания, которые потребуют внесения изменений. Эти замечания могут быть вызваны приоритетностью тех или иных проектов, взаимоотношениями с заказчиками (например, задержкой платежей) и другими обстоятельствами, известными руководству офиса.
Изменения плановых показателей по отдельным проектам могут повлечь за собой необходимость пересмотра планов управления этими проектами. Например, вполне вероятно, что потребуется пересмотреть некоторые графики выполнения проектов, т.е.
отработка этих изменений будет происходить в процессе А2.
Утверждение плановых документов не означает, что они останутся неизменными в течение планируемого периода. В процессе выполнения планов в них могут вноситься изменения, которые являются реакцией руководства офиса на изменения внешней и внутренней среды организации. В этом случае повторяется, пусть не в полном объеме, выполнение тех или иных функций процесса.
Планирование внутри подразделений. Эта процедура на схеме не обозначена:
она относится к другому уровню планирования.
До сих пор мы рассматривали функции процесса планирования на уровне подразделений. Между тем непосредственное управление производственным персоналом внутри подразделений тоже требует выполнения аналогичных действий. На этом уровне процедуры приобретают свои характерные особенности.
Если количество сотрудников в подразделении достаточно велико, тем более – если сотрудники имеют разные специальности, то подразделение имеет обычно внутреннюю структуру – делится на группы или секторы. В этом случае функции планирования, выполняемые офисом управления портфелем проектов, могут быть распространены на уровень групп или секторов: можно формировать планы отдельных групп, контролировать их загрузку. Тем не менее задача планирования работы конкретного сотрудника не перестает быть актуальной, она просто передается на более низкий уровень иерархии.
Руководитель, непосредственно управляющий работой нескольких сотрудников и планирующий их работу, обычно старается так или иначе документировать свои решения в отношении распределения заданий между ними, закрепления сотрудников за отдельными проектами. Это позволяет ему не упустить из виду необходимость соблюдения последовательности работ в соответствии с технологией проектирования и обеспечения готовности тех или иных проектных документов в установленные извне сроки. Такая внутренняя «бухгалтерия» у каждого руководителя своя, строится по-своему и вовсе не предназначена для внешнего анализа, да порой и непонятна никому извне.
Руководитель, с одной стороны, не любит «перебрасывать» сотрудников с одного проекта на другой, понимая, что ознакомление с новым объектом требует времени. С другой стороны, он хорошо знает сильные и слабые стороны каждого сотрудника и стремится Проектный менеджмент в проектной организации поручать каждому из них то, что у него получается лучше всего; на этой основе прорастает некоторая специализация сотрудников при их достаточной взаимозаменяемости.
Эти особенности непосредственного управления производственным персоналом обычно понятны, но недоступны руководителям более высокого уровня, которые и технологию проектирования соответствующих частей проектов, и деловые и профессиональные качества рядовых сотрудников знают намного хуже. Отсюда, естественно, следует, что планирование работы сотрудников производственных подразделений – набор процедур, которые требуют достаточного уровня конфиденциальности для руководителей подразделений. Это – одно из следствий принципа делегирования полномочий, являющегося одной из основ стандартов системы менеджмента качества.
Однако делегирование полномочий требует достаточной меры доверия со стороны руководителей организации к руководителям низших уровней. Иначе руководитель высшего уровня будет вынужден планировать работу рядовых сотрудников самостоятельно, «через голову» не удостоенных доверия руководителей подразделений.
Несомненно, качество такого планирования будет намного ниже. Да и ответственность за результат такого управления уже нельзя возложить на руководителей подразделений, если окончательные решения по планированию работы сотрудников принимают не они.
По той же причине вряд ли продуктивно стремление некоторых руководителей организаций унифицировать ту самую «внутреннюю бухгалтерию» руководителей подразделений: Если нет цели сквозного контроля управленческой документации внутри подразделений – нет смысла ее унифицировать, каждый руководитель подразделения ведет ее для себя – и пусть ведет так, как ему удобно.
Использование процедур в процессе. Сводную картину использования процедур в процессе описывает табл. 6.4.
Показатели Любое производство нуждается в том, чтобы периодически подводить итоги работы. Эти итоги являются мерилом успешности производственной деятельности, позволяют оценить качество производственных и управленческих процессов, служат базой для планирования работ на последующие периоды, наконец, являются источником данных для развития и совершенствования производства.
В проектном менеджменте процесс отчетности по одному конкретному проекту существенно отличается от процесса отчетности в условиях портфеля проектов. Если речь идет об одном конкретном проекте, то можно различать два вида отчетности:
1) Промежуточная отчетность. Такая отчетность может сводиться к контролю выполнения отдельных этапов проекта, проверке наличия или отсутствия отклонений от графика выполнения проекта. Она может быть приурочена к срокам окончания соответствующих этапов или быть периодической, привязанной к календарю. Такая отчетность реализуется в процессе А3 («Управление исполнением проекта»);
2) Заключительная отчетность. Этот вид отчетности служит для подведения итогов проекта, оценки его результатов и анализа хода процесса для использования этих оценок при планировании будущих проектов. Такая отчетность реализуется в процессе «Завершение проекта».
В условиях портфеля проектов отчетность по всему портфелю бывает только периодической. Действительно, раз портфель проектов бесконечен, заключительная отчетность по нему не может существовать. Основным содержанием отчетности в этом случае является получение общей картины состояния портфеля – его экономические результаты за период. Эти результаты используются в трех направлениях (рис. 6.8):
1) формирование бухгалтерской и налоговой отчетности;
2) как исходные данные для процесса планирования на следующий период;
3) как источник информации для принятия стратегических решений – по изменению структуры, численного и профессионального состава производственных подразделений, принципов планирования и т.д.
Проектный менеджмент в проектной организации Схема процесса. На рис. 6.9 и 6.10 приведены схемы процесса отчетности по портфелю. Для примера использован вариант, когда отчетность (как и планирование работы подразделений) ведется по трудозатратам.
Основным источником информации в этом случае является сам сотрудник производственного отдела. Он отчитывается об использовании своего рабочего времени (процедура PС1.1). Этот отчет может формироваться как в электронном виде, так и на бумажном бланке с последующим вводом. Чтобы данные, представленные сотрудником, были достоверны, необходимы определенные организационные меры.
1) Прежде всего необходимо, чтобы сотрудник был уверен, что представляемые им данные никак не повлияют на его заработную плату.
Это важнейший момент, который должен исключить побуждение сотрудника к сознательному искажению отчетных данных. Поэтому нельзя ставить оплату труда в производственных подразделениях в зависимость от затраченного времени: такое решение будет играть анитстимулирующую роль.
2) Периодичность отчетности должна быть по возможности короткой. Это важно потому, что сотрудник часто решает не отвлекаться на ввод отчетности каждый рабочий день и станет вводить cвой отчет в конце оговоренного периода. Если установить этот период, например, в месяц, то в конце месяца сотрудник вряд ли достоверно вспомнит, чем и сколько времени он занимался в начале месяца; поэтому вводимые им данные, скорее всего, будут недостоверны. Наилучший период – неделя.
3) Технология сбора данных должна быть как можно более простой – с тем, чтобы не отнимать у сотрудника много времени.
Руководитель подразделения должен проверить представленные сотрудником данные (процедуры PС1.2, PС1.3). Дело не в том, чтобы усомниться в представленных данных; просто сотрудник, хорошо знающий, проектированием какого именно объекта он занимается, вместе с тем обычно слабо осведомлен о календарном плане к договору, и может ошибаться в отношении конкретных этапов договора. Поэтому руководитель, работающий с плановой документацией, может внести важные поправки в отчет сотрудника.
Только после проверки данных они сводятся в общую базу (процедура PС1.5) и могут служить источником разнообразных отчетов (процедура PС.6). При этом необходимо, чтобы все подразделения своевременно сдали свои отчеты. За этим следит Администратор Timesheet, который контролирует поступление данных в базу и при необходимости напоминает руководителям подразделений о задержке.
Когда данные за отчетный период собраны, их уже можно использовать для подготовки отчетов. Однако основным их назначением является использование для формирования оперативных планов на последующий период; поэтому они должны быть сопоставлены с плановыми данными. Это выполняет Администратор Timesheet (процедура PС.4).
Вообще Администратор Timesheet является «хозяином» отчетных данных, он отвечает за их сохранность и использование. Нагрузка на него обычно очень невелика, поэтому функции Администратора Timesheet может выполнять практически любой сотрудник офиса управления портфелем проектов наряду с другими обязанностями.
Редко, но бывают случаи, когда в уже сданные отчеты подразделений возникает необходимость внести изменения. Этот момент должен быть оформлен организационно таким образом, чтобы выполнение любых изменений в отчетных данных выполнялось только администратором Timesheet по указанию руководителя процесса.
Конечно, при других показателях отчетности схема будет выглядеть совершенно иначе, как это следует из таблицы 6.5. Например, при отчетности по объему сбор данных, как и при трудозатратах, ведется «снизу вверх», но исходным уровнем этого сбора будет Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации подразделение, а не отдельный сотрудник. Еще сильнее будут отличаться схемы при других отчетных показателях.
Рассмотрим важнейшие процедуры процесса.
Сбор первичной информации. Первичная информация отчетности должна быть собрана в базе данных прежде, чем начнется ее обработка. Содержание этой функции существенно зависит от показателей.
Трудозатраты. Функция сбора данных по трудозатратам имеет установившееся название Timesheet, пришедшее к нам из управленческих технологий Запада и распространившееся у нас в последние годы.
Информация Timesheet в условиях портфеля проектов содержит данные о том, сколько часов потрачено тем или иным сотрудником производственного отдела на выполнение работ, связанных с тем или иным этапом определенного проекта. По существу единица информации в Timesheet представляет собой точку в трехмерном пространстве (рис. 6.11).
Здесь существенна привязка к определенной работе: иначе эти данные не будут представлять собой единицу отчетности по соответствующему проекту. Привязка к дате позволяет приписать эту единицу отчетности к определенному периоду времени, т.е.
обеспечить периодичность отчетности.
Наконец, привязка к определенному сотруднику, по существу, вынужденная, поскольку иначе собрать необходимые отчетные данные просто не представляется возможным. Эта «трехмерность» информации позволяет обобщать ее в самых различных направлениях, в том числе для получения определенных внутренних нормативов трудозатрат, которые в дальнейшем можно эффективно использовать в процессе планирования.
Таким образом, сбор отчетной информации по трудозатратам идет «снизу вверх»
по уровням иерархии.
Достаточно естественными представляются попытки как-то автоматизировать сбор этих данных. Например, были попытки связать их сбор с нахождением сотрудника в определенной среде проектирования, например, с открытием в AutoCAD Проектный менеджмент в проектной организации соответствующих файлов на сервере, как это происходило в технологии «единого проекта». Однако характер проектной работы порой требует от проектировщика открытия совсем других файлов, которые используются, например, как прототипы текущего проектного решения, и тогда автоматизированным образом собранная информация будет вносить искажения в отчетность.
Практика показывает, что при любой организации дела всегда в производственных отделах некоторая часть располагаемого фонда рабочего времени используется на цели, не связанные с выполнением работ по определенным договорам. Это время используется на выполнение различных общественных обязанностей или поручений руководства, подготовку конкурсных предложений (по которым еще никаких договоров, конечно, нет), не говоря уже об отпусках, больничных листах и т.д. Такого рода затраты времени будем называть отвлечениями. Их тоже целесообразно классифицировать и вводить в общую базу Timesheet с тем, чтобы анализировать долю и причины этих потерь, сводя по возможности к минимуму такие из них, которыми можно управлять.
Объем. Данные по объему собираются на уровне подразделений. Источником данных является руководство подразделения, которое оценивает степень готовности соответствующей части проекта. Данные поступают в офис управления портфелем проектов для дальнейшего обобщения. Таким образом, и здесь как в трудозатратах, сбор информации идет «снизу вверх».
Основным инструментом сбора данных в этом случае является документ «Планотчет». Он для данного подразделения содержит перечисление всех работ, которые должны выполняться им в планируемый период. В документе есть пустая графа (или графы), куда руководитель подразделения заносит свою оценку выполненного объема работ.
Здесь, как и в трудозатратах, необходимо принимать меры для обеспечения достоверности собираемых данных. Если объем лежит в основе системы оплаты труда в производственных подразделениях, то руководитель подразделения обычно склонен переоценивать состояние работ, завышать выполненный объем. В этой ситуации важно, чтобы была возможность сторонней оценки; эту роль может выполнять ГИП. Важно только, чтобы у ГИПа был иной стимул в оценке объема – он должен быть заинтересован в своевременном выпуске работы и, следовательно, не стремился бы завышать выполненный объем. Поэтому в плане-отчете принято, что ГИП в случае согласия подтверждает оценку руководителя подразделения своей подписью, и в таком виде документ сдается в офис управления портфелем проектов.
Бывают и обратные ситуации, когда руководитель подразделения не завышает, а, наоборот, занижает свою оценку выполненных объемов работ. Это может происходить, например, в случаях, когда сложившийся документооборот не позволяет руководителю подразделения заглянуть дальше планируемого периода. Тогда, опасаясь недостаточного объема работ в следующий период, руководитель начинает делать «запасы на черный день» - занижать в отчетности выполненный объем с тем, чтобы иметь резерв фонда оплаты труда на последующий плановый период. Это приводит к занижению объема незавершенных работ – с, возможно, отрицательными последствиями для экономики организации. Поэтому необходимо, чтобы руководитель подразделения имел в своем распоряжении инструмент, позволяющий ему заглянуть за «горизонт» планирования и выяснить, есть ли у него достаточная загрузка на последующие периоды.
Конечно, обе такие «стратегии» могут иметь место только в отношении работ, которые имеют свое продолжение в последующие периоды. Оставшиеся объемы по работам, которые закончены в отчетном периоде, должны быть включены в отчет полностью. Но и тут есть особенности. Например, при выпуске документации, подлежащей экспертизе, иногда оставляют некоторый (не более 15 – 20%) объем на случай возможных переделок по ее замечаниям.
Проектный менеджмент в проектной организации Документ «План-отчет» - это, конечно, ручной, бумажный вариант сбора отчетности. При компьютеризированном варианте логика остается той же, только и ввод данных, и согласие ГИПа фиксируются в электронном виде.
Отгрузка. При этом показателе фиксируется отправка проектной документации. C точки зрения показателя отчетности это означает, что в отчет за конкретный период попадают исключительно работы, выпущенные в этот период, и притом, как правило, в полном объеме. По своей трудоемкости такая отчетность значительно проще; кроме того, она легко централизуется в офисе управления портфелем проектов – для этого достаточно построить документооборот так, чтобы офис управления портфелем был включен в маршрут информации, связанной с выпуском, - например, получал копии накладной или уведомления о выпуске. Тогда отпадает нужда в документе «план-отчет».
Поскольку отгрузка является в настоящее время основным показателем, влияющим на налогообложение, то ее фиксация является необходимым звеном бухгалтерского и налогового учета. Однако в бухгалтерских системах эта фиксация не предусматривает распределения выпущенных объемов работ по подразделениям, участвовавшим в их выполнении – для налогового учета в этом просто нет необходимости. Но если система оплаты труда «завязана» на отгрузку, то распределение объема работ между подразделениями выполнять необходимо, и подразделения должны получать отчетный документ, позволяющий вести расчет зарплаты. Поэтому необходима функция «Распределение».
В состав выпускаемой проектной документации могут входить и результаты работы субподрядных организаций, но тут разделение объемов работ происходит вполне естественно.
Проектная продукция. При этом отчетном показателе фиксируется подписание заказчиком акта сдачи-приемки. Первичным документом здесь является подписанный заказчиком акт. В акте указана сумма принимаемой проектной продукции. Для периодической отчетности важен период, в который попадает дата подписания акта заказчиком. Учет таких актов обязательно централизован, и обработкой содержащейся в них информации занят офис управления портфелем проектов. Кроме того, эти сведения должны попадать также и в бухгалтерию, поскольку от них непосредственно зависит состояние дебиторской (а с учетом наличия субподрядчиков – также и кредиторской) задолженности.
Если учет проектной продукции на уровне подразделений не требуется, то необходимо только выделение в этих данных субподрядных сумм. Поскольку в самих актах суммы субподряда в составе принимаемой проектной продукции обычно не выделяются, то эта операция должна производиться отдельно, на основании договорной документации. Дело осложняется, если акт приемки сформирован или подписан заказчиком на неполную сумму этапа. В этом случае необходим содержательный анализ, какая часть субподрядных сумм входит в принятую проектную продукцию.
В некоторых случаях, особенно когда проектная организация выполняет работы по планам холдинга, в состав которого она входит, приемка работ производится помесячно на основании документа, называемого «Форма 4А», который имеет статус акта. В этом случае зачастую никакой отправки документации не происходит, фиксируется только объем работ, выполненный за очередной месяц. Подобным же образом может выполняться приемка работ по авторскому надзору, но такие работы обычно оформляются актом.
Реализация. Здесь требуется учитывать не только наличие подписанного акта, но и получение оплаты. Поэтому первичной информацией, кроме данных о подписании актов сдачи-приемки, является также сведения об оплате. Эти сведения должны поступать из бухгалтерской системы. Важным вопросом в этом случае является способ учета поступившей оплаты. Эти способы различаются по тому первичному документу, с которым сопоставляется поступившая оплата: учет ведется либо по актам, либо по Проектный менеджмент в проектной организации этапам календарного плана. Конечно, каждый акт имеет ссылку на соответствующий договор и этап, и при учете по актам всегда известно, какие именно этапы оплачиваются тем или иным поступлением на счет. Обратная ссылка имеет место не всегда. Поэтому в первом случае необходимо иметь информацию о всех выпущенных актах; во втором случае такая информация не обязательна – важен только факт, что такие акты существуют и они подписаны заказчиком.
Под реализацией понимается сумма поступившей оплаты, которая не меньше суммы принятой проектной продукции по соответствующему этапу. Поэтому для целей отчетности по реализации, вообще говоря, не имеет значения, когда и какими частями была оплачена работа; важно лишь значение поступившей оплаты в данный момент времени, особенно в момент подписания акта и в момент получения последнего платежа. Иначе говоря, для целей отчетности по портфелю проектов не важна история поступления оплаты, важен ее нарастающий итог. В момент подписания акта сумма реализации составляет меньшую из двух сумм – принятой проектной продукции и поступившей оплаты. В момент получения последний оплаты реализация составляет или 0, если нет подписанного акта, или сумму принятой проектной продукции, в частности – полный объем выполненных работ, если акт подписан на полный объем.
В этой связи необходим отдельный учет авансовых платежей – сумм, которые были оплачены заказчиком (инвестором) до подписания акта. Суммы этих платежей учитываются в той или иной степени при формировании актов сдачи-приемки, но до подписания акта не учитываются в реализации.
Наконец, как и для проектной продукции, из сумм реализации необходимо выделять суммы, приходящиеся на субподрядные работы – эти суммы должны быть перечислены субподрядчикам, что может быть сделано как до, так и после подписания генерального акта, по актам субподрядных организаций.
Легко видеть, что в последних трех случаях (отгрузка, проектная продукция, реализация) обработка данных отчетности идет «сверху вниз».
Показатели и уровни применяемой отчетности приведены в табл. 6.5. Направление формирования отчетности для разных показателей в ней обозначено стрелками.
Интеграция данных. Интеграция данных имеет смысл для тех показателей, для которых отчетность в соответствии с табл.1 формируется снизу вверх. К таким показателям относятся трудозатраты и объем. Интеграция этих показателей выполняется по двум направлениям: по уровням (подразделениям и организации в целом) и по работам (этапам и договорам). Цели, достигаемые интеграцией по разным уровням и работам, показаны на рис.6.12.
Эта функция позволяет получать отчетную информацию в разнообразных разрезах, предоставляя обширные возможности анализа.
Распределение. Функция распределения используется для показателей, у которых исходные данные возникают на верхнем уровне (отгрузка, проектная продукция, реализация). Эта функция служит для получения данных отчетности на уровне подразделения. Ее использование имеет смысл только тогда, когда значения этих показателей на уровне подразделений требуется для какой-либо цели – например, определения фонда оплаты труда по соответствующим работам соответственно при отгрузке, подписании акта заказчиком или получении оплаты по сданным заказчику работам. И, конечно, эта функция в обязательном порядке должна выполняться по тому показателю, который используется в планировании.
Представление данных. Эта функция состоит в подготовке разнообразных отчетов, представляющих отчетные данные в разнообразных разрезах. Эти отчеты должны получить руководители организации, все участники офиса управления портфелем проектов, ГИПы – по своим проектам и начальники подразделений – в части, относящейся к этим подразделениям.
Проектный менеджмент в проектной организации Организация Подразделение Сотрудник Важно, чтобы все участники процесса получали отчеты в наиболее удобном для них виде. Этот вид должен способствовать достижению цели, для которой собирались и обрабатывались отчетные данные. Если, например, предстоит распределение фонда оплаты труда в подразделении, то соответствующий отчет, получаемый руководителем подразделения, должен содержать перечень работ, которые попали в отчет за период, с указанием их наименований, объемов выполненных подразделением (или принятых заказчиком, или оплаченных) работ и размеров фонда оплаты труда по этим работам.
Специалистам, занимающимся формированием планов на следующий период, необходимо получить данные о текущем состоянии планируемых работ. И т.д.
Кроме отчетов, которые в основном представляют собой таблицы, возможна подготовка графического материала, облегчающего восприятие данных руководителями проектного производства. Это могут быть, например, круговые или столбчатые диаграммы, отражающие долю тех или иных подразделений (или ГИПов) в общей сумме отчета за период, структуру выпущенных объемов работ по стадиям, по группам заказчиков или отраслевой принадлежности объектов.
Сравнение. Некоторые виды отчетов должны содержать сопоставление планируемых значений показателей с отчетными. Сравнение этих показателей позволяет делать наиболее важные выводы об отклонениях фактического состояния портфеля проектов от запланированного на конец отчетного периода. Эти выводы могут лечь в основу уточненных планов на следующий период, получить оценку качества планирования, а в некоторых случаях побудить руководство организации к стратегическим решениям, влияющим на структуру и развитие организации.
Примером такого отчета (на уровне отдельного проекта) могут служить S-кривые (рис. 6.13).
Это – промежуточный периодический отчет по одному из проектов. Кривые показывают запланированный расход трудозатрат по месяцам нарастающим итогом (зеленая линия), фактические трудозатраты по месяцам на конец ноября 2008 г. (синяя линия) и прогноз трудозатрат на последующие периоды до завершения проекта (красная линия).
Проектный менеджмент в проектной организации Утверждение отчетов. Утверждение отчетов является завершающей функцией процесса. Практически всегда отчеты за период содержат некоторые детали, в которые могут быть внесены изменения в последний момент. Как правило, причины, по которым в отчетные показатели требуется вносить коррективы, связаны с экономическими и налоговыми обстоятельствами. Поскольку портфель проектов представляет собой основную деятельность проектной организации, то окончательный вид отчетных данных за период обязательно должен быть сопоставлен с данными бухгалтерской системы и приняты меры, исключающие или по крайней мере минимизирующие возможные отрицательные последствия неблагоприятных результатов.
Использование процедур в процессе. Сводную картину использования процедур в процессе описывает табл. 6.6.
Показатели Показатели
6.2. ГРУППА ПРОЦЕССОВ АВТОРИЗАЦИИ И КОНТРОЛЯ
Эта группа процессов включает всего два процесса, но они являются едва ли не самыми важными во всем управлении портфелем проектов. Вместе с тем при переходе от второго издания стандарта PMI к третьему изданию эта группа претерпела очень существенные изменения.Во втором издании в группе (которая носила название «Мониторинг и управление») было три процесса: «Мониторинг и управление рисками портфеля», «Обзор и формирование отчетности по исполнению портфеля» и «Мониторинг изменений в стратегии бизнеса». Из этих процессов второй и третий перешли в группу «Выравнивание», а первый, несколько изменив название на более общее («Мониторинг и контроль портфеля»), собственно, и является одним из ключевых процессов управления портфелем. Кроме того, в группу вошел процесс «Авторизация портфеля», который повлиял и на название группы. Суть этого процесса состоит в постоянном подтверждении соответствия процессов портфеля стратегическим целям организации и утверждении соответствующих управленческих решений. Это – еще одно свидетельство трактовки портфеля в стандарте PMI как портфеля инвестиционного; в нашем случае, когда портфель является основной деятельностью организации, его роль сводится только к утверждению управленческих решений, т.е. решений по корректировке планов управления проектами, прежде всего - графиков.
Собственно, мониторинг и контроль портфеля сводится в нашем случае главным образом к контролю за сроками выполнения отдельных работ по проектам и соответствующим реакциям в случае отклонения от плановых сроков. Однако реакции должны исходить не только из внутренних обстоятельств конкретных проектов, но и из ситуации в целом по портфелю, с учетом располагаемых ресурсов и внешних обстоятельств, оказывающих влияние на портфель в целом.
Процесс тесно связан с самой технологией выполнения проектных работ и опирается на результаты процессов А2 («Планирование проекта»), содержащие график выполнения проектных работ, и А3 («Управление исполнением проекта»), которые представляют собой утвержденные изменения в графиках по проектам, входящим в портфель.
Процесс (который мы в дальнейшем будем называть «диспетчеризация» и обозначать буквой D) обеспечивает контроль над состоянием всех проектов и обеспечивает руководство информацией, позволяющей своевременно реагировать на угрозу срыва сроков выпуска проектной документации.
Главным показателем, контролируемым в процессе, является время:
контролируются факты своевременного выполнения тех или иных событий, контрольные даты которых представлены в графиках. Под событием можно, вообще говоря, подразумевать любой имеющий отношение к проекту факт, например, выполнение того или иного расчета, готовность того или иного чертежа и т.д. С этой точки зрения можно дробить процесс разработки проектной документации на сколь угодно мелкие факты. В то же время надо считаться с тем, что если ставится задача контролировать эти факты, то чем более мелкими они будут, тем их будет больше в каждом проекте, и их контроль будет становиться все более и более трудоемким. Кроме того, большинство таких фактов будут влиять на состояние проекта только внутри того или иного подразделения, никак не отражаясь на иных участниках проекта до тех пор, пока не встанет вопрос о передаче информации в другие подразделения, т.е. о выдаче задания. Именно момент передачи такой информации и следует подразумевать под событием: такие события легко контролировать, поскольку в них есть минимум два подразделения-участника. Факт выполнения такого события, таким образом, подтверждается с двух сторон. Количество таких событий не слишком велико, и поэтому организация контроля не требует слишком больших трудозатрат.
Таким образом, график является совокупностью событий, каждое из которых состоит в передаче информации по проекту между подразделениями-участниками, а также окончании работ подразделения по проекту – будь то сдача документации в архив, выдача заказчику или представление ГИПу.
Эффективность процесса существенным образом зависит от качества графика.
Если представить график как последовательность обменов заданиями между подразделениями-участниками с указанием дат, когда эти обмены должны состояться (например, указывается, что отдел А выдает такое-то задание отделу В такого-то числа), то в случае каких-то нарушений можно, конечно, выявить все несостоявшиеся события.
Однако понятно, что большинство этих событий логически связаны между собой, и весьма вероятно, что первопричиной срывов является какое-то одно событие, невыполнение которого повлекло за собой невыполнение остальных. Между тем такой график не содержит сведений о взаимозависимости событий, поэтому выявление такой первопричины потребует от участников процесса определенных усилий и времени.
Поэтому необходимо, чтобы события графика описывали взаимоотношения не между подразделениями, а между событиями: информация, передаваемая в данном событии, используется принимающим подразделением для выполнения такого-то события.
Такой график становится сетевым (рис. 6.14).
Проектный менеджмент в проектной организации В процесс мониторинга и контроля решающее значение имеет организационная сторона. От того, как будет организован процесс, существенным образом зависит его эффективность. Важнейшим вопросом является организация коммуникаций.
Действительно, в этом процессе принимают участие практически все управленческие звенья организации: руководство, офис управления портфелем проектов, ГИПы, руководители подразделений. Поэтому результативность процесса во многом определяется, например, тем, кто, когда и каким образом уведомляется о том, что то или иное событие состоялось. Тут возможны различные решения – от полной централизации информационных связей через сотрудника ОУП, выполняющего функции диспетчера, до, наоборот, полной децентрализации этих связей на основе соответствующих технических средств.
Схемы. Схемы процесса очень разнообразны. На рис. 6.15 и 6.16 приведен пример таких схем.
Первая из этих схем описывает организацию децентрализованного взаимного оповещения участников процесса об изменении состояния событий. Подразделение, которое подготовило очередное событие, оповещает об этом заинтересованных участников процесса (прежде всего ГИПа), зарегистрировав для этого события состояние «Выдача». При этом ГИП получает соответствующее оповещение (например, по внутренней почте). Не имеет значения, на каком носителе и где находится документация, соответствующая этому событию: это может быть оговорено отдельно, но ГИП должен ознакомиться с ней и подтвердить свое согласие (состояние «Контроль») или возражение (состояние «Возврат») – в последнем случае он должен изложить свои замечания. В случае «Контроль» подразделения, нуждающиеся в материалах этого событий, получают оповещение и должны подтвердить приемлемость этих материалов (состояние «Прием») или отклонить материалы, сформулировав свои замечания (состояние «Возврат»). Когда все заинтересованные получатели подтвердили «Прием», событие считается состоявшимся и в базе данных устанавливается фактическая дата его выполнения. В случае «Возврат» снимаются все состояния «Прием» и «Контроль», и после внесения изменений должно быть повторено состояние «Выдача».
ГИП может сделать в графике соответствующие отметки, которые позволяют ему отказаться от контроля некоторых (или даже всех) событий графика. Это особенно важно в случаях командировки или болезни ГИПа – позволяет не останавливать процесс.
Вторая схема иллюстрирует получение и использование результатов процесса.
Предусматривается получение ряда отчетов-выборок из всех утвержденных графиков.
Так, например, отчет «Перечень событий» для начальника подразделения содержит упорядоченный список всех событий, которые должно выполнить его подразделение за определенный период; отчет «Напоминания» включает события, которые должно было выполнить подразделение, но они не выполнены, хотя срок выполнения уже прошел. В этом отчете важную роль играет наличие в графике информации о взаимной зависимости событий: в отчет попадают только те несостоявшиеся события, для которых все события, от которых оно зависит, уже состоялись.
Аналогичные выборки по своим графикам может получить и ГИП.
Наконец, общим отчетом, который предназначен руководству, является «Справка к диспетчерскому совещанию». Он по сути дела представляет собой объединение всех «Напоминаний», т.е. все срывы сроков выполнения событий, которые произошли на текущий момент. Этот отчет служит основным источником информации для принятия оперативных решений, направленных на предотвращение срывов конечных сроков.
Рассмотрим основные процедуры процесса.
Оповещение. Учитывая упоминавшуюся выше большую роль организационной стороны процесса, эта процедура во многом определяет его успешное функционирование.
Если оповещение централизовано, то вся информация должна стекаться к диспетчеру, и уже он регистрирует состояния событий в базе данных. Если оповещение Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации децентрализовано, то сами участники проекта регистрируют в базе данных изменения состояния событий, а диспетчер может лишь наблюдать и вмешиваться в процесс только в случае нештатных ситуаций. В обоих случаях, поскольку вряд ли заинтересованные участники процесса постоянно находятся в базе данных, необходимо, чтобы были использованы те или иные средства оповещения – от бумажного документа до электронного сообщения. Эта проблема снимается и процедура становится ненужной, если в организации работает система технического электронного документооборота: при ее достаточном развитии в ней изначально реализована схема, подобная рис. 6.15 и включающая средства оповещения.
Контроль. Эта процедура, в которой в той или иной мере участвуют все – и ГИПы, и начальники подразделений, и диспетчер, но последний играет в этой процедуре важнейшую роль. Именно он выявляет критические события, за которыми, собственно, и нужен контроль; на схеме рис. 6.15 он для этой цели располагает отчетом «предстоящие события». Остальные участники процесса в этой процедуре контролируют содержание событий – полноту и качество документов, моделей, решений, которыми они обмениваются в ходе работ.
Выявление угроз. Суть процедуры состоит в том, чтобы выявить отклонение хода работ от утвержденного графика как можно раньше, когда еще есть возможность принять меры с целью не допустить чреватого финансовым ущербом срыва конечного срока работы. Эта процедура, доступная в различном виде всем участникам процесса, выявляет угрозы одновременно по всему портфелю проектов. Процедура основана на регулярном выпуске таких документов, как «Напоминания» (доступные как начальникам подразделений, так и ГИПам) и «Справка к диспетчерскому совещанию» (доступная диспетчеру и руководству).
Авторизация. Эта процедура состоит в выработке и утверждении решений, направленных на снижение рисков срыва сроков по тем или иным проектам, с учетом их приоритетов и последствий. Выполняется руководителем основного производства при участии офиса управления портфелем и ГИПов.
Использование процедур в процессе. Общую картину использования процедур в процессе «Диспетчеризация» представляет табл. 6.7.
Показатели
6.3. КАЧЕСТВО УПРАВЛЕНИЯ ПОРТФЕЛЕМ
Мы сформировали три основных процесса управления портфелем проектов в основной деятельности проектной организации.Когда мы рассматривали процессы управления отдельными проектами, было очевидно, что одним из важнейших обстоятельств, определяющих качество управления Проектный менеджмент в проектной организации проектом, является квалификация конкретного ГИПа. В зависимости от его качеств, управление проектом может быть успешным или не очень.
Процессы управления портфелем проектов оказывают влияние на успешность управления всеми проектами портфеля и, в конечном счете, на авторитет, популярность и успех экономической деятельности всей проектной организации.
В уже упоминавшейся книге А.С.Козлова [3] автор сформировал типовые конфигурации офисов управления портфелями проектов в зависимости от качества функционирования тех или иных управленческих процессов. Он дал этим конфигурациям полушутливые наименования, которые на удивление точно отражают достоинства и недостатки каждой из конфигураций. Наш анализ процессов управления портфелем в проектной организации дает нам возможность воспользоваться опытом А.С.Козлова.
Более того, мы сохраняем даже присвоенные им наименования для аналогичных конфигураций.
Таблица 6.8 дает довольно ясное представление о качестве управления портфелем проектной организации, и подобная классификация позволяет руководству организации определить недостатки процессов управления и наметить пути их совершенствования.
Из таблицы видно, что процесс «Отчетность по портфелю» работает всегда:
организация не может существовать без отчетности по основной деятельности. Работа остальных процессов, собственно, и определяет качество управления.
Проектный менеджмент в проектной организации Типичные конфигурации офисов управления портфелем проектов в проектных организациях Типы офисов
7. ВЗАИМОДЕЙСТВИЕ ПРОЦЕССОВ УПРАВЛЕНИЯ В
ПРОЕКТНОЙ ОРГАНИЗАЦИИ
Процессы управления отдельными проектами и процессы управления портфелем проектов тесно связаны между собой. Они взаимодействуют во времени, обмениваются информацией, распределены по уровням иерархии в структуре организации.Как отмечалось выше, процессы управления отдельными проектами (на рис. 7. они обозначены А1 – А4), в отличие от процессов управления портфелем проектов (процессы B, C, D), одновременно выполняются для нескольких проектов и не имеют жесткой привязки к календарю.
На рисунке видно взаимное наложение процессов управления проектами (А1 – А4) и привязка процессов управления портфелем проектов к календарю. Характерно, что длительность периода процесса D («Мониторинг и контроль»), значительно меньше, чем длительность периодов процессов В и C. Действительно, если период этих последних процессов (месяц, квартал) по крайней мере сравнима с длительностью работ по некоторым договорам или их этапам, то период процесса «Мониторинг и контроль»
должен быть значительно короче, т.к. иначе этот процесс не сможет достигать своей основной цели – раннего предупреждения об отклонениях в проектах, которые потенциально могут быть источником риска нарушения сроков их выпуска.
Рис. 7.2 иллюстрирует информационные обмены между процессами.
Потоки данных между процессами должны быть регламентированы по времени и ответственным. Источником данных должна быть база данных управления портфелем, что гарантирует их единообразие и достоверность.
На рис. 7.3 показан пример распределения основных процедур процессов между уровнями иерархии в проектной организации. Пример построен для случая, когда основным показателем планирования работы подразделений являются объем или трудо затраты:
сбор отчетности идет «снизу вверх» по уровням иерархии.
Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации
8. НОВЫЕ ФОРМЫ ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ
Бурный прогресс информационных технологий, изменения в законодательстве, развитие строительной индустрии постоянно вносят изменения в процессы разработки проектной документации, предъявляя все новые требования к процессам управления этим видом деятельности. Изменения столь быстры и кардинальны, что было бы наивно надеяться предвосхитить необходимые изменения в практике управления разработкой проектной документации. Тем не менее пытаться это делать необходимо, потому что иначе управление может превратиться в тормоз развития отрасли. Давайте попытаемся это сделать.Среди существенных изменений в организации разработки проектной документации в последнее время наблюдаются две основных тенденции. Рассмотрим некоторые соображения о их влиянии на процессы управления.
8.1. СЛИЯНИЕ СТРОИТЕЛЬНЫХ И ПРОЕКТНЫХ ОРГАНИЗАЦИЙ
Исторически сложилось так, что в Советском Союзе производство проектной документации и строительство объектов недвижимости были организационно разделены.Россия, как и большинство постсоветских стран, унаследовали это разделение. В 90-е годы среди проектных организаций существовало стремление взять на себя, помимо разработки проектной документации, также и (хотя бы частично) функции заказчика, но успешно совместить эти функции редко кому удавалось.
В последнее время наметилась некоторая тенденция объединения в одном юридическом лице функций проектировщика и подрядчика. Этот процесс идет с двух сторон. Иногда крупные строительные фирмы создают у себя проектные организации, разрабатывающие проектную документацию с учетом сложившихся технологических особенностей, конструктивных решений и внутренних нормативов. Такая структура строительной фирмы позволяет оперативно реагировать на меняющуюся обстановку на рынках проектных и строительных услуг, создает конкурентные преимущества в глазах заказчиков благодаря комплексности предоставляемой услуги.
В других случаях (правда, реже) проектная организация приобретает или создает строительный бизнес, получая те же самые преимущества.
Подобной практике способствуют также изменения в технологии проектирования.
Распространение BIM-технологий, обеспечивающих создание информационных (как правило, трехмерных) моделей проектируемых объектов, позволяет сократить и упростить работы по подготовке строительного производства, что приводит к сокращению сроков и снижению себестоимости строительства. Более того, такие модели в дальнейшем могут служить информационной основой системы эксплуатации объекта.
Управление основными технологическими процессами разработки проектной документации в подобных организациях обычно существенно зависят от того, каким образом создавалась подобная организация. Если она создавалась на основе строительной фирмы, ее руководство обычно пытается механически распространить сложившийся управленческий документооборот строительной организации на управление разработкой проектной документации. Но строительство, как более крупное по своему масштабу производство, имеет значительно более сложный документооборот, чем тот, который требуется в проектировании: там участвуют разнообразные материальные ресурсы, строительная техника; использование этих, достаточно дорогих, ресурсов требует усложненной отчетности и более тщательного планирования, чем в разработке проектной документации. Поэтому такой подход переусложняет управление, является источником избыточных затрат.
Проектный менеджмент в проектной организации Если «первую скрипку» в организации играет разработка проектной организации, картина, как правило, получается обратной, и тогда потребности строительного бизнеса оказываются на первых порах ущербными, так что требует время и определенные усилия, чтобы управление строительным процессом довести до необходимого качества.
Рассмотрим, как влияет эта ситуация на управленческие процессы в проектной части организации.
Управление проектами Понятно, что структура договоров в такой организации много сложнее, чем в чисто проектной организации: договоры, как правило, охватывают не только проектирование, но и строительство объектов, поэтому в договорах должны быть оговорены многие обстоятельства и особенности, касающиеся именно строительства объекта, не говоря уж о том, что законодательство предъявляет к договорам на строительство ряд дополнительных требований. Выполнение проектных работ, особенно – рабочей документации, в таких договорах обычно выделяется как отдельный этап. Однако ранние стадии проектирования вполне могут выполняться по отдельным договорам, поскольку их результаты подлежат различным согласованиям.
Планирование проектов в таких организациях, особенно если их основу составляет строительное производство, ведется на основе «тяжелых» систем управления проектами (Microsoft Project, Primavera). Их использование вытекает из их хорошей приспособленности к управлению строительством, но избыточно и потому достаточно неудобно для управления разработкой проектной документации (см. главу 3).
Процесс завершения проекта в случае рабочей документации является по существу внутренним процессом в организации и потому предельно упрощен; на ранних стадиях проекта он ничем не отличается от такого процесса в чисто проектных организациях.
Управление портфелем проектов В таких организациях объем портфеля (т.е. количество параллельно выполняемых проектов) обычно невелик. Только у самых крупных строительных холдингов он сравним с портфелями самостоятельных проектных организаций. Однако в этом случае проектная организация имеет определенную «автономию», и ее внутренние процессы управления в меньшей степени зарегулированы корпоративными стандартами холдинга. В любом случае планирование портфеля строится исходя из плана работ строительной части организации и ее потребности в проектной документации, поэтому портфель проектной части в основном формируется единовременно (см. начало главы 5). Показателем планирования и отчетности, доводимым до нижнего уровня иерархии, обычно является отгрузка (т.е. выпуск проектной документации), поскольку основную часть плана составляет рабочая документация, используемая внутри организации.
В конечном счете можно сформулировать, что качество управления разработкой проектной документации в подобных структурах существенно зависит от меры самостоятельности проектной части компании – чем выше эта самостоятельность, тем, при прочих равных, выше качество управления.
8.2. УЧАСТИЕ ФРИЛАНСЕРОВ В ПРОЕКТИРОВАНИИ
Прогресс информационных технологий во многих сферах деятельности позволил обеспечить возможность рассредоточения участников производственного процесса.Наиболее характерным примером таких видов деятельности является оффшорное программирование, состоящее в разработке программного продукта высококвалифицированными программистами, находящимися далеко от создающий продукт организации. Аналогичным образом устроено и оффшорное проектирование, которое может быть организовано с участием квалифицированных проектировщиков, находящихся вдали от проектной организации. Собственно, участие в проектных работах Проектный менеджмент в проектной организации субподрядной организации – уже шаг к подобному разделению труда. Но когда таким образом – в удалении от проектной организации, работают физические лица (фрилансеры), возникают совершенно особые коллизии в управлении производственным процессом.
Такая форма организации проектных работ становится характерной для небольших провинциальных городов, где физически невозможно собрать воедино коллектив проектировщиков разных специальностей: специалисты живут в окрестных городах и редко контактируют между собой лично. Для проектирования небольших объектов любого назначения такая организация работы оказывается необычайно выгодной:
обращение к крупным проектным организациям в больших городах влечет за собой большие накладные расходы на командировки. В тоже время себестоимость разработки проектной документации оказывается значительно более низкой – минимальные расходы на аренду помещений, меньше управленческого персонала.
Обычно структура проектной организации, работающей на такое основе, строится примерно так.
Имеется компактная «головка» - руководство организации, минимальный управленческий персонал, несколько ГИПов и несколько хороших профессионалов по основным специальностям – конструкторы, архитекторы, электрики, всего – в пределах – 20 человек. И достаточно широкий круг специалистов-фрилансеров в разных городах, работающих с организацией на основе договоров подряда, заключаемых для выполнения каждого конкретного проекта. Специалисты в «головке» играют роль начальников отделов и главспецов, их роль – качественная проверка разработанной фрилансерами документации, иногда - принятие наиболее ответственных проектных решений, координация работы участников проектов, ведение архива. Взаимодействие участников работы строится на основе портала, обеспечивающего удобные оперативные коммуникации.
Какие последствия влечет за собой такая организация производства для управленческих процессов?
Управление проектами В инициации проекта большое внимание уделяется юридической стороне оформления взаимоотношений с фрилансерами – ответственность, точные формулировки требований. При планировании проекта принимаются дополнительные меры снижения рисков (подстраховка, резервирование времени); повышенное внимание к качеству графика. В завершении проекта – выполнение обязательств в отношении оплаты работ, резервирование средств на эти цели. В целом управленческие трудозатраты несколько выше, чем в обычных проектных организациях.
Управление портфелем проектов Здесь роль офиса управления портфелем несколько принижена – каждый проект управляется отдельно, одновременное участие одних и тех же исполнителей в разных проектах встречается относительно редко, поэтому вопросы загрузки касаются в основном «головки». Такие показатели, как трудозатраты, вообще не могут использоваться в планировании портфеля (хотя могут, имея формальный характер, участвовать в отчетности, если того требует заказчик), основными показателями планирования являются проектная продукция и – особенно – реализация. К диспетчеризации – повышенное внимание.
В целом такая форма организации проектных работ перспективна там, где речь идет о проектировании достаточно массовых и, как правило, небольших объектах в некрупных населенных пунктах.
Проектный менеджмент в проектной организации Вернемся теперь к вопросам, которые мы поставили во введении. Точнее – к первому из них: применимы ли к сфере их деятельности процессы управления проектами, описанные в вышеупомянутых документах? Если да, то - в какой мере?
Результаты наших рассуждений позволяют ответить на этот вопрос безоговорочным «да». И меру этой применимости мы обсудили достаточно подробно.
Однако мало этого. Мы получили инструмент, который позволяет анализировать сложившиеся системы управления основной деятельностью проектных организаций, выявлять их слабые места, готовить рекомендации по их совершенствованию. Некоторые специалисты считают, что такие возможности сами по себе, без всяких средств автоматизации, обеспечивают качество управления основными производственными процессами. Полагаем, что это не так: без поддержки средствами автоматизации даже самые лучшие организационные управленческие решения сами по себе не способны обеспечивать хорошую управляемость. Именно автоматизация дает надежную оперативную поддержку управленческих решений достаточной и качественной информацией, снижает риск ошибок, и при этом еще и снижает затраты труда управленцев. Да, при этом от них требуется высокая квалификация и исполнительская дисциплина. Но без этого невозможно надеяться на хорошие результаты.
Поэтому естественно, что начатая этой книгой работа требует продолжения.
Необходимо обсудить подходы к автоматизации управленческих процессов, алгоритмы выполнения тех или иных процедур.
Что касается остальных двух вопросов, а именно:
- какие особенности их сферы деятельности и каким образом отражаются на процессах управления проектами?
- как строить систему управления основной деятельностью проектных организаций на основе процессов, описанных в этих стандартах? – полагаем, что прочитанная Вами книга эти вопросы осветила в достаточной мере.
Проектный менеджмент в проектной организации
ЛИТЕРАТУРА
1. Руководство к своду знаний по управлению проектами (Руководство РМВОК).Пятое издание. Project Management Institute.
2. Стандарт управления портфелями. Второе издание. Project Management Institute.
Перевод Московского отделения PMI ( ISBN 978-5-905746-01-7).
3. Козлов А.С.. Методология управления портфелем программ и проектов. «Проектная практика», Москва, 2009.
4. Козлов А.С.. Управление портфелем программ и проектов: процессы и инструментарий. «Проектная практика», Москва, 2010.
5. Международный Стандарт по Управлению Проектами ISO 21500:2012.
http://splaniroval.ru/blog/best-practice/378.html 6. Селиховкин И.. Выступление на Life sciences invest. http://pmlead.ru/?p= 7. Zanotti Emmanuele. Assemblea Gen 2013 – 3. Portfolio Management 3rd edition.pdf.
8. ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектами».
9. ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелями проектов».
10. Ревин А.. Новые издания стандартов PMI. Что новенького? Доклад на Международном форуме по управлению проектами 15 марта 2013 г.
11. Шефов А.А. Многопроектное управление в проектных организациях России:
итоги, традиции, тенденции / Материалы Всемирного конгресса по управлению проектами “Проектно-ориентированные бизнес и общество”. - М.: СОВНЕТ, 2003.
12. Ходунов А.М. Эффективность функционирования автоматизированных систем управления в проектных организациях. «Обзоры по электронной технике», серия 7, вып. 4(1177). Москва, ЦНИИ «Электроника», 1986.
Проектный менеджмент в проектной организации
«