Определения

В теории термин "окружение проекта" понимается в очень широком смысле. В окружение проекта может быть включено:

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

• бизнес - среда: преимущественный способ ведения бизнеса в дан­ной местности;

• географическая среда, соседство;

• экологическая среда;

• социальная и политическая среда;

• различные субъекты, имеющие то или иное отношение к проекту. Наиболее важным элементом окружения проекта являются участни­ки и соучастники. В английском языке для обозначения как участников, так и соучастников используется одно слово stakeholder. К сожалению, адекватного перевода этого термина на русский язык не существует. Комплекс слов, описывающих трактовку термина stakeholder, вклю­чает: участник, соучастник, сосед по границе, влияющее лицо, заин­тересованное лицо. В русском языке слово "участие" подразумевает непосредственное выполнение каких-то действий. Слово stakeholder, помимо значения участия, имеет еще значение "существование". На­пример, компания купила земельный участок и намерена проложить дорогу к нему. Допустим, существует три альтернативных варианта прокладки трассы дороги, причем в каждом варианте дорога пройдет по участкам, принадлежащим трем независимым собственникам. Все три собственника будут иметь какое-то отношение к проекту, даже не подозревая об этом. Только один из них станет прямым участником проекта, тот, по участку которого пройдет дорога.

Примечание.

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

(2) Термин stakeholder часто путают с близким по звучанию терми­ном shareholder, которое имеет значения акционер, пайщик, участник коммерческого общества.

Автор данный книги предлагает пользоваться наряду с термином "участник проекта" и термином "соучастник проекта", чтобы выделить весь круг субъектов, имеющих какое-то отношение к проекту. Общее определение соучастника проекта состоит в следующем:

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

Участником проекта называется юридическое ши физичес­кое лицо, осуществляющее какие-либо действия по выполне­нию проекта;

Каждый участник одновременно является соучастником; не всякий соучастник имеет статус участника

К числу соучастников проекта, в частности, могут быть отнесены:

* департаменты компании, если они могут быть лишены части ре­сурсов вследствие выполнения проекта;

* внешние административные органы, предоставляющие какие-то разрешения или имеющие полномочия на вмешательство в ход вы­полнения работ;

* конкурирующие компании, особенно, если у них есть возможности для противодействия;

• население и/или соседи в географическом месте выполнения проекта;

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

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

Организационная схема проекта

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

Организационная схема проекта состоит из трех уровней:

1. уровень 1: непосредственное управление проектом (уровень проекта);

2. уровень 2: позиционирование управляющей команды в общей схе­ме компании (уровень компании);

3. уровень 3: управление с привлечением сторонних организаций, включая всех соучастников проекта (внешний уровень).

Схема уровней управления показана на рис. 37

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

Задача проектного менеджера при управлении своей командой со­стоит в нахождении баланса между7 необходимой дисциплиной и мак­симальным использованием творческого потенциала.

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

Рисунок 37. Уровни управления проектом

Привлечение специалистов может принимать формы:

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

• периодическое участие (например, один день в неделю);

• участие для выполнения определенных функций (проведение пла­тежей. технадзор);

• делегирование специалистов на ограниченный период времени. Участие других департаментов в управлении проектом может быть

Основано не только на прямом участии работников этих департаментов, но и с разделением подчиненности. В схеме с разделением подчинен­ности участники команды имеют два типа подчиненности: линейное и функциональное (на рис. 37 линейному подчинению соответствуют прямые линии, а функциональному — пунктирные линии). При ли­нейном подчинении руководитель распоряжается рабочим временем подчиненного, дает ему поручения. При функциональном подчинении участники команды должны согласовывать свои действия, методику работы с другими департаментами компании. Например, проектные финансисты согласовывают свои действия с финансовым департамен­том компании, юристы — с правовым и т. д.

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

• по функциям;

• по выполнению бизнес - процессов;

• по персоналу и его подчиненности;

• по полномочиям;

• по ответственности.

К сожалению, пока в России матричные схемы не удается полноцен­но внедрять. Кстати, и на Западе матричные схемы не идут "на ура".

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

1. договор с физическим лицом подрядного характера;

2. договор с юридическим лицом.

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

• исполнение функций руководителя проекта (в случае юридическо­го лица можно говорить о полноценной управляющей компании);

• предоставление консультаций;

• делегирование специалистов (сдача персонала в аренду, без переда­чи ответственности за исполнение проекта на арендодателя);

• разработка плана проекта;

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

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

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

• управление отношениями с контрагентами и внешними участниками:

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

• выполняемые функции:

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

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

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

Стороны заказчика; о право заказчика требовать замены специалистов;

• форма отчета, график отчетности;

• конкретный перечень ответственности компании-исполнителя.

На Западе применяется и вариант полной ответственности управ­ляющей компании — управляющий несет материальную ответствен­ность за неисполнение бюджета иди срока исполнения проекта.

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

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

Резюмируем сказанное по вопросу организационных схем. Продю­сер проекта при конструировании организационной схемы должен сле­довать правилам:

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

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

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

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

Система взаимодействия

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

Принятие решений

На старте проекта должны быть распределены полномочия между участниками проекта. Часть этих полномочий необходимо подтвер­дить соответствующими официальными документами (доверенности, письма). Особо следует выделить статус проектных совещаний. Кто является председателем совещаний? Насколько обязательными явля­ются решения совещаний для участников проекта?

Способ передачи документов

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

Таблица 31. Способы передачи документов Название способа Характеристика Электронный + бумажные экземпляры основных документов На бумаге сохраняются только докумен­ты, имеющие правовой статус (догово­ры, бухгалтерские документы) Электронный + бумажные дубликаты всех документов Для ускорения все документы сначала передаются в электронном виде, а затем дублируются в бумажном виде Бумажный документооборот Электронный документооборот исключен

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

Дополнительно, все участники должны согласовать точки входа-вы­хода документов и способы их регистрации. Это требование, в особен­ности, относится к электронным документам. Простота электронной передачи не должна приводить к бессистемному, нерегистрируемому потоку информации.

На практике указанное требование сводится к правилам:

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

О особо следует обратить внимание на способ нумерации версий

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

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

О рабочие документы (не носящие обязательный характер) могут

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

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

Списки рассылки

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

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

Электронная среда

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

• управление офисными документами, обыкновенно - MS Office;

• средства календарного планирования (MS Excel, Visio, Project);

• графические и чертежные программы;

• средства коллективной работы, порталы.

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

Способ согласования документов

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

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