Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекции по курсу «Управление проектами» Кафедра «Менеджмент» Кобулов Б.А.
1. Введение в управление проектами. 2
1.1. Определение понятия «проект» 2
1.2. История управления проектами 4
1.3. Стандарты и сертификация 6
1.3.1. Уровни международной сертификации 7
1.4. Типы и виды проектов 8
1.5. Окружение проекта 9
1.6 Участники / стейкхолдеры проекта 10
1.6 Концепция управления проектами 14
1.6.1.Содержание понятия «управление проектами» 14
1.6.2. Основные функции управления проектами 16
1.6.3. Жизненный цикл и фазы проекта 21
1.6.4. Критерии успешности управления проектом 23
1.6.5. Управление портфелями, программами и проектами организации 25
1.6.6. Превышение сроков и бюджетов в проектах и их причины 26
1.7. Цели проекта 28
2. Подготовка проекта 29
2.1. Особенности подготовки проектов, в основе которых лежит заказ 30
2.1.1. Требования заказчика 30
2.1.2. Проектное задание 31
2.2. Особенности подготовки проектов, в основе которых лежит идея 32
2.2.1. Логико-структурный подход 32
2.3. Особенности подготовки проектов, в основе которых лежит проблема 33
3. Дизайн проекта / организация проекта 33
3.1. Внутреннее и внешнее управление проектами 33
Организационная структура проектов с внутренним управлением 34
Функциональная структура 35
4. Планирование проекта 39
4.1. Структурный план проекта 39
4.2. Процессный план работ 42
4.3. Планирование времени 44
4.3.1. Сетевое планирование 44
4.3.2. Техника планирования времени выполнения проекта 50
4.3.3. Недостатки и проблемы сетевого планирования 52
4.5. Планирование издержек 56
4.6. Бюджет и финансовый план проекта 61
5. Управление рисками. 61
5.1. Современная концепция риска 62
5.4. Концепция управления рисками 64
5.5. Планирование управления рисками 65
5.6. Оценка рисков (выявление и анализ рисков) 66
5.6.1. Выявление рисков 66
5.6.2. Анализ рисков 68
5.7. Мониторинг и документирование рисков 70
Литература 71
Глоссарий 74
Единого общепринятого определения понятия «проект» в литературе не существует.
Германский промышленный стандарт DIN 69 901 определяет проект как «замысел (намерение), который в значительной степени характеризуется одноразовостью условий в их совокупности, например заданием цели, временными, финансовыми, людскими или другими ограничениями, разграничением от других намерений и специфической организацией выполнения проекта».
Институт проектного менеджмента PMI определяет проект как ограниченное во времени намерение создать уникальный продукт, услугу или результат.
Ограничение во времени подразумевает, что проект должен иметь фиксированное начало и фиксированный конец. Конец наступает, когда достигнуты цели проекта, или когда становится ясно, что цели не будут или не могут быть достигнуты, или когда отпала необходимость в проекте, и он прекращен. Ограничение во времени не означает краткосрочность; многие проекты могут длиться несколько лет. Временные рамки, как правило, не относятся к создаваемому в ходе проекта продукту, услуге или результату. Их жизнь может быть как многократно больше времени выполнения проекта (например, сооружение собора), так и много меньше (например, подготовка выборов). Большинство проектов предпринимается для достижения устойчивого, длительного результата.
Уникальность означает, что продукт или услуга имеет характерные отличия от всех подобных продуктов или услуг. Наличие повторяющихся элементов не изменяет фундаментальное свойство уникальности проекта. Уникальность является существенным признаком проекта, т.е. выполнение рутинных задач не может составлять предмета проекта. Это не означает, что в проекте должны отсутствовать повторяющиеся элементы. Несмотря на то, что зданий строится тысячи, проект каждого нового здания уникален – другой собственник, другой дизайн, другое местоположение, другой подрядчик и т.д. .
Причина такого внимания к понятию «проект» в том, что методы и инструменты управления проектами эффективно применять именно к проекту. Однако далеко не вся работа, ведущаяся в организации, является проектами. Поэтому компании, внедряющие управление проектами, часто испытывают затруднения с разделением проектов и операционной деятельности. .
К примеру, является ли курс обучения сотрудников проектом? Любой курс имеет ограниченные сроки проведения, бюджет, требования к качеству. Для курса могут быть определены цели. Таким образом, курс обучения можно рассматривать как проект. Но если компания проводит десятки курсов в год и деятельность по организации обучения является рутинной, повторяющейся, не несет никакой уникальности в плане управления, — является ли курс проектом? Необходимо ли применять методы управления проектом для каждого курса, например, назначать руководителя проекта и создавать график проекта? Аналогичная ситуация может возникать на заводе, производящем машины. Каждая машина может рассматриваться как небольшой проект.
В приведенных примерах, скорее всего, курс обучения и производство машины проектами не являются. Фактически, в предложенном контексте массового производства машин и проведения курсов, компания реализует серийное производство типовых продуктов и услуг без явного ограничения этой деятельности по срокам.
У каждого проекта есть четко определенные начало и окончание. Проект заканчивается вместе с достижением всех его целей или наоборот, когда становится ясно, что эти цели не могут быть достигнуты. Временность не означает краткосрочность проекта — многие проекты могут продолжаться несколько лет. В любом случае, проект конечен и не может состоять из постоянно продолжающихся действий.
Очень многие предприятия временны в том смысле, что в какой-то момент работа на них остановится. Например, понятно, что конвейер по производству определенной модели автомобилей когда-то остановится, так как машина будет снята с производства. Однако такой род временности не делает конвейер проектом, поскольку работа по сборке машин является типичной рутинной операционной деятельностью. Фундаментальное отличие проекта заключается в том, что проект заканчивается, когда поставленные цели достигнуты, тогда как при непроектной деятельности перед исполнителями ставятся новые цели и работа продолжается.
Временная природа проектов сказывается и на других аспектах проектной деятельности. Например, проекты обычно имеют четко очерченные временные рамки для создания продукта или услуги, поскольку благоприятная для них ситуация на рынке складывается на ограниченное время. Кроме того, проектная команда, как правило, по его окончании распадается, а ее члены переходят в другие проекты.
В отличие от конвейера по сборке автомобилей хорошим примером проекта может быть разработка нового автомобиля. Разработка осуществляется в ограниченные сроки и продолжается до достижения определенного результата — прототипа нового автомобиля. Когда результат достигнут, автомобиль отправляется в производство, а проектная команда — конструкторы, дизайнеры, инженеры и прочие — могут быть вовлечены в новый проект, хотя и не обязательно в том же составе.
Таким образом, операционная деятельность состоит из постоянного повторения одних и тех же операций с целью производства одного и того же продукта (или предоставления одной и той же услуги). Примерами могут служить серийное производство, продажи типовых продуктов, бухгалтерские операции.
Основная разница между операционной и проектной деятельностью (табл. 1.1) в том, что операционная деятельность оперирует привычными результатами в устоявшихся бизнес-процессах, а проектная работа подразумевает уникальные результаты и ограниченный срок работ.
|
Отличия проектной деятельности от операционной |
Проекты |
Операции |
|
Длительность |
Временная: проекты имеют начало и окончание (даже если длительность проекта 1 год или 1 день) |
Рутинная деятельность |
|
Конечные цели |
После достижения поставленных целей проект закрывается |
После достижения поставленных целей ставятся новые цели и операции продолжаются |
|
Результаты |
Создаются уникальные продукты или услуги |
Поддержка бизнеса |
|
Постепенное уточнение |
Постепенное уточнение проекта |
Не обязательно постепенное уточнение |
При проведении анализа необходимости применения проектных методов управления следует помимо формальных критериев руководствоваться здравым смыслом. Даже небольшая задача может управляться как проект, если например, она является стратегически важной для компании.
Управление проектом — это применение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований к проекту (PMI).
Текущая деятельность, как правило, представляет собой повторяющийся процесс, поскольку выполняется в соответствии с существующими в организации процедурами. А в проектах возможна неопределенность в отношении продуктов, услуг или результатов, создаваемых в ходе проекта, по причине их уникального характера. Задачи по проекту могут быть новыми для команды проекта, что обусловливает необходимость более тщательного планирования, в отличие от рутинных работ. Кроме того, проекты предпринимаются на всех уровнях организации. В проекте может участвовать один человек, одно структурное подразделение или несколько структурных подразделений организации.
Результатом выполнения проекта может быть:
▪ продукт, представляющий собой элемент другого изделия или конечное изделие;
▪ способность предоставлять услуги (например, бизнес-функции, поддерживающие производство или дистрибуцию);
▪ результаты − последствия или документы (например, исследовательский проект производит данные, которые можно использовать для определения наличия тенденции или пользы какого-либо нового процесса для общества).
Слайд 10Документ «Управление проектами 1»
Примерами проектов могут служить:
- разработка нового продукта или услуги;
- осуществление изменений в структуре, кадрах и стиле организации;
- разработка или приобретение новой или усовершенствованной информационной системы;
- строительство здания или сооружения;
- внедрение новой процедуры или нового процесса на предприятии.
Профессор В. И. Воропаев предлагает следующее определение проекта: проект – это ограниченное по времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и специфической организацией. Включение в определение «отдельной системы» указывает не только на целостность проекта и наличие у него границ, но и подчеркивает единственность проекта (в отличие от серийного производства или текущей деятельности организации), а значит, его неповторимость и признаки новизны.
P. Steinbuch дает практичное короткое определение: проект – это одноразовое намерение выполнения задачи.
Таким образом, проект характеризуется:
– определенной целью;
– определенными средствами (человеческие, материальные, финансовые ресурсы);
– определенным временем выполнения;
– уникальностью.
Слайд 11Документ «Управление проектами 1»
История развития управления проектами как таковыми восходит к Ноеву Ковчегу и коллективной охоте первобытных людей на мамонта. Более того, некоторые элементы управления проектами можно усмотреть в поведении хищников, охотящихся стаями. Однако история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам прошлого века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США – авиационных в «US AirCorporation» и нефтегазовых в фирме «Exon» [5]. В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.
Становление проектного менеджмента связано с военными разработками. В 1941 г. США приступили к выполнению Манхэттенского проекта с целью создания атомной бомбы. В 60-х годах стартовал проект НАСА «Аполлон», целью которого была высадка человека на Луне. В обоих случаях стояла задача координации действий по достижению целей в условиях жесткого ограничения времени. Проектный менеджмент разрабатывался и усовершенствовался как инструмент реализации сложных проектов, требовавших участия специалистов различных направлений и различных организаций. Первыми областями применения проектного менеджмента стали оборонные авиационные и космические проекты, введение новых технологий, например ядерной техники или поезда на магнитной подвеске и др.
В 1937 г. американским ученым Л. Гуликом была предложена матричная организация для выполнения сложных проектов. Практическое применение в полном объеме она получила в 1953 – 54 гг. в подразделениях совместных проектов Воздушных Сил США, специальных проектов по вооружению и с 1955 г. в Подразделении специальных проектов морского флота США. В 1956 г. компания «DuPontdeNemoursCo» образовала специальную группу для разработки методов и средств управления проектами. В 1957 г. к этим работам подключился исследовательский центр UNIVAC и фирма «RemingtonRand». Коллектив, который возглавляли Дж. Келли и Р. Уолкер, разработал метод критического пути (CPM) с программной реализацией на ЭВМ. В последующие два года была завершена и опробована при создании ракеты «Поларис» сис-тема сетевого планирования PERT. Программа «Поларис» включала 250 фирм-контракторов и более 9 тыс. фирм-субконтракторов. С этого вре-мени CPM и PERT стали использовать для планирования работ, оценки риска, контроля стоимости и управления ресурсами для ряда крупных военных и гражданских проектов в США. В 1959 г. комитетом Андерсона в НАСА был сформулирован системный подход к управлению проектом по стадиям его жизненного цикла. Тогда же вышла первая обобщающая статья Л. Гэддис по управлению проектами в журнале «HarvardBusinessReview».
До этого времени, а отчасти и сейчас, секретность, присущая большинству проектов в военно-космической сфере, препятствовала распространению методологии управления проектами. В особенности это касается анализа проблем, определения целей и задач проектов, формулировок ограничений и критериев их успеха.
В СССР, начиная с 30-х годов прошлого века, в ходе индустриализации страны и подготовки к войне реализовывались поражающие по своим масштабам и сложности проекты. К таким проектам можно отнести создание каналов, каскадов гидроэлектростанций, атомного оружия и др. Министерство среднего машиностроения (атомная промышленность) стало, по существу, государством в государстве, производя для отрасли практически все – от атомного оружия до продуктов питания. При выполнении этих проектов, несомненно, был накоплен уникальный и ценный опыт. К сожалению, положительные стороны этого опыта до сих пор не обобщены и не опубликованы. Большая его часть, оригинальные творческие находки потеряны безвозвратно, поскольку основных организаторов и участников этих проектов уже нет в живых.
Появление первых публикаций о сетевых методах дали толчок их развитию в СССР. В начале 70-х годов в СССР были разработаны оригинальные сетевые модели, более гибкие и мощные, чем в США (Г. М. Адельсон-Вельский, В. И. Воропаев, М. В. Шейнберг). Эти обобщенные сетевые модели были предназначены для сложных проектов с различными взаимосвязями между работами и временными ограничениями разного типа. Тогда же был разработан ряд стохастических и альтернативных моделей, учитывающих вероятностную природу различных элементов проекта: продолжительности работ, связей, ресурсов, альтернативных работ и др. (Д. И. Голенко, К. А. Антонавичюс, С. И. Лившиц). С 70-х годов сетевые методы начали преподавать студентам вузов как в США, так и в СССР.
Движение в защиту окружающей среды в 70-е годы создало серьезные проблемы при осуществлении крупных проектов по сооружению атомных электростанций, гидростанций, химических производств и др. В связи с этим началась интенсивная проработка вопросов, связанных с внешним окружением проектов и включением в их планирование эко-номических, политических, экологических и других факторов. В это же время интенсивно разрабатывались методы управления конфликтами, проблемы организационных структур, формирования команды проекта, стиля управления.
В 80-х годах П. Левене рассмотрел проблемы ресурсного и финансового обеспечения проектов как неотъемлемую составную часть проектного менеджмента. В эти же годы в СССР полностью централизованная и все более усложняющаяся система управления народным хозяйством подтолкнула к развитию методов мультипроектного управления и интегрированных систем управления (ИАСУ).
В 1987 г. в США было опубликовано первое издание коллективной работы сотрудников института PMI (ProjectManagementInstitute) – ProjectManagementBodyofKnowledge («Свод знаний по управлению проектами»). Проектный менеджмент окончательно сформировался как междисциплинарная сфера профессиональной деятельности. Далее началось стремительное распространение проектного менеджмента по странам и разным, в том числе нетрадиционным, сферам. Проектный менеджмент стал широко применяться в социальных и экономических проектах, программах помощи и т.д. Если на начальном этапе развития методология управления проектами рассматривалась только применительно к крупным и сложным проектам, то в дальнейшем утвердилась точка зрения, что многие ее элементы могут быть весьма эффективны и для выполнения малых проектов, вплоть до личных – организации от-пуска, юбилея родителей, свадьбы и т.п.
Ежегодно проходят всемирные конгрессы по управлению проектами. Были созданы национальные и международные организации, объединяющие специалистов по проектному менеджменту, например:
Советская (ныне Российская) ассоциация управления проектами СОВНЕТ (www.sovnet.ru) была учреждена в конце 1990 г. и зарегистрирована 1 февраля 1991 г. как добровольное объединение коллективов и общественных организаций, частных компаний, фирм и предприятий, а также отдельных специалистов, осуществляющих подготовку, выполнение и управление проектами в разных сферах деятельности.
Таким образом, в последней четверти прошлого столетия сформировался международный «Мир управления проектами», в котором объединены специалисты разных стран, направлений и сфер деятельности, разных национальностей и культур, что, несомненно, играет большую роль в развитии и обогащении управления проектами.
Развитие мировой экономики в последние годы ясно продемонстрировало, что предприятия могут выжить в длительной перспективе, только если им удастся при тех же или меньших издержках производить больше товаров или товары лучшего качества. Постоянно нарастающие технические и организационные нововведения и изменения в связи с сокращающимся жизненным циклом товаров, необходимость выпуска их широкой номенклатуры, интернационализация рынка приводят к необходимости мобилизации последних резервов рационализации производства. Если в прошлом повышение качества товаров и увеличение прибыли могли быть реализованы главным образом за счет рационализации и усовершенствования производственных процессов, то сегодня эти резервы в основном исчерпаны. Поэтому проектный менеджмент может и призван помочь тем, что он мобилизует творческие способности каждого работника. Уже в 60-х годах прошлого века компании начали осознавать, что внедрение проектного менеджмента является необходимостью, а не просто одной из альтернатив. При этом вопрос со-стоял не в том, как внедрять управление проектами, а как быстро это должно быть сделано. Почти каждая компания сегодня использует методологию управления проектами в той или иной мере.
Следует отметить, что процесс внедрения проектного менеджмента порой связан со значительным сопротивлением со стороны высшего руководства организаций, которое видит в нем определенную угрозу своему положению. Чаще всего эта категория руководителей заинтересована в сохранении статус-кво, причем эта заинтересованность основана скорее на интересах этого руководителя, чем на стратегических интересах организации в целом. Это обстоятельство, в свою очередь, приводит к разочарованию руководителей среднего уровня, стремящихся вне-дрить проектный менеджмент в интересах фирмы.
Международные и национальные ассоциации проектных менеджеров издают руководства и стандарты, которые регулируются и координируются IPMA. Наиболее известным и широко распространенным стандартом является PMBoK («ProjectManagementBodyofKnowledge»). Впервые он был издан американским Институтом проектных менеджеров в 1987 г. В 2000 г. вышло второе, в 2004 г. третье, а в 2008 г. четвертое издание этого стандарта.Руководства и стандарты обеспечивают интернациональный и междисциплинарный характер управления проектами. Благодаря им руководители проектов во всем мире руководствуются аналогичной философией и методологией управления проектами и, соответственно, говорят на «одном языке».
Вместе с тем стоит отметить, что стандарт PMBoK отражает требования к управлению проектами прежде всего с позиций интересов государственного заказчика, в частности министерства обороны США. В реальной жизни некоторые из этих требований, например, критерии успеха проекта, существенно зависят от того, являемся ли мы заказчиками или исполнителями проекта. Нередко организация-исполнитель перерасход бюджета проекта рассматривает как успех, если это не привело к санкциям, хотя это и противоречит кодексу этики проектных менеджеров.
Международные и национальные ассоциации проектных менеджеров активно участвуют в подготовке управляющих проектами и производят их сертификацию. Они ведут также и общедоступные реестры сертифицированных проектных менеджеров, с которыми можно ознакомиться на сайтах этих организаций.
Группа сертифицированных специалистов Российской ассоциации управления проектами на основе и в соответствии с Международными требованиями к компетенции специалистов по управлению проектами (InternationalCompetenceBaselineoftheInternationalProjectManagementAssociation – ICB, IPMA) разработала национальные требования к компетентности (НТК) специалистов по управлению проектами. В процессе разработки НТК вышли за рамки предусмотренного содержания и объема и по существу переросли в основы профессиональных знаний и требования к компетентности специалистов по управлению проектами. В итоге была подготовлена и издана книга «Основы профессиональных знаний и национальные требования к компетентности (НТК) специалистов по управлению проектами» (2002), ставшая основополагающим документом национальной сертификационной программы специалистов по управлению проектами IPMA / SOVNET.
Эта книга может служить путеводителем в современный мир знаний по управлению проектами и его библиографическим справочником. Кроме того, в издательстве «ЗАО “Проектная практика”» в 2010 г. вышла в свет книга «Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0)» [6]. Издание представляет основы профессиональных знаний, национальные требования к компетентности специалистов по управлению проектами и систему оценки их компетентности (NCB – National Competence Baseline SOVNET Version 3.0) и является нормативным документом Российской национальной сертификационной программы по управлению проектами.
Система сертификации, предлагаемая IPMA, включает четыре уровня, причем требования для каждого уровня зависят от требуемых в практической деятельности знаний, опыта, ответственности.
Уровень А. Сертифицированный директор программ или проектов СДП (Certificated Project Director – CPD) должен:
Уровень B. Сертифицированный управляющий проектами – СУП (Certificated Project Manager – CPM) должен:
Уровень C. Сертифицированный профессионал по управлению про-ектами – СПУП (Registered ProjectManagement Professional – RPMP) дол-жен:
Уровень D. Сертифицированный специалист по управлению проекта-ми – ССУП (CertificatedProjectManagementSpecialist – CPMS) должен:
обладать знаниями во всех областях управления проектами (и быть способным применять их в некоторых областях как специалист);
обладать широким спектром знаний в управлении проектами и быть способным применять эти знания на практике;
быть способным выступать в качестве члена команды проекта в любой функциональной области по управлению проектами.
Ноев Ковчег называют первым проектом человека. В качестве примера можно назвать целый ряд исторических проектов, которые известны всему миру:
строительные проекты:
– сооружение пирамид в Египте и Мексике,
– строительство Великой Китайской стены,
– строительство соборов (собор Святого Петра в Ватикане) и дворцов (Зимний дворец в С.-Петербурге);
военные проекты:
– походы Александра Македонского,
– военные походы римлян,
– нападение Германии на СССР,
– война в Персидском заливе;
технические проекты:
– сооружение Транссибирской магистрали,
– строительство Останкинской телебашни,
– высадка человека на Луну,
– создание космической станции «Мир».
Многообразие встречающихся в практической жизни проектов впечатляюще. В принципе, видов проектов столько же, сколько и самих проектов, что определяется уникальностью решаемых задач. Проекты различаются по сферам приложения, масштабу, длительности, сложности и т.д. Проекты можно классифицировать по различным основаниям, например:
по типу проекта: технический, организационный, экономический, социальный, смешанный;
по классу: монопроект, мультипроект, мегапроект;
по масштабу проекта: мелкий, средний, крупный, очень круп-ный;
по длительности проекта: краткосрочный, среднесрочный, долгосрочный;
по сложности проекта: простой, сложный, очень сложный;
по виду проекта: инвестиционный, инновационный, научно-исследовательский и др.
слайд 18Документ «Управление проектами 1»
Очевидно, что приведенная система классификации далеко не единственная и не лучшая. P. Steinbuch [10], к примеру, выделяет проекты личные, государственные и проекты предприятий. Он подчеркивает, что применение методов проектного менеджмента в ряде случаев полезно и для личных проектов, например таких, как получение образования, заключение брака, смена места работы, строительство дома, проведение юбилея.
Параллельно с ростом числа людей, занятых оказанием услуг, растет и число соответствующих проектов.
Любой проект осуществляется в окружении некоторой динамической среды, частью которой он и сам является. Очевидно, что среда оказывает на него определенное, порой решающее воздействие.
Когда проект начат, он вскоре получает самостоятельную жизнь. Во время осуществления проекта его участники концентрируются на выполнении своих заданий. Они живут, думают и действуют в мире их проекта. В рамках долговременной организации - предприятия возникает маленькая, относительно кратковременная «организация - проект». При этом важно не потерять связь с окружающей действительностью. Руководитель и команда проекта должны понимать и постоянно отслеживать изменения внешней и внутренней среды.
К факторам ближнего окружения проекта прежде всего относится руководство предприятия, которое определяет цели и основные требования к проекту. Большое влияние на проект могут оказывать основные структурные подразделения предприятия, инфраструктура предприятия, отношение общественных организаций и коллектива в целом.
К факторам дальнего окружения проекта могут относиться политические факторы, например политическая стабильность, поддержка проекта правительством; экономические факторы (цены, тарифы, налоги и т.п.); законы и право; характеристики общества; уровень развития и состояние науки, техники и технологий; состояние инфраструктуры страны; уровень развития и особенности культуры; природные и экологические факторы.
Существенное влияние на проект, особенно на процесс его успешной реализации, оказывает внутренняя среда проекта.
Внутреннюю среду проекта определяют [9]:
–стиль руководства проектом определяет психологическийклимат и атмосферу в команде проекта, влияет на ее творческую активность и работоспособность;
– специфическая организация проекта определяет взаимоотношения между основными участниками проекта, распределение прав, ответственности и обязанностей;
– участники проекта реализуют свои различные интересы в процессе осуществления проекта, формируют требования в соответствиис их целями и мотивацией и оказывают влияние на проект в соответствии с собственными интересами, компетенцией и степенью участия впроекте;
команда проекта является «мозговым центром», мотором и исполнительным органом проекта, от которого во многом зависит прогресс и успех проекта;
– методы и средства коммуникацииопределяют полноту, достоверность и оперативность обмена информацией междуучастниками проекта, что в значительнойстепени определяет успешность проекта;
– экономические условия проекта связаны сосметой и бюджетом проекта, ценами, налогами и тарифами, риском истрахованием, стимулами и льготами и другими экономическими факторами проекта и факторами, определяющими его основные экономические характеристики;
– социальные условия проекта характеризуются:
- обеспечением стандартных условий жизни для участников проекта,
- уровнем заработной платы,
- предоставляемыми коммунальными услугами,
- предоставляемыми социальными услугами (школы, детские сады,медобслуживание, отдых и т.д.),
- условиями труда и техники безопасности,
- страхованием и социальным обеспечением и др.
Факторы окружения проекта демонстрируют, как глубоко простираются связи проекта с его окружением. Степень влияния этих факторовдля различных проектов различна.
Из таблицы видно, что наибольшему влиянию внешнего окружения подвержены социальные и инвестиционные проекты, затем организационные, экономические, в меньшей степени инновационные. Наибольшее влияние на проекты оказывают: экономика, законы и право, затем культура, что несколько неожиданно, и только после этого политика и общество. Наименьшее влияние на проекты оказывают природа, экология и инфраструктура.
Учитывая сказанное выше, в задачи руководителя проекта и его команды входят:
- сбор полных требований к проекту и обеспечение проектной информацией всех заинтересованных участников;
- формирование прогноза динамики окружения проекта;
- постоянный мониторинг изменений внешнего и внутреннего окружения проекта;
- формирование критериев оценки приоритетов и иерархии требований: от обязательных для исполнения до мелких пожеланий.
В русскоязычной литературе по управлению проектами распространен термин «участники проекта». В зарубежной литературе обычно используется термин «stakeholders» («заинтересованные стороны», англ.), который вошел в целый ряд языков мира. Термин «участники проекта» является не вполне адекватным переводом английского термина «stakeholders». Поэтому, к примеру, в учебнике Ф.Тарасенко [11]предлагается прямое заимствование иностранного термина. В связи с отсутствием русского эквивалента термин «стейкхолдер», скорее всего, привьется.
Под стейкхолдерами проекта понимают все организации и всех личностей, которых так или иначе (в положительном или отрицательном смысле) затрагивает проект, и которые могут быть заинтересованы как в успехе проекта, так и в том, чтобы он вообще не состоялся.
К примеру, в Германии строительство одной из автострад пришлось надолго приостановить, поскольку один из фермеров воспротивился прохождению ее через свой земельный участок, на котором жили и были похоронены многие поколения его предков.
Состав стейкхолдеров проекта, их цели, роли, распределение функций и ответственности зависят от типа, вида, масштаба и сложности проекта, а также от фаз жизненного цикла проекта.
Очевидно, что для любого проекта принципиальный состав функций остается неизменным. Однако в простейшем случае (например, теплица на дачном участке) все основные функции проекта могут осуществляться одним лицом. В другом крайнем случае (например, строительство автозавода) мы будем иметь полный набор стейкхолдеров с детальным разделением функций.
Рассмотрим распределение ролей и как связаны с проектом и между собой основные стейкхолдеры проекта по выпуску новой продукции.
Заказчик – главная сторона, заинтересованная в осуществлении проекта и его успешности. Он будущий владелец и пользователь результатов проекта. Заказчик определяет основные требования и масштабы проекта, обеспечивает финансирование проекта за счет своих средств или средств привлекаемых инвесторов, заключает контракты с основными исполнителями проекта, несет ответственность по этим контрактам, управляет процессом взаимодействия между всеми участниками проекта. Он несет ответственность за проект в целом перед обществом и законом.
Инициатор– стейкхолдер проекта, который является автором главной идеи проекта, его предварительного обоснования и предложений по осуществлению проекта. Часто, хотя и далеко не всегда, инициатива исходит от заказчика. Но в любом случае для успеха проекта важ-но, чтобы заказчик был реально заинтересован в осуществлении проекта.
Инвестор(ы) – стейкхолдер(ы) проекта, вкладывающие средства в проект. Если инвестор и заказчик не являются одним и тем же лицом, то в качестве инвесторов обычно выступают банки, инвестиционные фонды и другие организации. Инвесторы вступают в контрактные отношения с заказчиками, контролируют выполнение контрактов и осуществляют расчеты с другими сторонами по мере выполнения проекта. Инвесторы являютсяполноправными партнерами проекта и владельцами всего имущества, которое приобретается за счет их инвестиций, пока им не будут выплачены все средства по контракту с заказчиком или по кредитному соглашению.
Руководитель проекта – лицо, которому заказчик и инвестор делегируют полномочия по руководству работами по осуществлению проекта (планирование, контроль и координацию работ всех участников проекта). Состав функций и полномочий руководителя проекта определяются контрактом с заказчиком. Обычно перед руководителем проекта и его командой ставится задача всеобъемлющего руководства и координации работ на протяжении жизненного цикла проекта до достижения определенных в проекте целей и результатов при соблюдении установленных сроков, бюджета и качества.
Команда проекта – специфическая организационная структура, возглавляемая руководителем проекта и создаваемая на период осуществления проекта. Задача команды проекта – осуществление функций управления проектом до эффективного достижения целей проекта. Состав и функции команды проекта зависят от масштабов, сложности и других характеристик проекта, однако во всех случаях состав команды должен обеспечить высокий профессиональный уровень всех возложенных на нее обязанностей
Контрактор (генеральный контрактор) – участник проекта, вступающий в отношения с заказчиком и берущий на себя ответственность за выполнение работ по контракту. Это может быть весь проект или его часть. В функции генеральногоконтрактора входит заключение кон-тракта с заказчиком (инвестором), отбор и заключение договоров с субконтракторами, обеспечение координации их работ, принятие и оплата соисполнителей. В качестве контрактора может выступать руководитель проекта или другие активные участники проекта.
Субконтрактор – это лицо (в т.ч. юридическое), которое вступает в договорные отношения с контрактором или субконтрактором более высокого уровня. Он несет ответственность за выполнение работ и ус-луг в соответствии с контрактом.
Проектировщик – юридическое лицо, выполняющее по контракту проектно-изыскательские работы в рамках проекта. Он вступает в договорные отношения с генеральным контрактором проекта или непосредственно с заказчиком.
Генеральный подрядчик – юридическое лицо, которое выбирается для реализации проекта. Он несет ответственность за выполнение работ в соответствии с контрактом, подбирает субподрядчиков для выполнения отдельных работ и услуг и заключает с ними договоры. В строительных проектах роль генподрядчика обычно выполняют строительные или проектно-строительные фирмы и организации.
Поставщики – субконтракторы, осуществляющие разные виды поставок на контрактной основе (материалы, оборудование транспортные средства и др.).
Лицензор – организации, выдающие лицензии на право владения земельным участком, ведения торгов, выполнения определенных видов работ и услуг и т.п.
Органы власти – сторона, удовлетворяющая свои интересы путем получения налогов от участников проекта, выдвигающая и поддерживающая экологические, социальные и другие общественные и государственные требования, связанные с реализацией проекта.
Владелец земельного участка– юридическое или физическое лицо, являющееся владельцем участка земли, вовлеченного в проект. Он вступает в отношения с заказчиком и передает на договорной основе право пользования или владения этим участком земли.
Производитель конечной продукции проекта– эксплуатирует созданные основные фонды и производит конечную продукцию. Его главная цель состоит в получении прибыли от продажи готовой продукции потребителям. Он принимает участие на всех фазах проекта и взаимодействует с основными участниками проекта. Его роль и функции за-висят от доли собственности в конечных результатах проекта. Во многих случаях он является заказчиком и инвестором проекта.
Потребители конечной продукции – юридические и физические лица, являющиеся покупателями и пользователями конечной продукции, определяющие требования к ней и оказываемым услугам, а также масштаб рыночного спроса. Именно за счет средств потребителей возмещаются затраты на проект и формируется прибыль всех участников проекта.
Другие участники проекта. На осуществление проекта оказывают влияние и другие стороны из окружения проекта, которые по существу также могут быть отнесены к стейкхолдерам проекта:
конкуренты основных стейкхолдеров проектов;
общественные группы и население, чьи экономические и вне-экономические интересы затрагивает осуществление проекта;
спонсоры проекта;
различные консалтинговые, инжиниринговые, юридические организации, вовлеченные в процесс осуществления проекта, и др.
.
Кроме субъектов – индивидов, групп, организаций – в число стейкхолдеров (в данном случае термин «участники проекта» совсем не подходит) рекомендуется также включать так называемых «безмолвных» стейкхолдеров, а именно [11]:будущие поколения (их еще нет, но их интересы необходимо учесть, чтобы не создать проблем нашим вмешательством в сегодняшнюю реальность, как это сделали с нами предыдущие поколения, – долги, ис-черпание даже возобновляемых ресурсов, проблема атомных и промышленных отходов, кислотные дожди и т.п.);
Для определения полного состава стейкхолдеров проекта, построения его функциональной и организационной структур для каждого проекта на стадии разработки концепции проекта должны быть определены:
Ответы на эти вопросы позволяют выявить релевантных стейкхолдеров проекта, их цели, мотивации, определить взаимоотношения и на этой основе принять обоснованные решения по организации и управлению проектом.
Основные функции стейколдеров приведены в таблице
Стандарт PMBoK [4] следующим образом определяет понятие проектного менеджмента:
Проектный менеджмент – это применение знаний, умений, инструментов и приемов к работам по проекту с целью удовлетворения требований к проекту. Руководитель проекта является лицом, ответственным за выполнение целей проекта.
Следует отметить, что в двух последних изданиях стандарта PMBoK [4, 12] в соответствии с современными тенденциями последовательно проводится процессный подход к управлению проектами от инициирования проекта до его завершения2.
Стандарт описывает суть процессов управления проектами в терминах интеграции процессов, их взаимодействия и целей, которым они служат.
|
Управление проектами выполняется с помощью применения и интеграции логически сгруппированных 42 процессов управления проектами, объединенных в 5 групп процессов: • Группа процессов инициации. Процессы, которые выполняются для определения нового проекта или новой фазы существующего проекта путем получения разрешения для начала проекта или фазы. • Группа процессов планирования. Процессы, требуемые для определения общего содержания проекта, уточнения целей и определения последовательности действий, требуемых для достижения целей проекта. • Группа процессов исполнения. Процессы, применяемые для выполнения работ, определенных в плане управления проектом для удовлетворения спецификаций проекта. • Группа процессов мониторинга и контроля. Процессы, требуемые для отслеживания, анализа и регулирования хода и эффективности исполнения проекта, выявления тех областей, в которых требуется внесение изменений в план, и инициации соответствующих изменений. • Группа процессов завершения. Процессы, выполняемые для завершения всех действий в рамках всех групп процессов и формального завершения проекта или фазы. Управление проектом включает: • идентификацию требований к проекту; • удовлетворение различных потребностей, решение проблем и удовлетворение ожиданий различных стейкхолдеров проекта в ходе планирования и выполнения проекта; • установление ясных и достижимых целей; • адаптацию спецификаций, планов и подходов к различным интересам и ожиданиям стейкхолдеров проекта; • балансирование противоречивых требований к качеству, объему работ, времени выполнения и стоимости. Удовлетворение или превышение нужд и ожиданий стейкхолдеров проекта неизменно включает баланс противоречивых требований между: • содержанием, временем, издержками и качеством; • стейкхолдерами проекта с различными нуждами и ожиданиями; • идентифицированными требованиями (нуждами) и не идентифицированными требованиями (нуждами). |
В связи со стремлением добиться такого баланса план управления проектом приобретает итеративный характер и проходит через последовательную разработку на различных стадиях жизненного цикла проекта. По мере накопления информации план управления проектом детализируется и улучшается. Последовательная разработка позволяет команде осуществлять управление на более детальном уровне по мере развития проекта.
Сфера управления проектами имеет свою уникальную область знаний, частично пересекающуюся с соседними областями. Область общего управления содержит знания, которые следует иметь каждому менеджеру проекта. Область технического управления содержит специальные знания в конкретной области деятельности. Это то, что делает менеджера проекта специалистом в этой области. Вспомогательные и поддерживающие дисциплины помогают менеджеру проекта лучше выполнять свои функции. Структурная модель областей знаний и компонентов основных процессов, приведенная на рис. 1.3, позволяет получить достаточно полное общее представление о современной концепции проектного менеджмента.
|
В международном стандарте PMBoK [4, 12] подробно рассматриваются девять функций управления проектами: 1. Управление интеграцией проекта. 2. Управление содержанием (предметной областью) проекта. 3. Управление сроками проекта. 4. Управление стоимостью проекта. 5. Управление качеством проекта. 6. Управление человеческими ресурсами проекта. 7. Управление коммуникациями (взаимодействиями и информационными связями) проекта. 8. Управление рисками проекта. 9. Управление контрактами и обеспечением проекта. |
|
1. Управление интеграцией проекта включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и действий по управлению проектом: |
|
2. Управление содержанием проекта. Цели проекта, задачи и работы, которые нужно выполнить для их достижения, вместе с требуемыми ресурсами определяют предметную область проекта, его содержательную сущность (англ. – scope). Поскольку цели, задачи, работы, их объемы и/или другие элементы предметной области проекта в процессе его «жизни» претерпевают изменения, то возникает необходимость управления содержанием (предметной областью) проекта. |
Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект тех и только тех работ, которые необходимы для успешного завершения проекта:
|
3. Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта: |
|
4. Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и управления расходами и обеспечивающие завершение проекта в рамках утвержденного бюджета: |
|
5. Управление качеством проекта включает в себя процессы и действия исполняющей организации, политику в области качества, цели и сферы ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, ради которых он был предпринят: |
|
Управление человеческими ресурсами проекта включает в себя процессы по организации команды проекта и управления ею: |
|
7. Управление коммуникациями проекта – это область знаний, включающая в себя процессы, необходимые для своевременного создания, сбора, распространения, хранения, получения и в конечном итоге использования информации проекта |
|
8. Управление рисками проекта включает в себя процессы, относящиеся к планированию управления рисками, их идентификации и анализу, реагированию на риски, мониторингу и управления рисками проекта |
|
9. Управление контрактами и обеспечением проекта включает в себя процессы покупки или приобретения тех необходимых продуктов, услуг или результатов, которые производятся вне исполняющей организации: |
Слайд 5. Документ «Концепция управления проектами 2»
Все проекты предпринимаются для решения какой-либо задачи: создания продукта, предоставления услуги, получения какого-либо результата. Жизненные циклы проекта и продукта (услуги, результата), как правило, не совпадают. Иногда жизненный цикл проекта бывает длиннее (например, организация выборной компании), но чаще всего он короче жизненного цикла продукта/услуги.
По современным воззрениям, принимая во внимание концепцию устойчивого развития человеческого общества, команда проекта должна понимать и учитывать полный жизненный цикл продукта (услуги, результата). Последними фазами жизненного цикла продукта, как правило, являются прекращение производства, сервисного обслуживания и поддержки и, наконец, утилизация продукта. Учет этого обстоятельства при выполнении проекта позволяет облегчить жизнь в будущем. Как показал опыт создания и ликвидации ядерных реакторов, затраты на их ликвидацию могут быть заметно выше затрат на их создание.
|
Проекты различаются по размеру и сложности. Независимо от размеров и степени сложности все проекты могут иметь следующую обобщенную структуру жизненного цикла: начало проекта; организация и подготовка; выполнение работ проекта; завершение проекта. |
Стоимость и вовлечение персонала в проект невелики в начале, достигают пикового значения по мере выполнения работ и быстро падают на этапе завершения проекта (рис. 1.5).
Влияние стейкхолдеров проекта, риск и неопределенность имеютнаибольшие значения в начале проекта (рис. 1.6). Эти факторы уменьшаются по ходу проекта.
Способность влиять на конечные характеристики продукта проектабез существенного влияния на стоимость имеет наивысшее значение в начале проекта и уменьшается по мере продвижения проекта к завершению.
Стоимость изменений и коррекции ошибок, как правило, существенно возрастает по мере приближения к завершению проекта.
В случае если ожидаемый результат проекта связан с продуктом,существует множество возможных взаимосвязей. Например, разработканового продукта сама по себе может являться проектом. С другой стороны, проект может состоять в добавлении новых функций или возможностей к существующему продукту, либо проект может быть предпринят для разработки новой модели. Многие составляющие жизненного цикла продукта могут сами по себе выступать в качестве проектов, например: проведение исследования применимости, проведение маркетингового исследования, запуск рекламной кампании, установка продукта, удержание целевой группы, проведение испытаний продукта на тестовом рынке и т.д. В каждом из данных примеров жизненный цикл проекта отличается от жизненного цикла продукта. Поскольку с одним продуктом может быть связано множество проектов, дополнительной эффективности можно достичь, управляя всеми сопутствующими проектами в совокупности.
|
Фазы проекта – это отдельные части в рамках проекта, требующие дополнительного контроля для эффективного получения основного результата проекта. Они позволяют разделить проект на логические подгруппы для более легкого управления, планирования и контроля. Фазы проекта обычно выполняются последовательно, но в некоторых проектных ситуациях могут перекрываться. При последовательном выполнении фаз завершение фазы сопровождается передачей полученного результата в следующую фазу. Такое завершение фазы представляет собой естественную точку для переоценки предпринимаемых усилий и при необходимости для изменения или досрочного завершения проекта. |
Эти точки называются выходами фаз, контрольными событиями, воротами фаз, воротами решений, воротами этапов, точками критического анализа или точками остановки. Как правило, работы фазы имеют свойства, которые отличают ее от других фаз. При этом могут привлекаться разные организации и использоваться разные наборы навыков.
Единого способа для определения идеальной структуры проекта не существует. Несмотря на общепринятую отраслевую практику стремления к использованию предпочтительной структуры, проекты в одной и той же отрасли (или даже в одной и той же организации) могут существенно отличаться друг от друга. Некоторые организации вводят правила, стандартизирующие все проекты, тогда как другие позволяют команде управления проектом выбирать наиболее подходящий вариант для каждого конкретного проекта. Например, одна организация может расценивать изучение выполнимости проекта как обычную предпроектную работу, другая может считать его первой фазой проекта, а третья может выделить изучение выполнимости в отдельный автономный проект. Аналогично: одна команда проекта может разделить проект на две фазы, тогда как другая команда проекта может принять решение об управлении всеми работами в единой фазе. Многое зависит от характера конкретного проекта и стиля работы команды проекта или организации.
Содержание отдельных фаз может меняться от проекта к проекту. К примеру, в исследовательских проектах или новшествах в технической или организационной области чаще всего в центре внимания стоит планирование и принятие решений о выборе альтернативы. Во внешних проектах центр тяжести чаще смещается на выполнение.
Иногда значение одной из фаз недооценивается. Так, практики нередко считают возможным пренебречь планированием, поскольку при малых проектах, по их мнению, в нем нет нужды, ведь они и так смогут на основе своего опыта сохранить контроль. Соответственно при больших и длительных проектах планирование отодвигается, поскольку многое еще может измениться, преждевременная фиксация не имеет смысла.
|
Планирование (фаза планирования) должно давать ответы на шесть вопросов: - Что должно быть сделано? Что является целью, предметом и содержанием проекта? - Кто может это сделать? Имеются ли соответствующие специалисты внутри пред-приятия или нужно привлекать сторонних? Кому будет поручена работа? - Как следует выполнять работу? Нужно ли соблюдать специальные предписания, нормы, пользоваться определенными способами? - Чем должна выполняться работа? Какие средства и ресурсы необходимы для ее проведения? - Когда работа должна быть выполнена? К какому сроку она должна быть закончена и, соответственно, не позднее какого срока она должна быть начата? Нередко фаза планирования подразделяется еще на ряд стадий. |
Патентованных рецептов с указанием, до какой степени точности необходимо рассматривать детали проекта уже на стадии планирования или достаточно задать только некоторые рамки, предоставив руководителю проекта большую свободу для действий и решений, не существует. Справедливо правило: планирования столько – сколько необходимо, и максимум делегирования ответственности и полномочий как можно ближе к рабочему месту.
|
Фаза управления проектом в наибольшей степени зависит от конкретного содержания работ. Следует только отметить, что в этой фазе нередко требуются решения особого вида, когда возникают отклонения, которые уже не могут быть скомпенсированы в рамках проекта и которые угрожают самой возможности достижения цели. Во многих случаях с завершением фазы выполнения проектацель проекта оказывается достигнутой. Но часто требуется еще обучение персонала и поддержка при освоении. Особое значение имеет эта фаза при внутренних проектах. Обычно цель всего мероприятия достигается только тогда, когда новые технологии, структуры и т.п. становятся ежедневной практикой и успешно используются работниками. Зачастую эта фаза требует гораздо больше времени, чем вначале предполагалось. |
|
Во время фазы планирования задачей контроля является поддержка процессов планирования и принятия решений, проверка соответствия частных планов целям проекта, их полноты и непротиворечивости. В фазе выполнения проекта фактические результаты сравниваются сзаданными, чтобы выявить отклонения от плана, проанализировать их причины и принять меры по исправлению положения. После завершения проекта должен быть проверен результат и должен быть зафиксирован и задокументирован опыт для будущих проектов. |
|
Успешное завершение проекта определяется как достижение целей проекта при соблюдении установленных ограничений: – на продолжительность и срок завершения проекта, – на издержки и бюджет проекта, – на качество выполненных работ и спецификации требований к результатам. При этом конечные результаты должны быть одобрены и приняты заказчиком. |
Казалось бы, какие могут быть еще вопросы, если все работы по проекту выполнены качественно и в срок, и деньги не перерасходованы. Дело в том, что жизнь меняется, и проект, который еще недавно был жизненно необходим заказчику, может стать для него ненужным или даже обременительным. Чтобы избежать неприятных неожиданностей, руководитель и команда проекта при всей занятости и увлеченности текущей работой по проекту обязаны отслеживать окружающую среду: появление новых технологий, действия конкурентов, смену руководства организации-заказчика и т.п.
|
Когда проект выполняется внутри организации, к нему предъявляются дополнительные требования: – минимальный или обоюдно согласованный (между клиентом/заказчиком и контрактором) объем допустимых изменений в предметной области проекта в отношении цели, задач, состава и объема работ; – отсутствие или по крайней мере минимальные нарушения те-кущей работы организации, и в то же время тесное взаимодействие между проектной командой и функциональными подразделениями, со-хранение производственной культуры и ценностей организации. Последние условия оценки успеха проектов требуют некоторых пояснений. 1. Изменения предметной области проекта, как правило, неизбежны, однако имеется потенциальная опасность, что крупные изменения могут повлиять на сущность или нарушить целостность проекта. Поэтому такие изменения должны быть одобрены как руководителем проекта, так и заказчиком/пользователем. 2. Руководство проектом должно вестись так, чтобы не нарушать текущую работу организации. Только в чисто проектных организациях проекты определяют их текущее существование. Для всех других организаций, как бы ни были важны проекты для их будущего существования и развития, жизненно важно поддержание текущей операционной деятельности. К примеру, в крупных вузах ежегодно выполняются сотни различных проектов. Если прекращение на год всех проектов еще как-то можно себе представить, то прекращение на год учебного процесса, несомненно, губительно для вуза. Приоритеты здесь очевидны, тем не менее в бюджетных организациях проекты, связанные с показательными мероприятиями, структурными перестройками и т.п., нередко оттесняют основную деятельность на второй план. Проектная и операционная деятельность в первую очередь различаются тем, что операционная деятельность является постоянной и дает на выходе повторяющиеся продукты, услуги или результаты. Проекты (наряду с членами команды) являются временными и конечными. Операционная деятельность поддерживает деловую среду, в которой выполняются проекты. Поэтому проектная и операционная деятельность организации должны осуществляться в тесном взаимодействии команды проекта и функциональных подразделений организации. |
Примером такого взаимодействия может являться проект по доработке продукта. Менеджер проекта может работать с несколькими операционными менеджерами для изучения предпочтений клиентов, разработки технических условий, создания прототипа, его испытания и начала производства. Команда будет связываться с операционными отделами для выяснения производственной мощности текущего оборудования или наиболее приемлемого времени для перевода производственных линий на выпуск новой продукции.
Объем ресурсов, поставляемых в проект функциональными подразделениями организации, меняется от проекта к проекту. Одним из примеров такого взаимодействия является назначение отдельных лиц, занятых в операционной деятельности, в качестве выделенных ресурсов в проект. Их операционный опыт используется для осуществления действий и оказания помощи в достижении результатов проекта при взаимодействии с остальной командой проекта.
В зависимости от характера проекта результаты могут изменять или дополнять существующую операционную деятельность. В этом случае операционный отдел будет внедрять результаты в последующую деловую практику.
Большинство руководителей проектов хотели бы, чтобы после старта проекта вся проектная деятельность проводилась независимо от деятельности материнской организации. Однако это бывает возможным далеко не всегда . Поэтому руководитель проекта должен быть готов вести свою работу, согласуясь с политикой, правилами, указаниями и требованиями «родительской» организации.
3. Компании и организации имеют свою производственную культуру и систему ценностей, которые создавались длительное время. Каждый руководитель проекта хотел бы иметь свою культуру в организации проекта и свои ценности на период работы над проектом. Однако надо помнить, что проект – это лишь эпизод в жизни организации.
К вышеназванным критериям успеха H. Kerzner добавляет еще один: проект можно считать успешным, если его заказчик готов в дальнейшем выступить в качестве рекомендателя [13]. Надо сказать, что наряду с истинной заботой о качестве проекта многие компании, чтобы «ублажить» заказчика, идут и на явное очковтирательство, демонстрируя наличие полного набора организационных и методических документов по управлению проектами, часть из которых сделана исключительно для показа заказчикам. К примеру, нередко заказчик просит показать ему общую схему управления проектами в компании. Многие компании США и Великобритании разрабатывают эту схему персонально для каждого заказчика, причем его проект, естественно, стоит на первом месте, позволяя клиенту думать, что его заказ является приоритетным [13].
|
В заключение укажем еще на основные (и типичные) ошибки в практике выполнения проектов, особенно малых и средних:
Но самая главная ошибка в проекте – это та, из которой не извлекли уроков. «Ошибку можно рассматривать как успех, если она была обнаружена достаточно рано, так что ресурсы могли быть переданы для выполнения более обещающего дела» [13]. Чтобы предвосхитить неприятные неожиданности в проекте, рекомендуется, как можно раньше определить ситуации, которые могут привести проект к провалу. С помощью команды проекта таким образом (метод «адвоката дьявола») может быть заранее выявлено большинство опасностей и, соответственно, приняты упреждающие меры. Наряду с методом «адвоката дьявола», при котором ставится вопрос «что может привести проект к провалу?», предложен и другой технический прием, который используется после завершения планирования проекта [14]. Обсуждение начинают с того, что проект «умер», и далее обсуждаются причины, почему это могло произойти. Каждому члену команды предлагается в течение нескольких минут написать две-три возможных причины провала проекта. К примеру, в качестве причины была названа и такая: «президент компании вышел на пенсию». Она вряд ли была бы на-звана даже при использовании метода «адвоката дьявола». Авторы [15] пишут, что многим кажется странным, что при достигнутом высоком уровне развития методологии и техники управления проектами большая доля выполняемых в мире проектов заканчивается если не полным провалом, то по крайней мере с большим превышением плановых сроков и стоимости. Дело в том, что успех или провал проекта в первую очередь определяется людьми, его выполняющими. По мнению H. Kerzner’a [13], в управлении проектами больше поведенческих аспектов, чем количественных. |
Чтобы поддерживать конкурентоспособность и жизнеспособность организации в условиях быстрого технического прогресса, приспосабливаться к социальным, экономическим и другим изменениям окружающей среды, необходимо своевременно адаптировать ее структуры и компетентность ее работников к новым условиям. Чтобы это было достигнуто быстро и эффективно, показано применение проектных форм работы.
Стоит отметить, что внутренние проекты развития организации в рамках управления изменениями (ChangeManagement) наиболее успешно могут выполняться группой внешних профессиональных менеджеров с привлечением специалистов предприятия. Одни сотрудники предприятия зачастую с этой задачей справиться не могут, поскольку психологически не готовы к радикальным изменениям.
|
В зрелых организациях управление проектами координируется в рамках всей организации или ее крупных частей в соответствии с ее стратегией. Координация обеспечивается централизованным управлением проектами, программами и портфелями. Портфель– это набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей. Проекты и программы портфеля не обязательно являются взаимозависимыми или напрямую связанными. Функция управления портфелями обеспечивает централизованное управление одним или несколькими портфелями, что включает выявление, установление приоритетов, авторизацию, управление и контроль проектов, программ и других связанных работ для достижения определенных стратегических целей. Управление портфелями предусматривает обеспечение пересмотра проектов и программ с целью установления приоритетов при распределении ресурсов и соответствия портфеля стратегиям организации. |
Организации управляют портфелями на основе стратегического плана, который может устанавливать иерархию портфеля, программы или включенных проектов. Одной из целей управления портфелем является максимальное увеличение его ценности с помощью тщательного изучения элементов портфеля – намеченных для включения программ, проектов и других сопутствующих работ. Элементы, наименее соответствующие стратегическим задачам портфеля, могут быть исключены. Таким образом, стратегический план организации становится первичным фактором, управляющим инвестициями в проекты. В то же время проекты обеспечивают программы и портфели обратной связью посредством отчетов о статусе и запросов на изменения, которые могут оказать влияние на другие проекты, программы или портфели. Потребности проектов, включая потребности в ресурсах, обобщаются и передаются на уровень портфеля, который в свою очередь задает направление организационного планирования.
|
Программа – эторяд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. Программы могут содержать элементы работ, имеющих отношение к проектам, но лежащих за пределами содержания отдельных проектов программы. Проект может быть или не быть частью программы, но программа всегда содержит проекты. Слайд 22.Документ «Концепция управления проектами 2» |
Управление программой определяется как централизованное, скоординированное управление группой проектов для достижения стратегических целей и преимуществ программы. Проекты в рамках программ связаны посредством общего результата или совместных функциональных возможностей. Если связь между проектами заключается только в наличии общего клиента, продавца, технологии или ресурса, предпринимаемыми усилиями следует управлять как портфелем проектов, а не программой.
Управление программами уделяет основное внимание взаимозависимостям проектов и помогает определить оптимальный подход к их администрированию. Действия, связанные с этими взаимозависимостями, могут включать:
Организации, постоянно выполняющие различные проекты, нередко создают специальное подразделение – офис управления проектами (ProjectManagementOffice, PMO). Это подразделение осуществляет различные функции, относящиеся к централизации и координации управления проектами, входящими в его сферу ответственности. Сфера ответственности офиса управления проектами может варьироваться от оказания поддержки в управлении проектами до прямого управления проектом. Проекты, поддерживаемые или управляемые PMO, могут быть не связанными, но управляться в совокупности. Конкретная форма, функции и структура PMO зависят от потребностей организации, поддержку которой он осуществляет. Конкретный PMO может получить полномочия действовать как неотъемлемая заинтересованная сторона проектов, имеющая решающее слово в начальной стадии каждого про-екта. Он может иметь полномочия давать рекомендации, или останавливать проекты, или выполнять другие действия, чтобы цели компании оставались согласованными и непротиворечивыми. Кроме того, PMO может участвовать в отборе, управлении и распределении общих или выделенных ресурсов проекта.
Основная функция PMO заключается в поддержке управления проектами различными способами. К примеру:
▪ управление общими ресурсами всех проектов, администрируемых PMO;
▪ определение и разработка методологии, лучших практик и стандартов управления проектами;
▪ коучинг, наставничество, обучение и надзор;
▪ мониторинг соответствия стандартам, процедурам и шаблонам управления проектами посредством аудитов проектов;
▪ разработка и управление принципами, процедурами, шаблонами проекта и другой общей документацией (ресурсами организационного процесса);
▪ координация коммуникаций между проектами.
Успехи в совершенствовании управления проектами несомненны. Тем не менее анализ выполненных проектов показывает, что по-прежнему большинство проектов выполняются с нарушением сроков и превышением бюджетов. Так, авторы [20, 21] указывают, что необоснованный оптимизм, объединенный с политическим давлением, приводит к тому, что вполне успешно завершаются лишь около 10 % инвестиционных проектов. При этом среднее превышение их бюджетов составляет 28 %. В исследовании, проведенном A. Shenhar и D. Dvir [22], было показано, что 85 % рассмотренных ими проектов были выполнены с превышением сроков и бюджета. Среднее превышение сроков составило 70 %, а бюджета – 60 %.
Значительные превышения сроков и издержек в проектах – это явления, известные уже тысячелетия. J. Elton и J. Roe по этому поводу пишут: «Сколько проектов в вашей организации были завершены во-время и уложились в бюджет? Большинство менеджеров ответят вам: ни один. И это вопреки использованию программных инструментов управления проектами, технологии менеджмента, систем управления данными, программ тренинга команд и использованию ”лучшего опыта”. Каждый менеджер имеет оправдания, почему данный проект удался плохо, но попытки предусмотреть впредь неожиданные проблемы редко имеют успех» 23.
Особенно ярко эффект большого превышения фактических из-держек над плановыми проявляется в проектах внедрения информационных технологий. При этом проблемы остаются нераспознанными в течение длительного времени. Так в 1992 г. Социальный департа-мент Калифорнии начал проект создания автоматизированной системы штата по поддержке детей. Был заключен контракт с фирмой на 75,5 млн дол. на три года. К 1995 г. расходы незавершенного проекта достигли 260 млн дол. Проект все же был продолжен, и только в 1997 г., после пятилетней работы, он был прекращен. При этом общие издержки достигли 345 млн дол. 13.
Ярким примером перерасхода средств и превышения сроков является история создания истребителя F-22 «Fighter». ВВС США планиро-вали закупить 183 таких истребителя по цене 137 млн дол. за штуку (полная его стоимость с учетом затрат на исследования и испытания превысила 300 млн дол.). Истребитель был задуман как противовес двум советским истребителям. В 1980 г. концерн «LockheedMartin» вы-играл контракт на поставку 750 истребителей F-22. В 1990 г. Пентагон снизил заказ до 648 истребителей в связи с возросшими расходами на разработку. В 1991 г. развалился СССР. В связи с постоянно возрастав-шими расходами на разработку истребителя Пентагон последовательно уменьшал заказ: в 1994 г. до 442 самолетов, в 1997 г. до 339 самолетов, а в 2003 г. до 276 самолетов. В 2004 г. были завершены летные испыта-ния истребителя, которые подтвердили, что создан один из самых со-вершенных боевых самолетов в мире. В 2005 г. первый самолет был принят на вооружение с десятилетним опозданием по сравнению с пла-новым сроком. В 2006 г. Пентагон заявил, что он приобретет только 183 истребителя. Что же касается общего результата этого проекта, то в 2008 г. министр обороны Роберт Гейтс поставил под сомнение его целесообразность, сообщив конгрессу, что «F-22 не смог выполнить от-дельной миссии» в Ираке и в Афганистане [18].
Ученые, правительственные и финансовые учреждения разных стран и международных организаций провели множество исследований причин нарушения плановых сроков и перерасхода средств, причем был изучен ход тысяч проектов. В табл. 1.4 представлены некоторые результаты этих исследований.
В качестве основных причин срыва сроков и перерасхода средств, а иногда и полного провала проектов создания нового вооружения, когда не достигаются требуемые технические характеристики, названы следующие [18]:
Периодический аудит проектов в области информационных технологий, проводимый группой специалистов Массачусетского университета, показал, что успешно завершаются только около четверти всех проектов. Они обнаружили также любопытную зависимость от размера проекта. Наиболее крупные проекты никогда не завершаются в срок и с соблюдением бюджета. A. Pavlak [26] объясняет это тем, что большие проекты являются сложными системами и в соответствии с теорией сложных систем имеют врожденный уровень непредсказуемости. В случае больших проектов эта непредсказуемость является результатом ряда факторов: много участников с потенциально разными интересами, длительные сроки, уязвимость по отношению к изменениям внешней среды, проблемы внутренней коммуникации. К примеру, в связи с сооружением во Франции скоростной железной дороги TGV возникли опасения по поводу экологического воздействия на национальный парк Luberon. Согласование траектории дороги заняло 30 месяцев, в течение которых было проведено более 2000 совещаний. Хотя план дороги был доведен до общественности в октябре 1992 г., строительство реально началось только в сентябре 1995 г.
Все это – потенциал для неожиданных технических сюрпризов. При этом большие проекты, как правило, возглавляются весьма квалифицированными проектными менеджерами, а команды состоят из опытных работников, прошедших все необходимые тренинги.
Группа корейских специалистов детально проанализировала ход текущего мегапроекта KTX («KoreaTraineXpress») сооружения скоростной железной дороги Сеул – Тегу – Пусан (Seoul – Daegu – Busan) [27]. Общая протяженность дороги составляет 412 км, число рабочих пакетов проек-та – 11 141. После того как стоимость проекта возросла с 5,8 до 18,4 млрд. дол., а время создания дороги с 7 до 12,5 лет, правительство под давлением общественности разделило дорогу на два пусковых участка, первый из которых был пущен в 2004 г. Второй участок продолжает строиться, и по плану должен быть завершен в 2010 г. Дорога состоит из 26 секций, из которых критичными оказались всего три секции. Они-то и определили перерасход средств и времени: секция 2-1 длиной 15,5 км, секция 5-1 длиной 9,4 км и секция 8-2 длиной 16,9 км. Сравнение плановых и фактических графиков сооружения этих участков приведено на рис. 1.9. Все остальные секции были завершены даже раньше запланированного времени.
Наибольший вклад в нарушение сроков внес участок 2-1, составляющий менее 4 % общей протяженности линии (задержка на 4 года из общих 5 лет задержки проекта), в связи с задержками в приобретении земли, неспособностью собственников стратегически планировать сложный проект, частыми изменениями маршрута из-за неудовлетворительного исследования грунтов, а также ряда задержек в получении раз-решений и экспертиз на ранних стадиях проектирования. К примеру, проектирование задержалось на два года в связи с обнаружением за-брошенной шахты вблизи тоннеля, что привело к изменению маршрута и перепроектированию линии.
Классическим примером превышения сроков и стоимости проектов считается здание Оперы в Сиднее, где издержки на строительство (свыше 100 млн дол.) превысили смету (7 млн дол.) в 16 раз [25]. Построить здание планировалось за 5 лет, реально срок составил более 16 лет.
В учебниках этот факт приводится в качестве наиболее яркого примера провала проекта и так воспринимается читателями. В то же время это может служить и яркой иллюстрацией относительности критериев успешности проектов: Оперный театр в Сиднее является одним из мировых архитектурных чудес, ежегодно его посещают миллионы туристов, принося значительный постоянный доход и славу городу. Сегодня никого не волнует, как этот проект управлялся, и большинство людей считают его большим успехом.
Для начала разграничим понятия «цель» и «задача».
Цель – это желаемый результат деятельности, который может быть достигнут в пределах определенного интервала времени.
Задача – это желаемый результат деятельности, достижимый за намеченный (заданный) интервал времени и характеризующийся набором количественных данных или параметров этого результата.
Таким образом, задача отличается от цели тем, что для нее должен быть указан срок ее выполнения и заданы количественные характеристики желаемого результата. Кроме того, цель представляет собой более общее понятие, чем задача: она достигается в результате решения ряда задач. Отсюда следует, что задачи можно упорядочить по отношению к целям. В этом кроется свойство множественности целей: каждая цель может быть декомпозирована на составляющие ее задачи или подцели.
Цели, как правило, формулируются по результатам анализа проблемных ситуаций (рис. 1.10).
Цели проекта, структура проекта и организация проекта могут описываться взаимосвязанными иерархическими (древовидными) моделями, в которых могут быть установлены отношения между компонентами: цели – части проекта – участники проекта и др.
Для возможности определения степени достижения целей проекта необходимо выбрать соответствующие критерии. На основе этих критериев можно оценивать альтернативные решения по достижению целей проекта.
Цели проекта должны быть функциональны и операциональны.
Функциональность целей означает, что они реалистичны и реализуемы. Это относится не только к ожидаемым результатам, но и к возможности достичь их с помощью выделенных средств и в рамках отведенного времени.
Операциональность целей означает, что они сформулированы так, что на их основе могут быть выведены конкретные мероприятия. Описание цели должно быть настолько однозначным, чтобы служить критерием для контроля и оценки результатов. С другой стороны, цели не должны излишне ограничивать поле возможных будущих решений.
Цели должны иметь ясный смысл. Результаты, получаемые при достижении цели, должны быть измеримы, а заданные ограничения и требования должны быть выполнимы, т.е. цели должны находиться в области допустимых решений проекта.
При управлении проектами область допустимых решений обычно ограничивается временем, рамками бюджета, выделяемыми ресурсами и требуемым качеством получаемых результатов. Могут быть и другие ограничения.
При нечеткой формулировке цели или нереалистичных условиях неуспех проекта запрограммирован, причем чаще всего ответственность за такой результат берет на себя не заказчик. Она возлагается на руководителя проекта. В связи с этим рекомендуется, прежде чем взяться за выполнение проекта, тщательно взвесить возможность успешного его завершения.
Кроме явных (объявленных) целей проекта почти всегда существуют еще неявные цели, о чем руководители проектов порой и не догадываются [25]. Фактически такие цели неявно существуют как следствие декларируемых целей или разного рода ограничений. Р. Альбонетти приводит по этому поводу пример реализации проекта в тропиках. Сезон дождей, попадающий на период строительства, должен рассматриваться как ограничение. Соответственно, в графике строительства, необходимо предусмотреть окончание всех подземных работ до начала сезона дождей. Это означает, что проект имеет неявную цель, которая была обнаружена вовремя. Если бы эта цель не была своевременно выявлена, то дожди могли остановить работы и сорвать своевременное выполнение проекта.
Могут быть неявные цели и другого характера. Например, во времена СССР нередко проводились какие-нибудь мероприятия «на благо народа». Но за этим нередко скрывалась главная цель – стремление руководителя прославиться, удержаться на посту или подняться по иерархической ступеньке. Если руководитель проекта не догадывался об этой главной цели и, предположим, не посчитал нужным пригласить прессу, это могло дорого ему обойтись.
Следует также подчеркнуть, что однажды сформулированные цели проекта не должны рассматриваться как нечто неизменное. В ходе реализации проекта под воздействием изменений в окружении проекта или в зависимости от прогресса проекта и получаемых промежуточных результатов цели проекта могут претерпеть изменения. Поэтому целеполагание нужно рассматривать как непрерывный динамический процесс, в котором анализируется сложившаяся ситуация, тенденция и при необходимости осуществляются корректировки целей.
|
Условия, на которых давались обещания, заказчики и руководители обычно забывают, но сами обещания помнят. |
Подготовка проекта может занимать значительное время, порой до года и более, требует привлечения высококвалифицированного персонала и, соответственно, может быть достаточно дорогим делом. В таких случаях вполне уместно рассматривать подготовку проекта как «проект проекта», хотя он, может быть, и не будет в полной мере удовлетворять определению проекта. К примеру, зачастую не определяется стоимость подготовки проекта.
В основе проекта обычно лежит проблема, идея, которую надо претворить в жизнь, или заказ. В зависимости от этого как время, необходимое для подготовки проекта, так и объем подготовительной работы могут существенно отличаться. Разными могут быть также критерии оценки успешности проектов. Поэтому с позиции исполнителей проекта это принципиально разные виды проектов.
Появление первых нормативных документов по управлению проектами, а также последующих публикаций и учебников было связано с заказами оборонных ведомств США, Великобритании и Советского Союза. Поэтому все они содержат определенный перекос в сторону интересов заказчика.
Если посмотреть на критерии успешности проектов, то в них «по умолчанию» предполагается, что обе стороны – заказчик и исполнитель – своей высшей целью считают исполнение проекта в минимально возможный срок, за минимальные деньги и c высоким качеством. Реально исполнитель обычно стремится иметь достаточный запас по времени, что обеспечивает ему не только более спокойную жизнь, но и возможность более гибкого использования своих ресурсов и снижения издержек. Что касается стоимости проекта, если исполнителю удается без опасных для себя последствий втрое перерасходовать плановый бюджет проекта, он вряд ли будет считать такой проект неуспешным. В прессе и в литературе по управлению проектами полно скандальных ис-торий о многократном превышении сроков и стоимости проектов. Более того, известна масса случаев, когда исполнитель намеренно занижал стоимость проекта, чтобы втянуть заказчика в выполнение работ, а когда «коготок увяз», то зачастую политикам уже деваться некуда.
Это, конечно, противоречит кодексу этики проектных менеджеров, но в реальной жизни дилемма разрешается далеко не всегда равным учетом интересов обеих сторон. Поэтому необходимо отдавать себе отчет в том, что исполнитель действует исключительно в собственных интересах, хотя, безусловно, взвешенный учет интересов важного заказчика соответствует стратегическим целям исполнителя. Конечно, во многих случаях значительные превышения сроков и стоимости проектов связаны не с умыслом исполнителя, а с плохой подготовкой проектов и неудовлетворительным управлением рисками.
Основанием для формирования заказа на выполнение проекта является появление у заказчика некоторой проблемы или идеи. Первым шагом для оформления заказа является подготовка технических требований (ТТ). Для этого заказчик должен провести работу по уточнению желаемых результатов, провести оценку возможной стоимости работы, а также проанализировать риски проекта. Далее он должен определиться с формой размещения заказа: будет ли он проводить тендер (что для многих государственных заказчиков является обязательным) или просто предложит заказ одному или нескольким возможным исполнителям. Кроме того крайне желательно проанализировать цели проекта с позиций хотя бы основных стейкхолдеров проекта.
Слайд 6.Документ «Концепция управления проектами 3»
Тщательная подготовка проекта заказчиком может избавить его от многих последующих неприятностей. Это кажется очевидным, тем не менее, остается только удивляться тому, как часто заказчики имеют смутное представление не только об объеме и стоимости работ, а также о возможностях исполнителях, но даже о собственных целях.
В учебниках принимается за аксиому положение о том, что представление технических требований является обязанностью заказчика. Однако сплошь и рядом заказчик не обладает достаточной компетенцией для формирования полного и грамотного набора технических требований, а иногда имеет лишь смутное представление о своих желаниях. В этом случае «просвещение заказчика» с четким его информированием о значении, финансовых и технических последствиях каждой позиции ТТ ложится на руководителя и команду проекта как на профессионалов в предметной области проекта. Технические требования необходимо проанализировать на полноту и корректность и при необходимости совместно с заказчиком доработать их.
Для проектов не технического характера может не существовать стандартного состава требований. В этих случаях, тем не менее, формальный документ, наиболее полно отражающий требования заказчика и при этом учитывающий нормативные документы в предметной области проекта, целесообразно получить от заказчика (или составить совместно с ним).
С получением технических требований от заказчика начинается подготовка проекта исполнителем. Исполнитель, получив технические требования заказчика, анализирует их с позиций осуществимости с учетом физической реализуемости и имеющихся у него человеческих и материальных ресурсов. После этого необходимо выполнить предварительное планирование проекта, что дает исполнителю возможность оценить стоимость и сроки выполнения проекта, а также провести анализ рисков проекта.
Такая подготовка не только вооружает исполнителя необходимой информацией для переговоров с заказчиком о сроках и стоимости работ, но и позволяет обоснованно обсуждать распределение рисков между исполнителем и заказчиком и договариваться относительно необходимых резервов на случай реализации наиболее опасных рисков.
Чрезвычайно важно, чтобы заказчик и исполнитель одинаково понимали цели проекта, предметную область проекта (по каждой позиции технических требований), фактическую основу для калькуляции работ, ограничения и условия. Автору учебника неоднократно приходилось сталкиваться с ситуациями, когда пункты технических требований толковались заказчиками и исполнителями совершенно по-разному. Н. Kerzner приводит яркие примеры таких недоразумений:
Дополнительные расходы компании на транспортировку оборудования и персонала и повторные испытания составили 1 млн дол. [13].
Неверная интерпретация технических требований может очень дорого обойтись обеим сторонам, поэтому этот документ должен быть проработан и обсужден с максимально возможной тщательностью. Следует избегать неточных формулировок: «около», «оптимально», приблизительно» и т.д. Полезным оказывается получение рецензии от стороннего эксперта. Тем не менее, разночтения в сложных проектах почти неизбежны, что ведет к последующему ползучему изменению предметной области проекта (creepingscope) с соответствующими последствиями в виде срыва плановых сроков и увеличения издержек. Для ряда отраслей (авиакосмическая промышленность, оборона, информационные технологии) это явление, по выражению Н.Kerzner’а, стало образом жизни. В связи с этим в НАСА имеется целый ряд детальных руководств по разработке технических требований.
На основе технических требований заказчика могут быть предварительно сформулированы цели и основные задачи проекта, что в свою очередь создает возможность выявления и анализа всех релевантных стейкхолдеров проекта и основных рисков проекта.
На основании глобальной цели проекта с помощью одной из форм мозгового штурма команда проекта должна определить стейкхолдеров проекта. Целесообразно составить возможно более полный список стейкхолдеров, проанализировать для каждого из них полезные и вредные последствия от выполнения проекта (как в период работы над проектом, так и после его завершения). Необходимо также рассмотреть возможный вклад стейкхолдеров в осуществление проекта, а также возможное противодействие, в случае, когда проект имеет некоторые отрицательные последствия для стейкхолдера. После этого может быть составлен перечень релевантных стейкхолдеров проекта, откорректированы при необходимости цели проекта, а в список задач включены задачи, позволяющие обеспечить успех проекта с учетом противоречивых интересов стейкхолдеров.
С помощью одного из известных логических или творческих методов поиска альтернатив, к примеру метода мозгового штурма, команда проекта должна выявить и зафиксировать основные риски проекта, которые могут привести его к провалу. Прежде всего целесообразно рас-смотреть технические, экономические, политические, социокультурные риски, а также риски по персоналу проекта и организации, в которой он выполняется. По результатам анализа выявленных рисков может потребоваться корректировка цели и задач проекта.
На основе технических требований заказчика и с учетом явных и неявных целей релевантных стейкхолдеров, результатов предварительного анализа рисков необходимо уточнить цели и задачи проекта.
Не следует стремиться к формулировке цели проекта в виде одной длинной фразы. Лучше сформулировать ее в виде нескольких четких недвусмысленных выражений. Важность однозначного понимания цели командой проекта и заказчиком несомненна. Поэтому необходимо вы-полнить детальное описание цели с пояснением смысла и содержания всех использованных терминов.
Нередко после формулирования цели проекта выявляются новые стейкхолдеры. В этом случае весь вышеизложенный процесс необходимо повторить.
Результаты предшествующей работы позволяют приступить к формированию технического задания (ТЗ) на проект (в общем случае, проектного задания), которое после утверждения является основным исходным документом для команды проекта и заказчика. В нем команда проекта излагает не только то, что она будет делать, но и как.
Ядром проектного задания являются требования заказчика (ТТ) и, соответственно, перечень подлежащих решению задач. Постановка задач должна быть описана как можно точнее. Как правило, должно быть проведено четкое разграничение того, что еще относится к проекту и что лежит уже за пределами проекта. К примеру, при внедрении программного продукта 1С в Томском политехническом университете (ТПУ) не было четко оговорено обучение бухгалтеров и приспособление программы к специфическим требованиям бухгалтерского учета в вузе, что привело к напряженности, когда для выполнения этих задач потребовались значительные дополнительные средства.
Полное проектное задание должно как минимум содержать определение задания, повод для выполнения проекта, условия выполнения проекта и сведения о представляемых в распоряжение проекта ресурсах.
Проектное задание должно содержать также информацию о том, почему появился проект. Исполнители проекта и все участники проекта должны знать причины, мотивы и повод для осуществления проекта. Обычно основой появления проекта является ранее проведенный проблемный анализ. Если для проведения проекта существует некоторый особый повод, то его тоже следует назвать и при необходимости обосновать.
В результате планирования проекта и последующего принятия решения о его выполнении должны быть известны и четко названы в проектном задании необходимые для выполнения проекта ресурсы. При этом ресурсы должны быть дифференцированы по основным группам и при необходимости по основным частям проекта:
Названные в проектном задании средства, как правило, следует понимать не как прогноз, а как твердое задание, за пределы которого при выполнении проекта выходить нельзя. При этом руководитель проекта отвечает за соблюдение заданных границ.
Зачастую в проектах задаются и различные другие условия, которые, естественно, обязательно должны быть названы в проектном задании. При этом речь может идти о двух видах условий: обязательных условиях, которые в любом случае должны быть соблюдены, и рекомендуемых (желательных) условиях, которые следует соблюдать, если они не вызывают серьезных проблем.
В техническом задании обязательно должны быть четко изложены критерии успеха проекта, причем не в общих фразах, а в желаемых измеримых параметрах результата выполнения проекта (по возможности в виде естественных атрибутов цели или в виде прокси-атрибутов, т.е. индикаторов достижения цели).
Необходимо проанализировать и отразить основные ограничения проекта, как со стороны заказчика, так и со стороны исполнителя (например, ограничения по срокам, средствам, применяемой технике и технологии, возможности нарушения текущих технологических процессов, соблюдение законов, предписаний и т.п.).
В проектном задании могут быть сформулированы различные рекомендации и запреты, требования по качеству, условия относительно порядка отчетности, требования к объему проектной документации. В проектном задании должны быть также четко выделены решения, которые не могут приниматься руководителем проекта или проектной группой.
При выполнении проекта должна быть полная возможность исходить из того, что все не оговоренные позиции никаким ограничениям не подлежат!
Подготовку проектов этого вида нужно рассматривать с позиций автора идеи, заказчика и инвестора. Основная задача автора заключается в том, чтобы найти заказчика и инвестора. Основная задача последних – провести грамотную экспертизу проекта.
Внутренние проекты в организациях часто основываются на видении руководителя, анализе состояния дел, процессах поиска идей по их улучшению. Осознанные недостатки также могут быть основанием для проекта. Идеи могут быть принесены извне. Основания для идей могут лежать в личной, производственной или общественной сфере.
Для проекта, в основе которого лежит идея инициатора проекта, в разделе «подготовка проекта» идея должна быть не только ясно и четко сформулирована, но и обоснована. В обосновании необходимо показать, что она не противоречит физическим законам и может быть в принципе реализована.
В случае инвестиционного проекта рациональной формой обоснования идеи является бизнес-план. Если он составлен реалистично, бизнес-план может быть убедительным обоснованием идеи. Примерами обоснования идеи проекта могут служить также формы заявок на гранты разнообразных международных, государственных и частных фондов.
Бизнес-план составляется по стандартной методике, которая реализована в достаточно мощных программах типа ProjectExpert и достаточно подробно рассматриваетсяв курсах по инвестиционному проектированию.
Далее необходимо определиться с заказчиком и инвестором. Конечно, можно, а иногда и нужно провести детальное планирование проекта до согласования идеи выполнения проекта с заказчиком и инвестором, поскольку последних далеко не всегда удовлетворяют грубые оценки сроков и стоимости.
Дальнейшие шаги в подготовке проекта аналогичны тем, которые были рассмотрены выше: получить от заказчика технические требования, выполнить анализ стейкхолдеров и рисков, сформировать техническое задание.
Подготовка заявок на такие проекты («проект проекта») может занимать до года и более. Основным методическим инструментом для подготовки заявок на международные проекты является логико-структурный подход.
Логико-структурный подход (ЛСП) был разработан Агентством Международного развития в США в конце 60-х годов для оказания помощи в планировании, управлении и оценке содействующих прогрессу мероприятий. С того времени этот подход в качестве инструмента планирования и управления был принят большим количеством других учреждений, оказывающих помощь в процессах развития, например Европейским Сообществом.
В период с 1990 по 1997 гг. в рамках европейской программы «Темпус» было осуществлено финансирование более 2,5 тыс. проектов. Опыт показал, что основные трудности в их выполнении возникали там, где в ходе разработки и осуществления проекта были упущены решающие для успеха проекта факторы. К примеру, в первоначальный план некоторых проектов не были включены все основные заинтересованные стороны, имели место сбои в системе мониторинга проектов и др. Поэтому с 1996 г. в предусмотренные программой «Темпус» процедуры был включен «Логико-структурный подход», представляющий собой средство совершенствования разработки и менеджмента проектов [45].
,,,,,,,,,,,,,,,,,,,,,,,,,,,
Подготовка проекта, в основе которого лежит проблема, начинается с анализа проблемы, возникшей в организации, в обществе или у отдельного человека. Содержание фазы подготовки проекта охватывает выявление подлежащей решению проблемы, определение цели проекта и формулирование на ее основе частных целей (задач). В результате мы можем сформировать содержание проекта, которое может быть оформлено в качестве заявки и представлено утверждающей инстанции. Если заявка утверждается, то начинается собственно проект.
…………………………
Проекту требуются организационные рамки, чтобы обеспечить целенаправленное взаимодействие всех участвующих в нем лиц. Этот вопрос имеет несколько аспектов.
Во-первых, заказчику необходимо определиться с тем, будет ли проект выполняться преимущественно силами самой организации или его поручат сторонней организации. Соответственно реализуются схемы внутреннего или внешнего управления проектами.
Во-вторых, поскольку проект, с одной стороны, является по существу некой относительно самостоятельной «организацией», а с другой – частью материнской организации, необходимо определить формы их взаимодействия, т.е. определить линии власти, полномочий и коммуникации. Проект и проектная группа должны быть интегрированы в процессы и организационную структуру предприятия, что может осуществляться четырьмя основными способами:
через создание чисто проектной организации,
через менеджмент влияния,
через создание линейной проектной организации,
через матричную проектную организацию.
В-третьих, самому проекту тоже необходима определенная организационная структура. Это связано как с необходимостью определения прав, ответственности и коммуникации внутри проекта, так и определения отношений с материнской организацией. Важность этого момента определяется тем, что каждый участник проекта, с одной стороны, принадлежит к линии, но, с другой стороны, временно работает в проекте, причем, возможно, с другими компетенциями. Организационная структура проекта регулирует взаимодействие руководителя проекта, команды проекта и других групп, участвующих в проекте (кто есть кто?).
Наконец, в-четвертых, организация процесса/хода проекта устанавливает фазы, формальные правила и методы работы (как делать будем?).
Под внутренним управлением проектом понимают ситуацию, когда проектная команда работает целиком в пределах существующей организационной структуры, а под внешним – ситуацию, когда нанимается внешний руководитель проекта, работающий как внешний агент по поручению клиента
Оба подхода имеют свои достоинства и недостатки.
Достоинства внутреннего управления проектами:
Недостатки внутреннего управления проектами:
Достоинства внешнего управления проектами:
Недостатки внешнего управления проектами:
Проекты в организациях чаще всего выполняются наряду с обычной рутинной работой. В принципе проекты могли бы выполняться и в линии
Структурная организация проекта регулирует взаимодействие руководителя проекта, команды проекта и других групп, участвующих в проекте, а организация процесса/хода проекта устанавливает фазы, формальные правила и методы работы.
Причина провала многих проектов кроется не в низкой профессиональной компетентности участвующих в них работников, а в организационной неразберихе.
Организационные структуры предприятия дают возможность его руководству реализовать цели предприятия и регулировать взаимодействие различных подразделений. По своему существу организация направлена на обеспечение надежности и постоянства. Надежность обеспечивается тем, что одинаковые процессы реализуются одинаковым образом, и выполнение повторяющихся работ происходит эффективно и с предсказуемым результатом. В этом смысле организации стремятся к консерватизму. Это зачастую полезно, например, когда однозначно определено, кто, за что и с какой компетенцией отвечает.
По другую сторону стоит скорость технического прогресса, как в смысле продуктов, так и в смысле технологий, изменение требований потребителей, открытие новых рынков с дополнительными шансами и рисками и т.д. Они требуют от предприятия большего и более тесного взаимодействия различных подразделений, что не всегда в достаточной степени обеспечивается существующими организационными структурами.
Проектный менеджмент дает предприятию шанс найти оптимальные решения при особых обстоятельствах. При этом не следует пренебрегать или подвергать опасности созданное ранее и существующее.
Функциональная структура организации
Функциональная структура предполагает использование существующей функциональной иерархической структуры организации.
Менеджер проекта осуществляет лишь общую координацию работ. В функциональной структуре (рис. 3.1) проекты ведутся, как правило, в пределах функционального подразделения. При необходимости привлечения специалистов других подразделений координация осуществляется на уровне руководителей.
Преимущества структуры:
Недостатки структуры:
Вывод: недостатки перевешивают преимущества с точки зрения проектной работы, управлять проектом в функциональной структуре очень сложно.
Чисто проектная организация
Проектная структура организации
В случае чисто проектной организации проекты непосредственно управляются руководством организации. При этом проекты и функциональные подразделения стоят на одном иерархическом уровне, а статус руководителя проекта примерно соответствует статусу руководителя функционального подразделения. На время выполнения проекта исполнители делегируются из своих структурных подразделений в проектную группу или принимаются для работы над проектом со стороны. После завершения проекта они возвращаются в свои подразделения, если, конечно, не задействуются для выполнения новых задач или проектов. Руководитель проекта является одновременно руководителем проектного подразделения и имеет все полномочия, как в отношении предметной части проекта, так и в отношении подчиненных ему исполнителей проекта. В советское время, когда проекты выполнялись преимущественно специализированными проектными организациями, эта модель была преобладающей.
Чисто проектные структуры обычно используются для проектов, которые трудно точно спланировать и в которых требуемые резервы не могут быть установлены заранее. Типичным примером являются проекты НИОКР. Чисто проектные структуры могут существовать и как отдельные организации, когда выполняются относительно большие одноразовые проекты. Такой проект обычно имеет большую длительность, порой ряд лет.
В простейшей форме чисто проектная модель включает некоторый пул человеческих ресурсов, который управляется организацией в целом. Конкретный руководитель проекта может «нырнуть» в этот пул и подобрать команду проекта. В больших проектных организациях может существовать также пул руководителей проектов.
Эта организационная форма имеет важные преимущества: система гибка и легко реагирует на изменения, руководитель проекта имеет полную власть над проектом, а члены команды подчиняются непосредственно и только ему. Формальные и неформальные линии коммуникации обычно короче и понятней. Непосредственный доступ руководителя проекта к руководству предприятия позволяет не только быстро решать все возникающие проблемы, но и одновременно подчеркивает важность проекта в структуре организации. Принятие решений относительно проекта оказывается непосредственно в сфере влияния руководства предприятия, что обеспечивает быструю реакцию на отклонения в ходе проекта в виде однозначных прямых указаний. Относительно легко в проект интегрируются внешние консультанты и эксперты.
Особенно эффективна данная модель, когда в организации параллельно выполняется ряд проектов. Это позволяет создавать и накапливать специфические знания и навыки, которые могут обеспечивать организации существенные конкурентные преимущества.
В чисто проектных системах проектная команда может сильно идентифицироваться с проектом и развивать высокую степень мотивации и чувства сопричастности. Руководителю и команде проекта относительно легко воспринимать проект в целом. Меньше вероятности, что они сосредоточатся только на отдельныхсубсистемах и потеряют глобальную цель.
К недостаткам этой организационной формы относят опасность превращения проекта в постоянную структуру, связанную с потребностью работников проекта в стабильности, а также тенденции формализации и бюрократизации. Кроме того, могут также возникнуть проблемы с возвращением исполнителей проекта в свои старые линейные подразделения, так как туда за время проекта могли быть приняты другие работники или внедрены новые технологии и методы работы.
Команда проекта в данной структуре может стать весьма компетентным коллективом, однако, с другой стороны длительный отрыв от соответствующего функционального подразделения может привести и к отставанию от современного развития в своей профессиональной области. Именно функциональные подразделения наилучшим образом приспособлены к получению и восприятию актуальной информации.
Еще одним важным недостатком чисто проектной организационной формы является возможная неравномерная загрузка ресурсов, поскольку проект имеет полную постоянную команду. Это приводит к повышенным издержкам на персонал. Кроме того, проектные менеджеры (по определению) имеют тенденцию заглядывать вперед. Поэтому они стремятся своевременно обеспечить себя ключевыми ресурсами с запасом, чтобы быть уверенными в их наличии, как только они понадобятся. Это также может вести к увеличенным издержкам. Иногда может возникать конкуренция между различными проектными командами.
3.1.2.2. Менеджмент влияния
В случае менеджмента влияния, который называют иногда также координацией проектов, проекты подчиняют не напрямую руководству предприятия, а создают специальное штабное подразделение (координационный отдел). Руководитель проекта не получает дисциплинарных прав в отношении исполнителей проекта, которые по-прежнему подчиняются руководителям своих структурных подразделений. В руках последних к тому же обычно остаются и другие производственные факторы. Что касается полномочий координационного отдела в отношении различных проектов, то они подлежат определению в каждом конкретном случае. Важнейшими достоинствами менеджмента влияния считают:
Эта организационная форма имеет и существенные недостатки:
В связи с легкостью внедрения описанной формы организации проектов, не требующей особых изменений в работе предприятия, она получила достаточно широкое распространение. Примером может служить Комплексная программа развития Томского политехнического университета (КПР ТПУ), в рамках которой ежегодно выполняется более сотни проектов университетского уровня. Действительно, для малых проектов такая форма может оказаться оптимальной. Для больших и сложных проектов со значительными рисками и большим числом участников эта модель мало пригодна.
3.1.2.3. Линейная проектная организация
Проекты могут также интегрироваться в линейную структуру организации. Такой подход чаще всего используется для проектов развития, информационных и маркетинговых. В этом случае они обычно подчиняются руководителю линейного подразделения. К примеру, так управляются проекты КПР ТПУ факультетского уровня.
Важнейшими достоинствами такой проектной организации являются:
В качестве недостатков можно указать следующие:
В связи с указанными недостатками эта организационная форма мало пригодна для проектов, затрагивающих интересы разных функциональных подразделений, но для проектов, выполняющихся в интересах одного функционального подразделения, ее вполне можно рекомендовать. В качестве примера здесь можно привести проекты НИОКР, выполняемые по хозяйственным договорам вузами.
3.1.2.4. Матричная проектная организация
Для больших и сложных проектов, в выполнении которых участвует ряд функциональных подразделений, оптимальной может оказаться матричная проектная организация (рис. 3.7).
При этой организационной форме вертикальная схема управления сочетается с горизонтальной таким образом, что каждая организационная единица проекта, расположенная в узлах матрицы, подчиняется двум инстанциям – руководителю проекта и руководителю функционального подразделения. Матричная проектная организация имеет существенные достоинства, но и не менее существенные недостатки.
Достоинства матричной проектной организации:
Недостатки:
Следует отметить, что конфликты между руководителями могут иметь и положительную сторону. Если имеются два различных мнения, то оба руководителя вынуждены их обсуждать, и в результате может быть найдено новое, и при этом лучшее решение. Как вариант может быть реализовано также разделение полномочий, когда руководители функциональных подразделений имеют дисциплинарные полномочия, а руководители проектов – полномочия в отношении содержания работы. Для минимизации споров и взаимных обвинений определяющим является четкое разделение компетенций. Пример упрощенной схемы разграничения компетенций представлен на рис. 3.8.
Формулирование цели и следующих из нее задач, а также установление сроков сосредотачиваются в руках руководителя проекта. В отношении этих позиций, а также в отношении соблюдения пределов издержек он имеет распорядительное право во всех функциональных подразделениях. Однако и в этой схеме возникновение конфликтов не исключено, если определяемые руководителем подразделения методы работы приводят к нарушению целевых, временных или стоимостных рамок проекта.
Матричная организация проекта особенно целесообразна, когда проекты выполняются с определенной регулярностью и параллельно друг другу.
Планирование проекта представляет собой «мысленное предвосхищение будущих действий и всегда предполагает систематический подход в виде ряда последовательных логических взаимообусловленных шагов» 17. Проекты необходимо тщательно планировать, чтобы вопреки множеству воздействующих факторов достичь желаемого успеха проекта. Планирование проекта устанавливает ход его выполнения.
Структурный план проекта (WBS – WorkBreakdownStructure) представляет собой стройную иерархическую декомпозицию проекта на составные части (элементы, модули), необходимые и достаточные для планирования и контроля осуществления проекта для различных участников проекта [9].
Как следует из этого определения, структурный план проекта (СПП) представляет собой основной стержень для всех частей проекта и всех его участников. Иногда его называют также «планом планов» [58]. СПП используется в основном для реализации следующих целей:
Деление проекта на составные части необходимо, чтобы каждая составная часть могла отдельно планироваться, управляться и контролироваться (рис. 4.2).
Последняя, далее не декомпозируемая в структурном плане проекта задача (т.е. находящаяся на последнем уровне декомпозиции), носит название рабочего пакета или просто работы. Она должна быть точно определимой, контролируемой и четко ограниченной, а также относящейся к совершенно определенным ответственным за нее подразделениям или лицам. Этим определяется требуемое число уровней иерархии. Для небольших проектов может быть достаточно трех уровней, в то время как для больших и сложных проектов нередко требуется шесть и даже семь уровней. Работы с высокой степенью риска приходится порой разбивать до мельчайших деталей, чтобы спланировать меры по их уменьшению.
Желательно, чтобы по времени выполнения рабочие пакеты были по возможности относительно короткими. Это уменьшает потребность оценки степени выполнения по ходу работ. Установление состояния проекта становится возможным на базе законченных рабочих пакетов.
Необходимо с самого начала выбрать подходящую цифровую систему кодирования работ. Коды работ могут быть использованы в течение всего проекта как уникальные индикаторы для самых разных целей: для определения ответственных за них лиц, отнесения издержек, отслеживания хода работ, отчетности. Весьма желательно, чтобы система кодирования была совместима с используемой системой управленческого учета, что существенно упрощает контроль издержек проекта. Большинство современных программных средств автоматически генерируют коды работ в процессе составления СПП. При этом они оказываются одинаковыми при планировании и контроле времени и издержек.
Базой планирования является проектное/техническое задание (ТЗ). Особенно важно составление технического задания по инвестиционным проектам.
Прежде чем приступить к декомпозиции и детальному планированию, составитель плана должен ознакомиться с имеющейся информацией, из которой важнейшей является формулировка цели и ее описание. Желательно, чтобы она была представлена в форме технических требований (ТТ) и всегда в виде письменного документа.
Следующая существенная для планирования информация касается различных ограничений, например информация по вопросам получения разрешений от различных инстанций. При этом следует уяснить, какие виды деятельности могут быть начаты только после получения таких раз-решений.
Структурирование проекта может осуществляться по различным принципам:
Схема деления структурного плана проекта должна по возможности соответствовать естественному делению рассматриваемой системы.
Предметная структуризация (рис. 4.3) не предоставляет достаточно информации для формирования рабочих пакетов.
Для формирования рабочих пакетов лучше подходит структурирование по видам деятельности или по функциям (рис. 4.4).
Для малых, легко обзорных проектов зачастую достаточно структурировать СПП по видам деятельности, но многим проектам требуется большая детализация. Для них часто используется комбинированное структурирование СПП (рис. 4.5).
Не существует единого, пригодного на все случаи жизни структурного плана, и, соответственно, нет и патентованных рецептов, каким образом выбрать оптимальный структурный план для конкретного проекта. Он зависит от вида проекта, установившихся традиций на предприятии и его организационных структур, а также от руководителя и команды проекта.
В конечном счете СПП должен быть составлен так, чтобы:
− весь проект мог быть описан как сумма всех элементов;
− могло быть выполнено детальное планирование проекта;
− могли быть определены издержки и бюджет проекта;
− могли отслеживаться время, издержки и выполнение предметной области (работы);
− цели могли быть логическим образом увязаны с ресурсами компании;
− могли быть установлены процедуры контроля хода выполнения проекта;
− могла быть установлена ответственность за каждый элемент проекта.
Структурный план проекта содержит базовую информацию для всех дальнейших частных планов – организационного, временного, материального снабжения, ресурсного, плана издержек, финансового.
К сожалению, универсального алгоритма, который позволял бы абсолютно надежно идентифицировать все составные части проекта, до сих пор создать не удалось. На первом этапе целесообразно составить укрупненный структурный план проекта, ограничившись первой ступенью иерархии работ. Для дальнейшей декомпозиции структурного плана командой проекта могут быть применены обычные инструменты: мозговой штурм, картографирование мыслей и др. Большую помощь могут оказать также различного рода вопросники. Даже весьма тщательное выполнение этой работы не может исключить риск пропуска существенных элементов проекта (порой с тяжелыми последствиями), однако сводит его к минимуму. В результате должен быть составлен по возможности полный список работ проекта.
Уровень детализации структурного плана должен быть таким, чтобы для каждого конечного рабочего пакета мог быть определен конкретный исполнитель (или организация), для которого дальнейшая детализация не требуется. При этом следует убедиться, что каждый исполнитель знает состав своего пакета и действительно достаточно компетентен для его качественного выполнения. К примеру, ответственный за пакет «Регистрация участников конференции» должен принять решения о том, когда, где и как будет проводиться регистрация, кто будет ее вести, обеспечить место регистрации мебелью, беджами, анкетами, раздаточными материалами, указателями «Регистрация участников конференции», передать итоги регистрации в президиум, организовать запись на экскурсии, а материалы передать для архивирования. Если имеются малейшие сомнения в том, что ответственный знает досконально весь объем работы по пакету и способен оценить затраты времени и ресурсов, может потребоваться введение следующего уровня иерархии СПП.
Объем действий или операций, объединяемых понятием «работа», обычно соразмеряют со связанным с ним риском (как в отношении времени, так и в отношении затрат). Так как риск большой работы трудно оценить и еще труднее с ним управляться, каждому руководителю про-екта следует стремиться к тому, чтобы раздробить работы до определенного уровня. Этот уровень определяется достижением обзорности работ. В результате риск оказывается достаточно хорошо просчитываемым. Далее лица, ответственные за работы, должны позаботиться об этих рисках с помощью соответствующих предупредительных мер. В отдельных случаях для пакетов, сопровождаемых большим риском, может быть целесообразна их дальнейшая детализация с позиций менеджмента рисков.
Планирование процесса выполнения проекта (ProjectLogicEvaluation – PLE) осложняется тем обстоятельством, что многие работы связаны с выполнением других работ. Процессный план содержит информацию о том, какие работы связаны между собой и как их следует располагать во времени с учетом этих зависимостей, и. может быть представлен в виде графа (рис. 4.6) или таблицы (табл. 4.2).
Зависимости между отдельными работами могут быть вызваны разнообразными причинами, например:
Определить все взаимосвязи в объемных и сложных проектах возможно только при систематическом подходе к их определению. На практике используются два основных метода. Наиболее употребительным является способ, в котором начинают с конца проекта и идут шаг за шагом к его на-чалу. Для каждой определенной работы определяют все предшествующие действия (работы), которые должны быть завершены, чтобы можно было приступить к выполнению данной работы. Другой, менее употребительный способ заключается в том, что начинают с первой от старта проекта работы и определяют все последующие работы, к которым можно приступать.
Разработка плана процесса выполнения проекта осложняется еще и тем, что часто последовательность выполнения некоторых работ можно изменять. С одной стороны, это усложняет планирование, но, с другой стороны, за счет перестановки работ можно достичь оптимизации процесса выполнения проекта как с точки зрения времени, так и с точки зрения эффективного использования человеческих и материальных ресурсов.
Далее следует иметь в виду, что даже если ряд работ может выполняться параллельно, в реальности может существовать (и, как правило, всегда существует) ограничение по ресурсам. Это может привести к изменению исходной логической последовательности работ. Так в примере, приведенном на рис. 4.6, три работы после старта могут выполняться одновременно (у них нет предшественников). Однако если чай готовит один человек, у него просто не хватит рук (ограничение по ресурсам). Поэтому две работы он будет выполнять в период кипячения воды. Более подробно вопрос планирования с учетом ограниченности ресурсов рассмотрен в разделе 4.3.
Для небольших и простых проектов процессный план может быть составлен без привлечения программных продуктов. Но даже для относительно несложных проектов полезно применить достаточно простые программные продукты, например программу MS Project. Для больших и сложных проектов может потребоваться использование более мощных программных пакетов. Удобно вначале составить укрупненный процессный план проекта, а затем постепенно разворачивать каждый блок.
Рис.4.7. Продуктовая разбивка ИСР (иерархическое содержание работ)
Замечание. Для относительно простых проектов применяется упрощенная схема создания плана проекта. Она называется Создание иерархической структуры работ (ИСР).
Создание иерархической структуры работ — это декомпозиция целей проекта на более мелкие и более управляемые компоненты ИСР — согласованная с результатами проекта иерархическая декомпозиция работ, которыекоманда проекта должна выполнить для достижения целей и создания результатов проекта.
Декомпозиция — это разбиение основных целей и результатов на более мелкие и управляемые с целью:
Этапы декомпозиции:
1) определение основных целей проекта;
2) декомпозиция основных целей;
3) разбиение каждой цели на фундаментальные компоненты.
Обычно применяют следующие виды ИСР:
Рис.4.8. Функциональная разбивка ИСР
продуктовую, когда проект разбивается по элементам продукта проекта (рис. 4.7);
Рис.4.9 Разбивка ИСР по этапам жизненного цикла
Могут быть и другие, в том числе смешанные типы. Основное требование при декомпозиции — на одном уровне иерархии не должно быть смешения принципов декомпозиции (то есть, нельзя смешивать классификацию яблок по принципам цвета, сорта и размера на одном уровне).
На каждый блок ИСР должен быть назначен ответственный сотрудник, что позволит закрепить ответственность за конкретными членами команды.
На практике ИСР формируется обычно в информационной системе управления проектами.
Германский промышленный стандарт DIN 69 900 определяет сетевое планирование как все приемы для анализа, описания, планирования, управления процессами на основе теории графов, при которых могут быть учтены время, издержки, ресурсы и другие влияющие параметры.
Сетевой план может рассматриваться как наиболее точный плановый инструмент, особенно полезный при больших и сложных проектах.
Основные достоинства сетевого плана:
1. Составление сетевого плана вынуждает всех участников проекта внимательно продумать его ход, заблаговременно провести необходимые согласования и принять соответствующие решения. Это играет большую роль особенно в тех случаях, когда в выполнении проекта участвуют раз-личные фирмы или разные подразделения одной фирмы.
2. За счет графического представления работ сетевой план дает прекрасный обзор проекта и позволяет наглядно фиксировать его плановое течение.
3. Вышеназванные достоинства облегчают контроль полноты планирования.
Каждый сетевой план представляет собой графическое изображение хода проекта, содержащее определенное число узлов и линий, их связывающих. При построении сетевого плана используются три основных понятия: «работа» (включая ожидание и зависимости), «событие» и «путь».
Под работой понимается трудовой процесс, требующий затрат времени и ресурсов. В понятие «работа» включается также и процесс ожидания, который не требует затрат труда и ресурсов, но требует времени.
Под событием понимается результат выполнения всех работ, входящих в данное событие, позволяющий начинать последующие работы.
Под путем понимается непрерывная последовательность работ, начиная от исходного события и кончая завершающим.
С 1956 года разработано множество вариантов сетевого планирования, которые обычно объединяют в три группы: метод критического пути, метод PERT и метод Метра-потенциал.
4.3.1.1. Метод критического пути
Метод был разработан в США и получил название метода критического пути CriticalPathMethod (CPM). В этом методе работы изображаются в виде стрелки, а зависимости между ними в виде узлов. На стрелке обычно отображается название работы, а под стрелкой соответствующее время ее выполнения. Первый узел называют начальным событием, второй – конечным событием. Узлам присваиваются порядковые номера (рис. 4.7).
Узел 1, к которому не подходят стрелки, называют стартовым узлом или стартовым событием. Если от узла 4 не отходит никакой стрелки, то его называют целевым событием. Эти два узла ограничивают старт и конец проекта. Работа D может начаться только после завершения как работы А, так и работы С. Это символизируется узлом 3, условием для которого является завершение работ А и С. Таким образом, представляемые в узле зависимости могут восприниматься как состояния, которые должны быть достигнуты, чтобы могла быть начата последующая работа.
Для этих событий могут быть указаны и соответствующие временные рамки, для чего предусмотрены две клетки. Первое число показывает самый ранний срок, когда событие может наступить (раннее окончание РК), второе – самый поздний допустимый срок, к которому событие должно обязательно наступить (позднее окончание ПК). Стартовое событие имеет раннее окончание РК = 0.
При составлении сетевого плана сначала последовательно определяют раннее окончание каждого события. При известной продолжительности работ проекта и заданной дате его старта последовательным расчетом может быть определено время его завершения. Такой подход называют прогрессивным планированием времени.
Поздние окончания событий определяются обратным счетом.
При заданной дате завершения проекта обратным расчетом может быть определена самая поздняя дата, когда необходимо приступить к выполнению проекта. Этот подход носит название регрессивного планирования времени. Если расчет показывает, что в заданные сроки выполнения проекта уложиться не удается, необходимо либо согласовать с заказчиком перенос срока завершения проекта, либо должны быть найдены альтернативные решения, которые позволили бы выполнить работу за более короткие сроки.
Если две работы идут параллельно, т.е. начинаются и заканчиваются одинаковыми событиями, для однозначного их представления вводится так называемая фиктивная работа (работа S на рис. 4.8).
Фиктивные работы имеют всегда нулевую продолжительность. Их вводят для наглядности представления работ и в том случае, когда многие работы кончаются (или начинаются) одним событием, даже если не все начинаемые работы требуют завершения всех предшествующих работ. В примере на рис. 4.9 введение фиктивной работы S позволяет продемонстрировать, что условием начала работы В является завершение работ А и С, а условием начала работы D является только завершение работы С.
На рис.4.10 в первой колонке представлены типичные ошибки при составлении сетевых планов, а во второй – правильные решения.
Следует помнить, что при подсчете времени, соответственно и в сетевом плане, должны быть учтены и времена ожидания, например для сушки, отверждения бетона и т.п. Для этого в сетевой план должны быть введены работы с соответствующей продолжительностью.
4.3.1.2 Метод Метра-потенциал
В разработанном во Франции Metra-Potenzial-Methode (МРМ) работы отображаются узлами, а их взаимосвязи – стрелками. Узел при этом содержит всю информацию, касающуюся работы (рис. 4.11), а стрелки показывают только зависимости, т.е. предшествующие и последующие работы.
В прямоугольнике, отображающем работу, помещается ее порядковый номер, название и продолжительность. Кроме этого могут быть помещены короткие тексты, например с указанием исполнителей работ. Далее наряду с продолжительностью работ указываются и свободные резервы времени, а также ранние и поздние времена начала и окончания работ.
4.3.1.3. Метод PERT
Другим вариантом сетевого плана является разработанный в начале 1960-х годов в Управлении Военно-Морских Сил США метод PERT – ProgrammeEvaluationandReviewTechnique. Он был успешно использован в рамках управления проектом создания баллистических ракет. В этом проекте был целый ряд работ, требовавших научных исследований и разработок, длительность которых невозможно было оценить с приемлемой точностью. Метод PERT реализует вероятностный подход к определению продолжительности работ с использованием среднего значения β-распределения:
где α, β > 0 – произвольные фиксированные параметры, и
По каждому рабочему пакету даются три оценки времени его выполнения: оптимистичное (a), наиболее вероятное (m) и пессимистичное (b), а среднее значениеТ и стандартное отклонение s вычисляются по формулам
Обратим внимание на то, что β-распределение придает наибольший вес наиболее вероятному значению.
Далее сетевой план рассчитывается так же, как в методе СРМ.
Ожидаемое время выполнения проекта в целом будет равно сумме средних значений времени выполнения работ, находящихся на критическом пути. Стандартное отклонение времени выполнения проекта можно определить как корень квадратный из суммы квадратов стандартных отклонений всех работ, лежащих на критическом пути.
Если продолжительность работ задана (например, заказчиком), то следует оценить вероятность уложиться в этот срок. Очевидно, что рассчитанное среднее время выполнения проекта будет достигнуто в 50 % случаев. Для расчета вероятности соблюдения установленного срока нужно вычислить разницу между этим сроком и рассчитанным средним значением. Разделив эту величину на стандартное отклонение, можем по статистическим таблицам определить искомую вероятность того, что проект будет завершен в требуемый срок.
Особенностью метода PERT является также то, что отображаются не сами работы, а наступление определенных событий в ходе проекта.
Эти события представляются узлами, а стрелками обозначаются взаимосвязи между ними (рис. 4.12).
По сравнению с двумя предыдущими такой сетевой план содержит меньше детальной информации и не приспособлен для того, чтобы непосредственно из него получать рабочие указания для отдельных процессов. Его применение целесообразно в тех случаях, когда либо еще не существует достаточной информации, либо желательно концентрированное представление плана для обеспечения лучшей обзорности. Например, если план используется для того, чтобы информировать другие подразделения предприятия о степени реализации проекта или о его текущем состоянии, то может иметь смысл пренебречь деталями и сосредоточиться на существенных событиях. Такие существенные события называют вехами.
Элементы трех рассмотренных вариантов сетевого плана обычно комбинируют между собой. Так, к примеру, в Метра-потенциал методе могут дополнительно вводиться существенные вехи, которые, в отличие от работ, изображаются кружками. Тогда эти вехи маркируют определенные события, при которых проводится контроль состояния проекта или отчитываются перед руководством предприятия или перед заказчиком.
Наряду с тремя рассмотренными сетевыми планами CPM, MPM и PERT в мире получили распространение также следующие их варианты и комбинации:
LESS – Least Cost Estimating and Scheduling;
CPS – Critical Path Scheduling;
CPPS – Critical Path Planning and Scheduling;
RAMPS – Resource Allocation and Multi-Project Scheduling;
PCS – Project Control System.
Для изучения методов сетевого планирования можно рекомендовать книгу «Модульная программа для менеджеров» [5], а также книгу H. Groh и R. Gutch [59], которая весьма логично построена и пригодна для самостоятельного детального изучения техники сетевого планирования.
4.3.1.4. Сетевые матрицы
Эффективным инструментом в управлении проектом являются так называемые сетевые матрицы, которые представляют собой более высокий уровень научной разработки традиционных сетевых графиков. Сетевая матрица является графическим изображением процесса выполнения проекта, где все работы (управленческие и производственные) показаны в определенной технологической последовательности и необходимой взаимосвязи и зависимости. Сетевая матрица совмещается с календарно-масштабной сеткой времени. Строки матрицы указывают ступень управления, структурное подразделение или должностное лицо, выполняющее ту или иную работу; столбцы – этап и отдельные операции процесса управления проектом, протекающие во времени. Для примера на рис. 4.13 показан фрагмент сетевой матрицы разделения административных задач управления.
На графике работа изображена в виде сплошной стрелки. В понятие «работа» включается также и процесс ожидания, который не требует затрат труда и ресурсов, но требует времени. В отличие от настоящей работы он изображен пунктирной стрелкой с обозначением над ней продолжительности ожидания. Зависимость между двумя или несколькими событиями, которая не требует затрат времени и ресурсов, а только указывает на наличие связи между работами, т.е. то обстоятельство, что начало определенной работы (или работ) зависит от выполнения других работ, изображается пунктирной стрелкой без обозначения времени. Событие изображено в виде кружка. Путь, имеющий наибольшую продолжительность, как уже указывалось выше, носит название критического и в матрице обозначается утолщенной или сдвоенной стрелкой.
Если используется табличная форма плана, что для небольших проектов вполне возможно, то табл. 4.2 развертывается до табл. 4.2а, в которой главным элементом является длительность каждой работы.
Прежде чем приступить к оценке длительности работ, выбирают некоторую практичную для данного проекта единицу времени (дни, часы, недели и т.д.).
Для многих видов работ объем и длительность могут быть определены с помощью справочников и баз данных. Но для новых видов работ, а также работ, выполняемых в иных условиях, единственным способом определения их объема и сроков выполнения являются экспертные оценки. Используемые при этом подходы, требования к экспертам, оценка согласованности мнений экспертов изложены в литературе, например, [39, 60].
Надежность оценки времени чрезвычайно важна для его дальнейшего планирования. Поэтому относиться к этому надо серьезно, а при необходимости для страховки привлекать к оценке экспертов или тех лиц, которые впоследствии будут отвечать за соблюдение этих сроков. По поводу способов определения оптимистичных, пессимистичных или средних сроков существуют различные мнения. Это зависит прежде всего от конкретного проекта.
Необходимо понимать, что оценки времени и стоимости выполнения работ во всех случаях являются именно оценками, а не точными величинами. Нередко попытки их уточнить наталкиваются на то, что уточнение информации требует много времени и стоит дорого. Поэтому графики проектов неизбежно содержат работы, основанные на некорректных данных. К сожалению, многие менеджеры, признавая это на словах, с трудом воспринимают динамичность проектных работ.
В качестве следующего шага для каждой работы определяется время ее раннего начала (РН) и время раннего окончания (РК). Это выполняется прямым счетом, начиная с момента старта проекта. Если ряд работ могут стартовать одновременно без предшествующих работ, то начинают с одной из этих работ (табл. 4.3). Работы, которые требуют завершения одной или более предшествующих работ, могут стартовать не ранее завершения самой поздней из них.
После определения ранних времен начала и окончания каждой работы, нужно рассчитать самые поздние моменты, когда работа должна быть начата или закончена (табл. 4.3). Определение этих времен – позднего начала (ПН) и позднего окончания (ПК) – производится обратным счетом либо от определенного прямым счетом времени раннего окончания проекта, либо от заданного договором допустимого предельного срока окончания работ.
Поздний момент окончания работы (ПК) является одновременно поздним сроком начала последующей работы. Иными словами, работа должна закончиться не позднее, чем должна начаться последующая за ней работа, а при многих последующих работах – не позднее, чем должна начаться самая ранняя из них.
Сопоставляя сроки раннего начала и раннего окончания работ со сроками позднего начала и позднего окончания работ, можно определить очень важные для последующего маневра времена резерва работ. При этом различают общий резерв работы (ОР) и свободный резерв работы (СР). Их определение также происходит в два приема. Общий резерв времени работы определяется как
ОР = ПН – РН = ПК – РК,
т.е. общий резерв представляет собой разность между сроком, не позднее которого работа должна быть закончена, и ранним возможным сроком ее окончания.
У ряда работ свободный резерв времени равен нулю. Если продолжительность работ оценена правильно и взаимозависимости работ установлены правильно, то это означает, что любая задержка одновременно приведет к смещению последующей работы, а соответственно, и к смещению срока завершения проекта в целом. В силу такой важности работ с нулевым резервом времени их называют также критическими.
Наличие общего резерва времени работы еще не означает, что его можно свободно использовать именно для этой работы, иначе могут оказаться без всякого резерва некоторые последующие работы. Поэтому рассчитывается еще свободный резерв времени работы, который определяется как отрезок времени, на который может быть задержана работа, с условием, что последующая работа может быть все-таки начата в свое раннее начало.
Определение резервов времени дает в руки руководства проекта полезный инструмент. Свободные резервы времени предоставляют определенную свободу действий. Но даже если свободный резерв времени равен нулю, но общий резерв времени больше нуля, опоздание в этих пределах еще возможно наверстать, если руководству проекта удастся отказаться от свободного резерва времени последующей работы.
Работы, у которых свободный и общий резервы времени равны нулю, лежат на так называемом критическом пути. Любые задержки на этом пути приводят к задержке окончания всего проекта, если, конечно, руководству проекта на последующих этапах за счет особых мер не удастся сократить время выполнения работ. Это, как правило, возможно лишь за счет привлечения дополнительных ресурсов, а следовательно, приносит дополнительные издержки. Если ранний срок окончания проекта по расчету выходит за пределы договорных сроков, то следует искать возможности сокращения времени выполнения работ, и прежде всего тех, которые лежат на критическом пути.
Следующим шагом является привязка работ к календарю, где должны быть учтены выходные и праздничные дни, а порой и период отпусков.
Для более наглядного представления планирования времени используется диаграмма Ганта (рис. 4.14). Отдельные работы заносятся в строки, и в календарной части диаграммы отмечается их продолжительность, начиная со дня старта. Особое преимущество этой методики заключается в наглядности, поскольку в любой интересующий момент времени можно разобраться, какая работа должна быть уже начата или закончена. Если в последующем в диаграмме дополнительно отметить другим цветом фактические моменты начала и окончания работ, то можно наглядно увидеть соответствие (или несоответствие) фактического и планового хода работ. Кроме того, хорошо видно, какие работы одновременно выполняются.
Такая диаграмма быстро и легко понимается несведущими в планировании работниками и поэтому очень популярна. Каждый работник сам в состоянии составить такую диаграмму без обучения и особых указаний. Однако это обстоятельство иногда приводит к легковесному подходу в планировании работ. При быстром составлении диаграммы нередко про-пускают существенные детали, следствием чего является появление иллюзорных планов работ. Однако проведение работы требует привлечения ресурсов, тем самым создавая издержки. Нереалистичное планирование времени приводит к нереалистичному плану издержек.
Табличная форма сетевого планирования сегодня применяется только для небольших проектов преимущественно личного плана. Для сколько-нибудь серьезных проектов, как правило, используются программные продукты, из которых наиболее популярным является MS Project (см. раздел 8).
Практический опыт использования сетевого планирования, как справедливо подчеркивает E. Wischnewski [61], весьма противоречив. С одной стороны, считается общепринятым, что составление и ведение сетевых планов является альфой и омегой управления проектами. Неоспоримое преимущество сетевых планов заключается в наглядном представлении взаимозависимости работ. Кроме того, они включают в себя расчет времени, а также расчет критического пути. Это, безусловно, является ценным вспомогательным средством при планировании и управлении проектом.
С другой стороны, методика сетевого планирования предъявляет высокие требования к квалификации работников, составляющих сетевой план. В большинстве случаев сетевые планы составляются непосредственно исполнителями проекта. Причем эта работа выполняется сотрудниками, которые знают только основные положения сетевого планирования. Глубокого понимания техники сетевого планирования, как правило, у них нет.
Независимо от уровня познаний составителей затраты времени на составление сетевого плана всегда весьма значительны.
Сетевой план только тогда оказывается полезным, когда он составлен качественно. Поскольку разработка плана требует детальной информации обо всех работах, нужна большая подготовка к его составлению. После первого прохода, когда обычно рассчитанный срок окончания проекта выходит за рамки договорных сроков, возникает необходимость оптимизации сетевого плана. Зачастую расчетный срок окончания проекта так далеко выходит за рамки договорных сроков, что приходится усиленно изыскивать различные резервы. Практика многих реализованных проектов показала, что даже если и удавалось тщательно, до деталей, разработать сетевые планы, дальнейшее их отслеживание требовало колоссальных затрат времени. Если же для упрощения составляется только грубый сетевой план, то все это «упражнение» служит только тому, чтобы удовлетворить клиента, который хочет его видеть.
В связи с указанным обычно раз составленный сетевой план в ходе проекта больше (добровольно) не актуализируется. К примеру, когда НИИ высоких напряжений при ТПУ создавал имитатор ядерного взрыва «Репер Р/Т», сетевой график по настоянию представительства Министерства обороны был составлен. Времени на изучение техники сетевого планирования и на составление самого сетевого графика было потрачено много. Реально же для управления проектом он не использовался. Поэтому, хоть сетевой план и содержит очень важную для управления проектом информацию, его составление и поддержка далеко не всегда являются подходящими средствами для управления проектом. Определенный выход из этого тупика представляет использование современных программных средств, из которых наиболее распространенным является MicrosoftProject, который работает под оболочкой Windows и полностью совместим с MS-Office, а соответственно, может использовать MS-Exel, базы данных MS-Access и текстовый редактор Word.
4.4. Материальное и ресурсное планирование
Нормальный ход проекта обеспечивается только в том случае, если в его распоряжение предоставлены необходимые виды и соответствующего качества ресурсы, причем:
Планирование ресурсов происходит в три шага:
1) определение потребности в ресурсах: какие материальные и человеческие ресурсы требуются для выполнения проекта в соответствии с планом?
2) уточнение наличия ресурсов: какие ресурсы предоставлены в распоряжение проекта?
3) сравнение плановых и фактических ресурсов: какие имеются узкие места?
Планируемая потребность в ресурсах должна быть привязана к определенной работе/рабочему пакету. Поэтому сначала определяют потребность по каждому виду ресурса для каждой работы. Затем ее суммируют для проекта в целом с учетом времени возникновения потребности. Для наглядности потребность в ресурсах представляется в виде диаграмм по каждому виду ресурсов. Описание рабочих пакетов, составляемое на основании структурного плана проекта, дает возможность определить также, когда должны выполняться те или иные монтажные работы.
Полезно с самого начала планирования завести таблицу потребного оборудования, инструментов и программных продуктов. По мере детализации работ она будет уточняться и дополняться. Такая таблица позволяет команде проекта не только своевременно подготовить ресурсы, но и сделать более реальным план издержек проекта.
Далее определяются наличные ресурсы. При этом их надо группировать так же, как это было сделано при составлении плана потребности в ресурсах. Только следует иметь в виду, что располагаемые ресурсы, как правило, существенно меньше максимальных ресурсов предприятия. Так, например, для механизмов необходимо учитывать время на их обслуживание и ремонт, а для персонала отпуска, болезни, занятость на других работах и т.д.
Далее производится сопоставление плановой потребности в ресурсах с фактическим их наличием. Чаще всего выясняется, что в определенные периоды времени располагаемых ресурсов не хватает, а в другие периоды времени они оказываются не полностью загруженными.
Флуктуации потребностей в ресурсах в период выполнения проектов неизбежны и всегда имеют место в той или иной степени. Чем больше разность между максимумом и минимумом потребности, тем обычно ниже эффективность их использования. Большие флуктуации не сказываются существенно на эффективности, если имеется возможность оперативного обмена ими с другими одновременно выполняемыми проектами. В противном случае возникают простои, которые ведут к снижению оплаты труда и, соответственно, к демотивации персонала, а также ряду других издержек. Если коэффициент использования трудовых ресурсов в проекте, определяемый как отношение суммарной трудоемкости проекта к общему располагаемому числу человеко-часов, ниже некоторого приемлемого значения (например, 70 %), то обязательно должно проводиться выравнивание потребности в ресурсах. Такое выравнивание повышает коэффициент использования трудовых ресурсов, что обеспечивает ряд преимуществ:
Для решения проблемы неравномерной потребности в ресурсах используется несколько возможностей:
При планировании материалов нужно иметь в виду, что они должны быть не только доступны, но также и предоставлены в распоряжение работников в нужное время, нужного качества, в нужном количестве и в нужном месте.
К материалам относятся:
При часто повторяющихся работах потребность в материалах для отдельных работ зачастую указывается в виде норм расхода на единицу продукта с одновременным указанием стоимости. При планировании персонала требуется определенная дифференциация, в частности по уровню образования и квалификации. С точки зрения соответствия плановой потребности в человеческих ресурсах и фактического их наличия важным является вопрос о том, могут ли быть выделены в распоряжение проекта на определенное время дополнительные человеческие ресурсы и, соответственно, могут ли временно свободные исполнители проекта быть задействованы на других работах предприятия.
Зачастую проблема таким способом не решается. Тогда в рамках про-ектного менеджмента могут быть использованы возможности регулирования отдельных работ в пределах резервов времени. Может быть также рассмотрено введение скользящего графика рабочего времени. Логическая схема планирования материалов представлена на рис. 4.16.
При решении вопросов обеспечения проекта необходимым оборудованием и материалами обычно рассматривается целый ряд альтернатив: делать самим или покупать (make or buy), взять в лизинг или купить (lease or buy), купить или арендовать (buy or rent), взять в лизинг или арендовать (lease or rent).
Факторы, влияющие на выбор альтернативы «делать самим»:
Факторы, влияющие на выбор альтернативы «купить»:
Многообразие взаимосвязей в планировании наглядно представлено на рис. 4.17. Понятно, что по ходу выполнения проекта план должен постоянно корректироваться, чтобы своевременно реагировать на возникающие ограничения.
Определенные проблемы появляются в случае, когда специально для выполнения проекта необходимо приобретение дополнительных средств производства. К средствам производства относятся машины, установки, транспортные средства, оснащение зданий, сами здания, электронно-вычислительная техника и т.д., т.е. то, что необходимо для выполнения работ и что по окончании работ останется в прежнем, хотя и несколько изношенном виде. Обычно на проекты относится только часть стоимости средств производства в размере амортизационных отчислений. Однако если существующих средств производства для выполнения проекта недостаточно и требуется приобретение дополнительных, то необходимо сопоставить прибыль от реализации проекта со стоимостью приобретаемых средств. Если эта прибыль выше стоимости приобретаемых средств, такое приобретение имеет смысл. Если же реализация проекта позволит компенсировать лишь часть этих затрат, то следует выяснить, могут ли приобретенные средства быть эффективно применены на предприятии после завершения проекта или проданы. В последнем случае надо иметь в виду, что
даже новое оборудование обычно может быть продано по цене, заметно меньшей, чем цена первоначального приобретения.
Многообразие взаимосвязей в планировании наглядно представлено на рис. 4.17. Понятно, что по ходу выполнения проекта план должен постоянно корректироваться, чтобы своевременно реагировать на возникающие ограничения.
Определенные проблемы появляются в случае, когда специально для выполнения проекта необходимо приобретение дополнительных средств производства. К средствам производства относятся машины, установки, транспортные средства, оснащение зданий, сами здания, электронно-вычислительная техника и т.д., т.е. то, что необходимо для выполнения работ и что по окончании работ останется в прежнем, хотя и несколько изношенном виде. Обычно на проекты относится только часть стоимости средств производства в размере амортизационных отчислений. Однако если существующих средств производства для выполнения проекта недостаточно и требуется приобретение дополнительных, то необходимо сопоставить прибыль от реализации проекта со стоимостью приобретаемых средств. Если эта прибыль выше стоимости приобретаемых средств, такое приобретение имеет смысл. Если же реализация проекта позволит компенсировать лишь часть этих затрат, то следует выяснить, могут ли приобретенные средства быть эффективно применены на предприятии после завершения проекта или проданы. В последнем случае надо иметь в виду, что даже новое оборудование обычно может быть продано по цене, заметно меньшей, чем цена первоначального приобретения .
Оценка издержек является прогнозом затрат на конкретные работы. Как слово «оценка», так и слово «прогноз» отражают большую долю неопределенности.
Принимающий решение о выполнении нового проекта нуждается в надежных стоимостных оценках именно на ранней стадии проекта, т. к. приходится принимать решение не только о старте данного проекта, но и зачастую делать выбор между альтернативными вариантами. В 62 ав-торы так подчеркивают дилемму между ранним принятием решения и недостаточным уровнем информации: «Общая дилемма заключается в том, что в начале жизненного цикла проекта должны приниматься самые важные решения, а уровень информации в этот момент минимальный».
В последние годы все настойчивее ставится вопрос о последующих затратах, которые приходится нести тому, кто эксплуатирует вновь созданный продукт (установку, прибор, здание и др.). Это могут быть затраты на дополнительный персонал, топливо, обслуживание и ремонт и т.д.
С ростом сложности проектов эти последующие затраты обычно существенно возрастают, что наглядно демонстрирует десятилетняя статистика Управления снабжения бундесвера Германии. Суммарные расходы на разработку, приобретение и эксплуатацию военной продукции оказались в соотношении 1:3: 6. Аналогичные данные (по 1979 г.) приводятся также и по Министерству обороны США: 1:2,6:6. При этом проблема последующих затрат не ограничивается только областью военной техники, космонавтики или самолетостроения, но во все большей мере затрагивает также общественный сектор, как, например, транспортные средства 56.
Здесь нельзя умолчать также о том, что очень часто стоимость проектов неумышленно, а иногда и умышленно, сильно занижается. Умышленное занижение происходит по принципу: «Проект начнем, а недостающие деньги потом найдутся». Неумышленное занижение стоимости проектов происходит обычно из-за того, что не учитывается объем и сложность многих работ или упускаются некоторые факторы внешней среды проекта (например, экология или общественное мнение). В том и другом случае обычно возникают серьезные проблемы для проекта, которые не только осложняют его выполнение, но могут привести и к его прекращению. Кроме того, они серьезно вредят имиджу организаций, принимающих участие в таких проектах.
Конечно, при оценке стоимости работ можно ошибиться. По этой причине многие люди испытывают глубокое отвращение к оценкам и стараются их обойти, особенно когда речь идет об оценках, опирающихся, образно говоря, на «глиняные ноги». Дело в том, что по опыту многие знают: раз высказанная оценка потом в определенной степени их обязывает, даже если, давая оценку, они настойчиво обращали внимание на ее низкую обоснованность. Однако даже при самых благоприятных обстоятельствах оценка остается оценкой и не более того. Непредвиденные обстоятельства в ходе проекта и обусловленный инфляцией рост издержек, правда, тоже можно оценить, но именно оценить, а не точно предсказать. Некоторые же внешние обстоятельства, могущие оказать решающее влияние на стоимость проекта, как, например, забастовки, приостановка строительства из-за протестов населения, стихийные бедствия и др., практически вообще не могут быть предсказаны.
План издержек в рамках общего планирования проекта служит нижеприведенным целям и задачам:
1. Он необходим при калькуляции и определении цен в целях:
2. Он служит вспомогательным средством при планировании, по-зволяя оценить экономичность рабочих процессов при:
3. Он нужен для контроля экономичности при выполнении проекта путем:
Прямые издержки проекта имеют место, когда материальные ценности и услуги приобретаются непосредственно для проекта и, соответственно, могут быть непосредственно отнесены на издержки проекта.
Для определения прямых издержек используются разные источники информации:
- стандартные справочники;
- базы данных предприятия;
- материалы ранее выполненных проектов;
- знание и опыт сметчиков.
А. Roberts и W. Wallace [15] подчеркивают, что хорошие сметчики жизненно важны для успеха проекта. Они должны быть точными и последовательными, что обеспечивает уменьшение общих рисков проекта. Каждый сметчик индивидуален, и два сметчика, анализирующие одну и ту же работу, дают различающиеся оценки издержек. Руководитель проекта должен правильно классифицировать сметчиков и при необходимости вводить определенные поправки.
В книге [15] приводятся интересные характеристики различных сметчиков: точных, оптимистичных, пессимистичных и непоследовательных.
Оптимистичные сметчики опасны. В связи с тем, что они занижают издержки проекта, они зачастую выигрывают контракты, но за это потом приходится дорого расплачиваться. Пессимистичные сметчики лишь незначительно менее опасны (потеря контрактов, неэффективное использование ресурсов). Но, пожалуй, наиболее опасны непоследовательные сметчики, поскольку на их оценки, в отличие от первых двух типов, невозможно ввести поправки.
Косвенные издержки (накладные расходы) возникают, когда для проекта используются материальные ценности или услуги, которые одновременно служат и другим целям предприятия и которые необходимо поддерживать на работоспособном уровне либо сохранить их готовность. По этой группе отнесение издержек на проект не столь очевидно и однозначно.
При выполнении внутренних проектов в организации зачастую на них либо вообще не относят накладных расходов, либо относят только в той степени, в которой они возросли в связи с выполнением проекта (граничные издержки).
A. Roberts и W. Wallace [15] приводят несколько иную, но весьма наглядную классификацию издержек (рис. 4.18), которая отражает логику определения цены внешних проектов.
Определение прямых издержек осуществляется в две фазы: сначала определяют расход ресурсов в натуральных единицах, например человеко-часах, литрах, метрах, кВт-часах и т.д., а затем их стоимость (табл. 4.5).
Достоинством такого подхода является то, что минимальная единица проекта – работа (рабочий пакет) – является одновременно носителем информации о сроках, длительности, необходимых ресурсах и издержках. Это улучшает последующую их фиксацию и контроль во время выполнения проекта. При этом отдельные работы могут подвергаться оптимизации. Например, могут быть рассчитаны издержки при проведении проекта своими силами и сопоставлены со стоимостью заказа на стороне. Вполне может оказаться, что заказать на стороне выгоднее, например, если стороннее предприятие в связи со своей специализацией имеет более совершенную технологию и более опытный персонал. При расчете издержек это традиционный вопрос: «Сделать или купить?» (Make or by).
Даже в том случае, когда изготовление у себя является более экономичным вариантом, выяснение цены в случае покупки на стороне может оказаться весьма полезным впоследствии, если, например, накопилось опоздание в ходе проекта и собственных ресурсов предприятия недостаточно для его компенсации.
Если предприятие при неполной загрузке мощностей очень заинтересовано получить заказ клиента на проект, оно может при калькуляции работы установить возможный нижний уровень цены на основе граничных издержек. До тех пор, пока заказчик готов платить не менее этой цены, выполнение проекта для организации все же выгодней, чем отказ от него, даже если покрывается только часть накладных расходов. При этом улучшается экономическое состояние предприятия в целом.
Основные трудности с оценкой стоимости материалов и оборудования связаны с непредсказуемостью проектов (особенно проектов НИОКР) и трудностью определения потребных объемов на ранних стадиях. Конструкторские работы к этому времени еще не выполнены, и во всяком случае часть материалов и оборудования не может быть специфицирована достаточно точно.
С практической точки зрения полезно, чтобы люди, производящие оценку стоимости проекта, работали совместно с отделом снабжения предприятия. Отдел снабжения имеет информацию о широком круге поставщиков товаров и услуг и может уже иметь опыт приобретения того, что требуется для проекта. Кроме того, если отдел снабжения вовлечен в проект на стадии определения издержек, он будет более эффективно работать, когда начнется приобретение.
Расчет издержек с учетом временного плана проекта позволяет получить план издержек с разверткой по времени (рис. 4.19).
Обычно при планировании издержек мы имеем дело с предварительной калькуляцией, а не с окончательными надежными цифрами, а всякий прогноз, как известно, связан с риском. Риск может, к примеру, заключаться в том, что материальные ценности в будущем уже нельзя будет купить по запланированным ценам. При долгосрочных проектах, продолжающихся больше года, целесообразно предусмотреть возможное повышение заработной платы. Цены на покупные изделия и на услуги тоже подвержены колебаниям, в особенности если они связаны с курсами валют.
При оценке издержек в проектах по разработке и постановке на производство нового продукта используются различные подходы.
Наиболее известным и наиболее часто применяемым из них является рассмотренный выше метод оценки, при котором для каждой работы оцениваются потребные ресурсы в натуральном выражении, как, например, потребные инженеро-часы, машино-часы, количества материалов. Затем эти цифры умножаются на принятые на предприятии расценки и цены. Однако такой детальный метод оценки предполагает, что к этому моменту должно быть выполнено глубокое структурирование и планирование проекта, на основе которого могут быть определены все работы и задачи проекта. Но именно это является большой проблемой на начальных этапах проекта, когда еще нет, да и не может быть, детальных плановых документов. В связи с этим попытка провести детальную оценку издержек на основе неполных плановых документов наверняка приведет к мало реалистичным результатам. Кроме того, требующиеся для такой оценки относительно большие затраты усилий на этот момент не оправданы. Поэтому более рационально проводить укрупненную оценку издержек.
При единоличной оценке на практике применяются два способа. В одном случае руководитель проекта сам оценивает все работы, в другом он поручает оценку каждому ответственному за рабочий пакет. Первый способ, конечно, быстрее и проще.
Возникает вопрос: какие достоинства и недостатки имеют эти два способа с позиций точности оценки? Руководитель проекта, возможно, знает детали конкретной работы поверхностно, поэтому скорее даст заниженную оценку издержек, в особенности если на него «давит» ограниченная смета. Когда оценку производит конкретный ответственный за работу специалист, надо учесть разницу между новичком и «старым волком». Новичок скорее переоценит свои возможности и тем самым придет к заниженным издержкам. «Старый волк», наоборот, предусмотрит на всякий случай запас и скорее завысит издержки.
Результат оценки зависит также и от того, является человек оптимистом или пессимистом. Каждый человек имеет некоторый зачастую достаточно стабильный коэффициент ошибки, который опытному руководителю проекта следовало бы знать.
При многократной оценке руководитель проекта опрашивает ряд специалистов (по отдельности) и затем выводит среднее значение. Да-лее может проводиться также групповая оценка, где в результате общей дискуссии приходят к конечному результату. Здесь можно упомянуть и часто применяемый метод Дельфи.
Оценка издержек может производиться как сверху вниз (top-down), так и снизу вверх (bottom-up). В первом случае руководство организации на основе своего опыта, знаний и доступных данных о проекте устанавливает общий бюджет проекта и доводит эту сумму до руководителей следующего уровня. Они в свою очередь дальше дробят ее до уровня отдельных рабочих пакетов. Преимуществом такого подхода является то, что бюджет проекта совместим с общими стратегическими целями организации. Велика вероятность, что бюджет будет реален, т.к. исходит от высшего руководства. Недостатком подхода является то обстоятельство, что высшее руководство может плохо знать детали. Это проявится в нереалистичном
бюджете, что отрицательно скажется на мотивации команды проекта, которой он навязан. Нереалистичный бюджет большого проекта может дезорганизовать всю финансовую систему предприятия. Кроме того, у руководства нередко есть «любимчики», которые могут получить неоправданно большой бюджет.
Преимуществом оценки издержек проекта «снизу вверх» является то, что люди на «передовой» могут лучше знать, что необходимо и сколько это будет стоить. Кроме того, возрастает мотивация людей: самостоятельно установив свой бюджет, они более склонны его соблюдать.
Недостатки такого способа установления бюджета:
- бюджет имеет более низкий статус, чем установленный руководством;
- он может быть отвергнут руководством организации;
- требуется следить за тем, чтобы его не урезали;
- может оказаться трудным регулирование бюджета в соответствии со стратегическими изменениями;
- руководители иногда ревниво реагируют на потерю части власти;
- менеджеры нижнего уровня зачастую стараются на всякий случай завысить стоимость;
- весь бюджет проекта может оказаться определяемым процессом его выполнения, а не условиями рынка.
Компромиссным вариантом определения издержек и бюджета проекта является итеративный подход, основанный на переговорах. При этом исполнители и менеджеры нижнего и среднего уровня разрабатывают детальный план проекта и одновременно производят оценку стоимости работ, за которые они отвечают. Затем они представляют эти планы руководству организации. В процессе обсуждения и переговоров происходит уточнение объема и стоимости работ. В результате получается оценка стоимости проекта, лежащая где-то между консервативной оценкой высшего менеджмента, определяемой условиями рынка, и оценкой операционных менеджеров, определяемой процессом. Такой подход часто применяется для проектов, в основе которых лежит заказ.
Преимуществом итеративного подхода является то, что он объединяет практические (операционные) соображения операционных менеджеров со стратегическими соображениями высшего руководства. Тем самым обеспечивается его реальность и одновременно учитываются стратегические цели организации и условия рынка. К недостаткам подхода относится то, что процесс переговоров требует много времени, а соответственно, дорог. Способность успешно вести переговоры может оказаться более существенной, чем умение верно оценивать работы. Некоторые операционные менеджеры могут «выторговать» себе более выгодный бюджет, чем их менее «пробивные» коллеги.
Смета проекта может быть также заказана профессиональному сметчику. Он должен иметь специальную подготовку и соответствующий опыт. Достоинством является то, что сметчик может достаточно точно оценить отдельные работы, взаимозависимости, связанные с использованием множественных ресурсов, возможные риски и потребные для них резервы, а также он обычно представляет ограниченность оценок. Сметчик не подвержен влиянию команды проекта.
Основным недостатком профессионального сметчика является то, что он не привержен команде проекта и его обязанности ограничены только профессиональной компетенцией.
Наконец, оценка издержек может быть поручена непосредственно команде проекта. Достоинством здесь является то, что люди, производящие оценку, прямо ответственны и за реализацию работ. Команда проекта лучше всех знает потребности в ресурсах и их наличие. Она также хорошо представляет себе все ограничения системы. Основной недостаток команды проекта как оценщика издержек состоит в том, что часто у членов ко-манды нет достаточного профессионализма в сметных вопросах. В резуль-тате увеличивается риск ошибок и слишком оптимистичных оценок.
Выбор метода оценки издержек существенным образом зависит также от стадии выполнения проекта. В предпроектной стадии, когда информация о будущем составе работ минимальна, оценка уровня за-трат обычно делается специалистами на основе укрупненных показателей стоимости. К примеру, при разработке новых высоковольтных импульсных устройств порядок затрат на их разработку может быть оценен исходя из 1$/В или 1$/Дж. Ошибка при этом, как правило, не превышает 100 %. Для большинства проектов вполне приемлемой на этой стадии считается точность ± 25 %. Такая оценка обычно достаточна для принятия решения о принципиальной возможности выполнения проекта.
С момента разработки концепции проекта оценки должны производиться уже на основе параметрических методов. Основой для оценки в этом случае являются известная информация и опубликованные данные. Обычно достигается точность оценки ± 10–15 %. Такой уровень точности достаточен для стадии участия в тендере и для переговоров с заказчиком.
Методы детальной оценки могут быть использованы только в той фазе проекта, когда уже разработан структурный план проекта и составлены перечни работ и спецификации. Считается (по крайней мере, в США), что они должны обеспечивать точность ± 5 %, что с лихвой перекрывается резервами, предусматриваемыми большинством стандартных контрактов.
Тщательный анализ издержек завершенных проектов позволяет накопить информацию для надежной оценки стоимости будущих проектов. Дело в том, что новые и сложные проекты в значительной степени состоят из известных элементов, по крайней мере их аналогов. Поэтому для фирм и директивных организаций очень важно иметь базы данных выполненных проектов с детальной информацией об их составе и стои-мости.
При оптимизации проектов с точки зрения их экономического эффекта необходимо рассматривать две стороны вопроса:
Экономический эффект проекта, т.е. соотношение между входом и выходом, может быть повышен, если удастся заменить некоторые составляющие, дающие малый конечный результат на единицу издержек, на составляющие, дающие значительно больший результат на единицу издержек. Этот тезис требует пояснений. Дело в том, что обычно стараются снизить издержки проекта. Однако порой целесообразно их несколько повысить, если это дает существенное улучшение конечного результата. За радикальное улучшение тактико-технических характеристик изделия клиент нередко готов заплатить гораздо большую сумму.
Для всех крупных (с позиций организации, выполняющей работу) проектов необходимо их финансовое планирование.
Целями финансового планирования являются:
Основой для составления плана платежей обычно является план издержек. Однако необходимо учитывать, что только часть платежей совпадает по сумме и времени с издержками. К примеру, при приобретении ма-териалов и комплектующих изделий имеют место исходящие платежи, а издержки появляются со значительной задержкой во времени только после списания материалов на проект.
При внешних проектах характер соглашения о платежах имеет особое значение. Чем больше размер аванса и чем чаще осуществляется оплата за выполненные объемы работ, тем у исполнителя меньше проблем с сохранением ликвидности и меньше риск в случае прекращения проекта. К примеру, возможна ситуация, когда по проекту создается новое изделие по столь специальным требованиям заказчика, что оно не может быть использовано другими, или имеет для других только ограниченную ценность, или круг возможных клиентов весьма узок. В этом случае возникает риск, что при неплатежеспособности заказчика другое применение изделия либо совсем невозможно, либо сопряжено с большими убытками, даже если договором предусмотрено право собственности на изделие.
Составление бюджета проекта преследует цель обеспечить финансовую прозрачность различных его альтернатив. Утверждение бюджета знаменует завершение плановой фазы. С момента его утверждения он становится обязывающим документом для ответственных за проект лиц и основой для последующего контроля. Ответственной за проект организационной единице для выполнения поставленных задач бюджетом на определенный период выделяются определенные средства.
В заключение этого раздела нужно еще отметить, что необходимые сведения о финансировании, планировании и учете издержек в форме, хорошо понятной и для непрофессионалов, приводятся в книге профессора А. Шваба (A. Schwab), который по этому поводу пишет: «Базовые знания внешнего и внутреннего счетоводства, финансирования и расчета инвестиций во все большей мере относятся к само собой разумеющемуся спектру знаний современного инженера. В рамках своей оперативной деятельности или в качестве руководителя проекта он часто и инженер, и коммерсант в одном лице.
Даже если инженер сам не выступает в качестве коммерсанта, ему все же необходимо иметь столько финансового ноу-хау, чтобы он мог составлять сметы и без недоразумений и эффективно осуществлять коммуникацию со своими клиентами, со своими коллегами-коммерсантами или своим налоговым консультантом. Далее он должен уметь читать и интерпретировать балансы и счета прибылей и убытков, например при сравнении своего предприятия с конкурентами, приобретении или продаже предприятия или его частей, при участии в предприятии среднего бизнеса, связанного особенно с приобретением доли и т.п.» [51]
Управление рисками должно начинаться в стадии подготовки проекта, занимать значительную долю на стадии его планирования и сопровождать проект практически до его завершения. Анализ рисков необходим уже для того, чтобы определить, стоит ли вообще браться за проект. Именно реализация рисков приводит к срыву сроков выполнения проектов, перерасходу средств, а порой и к полному провалу проектов. В связи с изложенным вопросы управления рисками вынесены в отдельную главу.
В западной литературе рискам обоснованно уделяется большое внимание. Так, в [15] управлению рисками посвящена одна из первых глав. Хотя это подчеркивает важность вопроса, все же представляется нерациональным, поскольку до изучения вопросов планирования проекта невозможно сколько-нибудь полно выявить и проанализировать возможные риски проекта. В солидном учебнике H. Kerzner’a [13] управлению рисками также посвящена отдельная глава, но уже после рассмотрения вопросов планирования проекта.
Проекты по определению хотя бы в чем-то уникальны. Кроме того, окружающая среда проекта нередко отличается значительной неопределенностью. Поэтому принятие решений в условиях неопределенности и риска для руководителя проекта является каждодневной функцией.
Наступление нежелательного или вредного события (авария, резкое изменение курса валют, отказ заказчика от оплаты и т.п.) часто связано с высокими издержками. Поэтому важнейшая задача руководства проекта состоит в том, чтобы предвидеть возможные будущие риски и своевременно запланировать предупредительные мероприятия, чтобы исключить или по крайней мере свести эти издержки к минимуму.
Упор в анализе рисков делается обычно на возможных опасных последствиях проявления рисков. С другой стороны, в реальной жизни столь же часто, как неприятности, появляются и возможности, использование которых может привести к крупным успехам. Глобализация всех сторон общественной жизни и резкое усиление конкуренции создают дополнительные опасности, но и возможности тоже. Чтобы добиваться успеха, предприятия должны рисковать. Риск может являться движущей силой инноваций и предпринимательства, но он может быть и угрозой, если его неправильно оценивать и не уметь им управлять. Концепция риска учитывает эти обстоятельства.
Слово «риск» происходит от французского слова «risque», которое означает «смелость, бесстрашие». «Словарь русского языка» (М., 1987) определяет риск как «возможную опасность чего-либо» и как «действие наудачу, требующее смелости, бесстрашия, в надежде на счастливый исход».
Мир полон неопределенности. Говорят, что определенными являются только налоги и смерть. Все аспекты жизни и предпринимательства связаны с риском. Риск является функцией возможностей. Компании постоянно сталкиваются с новыми возможностями, но в большинстве случаев они сопровождаются рисками. Потенциально наиболее выгодные возможности обычно связаны и с большими рисками. Чтобы воспользоваться преимуществами этих возможностей, приходится идти и на большую степень риска. Компании постоянно оперируют в пространстве риска, и риск воздействует на организацию на всех уровнях. При этом отдельные риски не следует рассматривать изолированно, поскольку всегда имеются внутренне присущие им связи между уровнями. Операционный риск непосредственно воздействует и на стратегический риск.
В целом риск отражает дефицит наших знаний о будущих событиях. При этом благоприятные события мы называем возможностями, а неблагоприятные – угрозами.
В Руководстве по управлению рисками Министерства обороны США [63] риск определяется как мера потенциальной невозможности достичь общих целей программы/проекта в пределах определенной стоимости, сроков и технических условий, причем выделяются два компонента: а) вероятность неудачи в достижении определенного результата и б) последствия (или воздействие) от неудачи в достижении этого результата.
В общем случае лицо, принимающее решение в условиях риска, сталкивается со следующими вопросами [15]:
Риск является функцией вероятности возникновения события и последствий от него, если оно произойдет. Комбинация этих двух факторов жесткая. Например, событие с низкой вероятностью появления, но весьма серьезными последствиями может требовать вмешательства, в то время как событие с высокой вероятностью возникновения, но последствия которого не представляют заметной опасности для проекта, может быть приемлемым и не требовать особого внимания.
Одновременно риск является функцией опасности события и степени готовности к ней. Рассмотрим для примера завод резиновой обуви. Наличие большого количества пожаро- и взрывоопасных веществ делает пожар весьма вероятным, а опасность пожара понятна без дополнительных комментариев. Но строгое выполнение противопожарных мероприятий, обучение персонала и наличие своей пожарной части приводят риск к приемлемому уровню.
Риск органически связан с принятием решений. В общем случае решения могут приниматься в условиях определенности, в условиях риска и в условиях неопределенности. Условия определенности имеют место, когда результат решения известен. Условия риска имеют место, когда существует определенная вероятность того, что событие произойдет и когда может быть проведена некоторая оценка этого события. Это так называемые «известные неизвестности» (known unknowns). Большинство решений в проектах принимается именно в условиях риска. Условия неопределенности имеют место, когда вероятность возникновения события и его последствия предсказать невозможно (unknown un-knowns).
Выбор стратегии принятия решения в условиях определенности, риска и неопределенности зависит от ряда обстоятельств:
В условиях неопределенности лицо, принимающее решение, в зависимости от типа проекта, размера и положения организации и ее политики риска (если таковая сформулирована), а также от собственного отношения к риску может выбрать одну из четырех стратегий: критерий максимакса (критерий Гурвича), критерий максимина (критерий Вальда), критерий минимакса сожаления (критерий Сэвиджа) и критерий Лапласа [64].
A. Roberts и W. Wallace дают более простую классификацию рисков [15]:
Все эти виды рисков в некоторой степени связаны между собой. Так, например, операционный риск может быть связан с остановкой производственной машины, что, в свою очередь, может быть следстви-ем аварии в электрической сети (аварийный риск). Авария может быть следствием некомпетентного управления энергосетями (стратегический риск).
В приведенных группах рисков целесообразно выделить еще некоторые специфические подвиды:
В управлении проектами чаще всего выделяют четыре больших группы рисков:
Источниками технических рисков являются инженерные ошибки, дефекты поставки сырья и материалов, ошибки при изготовлении, монтаже и сдаче в эксплуатацию.
Инженерные ошибки могут возникнуть, например, за счет того, что в связи с неудовлетворительным проектированием не достигается запланированная производительность установки, которая определяется количеством и качеством производимого продукта. Может быть также и ситуация, когда не соблюдены действующие в стране потребителя законы, нормы и правила.
Под дефектами поставки сырья и материалов понимают ситуации, когда их качество или количество не соответствует требованиям проекта, а также если они поставляются с опозданием.
Риски при изготовлении, монтаже и сдаче в эксплуатацию связаны главным образом с квалификацией персонала, и поэтому их особо трудно оценить. Риски могут также возникнуть и потому, что в других климатических или географических условиях известные приборы, установки или технологии реагируют неожиданным образом. Нередко имеет место и ситуация, когда на месте монтажа своевременно не подготовлена площадка или подъездные пути, отсутствуют необходимое сырье, материалы или их качество и количество не соответствует нуждам проекта и т.д.
Проекты с традиционно высокими рисками (например, проекты внедрения электронного документооборота или проекты реконструкции) при твердо установленной стоимости могут быть связаны с большими опасностями не только для исполнителя, но и для заказчика [66]. Исполнитель будет всегда стремиться выполнить проект без убытков, даже за счет снижения качества работ. Даже если в договоре четко оговорены условия, все равно в случае конфликтов число достигнутых удовлетворяющих компромиссов будет небольшим. Поэтому в таких случаях рекомендуется браться за проекты с твердой стоимостью (также как и поручать их) только после основательного анализа рисков и четкого согласования условий. Другая разумная альтернатива заключается в том, чтобы твердую стоимость устанавливать только для частей проекта с обозримыми рисками, а остальную часть принимать по фактическим затратам. Это позволяет уменьшить финансовую неопределенность проекта, в то время как в проектах, выполняемых полностью на условиях фактических затрат, превышение планируемых сумм в несколько раз является достаточно распространенным явлением. При этом следует учитывать, что подрядчик, предлагающий выполнить работу за меньшую сумму, при расчете по фактическим затратам нередко оказывается дороже.
Политические риски могут быть связаны с целым рядом обстоятельств:
Социокультурные риски
В зарубежных проектах особое значение приобретает разнообразие культурных и социальных условий.
Сюда относятся прежде всего такие институциональные факторы, как семья, клановость, религия и др.
Кроме того, следует учитывать специфические представления о ценностях, которые могут, например, выражаться в сопротивлении населения новшествам, существовании «черных» рынков, семейственности, ненависти к иностранцам, особых традиций и т.д.
В некоторых случаях риски просто нельзя исключить. Но если они правильно идентифицированы и оценены и имеется соответствующая система мониторинга и контроля, появляется возможность эффективно управлять ими. Менеджмент рисков предоставляет ряд аналитических инструментов, которые позволяют анализировать возможности и сопровождающие их риски, что позволяет принимать более или менее рациональные решения. Целями управления рисками являются увеличение вероятности и воздействия положительных событий и уменьшение вероятности и воздействия опасных для проекта событий [12].
Для управления известными рисками планируются соответствующие действия. Для неизвестных рисков этого сделать нельзя, и разумным подходом к ним является планирование определенных резервов на случай их появления. Резервы закладываются и для части известных рисков, для которых планирование специальных мероприятий нерационально.
Подходы к управлению рисками у разных руководителей могут радикально различаться [15]:
20
Все эти подходы реально встречаются при выполнении проектов, однако наиболее эффективным является систематический взвешенный подход, учитывающий многолетний опыт выполнения оборонных проектов [63].
Вместе с тем следует отметить, что управление и контроль рисков возможны только до определенных пределов, поскольку пространство рисков содержит не только предсказуемые риски, но также частично предсказуемые и совершенно непредсказуемые. Никакая система управления рисками не может быть безупречной. Всегда может оказаться некоторый внешний риск, который не мог быть предсказан даже при самом детальном анализе. Как пишут A. Roberts и W. Wallace [15], в качестве экстремального примера можно себе представить столкновение Земли с астероидом, которое сделает все системы управления рисками ненужными. Кроме того, «программа безопасности, целью которой является 100 %-ная безопасность, приведет организацию к 0 %-ной производительности» [67].
Управление рисками включает в себя следующие компоненты:
Управление рисками должно быть упреждающим, структурированным, информативным и непрерывным. Ключ к успешному управлению рисками состоит в раннем планировании и настойчивом исполнении плана. Качественное планирование обеспечивает организованный, всесторонний и итеративный подход к идентификации и оценке рисков и мер противодействия им, необходимый для достижения целей проекта. Для этого оценка должна быть проведена как можно раньше, чтобы меры для уменьшения критических технических, временных и стоимостных рисков были учтены при планировании проекта и составлении его бюджета.
Эффективное управление рисками требует участия всей команды проекта, а зачастую также и внешних экспертов, обладающих знаниями в критических областях риска, например в технологии, конструировании, логистике, финансах. Процесс управления рисками должен предусматривать также возможные проблемы с программными продуктами, человеческим фактором и интеграцией проекта. Внешними экспертами могут быть и представители заказчика, которые полезны, поскольку их участие может облегчить достижение приемлемого баланса между стоимостью, результатами и риском.
В серьезных организациях в основе планирования управления рисками лежит политика риска, которая может быть оформлена в качестве отдельного документа. Прежде всего она должна определять индивидуальные цели для каждого подразделения организации. Только в этом случае она будет работать как стратегический документ.
Индивидуумы и организации в целом имеют определенное отношение к рискам (risk attitude), от которого зависят понимание рисков и реакция на них. Различают осторожное отношение к рискам (не рисковать!), нейтральное и активное. Это отношение руководства организации к рискам должно быть честно и в ясной, прозрачной форме доведено до команды проекта. Степень риска, на который руководители готовы пойти, обычно зависит от их возраста и опыта. Старые и опытные руководители стараются меньше рисковать, в то время как молодые могут принимать более агрессивные рискованные решения прежде всего для того, чтобы проявить себя.
Помимо идентификации «держателей риска» (risk holders) политика риска устанавливает:
Приемлемые отклонения и допуски целесообразно устанавливать в виде пределов разброса. Это определяет границы разрешенной практики и обеспечивает подачу сигнала тревоги при выходе за эти пределы. Вопрос санкционирования важен для сложных проектов, в которых не всегда очевидно, кто имеет соответствующие права на те или иные решения.
Планирование управления риском является процессом развития и документирования организованной, всесторонней, интерактивной стратегии и методов выявления и отслеживания областей риска, разработки планов мероприятий по управлению рисками и их мониторингу, а также планированию адекватных ресурсов.
Планирование начинается с разработки и документирования стратегии управления рисками. Это обеспечивает команду проекта директивами и базой для планирования. Стратегия управления рисками устанавливает цели и задачи управления рисками, определяет ответственных за специфические области и необходимость дополнительной технической экспертизы, описывает процесс оценки рисков и области оценки, намечает процедуры рассмотрения мер по управлению рисками, определяет схему рейтинга рисков. Кроме того, определяются схемы и объем отчетов и прочей документации по рискам, а также требования к ним. Планирование должно также рассматривать оценку потенциальных ресурсов для выполнения проекта. Полезным является составление некоторой матрицы ответственности, в которой определяются индивидуальные цели и обязанности и демонстрируются взаимосвязи между ними. Для обеспечения системного подхода к выявлению рисков организации могут использовать по аналогии с СПП типовые структурные схемы рисков (Risk Breakdown Structure).
Планирование управления риском является итеративным процессом. Руководитель проекта должен периодически проверять план и вносить в него необходимые коррективы.
Главной целью оценки рисков является выявление, описание и анализ рисков проекта так, чтобы наиболее критическими из них можно было эффективно управлять. Процесс оценки рисков заключается в выявлении и количественном анализе возможных событий с позиций их вероятности и последствий. Результат анализа создает базу для большинства действий по управлению рисками. Процесс оценки является, вероятно, наиболее трудным и емким по времени процессом управления рисками. Быстрых ответов здесь не бывает. Конечно, имеется целый ряд инструментов для поддержки специалистов, оценивающих риски, но ни один из них не является полностью исчерпывающим для проектов любого типа. Более того, они могут вводить в заблуждение пользователя, если он недостаточно хорошо понимает, как их применять и как интерпретировать результаты. В то же время оценка рисков, хотя она и сложна, является наиболее важной фазой процесса управления рисками, поскольку уровень и качество оценки определяет его эффективность.
Наиболее частым источником рисков являются стыки. Стыки между двумя частями объекта, стыки между объектами или субъектами должны/могут преодолеваться с помощью коммуникации, которая служит мостиком между ними 61. Под объектом можно понимать компьютер, но это может быть и программный продукт. Мостиком между двумя машинами может быть разъем, привод или телефонная сеть. Стык между различными программами может быть преодолен с помощью соответствующего программного протокола. Стык между компьютером и принтером преодолевается с помощью драйвера. Человек пытается преодолеть стыки между собой и другими людьми с помощью речи. В общем виде при этом говорят о коммуникации, которая может быть как вербальной, так и невербальной.
Успешное наведение мостиков в местах стыков различных частей системы является одной из важнейших задач проекта. Поэтому весьма целесообразно распознать стыки, определить возможные мостики и тем самым определить и потенциальные риски.
Общая схема оценки рисков представлена на рис. 1.2. Следует обратить внимание на то, что целый ряд задач целесообразно решать еще до собственно оценки рисков. К ним относятся установление средств и формата коммуникации информации о рисках, а также тренинг членов команд по менеджменту рисков. Для этого может оказаться необходимым подготовить соответствующий пакет информационных и методических материалов для команды проекта и других участников.
В литературе можно встретить целый ряд методов, с помощью которых могут оцениваться риски проекта. Из них наиболее успешно применяются следующие:
1. Определение риска на основе структурного плана проекта.
2. Анализ отказов.
3. Контрольные листы.
Учитывая, что многие трудности и недостатки, которые приводят к отказам и другим проблемам, могут быть распознаны и с небольшими затратами устранены, центр тяжести выявления рисков целесообразно перенести на плановую фазу проекта. Финансовые затраты на контроль в плановой фазе обычно невелик по сравнению с издержками на устранение последующих недостатков и проблем.
Последовательность действий при определении рисков на основе структурного плана проекта может быть следующей:
Для определения рабочих пакетов, связанных с наибольшими рисками, все работы включаются в список, и каждая из них исследуется с помощью следующих вопросов:
Эту работу рекомендуется проводить составом команды, чтобы по каждому рабочему пакету были учтены соответствующие профессиональные аспекты.
Для каждого рабочего пакета выявляются источники риска, записываются все мыслимые трудности, указывается вероятность их возникновения и определяются затраты, которые могут понадобиться на их устранение. Как правило, достаточно дать грубую оценку возможных издержек. Произведение вероятности возникновения трудности на возникающие при этом издержки дает вероятное значение издержек по каждому случаю. Если обнаруживаются высокие вероятные издержки, необходимо определить причины этого явления. После выяснения причин издержек могут быть запланированы и приняты контрмеры для их исключения или уменьшения. Учитывая, что многие риски взаимосвязаны, необходимо выявить их возможное влияние друг на друга и определить суммарный риск.
Вначале надо определить основные источники рисков, и прежде всего в важнейшей области – по персоналу:
Проекту нередко угрожает множество опасностей, называемых факторами риска. Опыт выполнения проектов показал, что к наиболее распространенным факторам риска относятся:
Подход к анализу рисков на основе структурного плана проекта может быть применен для всех типов проектов и на любых их фазах.
Рекомендуется также периодически проводить переоценку рисков с учетом уже выполненных работ и новой информации. Это позволяет поддерживать анализ риска в актуальном состоянии.
Выявление рисков на основе анализа отказов базируется на том,
что проблемы часто возникают, когда появляются отклонения технологических параметров (количества, давления, температур, времени обслуживания клиентов и др.). Поэтому ставится цель зарегистрировать все мыслимые отклонения от нормальной эксплуатации и их проанализировать. Если речь идет об установке, то, исходя из схемы установки, по каждой из входящих в нее составных частей записываются все возможные отклонения процесса от нормы, определяются их причины и последствия.
При методе контрольных листов используются детальные контрольные списки (вопросники), составленные на основе опыта (своего или чужого) выполнения прошлых проектов. На вопросы отвечают соответствующие специалисты, привлеченные к работе по проекту. Это простой и часто применяемый метод. Главный его недостаток заключается в отсутствии системности, так что некоторые существенные риски могут быть пропущены.
Результатом процесса выявления рисков является документ, называемый регистром рисков. На практике при выявлении риска нередко сразу начинается и процесс его анализа. Например, если в интервью с экспертом выявляется некоторый риск, логично сразу же получить информацию о вероятности его появления и последствиях, а также о времени его появления (когда он может проявиться) и возможных вариантах борьбы с ним. Одновременно может осуществляться и первичное ранжирование рисков по вероятности и последствиям их появления.
Анализ рисков начинают с детального изучения выявленных критических рисков. Задачей является получение достаточной информации о рисках для оценки вероятности их появления и воздействия на стоимость, сроки и выполнение работ. Оценка воздействия обычно субъективна и основывается на информации, получаемой за счет:
В зависимости от конкретной техники и вида анализируемого риска может потребоваться еще некоторый дополнительный анализ, например анализ процессов контрактора, таких как конструирование, инжиниринг, анализ дерева неисправностей и др. В целом анализ обеспечивает базу для субъективных оценок.
Рейтинг рисков и установление приоритетов
Значимость риска зависит от последствий его проявления, вероятности его возникновения и эффективности мер противодействия этому риску. Часто эти три характеристики не удается выразить в цифрах. В этих случаях их ранжируют. Пример такого ранжирования представлен в табл. 1.1.
Таблица 1.1
Рейтинги являются индикаторами потенциального воздействия рисков на проект. Они являются мерой вероятности возникновения и последствий случаев риска.
Для определения рейтингов рисков наиболее эффективно привлечение группы экспертов, которые хорошо знакомы с каждой областью риска (например, конструированием, логистикой, производством и т.д.), а также с рабочими пакетами структурного плана проекта. Для начала они должны установить критерии рейтинга и согласовать их с руководителем проекта, который включает их в план менеджмента рисков. В большинстве случаев критерии будут основаны на опыте экспертов, а не на математических формулах. Поэтому они должны иметь достаточно большой диапазон для того, чтобы была возможность различить разницу в рейтингах. На уровне проекта в целом последствия проявления рисков должны быть отражены в терминах воздействия на стоимость, сроки и выполнение работ. Для этого может быть использован метод анализа ценности.
При зарубежных проектах руководству проекта следует обязательно разобраться с политическими рисками в соответствующей стране и попытаться оценить их возможное развитие в период выполнения проекта.
Для описания характеристик воздействия рисков наряду со словесными оценками также могут применяться численные шкалы как линейные, так и нелинейные, например: 0,05; 0,1; 0,2; 0,4; 0,8. Нелинейные шкалы могут выражать желание организации избегать больших угроз или соответственно использовать большие шансы, даже если они имеют малую вероятность появления. Однако при использовании нелинейных шкал важно понимать смысл, закладываемый в цифры, соотношение между ними и какой эффект они могут оказать на различные цели проекта.
На основании установленных критериев составляется таблица рейтингов конкретных рисков. Если в ней риски расположены по приоритету, такой документ называют контрольным списком рисков (Watch List). Часто пытаются риск представить с помощью одной цифры, учитывающей одновременно и вероятность случая риска, и его воздействие. Хотя и существуют методы установления совместимых (калиброванных) шкал, пользуются ими редко. Поэтому обычно используют некалиброванные шкалы, однако надо помнить, что любые математические операции с ними, например умножение, вообще говоря, недопустимы, т.к. это может привести к грубым ошибкам в установлении рейтинга риска.
Простой метод представления рейтингов рисков – принимают три уровня общего риска для разных комбинаций вероятности и воздействия: высокий (В), умеренный (У) и низкий (Н).
Игнорирование риска представляет собой рискованную стратегию. Но иногда жизнь вынуждает пренебрегать даже весьма большими рисками, хотя это может быть и опасным. Тем не менее информированное пренебрежение рисками, характеризующимися малыми периодическими потерями, вполне разумно. Обычно такой подход применяется к рискам, которые имеют малую вероятность и малое воздействие.
Управление риском не предполагает исключения источника риска, но направлено на его уменьшение или смягчение последствий, с тем чтобы минимизировать его воздействие на проект. Для оборонных проектов обычно применяется именно эта альтернатива.
Поскольку такой подход может увеличить стоимость проекта, целесообразность выбора данной альтернативы должна быть рассмотрена с позиций соотношения стоимости, сроков выполнения и качества проекта.
Трансфер риска предполагает передачу риска из одной части системы в другую с целью снижения общего системного риска или перераспределение риска между контрактором, заказчиком и другими организациями (рис. 1.6).
Прежде всего пытаются часть общего риска возложить на заказчика. Это достигается тем, что реализация определенных рабочих пакетов проекта, которые должны быть точно зафиксированы, а границы между ними и остальным проектом точно определены, остаются за заказчиком. По оставшимся рискам следует обдумать, какие из них могут быть делегированы контрагентам и поставщикам, какие могут быть переданы страховщикам и другим подобным носителям рисков, а какие риски вынужден нести сам подрядчик. В частности, ряд рисков может быть передан страховым компаниям в обмен на премию. Но не все риски можно передать, а по некоторым рискам это и экономически нецелесообразно.
Распределение рисков зависит от ряда вопросов:
Фиксация распределения рисков осуществляется в договорах с членами консорциума, договорах с поставщиками, страховщиками, банками и другими носителями рисков. По этому вопросу руководство проекта должно работать в тесной связке с юридическим отделом предприятия. По рискам, остающимся у подрядчика, должны быть приняты соответствующие технические и предпринимательские меры противодействия.
Наряду с этими уменьшающими риск мерами следует дать завершающую оценку общего риска проекта. В принципе общий риск проекта никогда не удается выразить в чисто монетарном виде. Часть риска, которая может быть определена в денежном выражении, проявляется в целом ряде позиций калькуляции:
издержки рисков, делегированных контрагентам и поставщикам, проявляются в форме высоких цен за поставки и выполняемые работы;
издержки рисков, покрываемых страховщиками и подобными носителями рисков, проявляются в виде соответствующих взносов;
издержки рисков, которые остались у подрядчика и которые минимизируются усилиями менеджмента, оказываются распределенными по многим статьям калькуляции.
Для рисков, которые не могут быть определены в денежном выражении, обычно делается некая грубая оценка, которая включается в калькуляцию в качестве платы за риск в виде дополнительной суммы. Обычно эту величину берут с определенным запасом с учетом не распознанных рисков. Результаты анализа рисков представляются руководству предприятия для принятия решения о том, браться за проект или нет.
Мониторинг рисков призван систематически отслеживать и оценивать эффективность мер по обращению с рисками путем сопоставления с заранее установленными заданиями и параметрами. Результаты мониторинга могут также служить базой для разработки дополнительных мер предупреждения и борьбы с рисками, а также выявления новых рисков. Ключом процесса мониторинга является установление рассмотренной нами выше индикаторной системы контроля издержек, времени и выполнения работ, которую руководитель проекта использует для оценки состояния проекта. Индикаторная система должна быть построена так, чтобы обеспечивать раннее предупреждение о потенциальных проблемах. Управление рисками является не техникой решения проблем, а скорее превентивной техникой контроля результатов обращения с рисками и выявления новых рисков. Поскольку по ходу проекта возникают новые риски, да и ранее выявленные могут оцениваться по-новому, в течение проекта необходимо периодически возвращаться к анализу рисков и производить их переоценку.
Одним из главных условий успешного управления рисками является непрерывное документирование всего менеджмента рисков. Под документированием рисков понимают регистрацию, поддержку и отчетность по оценке рисков, планам и анализу обращения с рисками и мониторингу результатов. Оно включает все планы, отчеты для руководителя проекта и вышестоящих лиц, принимающих решения, а также внутренние докладные команды проекта. Это важно, поскольку:
Кроме того, система выявления и анализа рисков может быть некорректной или использоваться неправильно. Поэтому очень важно, чтобы все предположения, допущения и процессы оценки были зарегистрированы и затем отслеживались, чтобы видеть, работают ли они корректно.
Документирование ошибок может оказаться даже более важным, чем фиксация успехов. Как пишет H. Petroski, «успех дает нам уверенность, что мы что-то сделали верно, но не обязательно говорит нам что и почему. Ошибки неопровержимо свидетельствуют о том, что мы что-то сделали неправильно. Это бесценная информация… Когда сложная система успешна, ее успех маскирует ее близость к провалу… Гибель “Титаника” обеспечила больший вклад в обеспечение безопасности океанских лайнеров, чем дал бы успех» [80].
«Безмолвные» стейкхолдеры – будущие поколения, прошлые поколения и окружающая среда.
Бенчмаркинг – способ распознавания проблемы путем сравнения существующих показателей организации, продукта, услуги со средними или лучшими показателями отрасли, другого предприятия, продукта, услуги.
Веха проекта – заданное ключевое событие, срок которого задан заказчиком или иными внешними органами и строго им контролируемое.
Внешнее управление проектом – ситуация, когда нанимается внешний руководитель проекта, работающий как внешний агент по поручению клиента.
Внутреннее управление проектом – ситуация, когда проектная команда работает целиком в пределах существующей организационной структуры.
Генеральный подрядчик – юридическое лицо, которое выбирается для реализации проекта.
Дерево целей – схема, показывающая членение общих (генеральных) целей проекта на подцели, последних – на подцели следующего уровня и т.д.
Заказчик проекта – человек или организация, выступающая заказчиком и формулирующая технические требования к проекту.
Инвестор проекта – стейкхолдер(ы) проекта, вкладывающие средства в проект, например посредством кредитов.
Инициатор проекта – человек (или организация), который является автором главной идеи проекта, его предварительного обоснования и предложений по осуществлению проекта.
Интеграция проекта включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и действий по управлению проектом.
Команда проекта – группа сотрудников, непосредственно работающая над осуществлением проекта и подчиненных руководителю проекта.
Коммуникация – это обмен информацией, где обе стороны играют активную роль.
Коммуникация горизонтальная – обмен информацией в пределах одного уровня иерархии управления.
Коммуникация вертикальная – обмен информацией между разными уровнями иерархии управления.
Контрактор (генеральный контрактор) – участник проекта, вступающий в отношения с заказчиком и берущий на себя ответственность за выполнение работ по контракту.
Контроль проекта – комплекс действий, предназначенных для фиксации отклонений в сроках, издержках, мощностях и ходе выполнения проекта путем сравнения планового и фактического состояния дел и привлечения внимания руководства проекта к необходимости принять встречные меры или откорректировать планы.
Конфигуратор – минимальный набор профессиональных языков, позволяющий дать полное описание проблемной ситуации и ее преобразований.
Критерии успеха проекта – комплекс требований к проекту, при выполнении которых проект может быть признан успешным.
Критические работы – работы с нулевым резервом времени.
Критический путь – цепь работ с нулевым резервом времени от старта проекта до финиша.
Лицензор – организации, выдающие лицензии на право владения земельным участком, ведения торгов, выполнения определенных видов работ и услуг и т.п.
Матрица обязанностей – схема функциональных обязанностей участников проекта.
Матрица ответственности – схема распределения ответственности должностных лиц, причастных к выполнению проекта.
Общий резерв работы / рабочего пакета – разность между сроком, не позднее которого работа должна быть закончена, и ранним возможным сроком ее окончания.
Ограничения проекта – ограничения на время и условия выполнения проекта, а также способы выполнения работ проекта.
Портфель – это набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей. Проекты и программы портфеля не обязательно являются взаимозависимыми или напрямую связанными.
Поставщики – субконтракторы, осуществляющие разные виды поставок на контрактной основе (материалы, оборудование, транспортные средства и др.).
Проблема – субъективное отрицательное отношение субъекта к реальности.
Проблемная ситуация – это некоторое реальное стечение обстоятельств, положение вещей, которым ктото недоволен, неудовлетворен и хотел бы изменить.
Проблемное месиво – список проблем всех стейкхолдеров проекта.
Программа – это ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности.
Проект – ограниченное во времени намерение создать уникальный продукт, услугу или результат.
Проектировщик – юридическое лицо, выполняющее по контракту проектно-изыскательские работы в рамках проекта.
Проектный офис – это подразделение, которое осуществляет различные функции, относящиеся к централизации и координации управления проектами, входящими в его сферу ответственности.
Процессный план проекта – схема (граф), демонстрирующая последовательность выполнения работ по проекту и связи между ними.
Работа (рабочий пакет) – действие с фиксированным началом и фиксированным концом, ответственность за выполнение которого закреплена за определенным лицом или организацией.
Риск – возможная опасность чего-либо, действие наудачу в надежде на счастливый исход.
Руководитель проекта – лицо, которому заказчик и инвестор делегируют полномочия по руководству работами по осуществлению проекта (планирование, контроль и координацию работ всех участников проекта).
Свободный резерв времени работы – отрезок времени, на который может быть задержана работа, с условием, что последующая работа может быть все-таки начата в свое раннее начало.
Сетевое планирование – все приемы для анализа, описания, планирования процессов и управления ими на основе теории графов, которые позволяют учитывать время, издержки, ресурсы и другие влияющие параметры
СОВНЕТ – Советская (ныне Национальная) ассоциация управления проектами.
Стейкхолдеры проекта – все организации и личности, которых каким-либо образом задевает проект.
Структурный план проекта – стройная иерархическая декомпозиция проекта на составные части, необходимые и достаточные для планирования и контроля осуществления проекта для различных участников проекта.
Субконтрактор – это лицо (в т.ч. юридическое), которое вступает в договорные отношения с контрактором или субконтрактором более высокого уровня. Он несет ответственность за выполнение работ и услуг в соответствии с контрактом.
Управление проектами – это применение знаний, умений, инструментов и приемов к работам по проекту с целью удовлетворения требований к проекту.
Фазы проекта – это отдельные части в рамках проекта, требующие дополнительного контроля для эффективного получения основного результата проекта.
Целевое месиво – список целей всех стейкхолдеров проекта.
2Применение процессного подхода во многих случаях действительно позволяет наглядно представить связи и последовательность процессов и радикально улучшить выполнение задач человеческой деятельности. Однако в случае управления проектами излишняя формализация и жесткая привязка к процессам может скорее ограничить творчество и здравый смысл.