Под внутренним управлением проектом понимают ситуацию, когда проектная команда работает целиком в пределах существующей организационной структуры, а под внешним - ситуацию, когда нанимается внешний руководитель проекта, работающий как внешний агент по поручению клиента (рис. 3.1). Оба подхода имеют свои достоинства и недостатки.
Рис. 3.1. Внешнее управление проектами
Достоинства внутреннего управления проектами:
· большая гибкость в использовании персонала;
· отдельные эксперты могут быть задействованы в ряде проектов;
· специальные знания легко аккумулируются и распространяются внутри организации;
· стабильность обеспечивается независимо от смены отдельных личностей.
Недостатки внутреннего управления проектами:
· руководителю проекта необходимо много дипломатии при переговорах с функциональными менеджерами относительно ресурсов;
· нарушение принципа единоначалия;
· принятие решений, оплата труда и др. находятся в поле напряжений между функциональным подразделением и проектной командой.
Достоинства внешнего управления проектами:
· внешний руководитель проекта может быть нанят на требуемое время;
· команда проекта дисциплинарно подчинена руководителю проекта;
· функциональные структуры организации существенно не влияют на работу команды проекта;
· проект быстро реагирует на изменения среды;
· использование внешних специалистов обогащает организацию новыми идеями и подходами;
· работы, для которых внутри организации нет подходящих специалистов, могут быть поручены внешним экспертам;
· команда проекта может быть легко сокращена или расширена в зависимости от изменения потребности.
Недостатки внешнего управления проектами:
· внешние специалисты обычно дороги;
· коммуникация осуществляется через границы организации (преодоление барьеров);
· цели внешнего руководителя могут быть далеки от целей организации;
· претензии к внешним специалистам и организациям трудно реализовать, а уровень возможного контроля и управления ими ограничен;
· требуются дополнительные административная и контрольная системы, а также необходимо подключение к проекту дополнительных внутренних подразделений (например, юридического отдела);
· требуется более четкий контроль коммуникаций, когда они пересекают границы организации. Коммуникации с внешними специалистами могут приводить к контрактным осложнениям;
· не накапливается опыт внутри организации;
· команда проекта менее привержена организации;
· выше требования к трансферу рисков и контролю контрактов.
Организационная структура проектов с внешним управлением
При совместном выполнении проектов рядом независимых предприятий в рамках кооперации появляется множество дополнительных вопросов. Основанием для них могут быть вид кооперации, сложность, объем и риск проекта, объем финансирования, ограниченные ресурсы предприятий и т.д. В кооперации системное руководство проектом часто поручается одному из предприятий, либо каждое предприятие направляет минимум одного своего представителя в совместную команду проекта. Правовые формы при этом могут быть различными. Примером таких совместных проектов служат проекты трансфера технологий из научно-исследовательских организаций в промышленные предприятия.
Форма проектов с внешним управлением часто используется небольшими предприятиями как более гибкий подход, особенно для предприятий с переменным объемом работ. При этом может быть приглашен только внешний руководитель проекта, а команда проекта формируется: а) полностью из своих людей; б) из своих работников и приглашенных экспертов. Но команда проекта может быть и полностью внешней. Внешние эксперты могут работать в нескольких проектах, в том числе и для разных организаций.
Система внешнего управления проектами позволяет обеспечить ценовую конкуренцию. Обычно проекты выполняются на основе подробных контрактов разных типов, включающих целый ряд условий. При этом организация-заказчик зачастую создает у себя специальное подразделение, действующее в качестве формального интерфейса между нею и проектом. Взаимодействие с обеих сторон обычно осуществляется с участием юридических отделов. Кроме того, поскольку при внешнем управлении существуют развитые связи между организацией и проектной командой, организации могут создавать также специальные группы/подразделения контроля изменений. Они отслеживают решения об изменениях в проекте и согласуют их в соответствии с внутренними правилами организации и условиями контракта (рис. 3.2).
Рис. 3.2. Внешнее управление большими проектами |
Линии управления (власти и контроля), контрактные связи и коммуникационные связи могут быть идентичными, но могут идти и разными путями в организационной структуре. В приведенном на рис. 3.3 примере руководителю проектов предоставлено право давать указания и контролировать внешних контракторов и консультантов. Однако риск того, что контрактор и консультанты будут действовать некорректно, а соответственно, и платежи, остается за клиентом.
Линии управления Контрактные связи Рис. 3.3. Пример возможных управленческих и контрактных связей |
Теоретически совершенно недопустимы прямые коммуникационные связи (минуя руководителя проекта) между клиентом и структурами проекта. Классическим результатом таких коммуникационных связей является «ползучее» увеличение объема работ (creeping scope) и эскалация издержек проекта. В то же время заказчики зачастую не только хотят иметь информацию «из первых рук», но предпочитают, чтобы их специалисты могли непосредственно взаимодействовать со специалистами, работающими в проекте. Это, конечно, не нравится руководителю проекта, но запретить такие контакты практически невозможно. Поэтому их приходится позволять, но при этом необходимо четко и недвусмысленно разъяснить заказчику, что любые обещания исполнителя, касающиеся объема или технологии выполнения работ, могут иметь силу только после согласования с руководством проекта.
Основные типы контрактов на выполнение проектов
В международной практике наибольшее распространение получили следующие типы контрактов на выполнение проектов:
• контракт с фиксированной ценой;
• контракт с отчетной калькуляцией;
• контракт с периодическим возмещением затрат;
• контракты с целевой стоимостью.
В контрактах с фиксированной ценой издержки проекта согласуются и фиксируются до начала проекта. В больших проектах это происходит обычно в форме конкурентного тендера. При этом цена может быть абсолютно твердой, и тогда контракторы неизбежно будут требовать повышенную цену, чтобы застраховаться от риска возможного увеличения цен на товары поставщиков. Одни клиенты предпочитают контракты с твердой ценой (риск исполнителя), а другие - контракты с изменяемой ценой (риск клиента). Компромиссом является контракт с фиксированной ценой с возможной корректировкой. Клиент при этом берет на себя риск возрастания цены в период выполнения проекта, но только по определенным позициям сметы. По остальным позициям риск остается за контрактором. Часто в контракте предусматривается определенная премиальная сумма, выплачиваемая клиентом в зависимости от того, насколько контрактор уложился в фиксированный бюджет. При этом клиент может потребовать права жесткого контроля над расходом средств, предусмотренных в проекте на оплату соисполнителей, а также резервных сумм бюджета проекта. Контракт с твердорасчетной ценой требует от контрактора тщательной подготовки проекта до выхода на тендер.
В контрактах с отчетной калькуляцией фактические издержки оплачиваются клиентом полностью и часто фиксируется прибыль исполнителя. Для таких контрактов риск исполнителя низок. Такой тип контрактов используется в случаях, когда нет возможности рассчитать с приемлемой точностью издержки проекта. Контрактор при этом обязуется приложить все силы, чтобы обеспечить высокую эффективность использования средств, но прибыль его зафиксирована независимо от этого. Преимуществом такого типа контрактов является то, что не требуется очень глубокой предварительной проработки содержательной части проекта (например, минимум конструкторской проработки). Заявка на тендер может быть подготовлена быстро и с малыми расходами контрактора.
Более гибкими являются контракты, в которых прибыль контрактора устанавливается в процентах от фактических затрат, но при этом у исполнителя нет стимула к сокращению издержек проекта. Выходом из положения являются так называемые издержки-плюс (cost-plus) контракты. В них прибыль исполнителя рассчитывается по согласованным формулам, в которых производится сравнение фактических и целевых издержек.
Контракт с периодическим возмещением затрат является альтернативой предыдущей форме. Контрактор выполняет проект за счет своих средств и ежемесячно предъявляет счет, включающий издержки за прошедший месяц и соответствующую долю прибыли. Размер прибыли может быть как фиксированным, так и переменным. Он может как возрастать пропорционально издержкам, так и снижаться при возрастании издержек. Используются также варианты, когда экономия издержек делится между исполнителем и клиентом.
Контракты с целевой стоимостью предусматривают некоторую согласованную между клиентом и контрактором целевую стоимость проекта плюс прибыль контрактора. Если стоимость превышена, прибыль контрактора может быть уменьшена. И наоборот, если издержки будут ниже целевых, прибыль контрактора может быть увеличена. Это снижает риск клиента за счет того, что у контрактора появляется стимул к снижению издержек проекта.
Смысл рассмотренных типов контрактов можно проиллюстрировать на основании практики выполнения хозяйственных договоров на НИОКР, выполнявшихся вузами и НИИ по заказам Министерства обороны СССР и оборонных отраслей промышленности. Существовало два основных типа договоров - договор с отчетной калькуляцией и договор с уточнением сметной стоимости.
По договорам с отчетной калькуляцией ориентировочно определялась общая сумма договора, а оплата производилась на основании документально подтвержденных и принятых заказчиком фактических затрат проекта. Оговорка относительно принятия затрат заказчиком не случайна. К примеру, заказчик вовсе не был обязан компенсировать расходы по заработной плате с соответствующими начислениями исполнителям проекта, которых обком КПСС заставил направить на строительство сельхозобъектов. Кроме того, у бюджетных организаций не начисляется амортизация основных средств, но оборудование ведь изнашивается. А приобретать за счет средств проекта можно было только специализированное оборудование, необходимое именно для данного проекта. Как же тогда приобретать рядовое оборудование? В особо сложном положении находились научно-исследовательские организации, у которых доля бюджетного финансирования была мала (например, 10-15 %), а доля работ оборонного назначения доходила до 70 % и выше.
Более приемлемым для них было заключение договоров с уточнением сметной стоимости. Идея состояла в том, что после выполнения значительной части проекта, когда неопределенность относительно объема предстоящих работ снижена до минимума, производилась проверка и приемка фактических затрат и уточнение предстоящих затрат. В результате определялась уточненная сметная стоимость проекта. После этого этапа заказчик терял право проверки затрат исполнителя, получавшего определенную свободу действий. Заказчик, естественно, стремился приблизить момент (веху) уточнения сметной стоимости как можно ближе к концу проекта, чтобы сохранить право контроля над финансовой деятельностью исполнителя. Исполнитель в свою очередь стремился добиться смещения этой вехи как можно ближе к началу проекта.
Отдельные типы контрактов могут иметь ряд различных форм:
- стандартный контракт;
- контракт на профессиональные услуги;
- контракт на поставки;
- соглашения с субконтракторами:
- соглашения с обычными субконтракторами;
- соглашения с номинированными субконтракторами;
- про-форма контракты.
Стандартные формы контрактов задают ясные сроки и условия контрактов. Эти формы обычно создаются ассоциациями или арбитражными судами, т.е. органами, в задачи которых входит защита интересов клиентов, контракторов, субконтракторов и всех других лиц и организаций, которые могут быть стороной контракта.
Формы контрактов на профессиональные услуги обычно создаются соответствующими профессиональными объединениями. Примером может служить созданный Ассоциацией проектных менеджеров Великобритании документ «Conditions of Engagement».
Контракты на поставки специфицируют поставляемые товары и указывают разные дополнительные условия, например сроки поставок, требования к хранению и т.п., а также гарантии и обязательства. Формы таких контрактов обычно создаются самими поставщиками. Зачастую они содержат набранный мелким шрифтом на обороте документа целый набор условий и ограничений, который необходимо тщательно изучить, особенно если с этим поставщиком организация имеет дело впервые.
О соглашениях с обычными субконтракторами говорят, когда контрактор свободен как в выборе работ, которые поручаются субконтрактору, так и в выборе самого субконтрактора. О соглашениях с номинированными субконтракторами говорят в тех случаях, когда клиент желает иметь определенного субконтрактора или поставщика. Очень часто они имеют форму трехстороннего контракта между клиентом, главным контрактором и субконтрактором. Формы соглашений с номинированными субконтракторами обычно создаются ассоциациями или судами с целью равного учета интересов всех сторон.
Про-форма контракты обычно создаются одной стороной для навязывания другой стороне желаемых условий. Типичными примерами таких контрактов являются договора предоставления услуг монопольными или близким к монопольным организациями (договора на снабжение электрической и тепловой энергией, газом и т.п.). В таких договорах, даже если и предусматриваются определенные гарантии со стороны поставщика, в случае нарушений их весьма трудно реализовать.
Варианты организации внешних проектов
Различают три классических варианта организации внешних проектов. Заказчик может разделить проект на отдельные заказы, которые он распределяет среди различных предприятий-исполнителей (рис. 3.4). При этом координацию он либо оставляет за собой, либо поручает ее внешнему консультанту. Такой подход приемлем только в том случае, когда между отдельными частями проекта практически не требуется согласования и они могут выполняться независимо друг от друга.
Рис. 3.4. Организация проекта в виде отдельных заказов |
Во втором варианте (рис. 3.5) заключается договор между заказчиком и генеральным подрядчиком, при этом последний берет на себя ответственность за проект в целом и иногда (но не всегда) выполняет и большую часть работы. Далее он заключает договоры с субподрядчиками. Примером здесь могут служить строительные проекты. По такой же схеме обычно выполняются и оборонные заказы. Министерство обороны заключает договор с большим предприятием, которое затем привлекает порой многие сотни контрагентов. Иногда, по крайней мере в прошлом, это делалось и по соображениям соблюдения секретности, чтобы никто не мог себе представить истинные цели проекта.
Рис. 3.5. Схема организации проекта с генеральным подрядчиком |
При организации проекта по схеме консорциума (рис. 3.6) заказчик поручает выполнение проекта консорциуму, в который объединяются ряд самостоятельных предприятий для совместного выполнения проекта. Члены консорциума заключают между собой договор, которым помимо прочего регулируется и вопрос организации руководства проектом. Обычно один из членов консорциума берет на себя функции головной организации, либо создается специальный орган управления проектом из представителей руководства всех участников консорциума. Такая схема используется, к примеру, при выполнении проектов европейских программ «Темпус», «Тасис», «Интас», а также рамочных программ.
Рис. 3.6. Организация проекта по схеме консорциума |
Организационная структура проектов с внутренним управлением
Проекты в организациях чаще всего выполняются наряду с обычной рутинной работой. В принципе проекты могли бы выполняться и в линии. Однако эта альтернатива заключает в себе существенные недостатки, которые одновременно являются аргументами в пользу специфической организации проекта, а именно:
• отсутствие ориентировки на проект;
• сопротивление переменам;
• сложность координации работы участников проекта;
• низкая мотивация к творчеству и инновациям;
• низкий авторитет проекта;
• ориентация на функции, а не на потребителя;
• тенденция рассматривать себя в качестве замкнутой системы и игнорировать окружающие условия;
• сосредоточение на отдельных функциональных задачах и игнорирование общих задач и интересов всего предприятия;
• проблема стыков (границы между подразделениями, службами слишком застывшие);
• односторонняя вертикальная коммуникация по линии вместо междисциплинарной, прямой и горизонтальной коммуникации;
• отсутствие генералистов.
Структурная организация проекта регулирует взаимодействие руководителя проекта, команды проекта и других групп, участвующих в проекте, а организация процесса/хода проекта устанавливает фазы, формальные правила и методы работы.
Причина провала многих проектов кроется не в низкой профессиональной компетентности участвующих в них работников, а в организационной неразберихе.
Организационные структуры предприятия дают возможность его руководству реализовать цели предприятия и регулировать взаимодействие различных подразделений. По своему существу организация направлена на обеспечение надежности и постоянства. Надежность обеспечивается тем, что одинаковые процессы реализуются одинаковым образом, и выполнение повторяющихся работ происходит эффективно и с предсказуемым результатом. В этом смысле организации стремятся к консерватизму. Это зачастую полезно, например, когда однозначно определено, кто, за что и с какой компетенцией отвечает.
По другую сторону стоит скорость технического прогресса как в смысле продуктов, так и в смысле технологий, изменение требований потребителей, открытие новых рынков с дополнительными шансами и рисками и т.д. Они требуют от предприятия большего и более тесного взаимодействия различных подразделений, что не всегда в достаточной степени обеспечивается существующими организационными структурами. Так, К. Ellerbrock пишет: «Выполнение НИОКР является ключевой стратегией для обеспечения успеха предприятия и его конкурентоспособности. Время выполнения НИОКР обычными методами можно сократить лишь минимально. Издержки на НИОКР перманентно возрастают. Элементарным недостатком является отсутствие четко организованного проектного менеджмента, который сможет этому противодействовать» [49].
Проектный менеджмент дает предприятию шанс найти оптимальные решения при особых обстоятельствах. При этом не следует пренебрегать или подвергать опасности созданное ранее и существующее
Выбор организационной структуры проекта
Как у руководителя проекта, так и у руководителей организации далеко не всегда имеется возможность свободного выбора организационной структуры планируемых проектов. Но если такая возможность имеется, то для ее обоснованного выбора необходимо четко представлять себе основные критерии выбора, а также рациональные области применения той или структуры или некоторой их комбинации.
Кратко рассмотрим основные критерии, влияющие на выбор организационной структуры проектов [15].
1. Власть и реализация полномочий.
- В чисто функциональной структуре используется иерархическая цепь управления с ясной линией власти сверху вниз. Каждый работник имеет ясный набор задач и ясную линию подчинения.
- В матричной структуре члены команды проекта имеют две линии подчинения, что содержит в себе риск путаницы и конфликтов. Это означает, что требуется более строгая система коммуникации и координации. Более трудно становится оценивать эффективность работы отдельных групп. Появляется необходимость введения нового уровня контроля в виде спонсора проекта.
- В чисто проектной системе может вызвать затруднения контроль ряда одновременно выполняемых проектов.
2. Организация и эффективность коммуникаций.
- Формальные коммуникации наиболее легко реализуются в функциональной структуре, однако неформальные коммуникации существенно ограничиваются барьерами на границах функциональных подразделений. Границы между иерархическими уровнями могут блокировать как формальные, так и неформальные коммуникации по вертикали власти.
- Матричная структура в некоторой степени снижает эту блокировку и облегчает формальные коммуникации между функциональными подразделениями.
- Чисто проектная структура широко использует неформальные коммуникации и вообще обеспечивает наиболее гибкую систему коммуникации.
3. Трансфер знаний.
- В функциональной структуре наиболее легко сохраняются и накапливаются профессиональные знания для использования в будущей деятельности.
- Матричная структура позволяет эффективно использовать в проектах профессиональные знания, накопленные в функциональных подразделениях. Знания, полученные в процессе выполнения проектов, могут пополнять багаж знаний функциональных подразделений.
- Трансфер знаний в чисто проектных структурах обычно ограничен только общими сферами отдельных проектов.
4. Лояльность.
- Функциональная структура обеспечивает наибольшую лояльность индивидуумов, т.к. они связывают с ней развитие своей карьеры. Однако это может вести к тому, что проект будет рассматриваться ими как второстепенное дело.
- В матричной структуре лояльность в определенной степени также обеспечивается, поскольку отдельные члены команды проекта остаются и членами своих функциональных подразделений.
- В чисто проектной структуре индивидуальная карьера может быть, а может и не быть привязана к успеху отдельных проектов. Вопрос лояльности может стать проблемой.
5.Технология.
- Функциональные подразделения имеют тенденцию к сохранению существующей технологии для обеспечения текущего производства.
- В матричной структуре команда проекта стремится творчески использовать существующие технологии. Кроме того, поскольку команда рассматривает проблемы с разных сторон, она может генерировать потребность в технологических инновациях либо в использовании известных технологий, ранее не применявшихся в данной организации.
- Чисто проектные структуры в наибольшей степени склонны к инновациям.
6.Финансовые издержки.
- Чисто функциональные структуры, как правило, имеют большие накладные расходы. Кроме того, они не могут гибко реагировать на изменение объема работ.
- Матричная структура более гибка. Проектная команда может увеличивать и уменьшать персонал в зависимости от вариации объема работ.
- Чисто проектная структура является наиболее гибкой и может обеспечивать наименьшие текущие затраты.
7.Координация.
- Чисто функциональные структуры имеют наиболее формальную систему команд и поэтому требуют наименьших усилий по координации.
- Большие усилия по координации требует матричная структура из-за наличия границ функциональных подразделений и повышенного потенциала деструктивной конкуренции и конфликтов.
- Чисто проектные структуры также требуют высокого уровня координации, чтобы избежать дублирования усилий.
8.Функции поддержки.
- Чисто функциональные структуры требуют хорошо развитых централизованных поддерживающих структур.
- Матричные структуры предъявляют похожие требования к поддержке. Большие проекты могут иметь свою собственную администрацию и инфраструктуру (например, отдел информационных технологий).
- Чисто проектные структуры могут почти не нуждаться в централизованной поддержке.
Рассмотренные критерии позволяют выбрать организационную структуру проекта (если, конечно, такая возможность предоставляется).
Чисто функциональная организационная структура рекомендуется при условиях, когда:
- объем работ в период выполнения проекта мало меняется:
- проекты выполняются относительно редко;
- имеется развитая поддерживающая централизованная инфраструктура;
- требуется четко определенная цепь команд;
- не требуется развитой системы неформальных коммуникаций;
- имеется адекватная замена для ключевого персонала;
- задачи функционального подразделения являются для организации первоочередными;
- изменения не являются ключевым моментом;
- все проекты относительно малы или не особенно важны;
- в проекте не требуется быстрой реакции на изменения.
Матричная организационная структура может быть рекомендована в условиях, когда:
- объем работ переменный;
- проекты выполняются часто;
- требуется определенный объем исследований и инноваций;
- имеется централизованная поддерживающая инфраструктура;
- приемлемо «расщепление» структуры власти;
- приемлемы неформальные коммуникационные системы;
- проекты, хотя и не являются условием существования организации, но имеют большое значение;
- приемлема определенная степень изменений;
- все проекты имеют малый или средний размер;
- быстрая реакция на изменения в общем случае не требуется.
Чисто проектная организационная структура может быть рекомендована, если:
- объем работ подвержен большим колебаниям;
- проекты выполняются часто или преобладают;
- требуется значительный объем исследований и инноваций;
- централизованная поддерживающая инфраструктура мала или отсутствует;
- власть может быть почти всецело передана руководителю проекта;
- проекты являются главным видом деятельности организации;
- высок уровень изменений;
- проекты большие и потребляют много ресурсов;
правилом является быстрая реакция на изменения среды.
Линейная проектная организация
Проекты могут также интегрироваться в линейную структуру организации. Такой подход чаще всего используется для проектов развития, информационных и маркетинговых. В этом случае они обычно подчиняются руководителю линейного подразделения. К примеру, так управляются проекты КПР ТПУ факультетского уровня.
Важнейшими достоинствами такой проектной организации являются:
· выполнение проекта функциональным подразделением обеспечивает больший профессионализм решений;
· отпадает проблема выделения хороших работников для выполнения проекта вне структурного подразделения;
· ресурсы подразделения непосредственно могут быть использованы в проекте;
· высококвалифицированные работники относительно легко могут быть задействованы в ряде проектов;
· специальные знания и опыт относительно легко передаются в пределах функционального подразделения и могут эффективно использоваться проектной командой;
· легче обеспечивается непрерывность рабочих процессов в случае болезни или выбытия членов команды;
· функциональное подразделение обеспечивает наиболее безопасный карьерный путь индивидуума.
В качестве недостатков можно указать следующие:
■ проект оказывается далек от руководства предприятия, и, соответственно, значение проекта оказывается приниженным;
■ межфункциональные коммуникации сильно затруднены;
■ позиция руководителя проекта сильно зависит от руководителя подразделения.
В связи с указанными недостатками эта организационная форма мало пригодна для проектов, затрагивающих интересы разных функциональных подразделений, но для проектов, выполняющихся в интересах одного функционального подразделения, ее вполне можно рекомендовать. В качестве примера здесь можно привести проекты НИОКР, выполняемые по хозяйственным договорам вузами.
Матричная проектная организация
Для больших и сложных проектов, в выполнении которых участвует ряд функциональных подразделений, оптимальной может оказаться матричная проектная организация (рис. 3.7).
Рис. 3.7. Матричная проектная организация |
При этой организационной форме вертикальная схема управления сочетается с горизонтальной таким образом, что каждая организационная единица проекта, расположенная в узлах матрицы, подчиняется двум инстанциям - руководителю проекта и руководителю функционального подразделения. Матричная проектная организация имеет существенные достоинства, но и не менее существенные недостатки.
Достоинства матричной проектной организации: п за счет независимости проекта возрастает его значимость; п проектные группы могут быть сформированы быстро и без особых трений;
персонал может быть задействован гибко и, соответственно, может быть обеспечена быстрая реакция на требования клиента;
используются и стимулируются синергетические эффекты всего предприятия;
удовлетворяется мотив безопасности работников, которые не «выдергиваются» из своих подразделений;
сотрудники имеют возможность поддерживать актуальность своих профессиональных знаний, т.к. они остаются в своих функциональных подразделениях.
Недостатки:
■ более затратная форма организации;
■ повышенная опасность возникновения конфликтов как между руководителями проектов, так и между руководителями проектов и руководителями функциональных подразделений;
■ нарушение принципа единоначалия, что нарушает степень уверенности работников;
■ частичная потеря власти руководителей функциональных подразделений над своими подчиненными, т.к. часть власти переходит к руководителям проектов;
■ управление проектами является достаточно сложным делом, к которому матричная форма организации добавляет дополнительную размерность: наличие пограничных барьеров в иерархической цепочке по вертикали, между руководством проекта и функциональными подразделениями, а также между разными функциональными подразделениями отнюдь не облегчает жизнь руководителю проекта и проектной команде;
■ нередко к концу фазы реализации проекта его лишают части необходимых ресурсов, что весьма затрудняет его завершение;
■ высокие требования к коммуникационной готовности рассеянных по предприятию исполнителей проекта.
Следует отметить, что конфликты между руководителями могут иметь и положительную сторону. Если имеются два различных мнения, то оба руководителя вынуждены их обсуждать, и в результате может быть найдено новое, и при этом лучшее решение. Как вариант может быть реализовано также разделение полномочий, когда руководители функциональных подразделений имеют дисциплинарные полномочия, а руководители проектов - полномочия в отношении содержания работы. Для минимизации споров и взаимных обвинений определяющим является четкое разделение компетенций. Пример упрощенной схемы разграничения компетенций представлен на рис. 3.8.
Формулирование цели и следующих из нее задач, а также установление сроков сосредотачиваются в руках руководителя проекта. В отношении этих позиций, а также в отношении соблюдения пределов издержек он имеет распорядительное право во всех функциональных под-
разделениях. Однако и в этой схеме возникновение конфликтов не исключено, если определяемые руководителем подразделения методы работы приводят к нарушению целевых, временных или стоимостных рамок проекта.
Матричная организация проекта особенно целесообразна, когда проекты выполняются с определенной регулярностью и параллельно друг другу.
Поддержка проекта
Для успешного выполнения проекта немаловажное значение имеет наличие куратора. Эта функция может выполняться вышестоящим руководителем, однако нередко между ним и проектом вводится промежуточное звено, которое курирует один, несколько или все проекты предприятия. В качестве такого звена может быть создан специальный совет, проектный штаб или - в простейшем случае - координатор проектов.
Опыт показал, что наличие специального совета или штаба способствует более гладкому протеканию работ. Он поддерживает взаимодействие между проектом, его руководителем и командой проекта, с одной стороны, и руководством предприятия и внешними организациями - с другой. Обычно в состав такого штаба входит один из руководителей предприятия, руководитель проекта, руководители задействованных функциональных подразделений, которые должны представлять свои ресурсы для выполнения проекта, а также внешние представители. В функции штаба входит координация сторон, принятие решений, улаживание конфликтов.
Успех проекта в немалой степени зависит и от наличия покровителей. Они поддерживают проект, исполняют функции мультипликаторов и порой представляют в распоряжение проекта свое ноу-хау. В случае больших проектов и проектов, целью которых является введение серьезных изменений в организациях, особенно важно иметь в качестве покровителей авторитетных людей, которые пользуются доверием как участников проекта, так и общественности. Задачей такого покровителя является реклама идеи проекта и его результатов, компенсация страхов, поддержка в критических ситуациях.
Различают следующие типы покровителей:
■ покровители, обладающие властью. Такие покровители необходимы при реализации серьезных (порой непопулярных) решений. Чаще всего ими являются члены руководства предприятия, а иногда неформальные лидеры, пользующиеся соответствующим влиянием;
■ социальные покровители. Это люди, которым доверяют в коллективе. Они могут действовать как мультипликаторы, распространяя цели и результаты проекта. Они очень важны для признания результатов проекта работниками предприятия, уменьшения страхов и сопротивления;
■ покровители-профессионалы оказывают на работников предприятия примерно такое же влияние, как и социальные покровители, поскольку люди верят, что как специалисты они способны компетентно оценивать результаты проекта. Кроме того, они при случае поддерживают проект своим ноу-хау.
При малых проектах можно, конечно, обойтись и без покровителей, а порой и без штаба. Однако в случае больших проектов весьма целесообразно «обзавестись» поддержкой влиятельных людей, в качестве которых можно рассматривать членов руководства предприятия, членов наблюдательного совета, политиков, известных ученых.
Руководитель проекта
Личность руководителя в значительной степени определяет успех проекта. В то же время его возможности сильно зависят от его позиции в организации и в команде проекта. Поэтому рекомендуется права и ответственность руководителя за фиксировать письменно, чтобы избежать споров по этому поводу.
Позиция менеджера проекта в разных организациях и разных проектах может варьировать в пределах от представителя проектной группы до полноправного руководителя проекта. В первом случае он представляет проект во внешней среде, а внутри команды остается исполнителем проекта, как и все другие. Во втором крайнем случае он имеет такие же полномочия по отношению к подчиненным ему работникам проекта, как и линейные руководители, и несет всю ответственность за работу и результаты проекта.
Очень важно для успеха проекта, чтобы цели руководителя проекта были идентичны целям проекта, что, к сожалению, не всегда имеет место. Если существуют большие ножницы между личными целями руководителя и целями проекта, то такой работник непригоден для этого поста.
Задачи руководителя проекта весьма обширны:
► уточнение заданных целей в отношении требований по качеству, срокам, издержкам, ресурсам и т.д.;
► фиксация согласованных целей в проектном задании и получение утверждения со стороны заказчика;
► проверка реализуемости целей проекта;
► согласование организационной структуры проекта и порядка его выполнения;
► организация системы планирования, управления и информации в соответствии с видом и масштабом проекта;
► планирование проекта;
► контроль и управление проектом;
► принятие решения по альтернативам, касающимся как предмета, так и процесса выполнения проекта;
► подготовка и принятие принципиальных решений, например по приостановке работ;
► обеспечение требуемыми ресурсами;
► руководство работниками и их мотивация;
► делегирование задач и постановка задач контрагентам;
► координация всех участников проекта как внутри проекта, так и во внешней среде;
► периодическое информирование руководства предприятия и заказчика в соответствии с установленными сроками или в связи с потребностями проекта.
Все эти задачи руководитель проекта может успешно решать только в том случае, если он располагает полной поддержкой вышестоящего руководства.
Права руководителя проекта в отношении выбора работников и принятия решений, распорядительные права как дисциплинарные, так и предметные должны быть не только четко и недвусмысленно определены, но, как уже указывалось выше, лучше всего, чтобы они были письменно зафиксированы.
Риск и ответственность руководителя проекта порой могут быть гораздо выше, чем у линейного руководителя, поскольку ему часто приходится принимать решения в условиях неопределенности. Он отвечает за последствия своих решений, действий и бездействия. Основными областями ответственности руководителя проекта являются результаты, персонал, сроки, материальные ресурсы и бюджет проекта.
Помимо этого к руководителю проекта предъявляется ряд специальных требований. Он является посредником между исполнителями проекта и руководством организации или заказчиком, а также другими заинтересованными сторонами. Для этого ему требуется умение и способность вести за собой людей и обеспечивать кооперацию. Он должен иметь достаточную профессиональную квалификацию по предметной части проекта, чтобы хорошо понимать его содержание. Наконец, он должен владеть методологией управления проектами.
Как руководитель коллектива, менеджер проекта должен располагать таким же набором качеств, которые требуются от любого руководителя высшего звена: способностью убеждать, способностью «пробивать вопросы», выносливостью, надежностью, чувством ответственности, контактностью, способностью работать в команде, творческими навыками и способностями, способностью принимать решения, инициативностью, умением вести переговоры. Этот список можно продолжать долго.
От руководителя проекта требуется также, чтобы он располагал качествами лидера, что прежде всего предполагает выраженный кооперативный стиль руководства. Чтобы каждый участник проекта работал с полной отдачей сил, оптимально использовал свой потенциал и способности, руководитель проекта должен уметь мотивировать работников и создавать условия, в которых работник будет чувствовать себя комфортно. Для этого надо предоставить ему возможность работать достаточно самостоятельно. При этом он должен чувствовать поддержку руководителя проекта и руководства организации, а задачи проекта должны быть для него интересны.
Профессиональная квалификация руководителя проекта охватывает все знания, опыт и способности, относящиеся к предмету проекта. Желательно, чтобы он был профессионалом в предметной части проекта, по крайней мере не быть в ней дилетантом. Конечно, как правило, у него будут узкие специалисты по отдельным задачам проекта, но без глубокого понимания существа проекта успешно руководить им практически невозможно.
Наконец, руководитель проекта должен обладать необходимой квалификацией в области проектного менеджмента. Для этого он должен быть знаком с методологией и техникой управления проектами и иметь практический опыт проектной работы. Он, как главный ответственный за проект человек, должен чувствовать себя уверенно в этой области, чтобы работа над проектом шла организованно и могла быть успешно завершена.
Выбор руководителя проекта представляет собой сложную задачу, тем более что он основан больше на характеристиках личности, чем на содержании работ проекта.
Желательные характеристики личности руководителя проекта :
• гибкость и приспособляемость;
• предпочтение инициативы и лидерства;
• напористость, уверенность, способность убеждать, свободное владение речью;
• честолюбие, активность, сильная воля;
• эффективность в качестве коммуникатора и интегратора;
• широкий спектр личных интересов;
• стабильность, энтузиазм, воображение, естественность;
• способность сбалансировать технические решения с факторами времени и стоимости, а также человеческим фактором;
• высокая организованность и дисциплинированность;
• в большей степени генералист, чем специалист;
• способность и желание посвящать большую часть своего времени планированию и контроллингу;
• способность выявлять проблемы;
• готовность принимать решения;
• способность поддерживать должный баланс в использовании времени.
Любое предприятие и каждый руководитель проекта были бы счастливы иметь хотя бы 70-80 % приведенных качеств. Видимо, основной части вышеперечисленных требований удовлетворял гениальный архитектор Инхотеп, который спроектировал и соорудил первую пирамиду в Египте.
Обычно руководители больших структурных единиц организации не принимают участия в рутинной работе своих сотрудников. Что касается руководителя проекта, то он, как правило, лично участвует в выработке проектных решений. Это необходимо, поскольку он должен непосредственно влиять на результаты проекта. Эффективность его влияния обеспечивается только в случае непосредственного участия в работе над проектом, так как результаты проекта гораздо менее предсказуемы, чем результаты деятельности линейного руководителя. Это не означает, что менеджер проекта должен в большом объеме заниматься деталями, но в решении принципиальных вопросов ему следует участвовать.
Чтобы удовлетворять многочисленным требованиям, руководитель проекта должен как минимум иметь хорошее здоровье и должен суметь его сохранять. Это непросто, поскольку длительность рабочей недели у него зачастую может превышать 60 часов. Кроме того, его обязанности могут требовать длительного пребывания вдали от дома. Н. Kerzner по этому поводу пишет, что если руководитель проекта начинает любить работу больше, чем свою семью, следствием оказывается потеря друзей, плохие семейные отношения и, возможно, развод [13].
Исследования показали, что в США в период выполнения больших проектов по созданию ракет и космических систем частота разводов среди руководителей проектов и ведущих специалистов проектных команд была вдвое выше, чем в среднем по стране. В качестве характерных признаков трудоголизма у них были отмечены следующие:
· каждую пятницу они считали, что у них есть два дополнительных рабочих дня до понедельника;
· 5 часов вечера они рассматривали как середину рабочего дня;
· они не находили времени для отдыха;
· уходя домой, они всегда брали с собой работу;
· они всегда брали работу с собой, отправляясь в отпуск.
Одним из сложных вопросов является установление уровня зарплаты руководителя проекта. Представляется разумным подход, по которому зарплата руководителя должна примерно соответствовать зарплате тех людей, с которыми ему ежедневно нужно вести переговоры. Обычно это руководители функциональных подразделений. Практика показала, что если зарплата руководителя проекта существенно больше или меньше, чем у линейных менеджеров, обычно возникают конфликты. Линейные руководители нередко заявляют, что они не могут выполнять свои обязанности и «еще контролировать этих примадонн, которые получают больше денег и имеют более высокий разряд, чем линейный руководитель». В то же время зарплата и разряд не должны стоять на пути создания эффективной команды проекта, и если необходимо, то работник с более высоким разрядом на время выполнения проекта может быть подчинен человеку с меньшим разрядом.
Выбор и назначение руководителя проекта является сложной и ответственной обязанностью высшего менеджмента организации. Если человек проявил себя так, что можно надеяться, что из него получится руководитель проекта, то у руководства организации имеется ряд альтернатив:
· Повысить ему зарплату и разряд и поручить ему руководящую работу в сфере управления проектами.
· Перевести индивидуума на руководящую работу в сфере управления проектами без всяких изменений зарплаты и разряда. Если за три- шесть месяцев он продемонстрирует успешную деятельность, ему повышают зарплату и разряд.
· Производят небольшое повышение зарплаты при том же разряде или повышение разряда с сохранением прежней зарплаты с оговоркой, что при успешной работе он получит соответствующее повышение зарплаты и разряда.
Многие руководители организаций не без оснований считают, что если работник входит в сферу управления проектами, то у него только две дальнейших траектории - вверх или за дверь. Если ему повысили зарплату и разряд, а он провалил дело, то ему нет места в исходной линейной структуре. Поэтому большинство руководителей, да и работников тоже, предпочитают второй из вышеназванных вариантов, поскольку он обеспечивает большую безопасность для обоих. Конечно, работник может не захотеть вернуться обратно с клеймом провалившегося руководителя проекта. Многие компании не осознают, пока не оказывается слишком поздно, что выдвижение в руководители проекта основано на другом пакете критериев, чем выдвижение в линейные руководители. Первое основано прежде всего на коммуникационных способностях, в то время как второе основано на технических знаниях и умениях. Впрочем, по мнению автора, это справедливо и для обычного выдвижения работника на должность руководителя.
Проектная группа и команда проекта
Проектная группа и команда проекта могут рассматриваться как идентичные понятия. Вместе с тем иногда различают группу или команду во главе с «командиром» и творческую команду типа «team», в которой не бывает иерархических структур. Последняя целесообразна, когда решаются сложные задачи и требуется творческий обмен мнениями.
Формирование проектных групп, работающих полный день над проектом, обеспечивает целый ряд существенных преимуществ:
· больший творческий потенциал группы позволяет надеяться на более высокое качество решений;
· участие в группе работников функциональных подразделений улучшает признание результатов проекта в этих подразделениях;
· управление и координация в такой группе существенно проще; п
· в проектную группу могут быть включены сторонние специалисты; п
· за счет большего числа людей уменьшается степень риска в проекте;
· группа быстрее справляется с выполнением проекта и, соответственно, его результаты могут быть раньше использованы предприятием.
К недостаткам проектных групп относятся известные проблемы групповой динамики (поведения групп), такие как конформизм, групповая безответственность, потери времени на достижение консенсуса, большая опасность деструктивных конфликтов.
Проблемы при коллективной работе чаще всего возникают по следующим причинам:
У несколько человек равной квалификации работают вместе, и им трудно договориться о распределении ролей. В этом случае может возникнуть целевой конфликт в отношении личных карьерных устремлений отдельных членов команды (не каждый может стать начальником). Многие люди в этом случае скрывают свои знания. Если к тому же помощь коллег не отмечается должным образом, а выдается за собственное достижение, обоюдное доверие постепенно разрушается, а готовность к кооперации стремится к нулю;
У один член команды ввиду особого усердия выделяется из общей массы. Часто это побуждает остальных отказывать ему в поддержке или даже «ставить палки в колеса». Если этому не препятствует сильный руководитель команды, этот эффект групповой динамики может привести к уравниловке. Требуется определенное величие души, чтобы признать превосходство особо сильных коллег;
У руководитель команды склонен рядиться в «чужие перья», представляя успешную работу по проекту исключительно как свое собственное достижение. Заниженная оценка существенного вклада отдельных членов команды часто происходит из опасения, что сильные сотрудники могут его обогнать.
Условия успешной коллективной работы проектной команды:
· Все члены команды должны отождествлять себя с общей целью и вместе должны желать достичь ее. Цель должна быть ясной и видеться целесообразной.
· Каждый член команды должен точно знать и понимать свою индивидуальную задачу.
· Члены команды должны понимать, что каждый зависит от других. Цель может быть достигнута оптимальным образом только тогда, когда все работают друг с другом, а не друг против друга.
· Индивидуальное достижение должно быть ясно узнаваемо, даже если члены команды опираются друг на друга. Например, в футболе отмечается не только игрок, забивший гол, но и тот, кто обеспечил голевую подачу.
· Помощь и подсказки других не должны выдаваться за собственное достижение, но должны ясно и подобающе отмечаться. Уверенность в том, что авторство не теряется, является фундаментальной предпосылкой взаимной помощи.
· Успешная коллективная работа требует регулярных общих совещаний о нерешенных либо потенциальных проблемах (превентивное или последующее обсуждение).
Далеко не всегда, а скорее редко, сформированная для выполнения проекта команда состоит из людей, симпатизирующих и доверяющих друг другу. Тем не менее и без обоюдного доверия команда может успешно делать общее дело, если:
• речь не идет о чем-либо, что может быть полезным для личной карьеры (обсуждение стратегии, мозговые штурмы и т.п.);
• личная цель может быть достигнута исключительно во взаимодействии с другими;
• личное достижение остается явно заметным, как, например, в футбольной команде или у продавцов;
• руководитель команды с самого начала дает понять, что при оценке достижений отдельных сотрудников способность к работе в коллективе будет особо отмечена и оценена.
Подведение итогов по вехам и фазам проекта в случае успешного их выполнения должно быть использовано для выражения благодарности и наград членам команды. При этом нужно отметить как можно больше людей. Не должны быть забыты и сотрудники других подразделений, чье содействие способствовало успеху проекта. Включенность во времена успеха строит мосты на время трудностей!
Исследования показали, что в долгосрочной перспективе наибольшее мотивирующее воздействие оказывают не обязательно деньги, а уважение к профессионализму, развитию и выражение благодарности.
Следует упомянуть, что проведение проектов на предприятии приводит к появлению дополнительных нюансов в управлении персоналом предприятия:
• наличие временных рамок у проектов приводит к соответствующему ограничению времени участия в них работников предприятия;
• междисциплинарная постановка задач усложняет требования к квалификации работников;
• ориентировка на группы, а не на индивидуальные рабочие места;
• строгие технические, временные и стоимостные стандарты производительности и, соответственно, повышение уровня стресса у работников;
• расширение мультинациональной кооперации в проектах и связанные с этим языковые проблемы.
Эффективность проектной группы зависит от целого ряда факторов, важнейшие из которых приведены ниже.
· Большие отклонения от оптимальной численности группы, составляющей 3-6 человек, отрицательно сказывается на ее производительности. Вместе с тем большее или меньше число работников может требоваться по ходу проекта. В различных фазах проекта может потребоваться также привлечение экспертов. Поскольку в проектах могут быть задействованы многие подразделения предприятия, а от каждого подразделения обычно включается в группу как минимум один представитель, численность группы может оказаться значительной.
При большой численности группы целесообразна ее структуризация - распределение работников в малые группы по выполняемым задачам. Это распределение может меняться в разных фазах проекта. Детальное исследование динамики групп для таких условий представлено в [52].
· Мотивация работников проектной группы имеет большое влияние на производительность их труда.
· Выбор членов группы обычно осуществляется руководителем проекта по согласованию с руководителями функциональных подразделений, откуда берут работников, и с самими работниками. При этом надо следить за тем, чтобы линейные руководители не использовали ситуацию для того, чтобы «спихнуть» в проект неугодных им работников. Именно поэтому руководителю проекта должно быть дано право отклонения неподходящих кандидатур.
· Отсутствие у работников идентификации с проектом сильно снижает их производительность.
· Личные качества руководителя проекта и стиль его руководства также очень сильно влияют на эффективность работы группы.
· Важными фактора ми являются квалификация, и проявиться эффект «зашоренности».
· На эффективность работы проектной группы влияют также такие факторы, как ее однородность или гетерогенность в отношении возраста, жизненного опыта, служебного положения, пола и др.
При подборе команды руководитель проекта должен как можно раньше наладить взаимодействие с руководителями функциональных подразделений. Это целесообразно по двум соображениям. Во-первых, руководитель функционального подразделения, как специалист, гораздо лучше знает предметную сторону своей части проекта и может выявить области с высоким риском. Во-вторых, нужно, чтобы у него выработалось положительное отношение к успеху проекта, а это наилучшим образом достигается, когда он участвует уже при планировании проекта.
Руководитель проекта должен понимать трудности линейного руководителя, связанные с включением своих людей в команду проекта. С одной стороны, ему, как правило, никто не уменьшает объема обычной оперативной деятельности подразделения. И опытные работники ему нужны самому. Но даже если он всей душой за проект и готов отдать такого работника, это не всегда гарантирует успех. Н. Kerzner [13] приводит наглядный пример. Работник проработал тридцать лет и был почти богом в своем деле, но никогда не работал в команде. Руководитель умышленно дал ему очень большую работу, рассчитывая, что тот попросит помощи. Однако работник стал оставаться сверхурочно и с работой отлично справился. Тогда руководитель поручил ему небольшой самостоятельный проект в рамках подразделения и подчинил ему двух сотрудников. Эти люди в основном сидели без дела, поскольку работник по-прежнему всю работу делал сам (причем хорошо). Руководитель не хотел терять этого работника и после указанных экспериментов поручал ему только те задачи, которые он мог решать в одиночку.
Здесь хотелось бы сделать одно замечание по поводу пожилых работников. Конечно, необходимо дать дорогу молодым. Однако вытеснение опытных, добросовестных работников при сокращении численности работников организации может оказать ей плохую услугу. «Пожилой работник проектной команды может иметь ценность, равную его весу в золоте, благодаря его опыту и знаниям. Этот опыт и знания устраняют кривую обучения и сокращают объем работы. Если этих людей больше нет, команда проекта может делать те же ошибки, которые были сделаны 20 лет назад» [38]. Это наглядно проявилось в нашей стране в последние годы, когда оборонные предприятия потеряли большую часть своих опытных кадров и порой неспособны восстановить некоторые тонкие технологии, т.к. даже самая детальная документация не может отразить все тонкости сложных технологических процессов.
Наряду с профессиональными качествами, привлекаемые к проекту работники должны обладать способностью к работе в команде. Состав команды должен дополнять друг друга и должна быть гарантирована совместимость людей. Если выясняется, что отдельные работники нарушают гармонию команды, их следует непременно заменить другими, даже если речь идет о носителях важнейших ноу-хау.
Нередко у руководителя проекта возникают сложные проблемы взаимодействия с высококвалифицированными профессионалами, которые гордятся своей способностью находить наилучшие, порой революционные решения задач, в то время как существуют более простые, надежные стандартные решения. При этом их обычно не интересует цена такого решения. Руководителю проекта приходится, не задевая самолюбия этих людей, постоянно следить за тем, чтобы решения укладывались в ограничения проекта по стоимости, времени и предметной области.
Идентификация необходимого состава команды проекта критична для нормального старта и хода проекта. Типовые шаги этого процесса:
1. На основе технического задания, устава проекта определить, какие функциональные группы и потенциальные партнеры необходимы для выполнения работ. Как внутри компании, так и во внешних организациях выявить группы, чье время может понадобиться.
2. Идентифицировать все особые компетенции и опыт, который требуется от отдельных членов команды. Желательно определить необходимые компетенции (если это уже известно) еще до отбора людей в функциональных подразделениях. Эти люди должны быть технически компетентными в области их ответственности. Наборы их умений должны дополнять друг друга. Частичное наложение умений позволяет увеличить гибкость при распределении работ. При отборе людей стоит учитывать не только демонстрируемые способности, но и потенциальные.
3. Скомпоновать исходный лист необходимых членов команды в начале проекта. Лист может содержать фамилии конкретных людей, если к этому времени известны требуемые для проекта специфические знания и навыки. В остальных случаях достаточно включить в исходный лист функциональные подразделения, из которых нужно привлечь людей, и/или необходимые умения.
4. Определить организационную структуру команды. Нужно ли выделить суб-команды (особенно в случае больших проектов)? Если это так, то подобрать руководителей этих суб-команд. Определить, как и когда подключить их для отбора людей в команды и распределения работ.
5. Обойти функциональные подразделения организации с вопросом, нужны ли их представители в команде проекта. Такой подход позволяет вспомнить о необходимости привлечения некоторых критических специалистов, которые в противном случае могли бы быть забыты, что на последующих стадиях проекта могло бы стать проблемой.
6. Определить, кто/какие позиции будут представлять собой ядро команды и кто будет входить в расширенный список. Члены ядра команды представляют свои функциональные подразделения или особые компетенции и, как правило, участвуют во всех совещаниях команды и работают непосредственно с руководителем проекта. Люди, входящие в расширенный список, выполняют работы по проекту, но не обязательно участвуют во всех совещаниях. Требуемые умения необходимо обсудить с руководителями функциональных подразделений. Необходимо также, чтобы руководитель функционального подразделения получил хотя бы грубую оценку объема работ и времени привлечения в проект каждого своего работника (и согласился с ними).
7. Получить персональное согласие каждого члена команды на участие в работах по проекту. Необходимо удостовериться, что каждый член команды имеет время, необходимое для проекта, и может принимать решение и давать согласие за свою организацию.
8. Составить матрицу/ы (таблицу) ролей и ответственности для фиксации основного вклада в проект членов команды и получения согласия от непосредственных руководителей членов команды. Это позволяет всей команде понимать границы, с которыми они будут сталкиваться при совместной работе, а также пределы своей независимости.
Матрицы могут в дальнейшем быть использованы для составления списков участников совещаний и списка рассылки информации.
9. Дополнить лист по мере идентификации новых задач в процессе планирования проекта, а также по мере того, как функциональные подразделения предоставят конкретные кандидатуры.
Руководитель проекта должен знать сильные и слабые стороны каждого члена команды, его компетенции, предпочтения. Следует помнить, что диплом, титул и роль члена команды далеко не всегда характеризуют его компетенции. Руководитель проекта должен, не считаясь со временем, добиваться того, чтобы все члены команды понимали цели и задачи проекта.
После формирования команды проекта обычно проводится стартовое собрание (Kick-off-Meeting). На этом собрании обычно еще не обсуждается содержание проекта. Оно служит главным образом взаимному знакомству, распределению ролей, установлению «правил игры» и создания некоторого общего уровня информированности.
В дальнейшем руководителю проекта необходимо постоянно вести мониторинг функционирования и производительности работы команды проекта, чтобы своевременно предупредить или устранить возможные проблемы командной работы. Ранними индикаторами потенциальных проблем могут быть:
• заметное снижение производительности труда команды в целом или отдельных ее членов. Причиной этого могут быть конфликты, коммуникационные проблемы, неясные цели;
• вербальная и невербальная информация от членов команды. Руководителю проекта нужно уметь услышать нужды и опасения членов команды, а также увидеть и распознать невербальные сигналы;
• недружественное или агрессивное поведение отдельных членов команды по отношению к коллегам.
В литературе по управлению проектами настоятельно рекомендуется регулярно проводить собрания команды проекта с обсуждением результатов работы и проблем функционирования команды. Вначале обсуждается положительный опыт и результаты деятельности, а затем руководитель просит каждого члена команды сказать о фактических или потенциальных проблемах. При этом, конечно, предположения и факты должны быть четко разделены.
Организация процесса выполнения проекта
В этом разделе речь пойдет о работах, их последовательности и процессе их реализации.
Цель организации процесса выполнения проекта состоит в координации отдельных работ по времени и содержанию так, чтобы ход проекта обеспечивался без нарушений. К этому относится также определение основных фаз проекта, методов работы, порядка коммуникации, определение сроков и форм отчетности и т.д.
На практике применяется целый ряд фазовых моделей, вид которых зависит от типа проекта, его сложности, масштаба и др. К примеру, для проекта в сфере услуг часто используют следующую фазовую модель:
• фаза анализа проблемы;
• фаза разработки концепции;
• фаза дизайна проекта, подробная концепция проекта;
• фаза реализации;
• фаза завершения проекта.
В некоторых случаях фазы проекта заданы нормативными документами или определены стандартами. Для примера можно привести систему стандартов разработки и постановки продукции на производство [53], в особенности рекомендации ВНИИ Госстандарта [54].
В каждом случае фаза проекта имеет определенное начало и конец. Конец фазы, обозначаемый вехой, включает в себя функции:
• фиксации окончания фазы проекта;
• фиксации факта, что планировавшиеся результаты фазы достигнуты/не достигнуты;
• разрешения на старт последующей фазы.
По окончании фазы достигнутые результаты подлежат сравнению с планировавшимися. Тем самым проверяется успешность ее завершения, т.е. достижение целей, поставленных для этой фазы. Управляющий орган, который проверяет результаты, имеет при этом следующие альтернативы:
• разрешить приступить к последующей фазе;
• повторить последнюю фазу;
• потребовать устранения недостатков к определенному сроку;
• прекратить проект.
Каждую последующую фазу проекта следует начинать с анализа проблем. Если перед началом проекта была выполнена солидная предпроектная подготовка, то анализ проблем в каждой очередной фазе может быть иногда опущен или по крайней мере сильно сокращен. Но, например, при внешних проектах предпроектная подготовка часто протекает на предприятии заказчика. Тогда организации-исполнителю, естественно, совершенно необходимо провести подробный анализ проблемы, чтобы вникнуть в существо проекта.
Во второй фазе (разработка концепции) вначале исследуется исходное состояние, разрабатывается грубая концепция решения, выясняются поперечные связи (причинно-следственные цепи) и более точно формулируется желаемое конечное состояние. Затем проверяется его реализуемость, ищутся подходы к решению, и на их основе определяются последующие шаги. Конец фазы концепции достигнут, когда представляемая грубая концепция утверждена, а руководителю и команде проекта дано добро на его продолжение.
В следующей фазе (дизайн проекта или подробная концепция проекта) имеющаяся грубая концепция детально разрабатывается с одновременной проверкой по критериям издержек, времени и качества. В результате этой фазы появляется подробная концепция, в которой детально изложено содержание работы и подходы к ее выполнению. После этого может быть начато выполнение следующей фазы (фаза реализации), целью которой является претворение концепции в жизнь.
Остается последняя фаза проекта (фаза завершения). В этой фазе производятся окончательные расчеты с заказчиком, проводится анализ проекта с позиций результативности работы, соблюдения сметы и сроков, представляется заключительный отчет, ликвидируются созданные на время выполнения проекта структуры. Для внутренних проектов важно еще позаботиться о живучести проекта в организации, с тем чтобы через некоторое время все не вернулось на «круги своя».
Поскольку издержки по мере перехода к последующим фазам обычно возрастают, целесообразно строго придерживаться принятой последовательности фаз и к новой фазе приступать только тогда, когда предыдущая фаза завершена в соответствии с установленным порядком и с желаемыми результатами. За счет этого может быть заметно уменьшена опасность ошибочного развития событий и обеспечено экономичное выполнение проекта.
Стремление ускорить процесс создания новых изделий и обойти конкурента привело к тому, что в последние годы положение о строгом соблюдении последовательности фаз проекта, казавшееся ранее фундаментальным, стало размываться. Компании все чаще совмещают процессы разработки и изготовления изделий (concurrent engineering), т.е. изготовление начинается, когда готова только часть документации. Конечно, иногда это приводит к необходимости переделывать изготовленное, но в целом общую продолжительность проекта по выводу на рынок нового изделия порой удается сократить в несколько раз.
В рамках отдельных фаз процесс выполнения проекта опять же может быть разложен на аналогичные составляющие, представляющие собой циклы решения проблем (рис. 3.9). При этом задачи и аспекты каждого шага рекомендуется формулировать в виде вопросов (табл. 3.1), чтобы исполнители проекта чувствовали, что они обращены к ним.
Для больших и сложных проектов деление проекта на отдельные фазы имеет особое значение. В этом случае нет необходимости принимать решение по проекту в целом в начале проекта, сначала может быть принято решение по самому первому шагу, потом по следующей фазе и т.д. При дисциплинированном соблюдении этого подхода исключается ситуация, при которой приступают к фазам с большими затратами ресурсов (материальных и человеческих) до завершения в установленном порядке относительно более дешевых фаз.
Для проектов, связанных с созданием нового изделия, если за базу взять фазу его разработки, соотношение издержек для отдельных фаз имеет следующий порядок [56]:
фаза разработки концепции < 0,03, фаза выработки задач < 0,10, фаза разработки = 1, фаза изготовления и снабжения = до 3, фаза эксплуатации и обслуживания = до 6.
К сожалению, возможность прекратить бесперспективные проекты либо вообще не используют, либо используют слишком поздно. Причины:
• заказчику не хочется лишать работы руководителя проекта и его команду;
• затрачено уже много средств и с продолжением финансирования связывается надежда, что проект все-таки удастся довести до приемлемого завершения. Опыт, однако, показывает, что обычно потери средств и времени за счет этого только возрастают;
• опасение руководства «обнажить» ошибочность своего исходного решения о выполнении проекта.
В проектах разработки и постановки продукции на производство каждое новое и к моменту возникновения идеи проекта еще не существующее изделие имеет впереди весь свой жизненный цикл, вплоть до снятия с производства и ликвидации. Только рассматривая цикл в целом можно оценить инвестиционный проект с позиций заказчика.
Таблица 3.1 Задачи в цикле решения проблем
|
|
Дата: 2019-02-02, просмотров: 361.