авторефераты диссертаций БЕСПЛАТНАЯ  БИБЛИОТЕКА

АВТОРЕФЕРАТЫ КАНДИДАТСКИХ, ДОКТОРСКИХ ДИССЕРТАЦИЙ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:   || 2 |
-- [ Страница 1 ] --

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО

ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ЭКОНОМИКИ И ФИНАНСОВ»

КАФЕДРА ЭКОНОМИКИ ПРЕДПРИЯТИЯ

И ПРОИЗВОДСТВЕННОГО МЕНЕДЖМЕНТА

УПРАВЛЕНИЕ ПРОЕКТАМИ

УЧЕБНОЕ ПОСОБИЕ

ИЗДАТЕЛЬСТВО САНКТ-ПЕТЕРБУРГСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА ЭКОНОМИКИ И ФИНАНСОВ 2012 ББК 65.050.2 У 66 Управление проектами : учебное пособие / М.В. Тихонова У 66 [и др.]. – СПб. : Изд-во СПбГУЭФ, 2012. – 83 с.

2 Учебное пособие предназначено для изучения дисциплины «Управление проектами» и охватывает основной круг вопросов управ ления проектами в современных условиях. В нем изложены сущность, цель и функции управления проектами, дана классификация проектов, подробный анализ источников финансирования инвестиций, рассмот рены этапы жизненного цикла проекта, управления его реальными и финансовыми инвестициями, формирования инвестиционных ресурсов.

Рассматривается сущность проекта как объекта управления. Подробно анализируются стандарты управления проектами.

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

ББК 65.050. Авторский коллектив:

канд. экон. наук М.В. Тихонова (пп. 1.1-1.3) канд. экон. наук Г.Р. Хакимова (пп. 1.4, 1.5;

2.1) И.П. Чуян (пп. 2.2, 2.3) канд. экон. наук О.С. Павлова (пп. 1.1, 2.3) канд. экон. наук Ю.Б. Шутов (п. 2.4) М.А. Матуленко (п. 2.5) Рецензенты:

канд. техн. наук, доц. каф. «Экономика промышленности и организации производства» СПбГУНиПТ Ф.С. Мазитова д-р экон. наук, проф. Е.А. Горбашко © СПбГУЭФ, СОДЕРЖАНИЕ Введение.............................................................................................................. Тема 1. Основы управления проектом........................................................ 1.1. Исторический аспект возникновения управления проектами..... 1.2. Понятие проекта. Субъекты проекта............................................ 1.3. Этапы проекта.................................................................................. 1.4. Процессы управления проектом.................................................... Тема 2. Стандарты в управлении проектами........................................... 2.1. Основные стандарты управления проектами............................... 2.2. Профессиональные международные и национальные квалификационные стандарты....................................................... 2.3. Своды знаний................................................................................... Тема 3. Структура стандартов..................................................................... 3.1. Специализация и детализация стандартов управления проектом........................................................................................... 3.2. Документационное обеспечение................................................... Библиографический список............................................................................. Приложение...................................................................................................... ВВЕДЕНИЕ Современная теория управления проектами базируется на возник ших в конце 50-х годов методах структуризации работ и сетевого плани рования. Появление и развитие метода анализа и оценки программ PERT (Program Evolution and Review Technique) и метода критического пути СРМ (Critical Path Method) привело к определению методики сетевого планирования.

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

Существуют две профессиональные ассоциации, объединяющие специалистов по управлению проектами и определяющие стандарты и профессиональные требования в данной области. Институт управления проектами PMI (Project Management Institute) – организация с единым членством, в которую входят менеджеры всего мира. PMI разрабатывает и издает Project Management Body of Knowledge (PMBoK) – свод понятий и практических требований по управлению проектами, признанный между народный стандарт в этой области. Международная ассоциация по управ лению проектами (International Project Management Association – IPMA) объединяет национальные ассоциации, преимущественно европейские, и издает собственный свод требований к специалистам по управлению про ектами, International Competence Baseline (ICB). На его основе формиру ются национальные требования. Так, в России национальной ассоциацией, входящей в IPMA, является СОВНЕТ, которая выпускает Национальные требования компетенции по управлению проектами.

Целью изучения учебной дисциплины «Управление проектами» яв ляется ознакомление со стандартами управления проектами, изучение ме тодик. Студент должен знать пять основных процессов проекта – инициа цию, планирование, исполнение, контроль и завершение, а также должен обладать знаниями и навыками в таких областях, как управление пред метной областью проекта, управление сроками, бюджетом проекта, обра зование команд (управление персоналом проекта), управление коммуни кациями между участниками проекта, управление рисками, управление взаимодействием с внешними поставщиками и субподрядчиками, управ ление качеством.

ТЕМА 1. ОСНОВЫ УПРАВЛЕНИЯ ПРОЕКТОМ 1.1. Исторический аспект возникновения управления проектами Вопросами эффективного управления занимались ещё во времена древних цивилизаций Египта, Рима, Греции, Китая. Греки начали разде лять технические знания и искусство управления. Административный та лант римлян, проявившийся в создании эффективной системы управления, превратил Рим из маленького города в столицу огромной империи. Рели гиозные организации Средневековья создали сложную иерархическую структуру, построенную по территориальному принципу. Основные эле менты современного управления, такие как единоначалие, делегирование полномочий, исполнительная вертикаль и принцип соотношения линей ных и штабных подразделений, впервые появились в военных организа циях. Наконец, промышленная революция XVIII века привела к возникно вению науки управления как академической дисциплины.

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

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

В 1911 году американский инженер, основоположник научной орга низации труда и менеджмента, представитель научной школы управления Фредерик Уинслоу Тейлор учредил Общество содействия научному ме неджменту. Его труды стали прототипами многих современных инстру ментов, включая иерархическую структуру работ (WBS). Ф.У. Тейлор считал, что главная цель управления – обеспечение высокой производи тельности труда и социальной гармонии. Им были разработаны принципы рациональной организации труда, основанные на идее разделения, спе циализации и стандартизации исполнительского и управленческого труда.

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

«Принципы научного менеджмента» и «Управление предприятием».

В 1916 году Француз Анри Файоль опубликовал работу «Общее и промышленное управление», в которой обобщил наработанные им схемы управления. А. Файоль предложил пять функций менеджмента (планиро вание, организация, мотивация, контроль, координация);

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

выделил 6 ос новных сторон деятельности (техническую, коммерческую, финансовую, обеспечение безопасности труда и собственности, ведение отчетности, собственно управление).

Ни один из представителей английских промышленных или научных кругов не внес такого значительного вклада в развитие практического ме неджмента и преподавание управленческих дисциплин, как Линдал Ур вик. Л. Урвик заинтересовался вопросами управления в период прохожде ния допризывной военной подготовки в колледже и затем попытался при менить усвоенные им знания в принадлежавшей его семье производствен ной компании. В апреле 1921 г. он выступил на собрании преподавателей в Оксфорде с лекцией на тему «Менеджмент как самостоятельная наука».

Л. Урвик уделял особое внимание разработке конкретных рекомендаций по управлению, особенно в той части, которая касалась разделения труда.

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

серийный (каждая служба ответственна за одну из операций в общем технологическом процессе);

субъектный (службы группируются вокруг отдельных людей, обладающих необходимой специализацией и возможностями). Л. Урвику также ставят в заслугу популяризацию прин ципа «зоны регулирования» – количества лиц, которыми эффективно мо жет управлять руководитель. Норма управляемости определялась им в ко личестве 5, 6 человек. Среди множества работ Л. Урвика особое внимание заслуживает исследование «Элементы администрации». Л. Урвик глубже А. Файоля исследовал принципы построения формальной организации, особо выделив соотношение полномочий (прав) и ответственности. В те чение четырех десятилетий Л. Урвик занимался внедрением в практику управления разумных принципов менеджмента. Эти усилия подкрепля лись опытом его работы в разных должностях и дополнялись активным участием в английском институциональном «движении за совершенство вание менеджмента» и в процессах развития высшего образования.

В 30-е годы XX столетия в США началась разработка специальных методов координации инжиниринга крупных проектов (авиационных – в US Air Corporation, нефтегазовых – в фирме Exxon). В 1937 году амери канцем Лютером Гуликом была создана матричная организация проектов, которая способствовала увеличению эффективности реализации сложных проектов. Благодаря этому был подготовлен переход от бюрократических организационных структур к более гибким, в большей мере отражавшим специфику управления проектами. Л. Гулик изобрел акроним POSDCORB, первые буквы которого соответствуют английским словам: планирование, организация, подбор персонала, командование, координация, отчетность и бюджетирование. Позднее Л. Гулик изменил акроним POSDCORB на POSDECORB, вставив в него букву Е – от английского «evaluation» – оценка. Помимо этого, Л. Гулик разработал 4 варианта выделения струк турных подразделений внутри организации в зависимости от конкретных условий: основной цели подразделения;

специфики работы;

тех, с кем или того, с чем данное подразделение работает;

географического местополо жения подразделения.

Руководители компании «Дженерал Моторс» Джеймс Муни и Алан Рейли в 1931 г. опубликовали книгу «Прогрессивная индустрия», в 1939 г.

вышло дополненное издание «Принципы организации». Д. Муни и А. Рейли утверждали, что результативное управление возможно только за счет зна ния уникальных свойств организации, которые проявляются во всех без исключения группах людей. Свою главную задачу они видели в том, что бы сформулировать принципы построения эффективной структуры. В окончательной редакции 1947 г. перечисляется 4 таких принципа: прин цип координации;

принцип иерархии;

принцип функциональности;

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

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

С началом холодной войны стратегической задачей США стало обеспечение военного превосходства над СССР. Министерство обороны пришло к выводу, что в рамках традиционной системы управления невоз можно справиться с такими задачами, как разработка стратегического бомбардировщика Б52, подводной лодки «Поларис» и др. Теория управ ления проектами получила признание в проектах создания большей части вооружений и в аэрокосмических разработках НАСА. В других сферах хо зяйственной деятельности использование методов управления проектами было незначительным.

Впервые современное практическое применение матричной органи зации Л. Гулика произошло в 1953–54 гг. в Офисе совместных проектов воздушных сил США и в Офисе специальных проектов по вооружению, а в 1955 г. – в Офисе специальных проектов морского флота США. Это бы ли первые и наиболее организованные механизмы для достижения инте грации при управлении сложными проектами. Как следствие интеграции сложилась определенная практика управления проектами: определение требуемых результатов;

тщательное предварительное планирование во из бежание будущих изменений плана;

назначение ответственного за разра ботку и выполнение проекта. В 1956 г. М. Уолкер из фирмы «Дюпон», ис следуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д. Кел ли из группы планирования капитального строительства фирмы «Реминг тон Рэнд». Они попытались использовать ЭВМ для составления планов графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». В результате был создан рациональный и простой метод описа ния проекта с использованием ЭВМ. Первоначально он был назван мето дом Уолкера-Келли, а позже получил название Метода Критического Пу ти – МКП (CPM – Critical Path Method). СРМ с успехом был опробован на разработке плана строительства завода химического волокна в городе Лу исвилле, штат Кентукки. В результате этой работы появились первые пуб ликации по управлению проектом.

Впервые методы моделирования и согласования комплекса работ были использованы при разработке ракетной системы «Поларис», начатой в 1957 году. Реализация проекта, объединявшего около 3800 основных подрядчиков и состоявшего из 60 тысяч задач, была поручена Главному управлению вооружений ВМС США. Для управления реализацией этого проекта корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» был создан специальный метод планирования работ на основании оптимальной логической схемы процесса, названный методом анализа и оценки программ PERT (Program Evaluation and Review Technique). Использование метода PERT позволило руководству програм мы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также какова вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить раньше запланиро ванного срока. Благодаря такому успешному началу данный метод управ ления был засекречен и вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя заре комендовала при координации работ, выполняемых различными подряд чиками в рамках крупных проектов по разработке новых видов вооруже ния.

В 1959 году комитетом Андерсона (NASA) был сформулирован сис темный подход к управлению проектом по стадиям его жизненного цикла, в котором особое внимание уделялось предпроектному анализу. Развитие УП в 50-е годы завершилось публикацией Gaddis в Harvard Business Review первой обобщающей статьи по управлению проектами.

В 60-е годы развитие управления проектами базируется на методах и средствах PERT и СРМ. Расширяется сфера применения сетевых методов, разрабатываются методы и средства оптимизации стоимости для СРМ и PERT, распределения и планирования ресурсов (RPSM, RAMPS и др.).

Фирма IBM разрабатывает пакет программ на базе PERT/COST как систе му для управления проектами – PMS, создаются первые системы контроля проектов на основе сетевой техники (PSC) и др. Начинается распростра нение сетевых методов управления проектами на Европу и другие конти ненты, дальнейшее развитие получает организационная интеграция.

Руководители предприятий стали осознавать необходимость созда ния системы управления и организационной структуры, адекватных быст ро изменяющимся условиям внешней среды. В 1967–68 гг. Пол Лоуренс и Джей Лорш занялись проблемами дифференциации организаций и внеш ней среды. Интеграции дифференцированных функций в рамках органи зации позволили выработать рекомендации как для теоретиков, так и для практиков менеджмента. Результатом научных усилий П. Лоуренса и Дж.

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

В 1967 году в Европе была основана Международная ассоциация управления проектами International Project Management Association (IPMA), которая создала квалификационный стандарт деятельности специалистов по управлению проектами IPMA Competence Baseline. В 1969 году в США появилась профессиональная некоммерческая организа ция, представляющая интересы индустрии управления проектов – Инсти тут управления проектами (PMI). Уже к 1970 г. в Австралии действует Австралийский институт управления проектами (AIPM);

в Азии – Япон ская ассоциация развития инжиниринга (ENAA). Эти организации со вре менем установили тесные взаимоотношения для обмена опытом (инфор мацией, идеями, публикациями).

В 70-х годах продолжается развитие и внедрение систем сетевого планирования и управления, техника сетевого анализа впервые вводится в учебных заведениях США в качестве обязательных инженерных предме тов. Метод критического пути получает законодательную поддержку. По водом для разработки внешнего окружения проектов и формального включения внешних факторов (экономических, экологических, общест венных и др.) в процесс управления проектами стали проблемы с оппози цией защитников окружающей среды, в связи с чем в 1977 году разраба тываются методы управления конфликтами.

В начале 80-х годов XX века часть компаний осознала необходи мость проектно-ориентированного подхода к управлению проектами из-за масштабов и сложности выполняемых работ. К этому времени уже суще ствовало множество публикаций по проблемам управления проектами. В 1981 году в PMI началась подготовка документа, излагающего методоло гические основы управления проектами – «A Guide to the Project Manage ment Body of Knowledge» (PMBOK Guide). Пробный вариант руководства стал доступен в 1987 году, а первая редакция опубликована в 1996 г. В 1987 г. публикуется первая версия Свода знаний по управлению проекта ми – PMBOK (Project Management Body of Knowledge), содержащего сум му профессиональных знаний, позволяющих успешно достичь целей при реализации проектов в различных сферах деятельности. Сегодня стандарт PMBOK широко используется во всем мире.

В середине 80-х в практику входят методы управления конфигура цией (изменениями), развивается управление качеством, что позволяет лучше управлять инновационными проектами. Осознается высокая роль партнерства и работы проектной команды, управление риском выделяется в самостоятельную дисциплину. Петер Левене воедино сводит проблемы управления и ресурсного обеспечения проектов.

В 1991 г. в Германии вышли учебник и практическое руководство по управлению проектами, подготовленные Национальной Ассоциацией Управления Проектами Германии (GPM), в которых обобщен и система тизирован многолетний опыт по управлению проектами.

В 90-е годы многие предприятия пришли к выводу, что использова ние проектно-ориентированного управления жизненно необходимо для обеспечения конкурентоспособности операционной деятельности. Начи нается применение методов управления проектами в социальных и эконо мических проектах, крупных международных проектах. Для отдельных предприятий решение проблемы внедрения управления проектами стало одним из самых серьезных испытаний. На начальной фазе предприятие осознает необходимость внедрения управления проектами. Обычно это происходит на нижних и средних уровнях, где осуществляется практиче ская реализация проектов. Затем данная ситуация оценивается, а резуль тирующая информация передается на высший уровень управления. На фа зе принятия решения высшим руководством переход к управлению проек тами должен быть официально озвучен и поддерживаться руководством предприятия. На фазе принятия линейным руководством должна быть обеспечена поддержка внедрения новой системы управления линейными руководителями. На фазе роста развивается методология управления про ектами – планирование, контроль, происходит выбор прикладных компь ютерных программ. На фазе зрелости предприятие применяет инструмен ты управления проектами, внедренные на предыдущей фазе.

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

С 30-х по 50-е годы начинается зарождение некоторых инструментов управления проектами. Развитие однотипного, серийного производства повлияло на появление поточной организации работ по реализации строи тельных проектов. Теория строительного потока является основой совре менной научной организации и управления строительным производством.

Таким образом, в данный период зарождаются основы управления проек тами, планирование и контроль выполнения проектов основывается на моделях Гантта и циклограммах с использованием графоаналитических методов их расчета и оптимизации. Теорией и организацией поточного производства в строительстве занимались такие учёные, как О.А. Вутке, М.В. Вавилов, А.В. Барановский, А.А. Гармаш, В.И. Батурин, М.С. Буд ников, Е.И. Вареник и др.

Развитие и внедрение методов сетевого и календарного планирова ния началось с выпуском первых публикаций о сетевых методах в 60-е го ды XX века. После появления данных публикаций, разработанных в США, ряд советских ученых, такие как С.П. Никаноров, А.И. Теймана, публику ют первые отечественные работы. Монография С.И. Зуховицкого и К.А. Радчик до сегодняшнего дня остается одной из лучших по данному предмету.

В 1971–1974 гг. Г.М. Адельсон-Вельский, В.И. Воропаев и М.В.

Шейнберг разработали обобщенные сетевые модели, имеющие некоторые преимущества перед западными аналогами. В это время появляются пер вые программные средства для расчета сетевых графиков. Д.И. Голенко, К.А. Антонавичюс и С.И. Лившиц создают стохастические и альтернатив ные модели, учитывающие вероятностную природу различных элементов проекта.

В 70-е годы происходит развитие системного подхода и программ ных средств для управления проектами, появляются первые программные комплексы для многопроектного управления программой деятельности организации с учетом её целей и ресурсных возможностей, создаются ав томатизированные системы управления организациями и предприятиями в различных отраслях народного хозяйства. Первые электронно-вычисли тельные системы управления проектами содержали временной и стоимо стной анализы. Со временем системы сетевого планирования и управле ния стали использоваться не только в рамках отдельных проектов, но и для организации деятельности предприятия в целом.

80-е годы ознаменовались появлением интегрированных автомати зированных систем управления (ИАСУ), что стало основой технической политики в области автоматизации производства и управления и др.

ИАСУ создавались с начала 80-х годов во многих крупных промышлен ных и строительных организациях, объединениях и министерствах.

Развитие и внедрение профессионального управления проектами стало происходить уже в 90-е годы. К этому времени создаётся рынок ус луг и программных продуктов по управлению проектами, вводится в дей ствие национальная программа подготовки и сертификации менеджеров проекта на основе международных требований и стандартов, начинается применение методов управления проектами в нетрадиционных сферах (социальные и экономические проекты и др.). В конце 1990 г. появляется Советская ассоциация управления проектами (СОВНЕТ).

Развитие методов управления проектами в России, так же как и в других странах, своими корнями уходит в период индустриализации 30-х годов. На сегодняшний день в нашей стране сделаны лишь первые шаги в применении методов управления проектами. Методология и средства управления широко используются во всех сферах целенаправленной и проектно-ориентированной деятельности, в том числе и в государствен ном управлении развитыми странами. Так, например, практически каждый чиновник правительства США использует на своем персональном компь ютере программные средства управления проектами в составе набора стандартных пакетов программ. Эти средства активно применяются не только для управления федеральными проектами и программами, но и для осуществления управленческих функций внутри правительственного ап парата.

Управление проектами сегодня – один из важнейших механизмов рыночной экономики. Во многих развитых странах он используется прак тически на всех проектах. По данным Международной ассоциации управ ления проектами (IPMA), использование современной методологии и ин струментария управления проектами позволяет сэкономить порядка 20 30% времени и около 15-20% средств, затрачиваемых на осуществление проектов и программ. В России же, где организационная система и мето ды управления гораздо слабее, чем на Западе, эффект от внедрения мето дов окажется еще более значительным. В настоящее время управление проектами становится необходимым фактором обеспечения конкурентно го преимущества предприятий.

В России существует целый ряд успешных примеров внедрения ин струментов управления проектами. В первую очередь это высокотехноло гичные компании, такие как: РИА «РосБизнесКонсалтинг» и Integrated Business Systems, холдинг «Ланит» и др. Методы проектного управления были также использованы при реализации двух проектов Росэнергоатома – на строительстве первого блока Ростовской и третьего блока Калининской АЭС, а также в проекте развития судостроения «Адмиралтейская верфь».

Во всех случаях в результате их применения затраты на проекты снижа лись на 25-30% по сравнению с аналогичными.

1.2. Понятие проекта. Субъекты проекта Предприятия производят продукцию, оказывают услуги, выполняют работы. Работы включают различные операции или проекты, которые, тем не менее, имеют общие признаки. Действия и проекты имеют общие чер ты, такие как ограниченные ресурсы, планирование, контроль и т.п.

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

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

1. Разработка нового продукта или оказание новой услуги.

2. Осуществление изменений в структуре, кадрах организации.

3. Разработке новых транспортных средств.

4. Развитие или приобретение новых или модернизирование инфор мационных систем.

5. Строительство зданий или производство оборудования.

6. Прокладка систем водоснабжения для развивающихся территорий.

7. Выполнение кампаний для политических партий.

8. Выполнение новых бизнес процедур или процессов.

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

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

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

Временный характер проектов может применяться и к другим аспек там, например:

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

II. Команда проекта редко переживает сам проект – обычно создает ся команда для выполнения проекта, которая распускается после его за вершения.

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

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

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

Проект строительства может включать тысячи индивидуальных квартир.

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

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

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

Пример 1. Создание химического производства начинается с процес сов инжиниринга, описывающего характеристики процесса. Эти характе ристики используются при разработке наиболее важных производствен ных единиц. Эта информация является основой для разработки, которая описывает как детальную структуру завода, так и механические характе ристики основных производственных процессов и вспомогательных про изводств. Все эти результаты разработки изображаются графически, и по следовательно выполняются производственные (изометрические) черте жи. Во время сооружения, исполнения и адаптации, выполняемых по мере необходимости, происходит утверждение объектов. Дальнейшее выпол нение характеристик фиксируется в технической документации. Во время тестирования дальнейшее развитие характеристик часто происходит в форме окончательной производственной настройки.

Пример 2. Продукт проекта экономического развития может быть изначально описан как: «Улучшение качества жизни низших слоев группы Х». Во время выполнения проекта продукт может быть описан более де тально, например: «Обеспечить пищей и водой 500 наиболее бедных чле нов группы Х». Следующим шагом последовательного выполнения может быть увеличение объема сельскохозяйственного производства и марке тинг, в первую очередь, а обеспечение продовольствием и водой – сопут ствующими задачами.

Таблица 1. Сравнительная характеристика проектов и бизнес-процесса Проект Бизнес-процесс 1. Временный процесс: имеет 1. Непрерывный процесс: постоянно начало и конец повторяются одни и те же действия 2. Одинаковые результаты каждый раз 2. Результат уникален при выполнении задачи 3. Не существует должностных 3. Имеются определенные должностные инструкций инструкции Множество людей либо непосредственно участвуют в проекте, либо претендуют на часть его результатов. Такие люди называются дольщика ми. Основными дольщиками в большинстве проектов являются:

1) лидер (менеджер) проекта – это человек, который возглавляет проект;

2) член команды проекта – тот, кто непосредственно занимается осуществлением проекта, а также принимает участие в процессе управления им;

3) спонсор – это член правления, который выступает в качестве свя зующего звена между правлением компании и лидером проекта;

4) заказчик проекта – человек или группа людей, которые получат конечный продукт проекта. Конечный продукт – это результат проекта, поставляемый заказчику, чьи желания и потребности и были основополагающими в этом проекте;

5) менеджер по ресурсам – также известен как функциональный ме неджер. Это человек, отвечающий за ресурсы, в частности за пер сонал, непосредственно занятый в проекте.

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

Лидер проекта Лидера проекта также называют менеджером проекта. Однако при совместном подходе к управлению проектом его основная роль – лидер ство, поэтому в дальнейшем мы будем говорить о нем как о лидере проек та. Он должен:

задать команде исполнителей направление работы;

руководить командой исполнителей во время процесса управле ния проектом (создания и выполнения плана по проекту);

получить одобрение проектного плана;

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

реагировать на запросы по изменению плана;

способствовать сплочению команды – межличностному процес су, направленному на объединение исполнителей проекта в одну команду;

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

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

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

организовывать и проводить собрания команды;

подготовить заключительный отчет по результатам проекта.

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

Руководитель проекта несет ответственность за успех проекта.

Член команды проекта Член команды проекта является одним из важнейших факторов ус пеха проекта. Член команды должен:

обеспечивать техническую экспертизу;

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

выполнять свою часть работы над проектом вовремя;

сообщать команде о возникающих проблемах;

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

контактировать с поставщиками по своей части проекта;

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

выполнять обязательства по проекту, данные команде;

помогать команде не сойти с правильного пути при воплощении проекта;

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

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

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

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

Спонсор должен:

начать проект, выбрав лидера проекта;

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

обозначить общее направление проекта;

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

заручиться обязательством отдела логистики по поддержке про екта;

проанализировать и утвердить план проекта;

изучать данные по текущему состоянию проекта;

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

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

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

проанализировать и утвердить итоговый отчет.

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

Начинать проект без спонсора очень рискованно.

Заказчик проекта Проект создается для того, чтобы удовлетворить потребности заказ чика. Заказчик проекта – это получатель основного результата проекта, называемого конечным продуктом. Чтобы убедиться в том, что конечный продукт удовлетворит заказчика, последний должен изложить проектной команде свои запросы и требования к продукту. По отношению к органи зации заказчик может быть внутренним и внешним. Большинство проек тов разрабатывается для внутренних заказчиков (заказчиков внутри орга низации), хотя конечный продукт проекта, в конце концов, может быть передан или продан внешнему заказчику.

Предположим, что вы работали над проектом по разработке нового детского кардиомонитора – аппарата для непрерывного наблюдения за со стоянием сердечной деятельности. Заказчиком проекта, возможно, будет ваш маркетинговый отдел, так как в его обязанности входит продажа при бора конечным покупателям – больницам. Пациентов, подключенных к такому прибору, можно считать конечными пользователями кардиомони тора. (Конечный пользователь – это непосредственный потребитель про дукции.) Большинство проектов выполняется для внутренних заказчиков, ко торые затем удовлетворяют нужды потребителей и конечных пользовате лей вне организации. Однако некоторые проекты разрабатываются специ ально для внешнего заказчика. В таких случаях заказчик обычно прямо платит за готовый продукт. Примером такого проекта может служить про граммное обеспечение, разработанное консалтинговой фирмой для внеш него заказчика. Внешний заказчик будет оплачивать работу исходя либо из временных и материальных затрат исполнителя, либо из фиксирован ной платы за проект.

Вне зависимости от того, является ли заказчик внешним или внут ренним, во время работы над проектом он выполняет приблизительно одинаковые функции:

ясно описывает проектной команде свои потребности и запросы;

анализирует и утверждает программу проекта;

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

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

утверждает изменения в проекте, если они требуются для его успешного воплощения;

анализирует отчеты о ходе работ по проекту;

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

оценивает готовую продукцию и весь процесс воплощения про екта.

Внутренние заказчики часто выполняют и дополнительные функции:

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

анализ итогового отчета о состоянии работ.

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

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

Лидеру проекта довольно трудно добиться сотрудничества и преданности от тех, кто не подчиняется непосредственно ему.

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

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

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

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

отвечать за то, чтобы члены проектной команды обладали над лежащими знаниями и квалификацией для выполнения работы;

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

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

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

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

Подготовка проекта Первый этап, подготовка проекта, начинается сразу после того, как руководство компании принимает решение о разработке данного проекта.

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

Завершается первый этап составлением документа, который называ ется программой проекта. Проведение этапа подготовки проекта – это зо на ответственности спонсора, но на самом деле программу проекта в большинстве организаций составляет лидер проекта, а спонсор затем ут верждает ее (табл. 1.2).

Таблица 1. Этап подготовки проекта Этап Описание задачи Результат Подготовка Спонсор должен указать лидеру проекта Программа проекта общее направление работы над проектом. проекта Определяются ограничения, сдерживающие факторы и приоритеты проекта Планирование Следующий этап работы над проектом называется планированием (табл. 1.3). На этом этапе проектная команда разрабатывает план, описы вающий, как и когда будет выполнена работа. Планирование – это наибо лее важный этап проекта, потому что именно сейчас принимаются реше ния о том, кто и чем будет заниматься и как обеспечить эффективную со вместную работу. Если пропустить этап планирования и позволить членам команды делать то, что они сами посчитают нужным, то обязательно бу дут упущены какие-либо важные части проекта. В результате вам придет ся переделывать работу, что довольно дорого и трудоемко и может поста вить проект на грань срыва. Когда вы спланировали работу заранее, то каждый разбирается в проекте в целом и его выполнение протекает более гладко.

Таблица 1. Этап планирования проекта Этап Описание задачи Результат Планирование Подобрать членов команды План проекта Определить масштаб проекта Выявить риски, связанные с проектом, и разработать способы их предотвращения Оценить ресурсы, требующиеся для воплощения проекта Результатом этапа планирования является план проекта, т.е. подроб ный план выполнения работ. Этот документ должны утвердить спонсор, заказчик проекта и менеджеры по ресурсам.

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

Команда также информирует других дольщиков о ходе воплощения про екта. Этот этап завершается передачей конечного продукта заказчику про екта (табл. 1.4).

Таблица 1. Этап воплощения проекта Этап Описание задачи Результат Воплощение Отчеты о состоянии Создание конечного продукта проекта работ Контроль за ходом работ над проектом Конечный продукт Решение проблем Обмен информацией о результатах работ Внесение изменений в план проекта Завершение проекта После того как заказчик принимает конечный продукт, начинается этап завершения проекта. На этом этапе заказчик оценивает степень своей удовлетворенности результатами проекта. Спонсор и команда также оце нивают свою работу. Затем команда обсуждает, чему она научилась за это время, и на этой основе делает выводы по улучшению общей системы управления проектами. Подготавливается заключительный отчет о со стоянии проекта, который включают в итоговый отчет по проекту (иногда называемый отчетом о завершении проекта). Этот отчет отправляют спон сору, заказчику и основным дольщикам проекта (табл. 1.5).

Таблица 1. Этап завершения проекта Этап Описание задачи Результат Завершение проекта Оценка степени Отчет о завершении проекта удовлетворенности заказчика Анализ «уроков», полученных во время воплощения проекта После подготовки отчета о завершении проекта он считается полно стью выполненным. Однако важно помнить, что нужно не только отме чать завершение проекта, но и устраивать небольшие праздники во время его осуществления, после того как ваша команда выполнила что-нибудь важное или сложное. Этапы работы над проектом также можно предста вить в виде блок-схемы последовательных действий, приведенной на рис. 1.1.

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

Этап подготовки проекта Потребность бизнеса Спонсор утверждает Программа проекта: цели и основные программу проекта направления работы Этап планирования План проекта: выявление Команда разрабатывает необходимых ресурсов проектный план Этап воплощения проекта Конечный продукт: заказчик Команда создает конечный продукт принимает конечный продукт Этап завершения проекта Отчет о завершении работы:

Команда делает выводы из усвоенные уроки и рекомендации своей работы по улучшению работы Рис. 1.1. Последовательность этапов проекта Процесс утверждения в конце каждого этапа называют этапными во ротами, т.е. ограничительными требованиями по завершению этапа (рис. 1.2).

Рис. 1.2. «Этапные ворота, рамки, арки, проходы, отверстия»

Одно из преимуществ утверждения результатов в конце каждого этапа состоит в том, что таким образом затраты на проект минимизируют ся, так как издержки по воплощению проекта экспоненциально увеличи ваются по мере того, как вы переходите от этапа подготовки проекта к этапу планирования, а затем к этапу воплощения. Затем на этапе заверше ния проекта затраты значительно уменьшаются. Убеждаясь в том, что вы выполнили все основные поставленные задачи, перед тем, как перейти к следующему этапу, вы не только снижаете затраты, но и избегаете беспо лезной траты бесценного времени (рис. 1.2).

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

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

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

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

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

Но если он рассчитывает на большее, а получит меньшее, то будет разоча рован. В обоих случаях вы передадите ему один и тот же продукт;

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

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

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

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

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

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

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

процессы управления проектами, касающиеся организации и описания работ проекта (которые будут подробно описаны далее);

процессы, ориентированные на продукт – касающиеся специфи кации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения.

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

Группы процессов Процессы управления проектами могут быть разбиты на шесть ос новных групп, реализующих различные функции управления:

процессы инициации – принятие решения о начале выполнения проекта;

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

процессы исполнения – координация людей и других ресурсов для выполнения плана;

процессы анализа – определение соответствия плана и исполне ния проекта поставленным целям и критериям успеха и приня тие решений о необходимости применения корректирующих воздействий;

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

процессы завершения – формализация выполнения проекта и подведение его к упорядоченному финалу.

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

Рис. 1.4. Наложение процессов управления проектами на разных фазах Процессы управления проектами связаны своими результатами – ре зультат выполнения одного становится исходной информацией для другого.

Существуют взаимосвязи групп процессов различных фаз проекта.

Закрытие одной фазы может являться входом для инициации следующей фазы (пример: завершение фазы проектирования требует одобрения заказ чиком проектной документации, которая необходима для начала реализа ции).

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

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

1. Входы – документы или документированные показатели, со гласно которым процесс исполняется.

2. Выходы – документы или документированные показатели, яв ляющиеся результатом процесса.

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

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

Процессы инициации Инициация включает единственный подпроцесс – авторизацию, т.е.

решение начать следующую фазу проекта.

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

Напомним, что следует различать цели проекта и цели продукта про екта, под которым понимается продукция (или услуги), созданная или произведенная в результате исполнения проекта.

Цели продукта – это свойства и функции, которыми должна обла дать продукция проекта.

Цели проекта – это работа, которую нужно выполнить для производ ства продукта с заданными свойствами.

В ходе исполнения проекта эти процессы многократно повторяются.

Изменениям могут подвергнуться цели проекта, его бюджет, ресурсы и т.д. Кроме того, планирование проекта – это не точная наука. Различные команды проекта могут разработать различные планы для одного и того же проекта, а пакеты управления проектами могут составить различные расписания выполнения работ при одних и тех же исходных данных.

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

планирование целей – разработка постановки задачи (проектное обоснование, основные этапы и цели проекта);

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

определение состава операций (работ) проекта – составление перечня операций, из которых состоит выполнение различных этапов проекта;

определение взаимосвязей операций – составление и докумен тирование технологических взаимосвязей между операциями;

оценка длительностей или объемов работ – оценка количества рабочих временных интервалов либо объемов работ, необходи мых для завершения отдельных операций;

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

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

оценка стоимостей – определение составляющих стоимостей операций проекта и оценка этих составляющих для каждой опе рации, ресурса и назначения;

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

оценка бюджета – приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам);

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

определение критериев успеха – разработка критериев оценки исполнения проекта.

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

планирование качества – определение того, какие стандарты ка чества использовать в проекте, и того, как этого достичь;

планирование организации – определение, документирование и назначение ролей, ответственности и взаимоотношений отчет ности в организации;

назначение персонала – назначение человеческих ресурсов на выполнение работ проекта;

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

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

оценка риска – оценка вероятностей наступления событий рис ка, их характеристик и влияния на проект;

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

планирование поставок – определение того, что, как и когда должно быть поставлено;

подготовка условий – выработка требований к поставкам и оп ределение потенциальных поставщиков;

взаимосвязи между вспомогательными подпроцессами;

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

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

Как и в планировании, процессы исполнения можно подразделить на основные и вспомогательные.

К основным можно отнести сам процесс исполнения плана проекта.

К вспомогательным процессам относятся:

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

подтверждение качества – регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам каче ства;

подготовка предложений – сбор рекомендаций, отзывов, предло жений, заявок и т.д.;

выбор поставщиков – оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов;

контроль контрактов – контроль исполнения контрактов постав щиками и подрядчиками;

развитие команды проекта – повышение квалификации участни ков команды проекта.

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

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

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

Процессы анализа также можно подразделить на основные и вспо могательные.

К основным относятся те процессы анализа, которые непосредствен но связаны с целями проекта и показателями, характеризующими успеш ность исполнения проекта:

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

анализ стоимости – определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным;

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

подтверждение целей – процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т.д.).

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

1) оценку исполнения – анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;

2) анализ ресурсов – определение соответствия фактической и про гнозной загрузки и производительности ресурсов запланирован ным, а также анализ соответствия фактического расхода материа лов плановым значениям.

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

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

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

Итак, процессы управления предназначаются для определения, со гласования и внесения необходимых изменений в план проекта. Такие процессы управления часто называются управлением изменениями и ини циируются процессами анализа.

Рис. 1.5. Элементы процессов управления проектами К основным процессам управления, встречающимся практически в каждом проекте, относятся:

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

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

управление целями – корректировка целей проекта по результа там процессов анализа;

управление качеством – разработка мероприятий по устранению причин неудовлетворительного исполнения.

Среди вспомогательных процессов управления отметим:

управление рисками – реагирование на события и изменение рисков в процессе исполнения проекта;

управление контрактами – координацию работы (суб)подрядчиков, корректировку контрактов, разрешение конфликтов.

Процессы завершения Завершение проекта сопровождается следующими процессами:

1. Закрытие контрактов – завершение и закрытие контрактов, включая разрешение всех возникших споров.

2. Административное завершение – подготовка, сбор и распреде ление информации, необходимой для формального завершения проекта.

ТЕМА 2. СТАНДАРТЫ В УПРАВЛЕНИИ ПРОЕКТАМИ 2.1. Основные стандарты управления проектами Стандарт – общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль – набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи.

Классификация стандартов Стандарты можно классифицировать следующим образом:

• по типу установления требований:

устанавливающие требования к объекту;

устанавливающие требования к процессу;

• по масштабу:

международные;

государственные;

отраслевые;

предприятий;

• по степени юридического оформления:

принятые юридически;

действующие фактически.

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

International Organization for Standardization (ISO) – междуна родная организация по стандартизации. В 1947 году представите ли 25 стран решили создать организацию, основной задачей ко торой стала бы координация разработок и унификация между народных стандартов. Новая организация получила название International Organization for Standardization (ISO). Несоответствие полного названия и аббревиатуры объясняется тем, что «ISO» – это греческий префикс, означающий «равный».

International Electrotechnical Commision (IEC) – международ ная электротехническая комиссия.

International Telecommunication Union-Telecommunications (ITU-T) – международный союз по телекоммуникации – теле http://www.citforum.ru/programming/prg96/sukhomlin.shtml коммуникация. До 1993 года эта организация называлась Interna tional Telegraph and Telephone Consultative Committee (ITTCC) – международный консультативный комитет по телефонии и теле графии.

Промышленные профессиональные или административные орга низации.

Institute of Electrical and Electronic Engineers (IEEE) – институт инженеров по электротехнике и электронике.

Internet Activity Board (IAB) – совет управления деятельностью Интернета.

Промышленные консорциумы.

Object Management Group (OMG) – группа управления объек тами. Разрабатывает, в частности, стандарты CORBA, UML, XMI, MOF.

Х/Open – консорциум, организованный группой поставщиков компьютерной техники.

Open Software Foundation (OSF) – фонд открытого программно го обеспечения.

В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган – Joint Technical Committee 1 (JTC1) – объединенный технический комитет 1.

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

Таблица 2. Общие стандарты управления проектами Компоненты содержания РМ и соответствующие стандарты Компоненты Стандарты содержания РМ Основные Дополнительные Стратегический ISO 10006, ICB IPMA, PM ISO Bok uk Ed. ISO 10006, ICB IPMA, PM BS xxx, DIN xxx Инструментальный Bok uk Ed. ISO 10006, ICB IPMA, PM ISO 9004:2000, ISO Bok PMI, PM Bok uk Ed.4, 15288:2000, ISO/IEC TR Операционный HTK COBHET, BS xxx, 15504 SPICE, ISO DIN xxx ISO 15188:2001, ISO 15288:2000, ISO/AVI 22799, Технический ISO/IEC TR 16326:1999, SPICE, ISO/IEC TR SPICE, ISO B настоящее время в мире существует большое количество стандар тов и методологий управления проектами, которые имеют распростране ние как на международном, так и на национальном уровнях.

Стандарты по управлению единичным проектом представлены Ру ководством к своду знаний по управлению проектами – PMBOK (Project Management Body of Knowledge), Руководством по качеству при управле нии проектами (Guidelines to Quality in Project Management) – ISO 10006, Системой знаний о процессах управления проектами – PRINCE (PRojects IN Controlled Environments) и являются наиболее ранней и дос таточно проработанной по структуре и содержанию группой стандартов.

В группе стандартов по управлению портфелями проектов заслужи вает внимания готовящийся к официальному принятию PMI драфт – Portfolio management, основанный на PMBOK и Модели организационной зрелости управления проектами – OPM3.

Среди стандартов, определяющих требования к компетенции менед жера проекта, в качестве основных можно выделить Международные тре бования к компетенции специалистов по управлению проектами (PM ICB), разработанные Международной ассоциацией управления проектами IPMA (Швейцария), а также основанный на них российский стандарт – Нацио нальные требования к компетенции СОВНЕТ (Россия). В рамках данных стандартов профессионализм менеджера проекта определяется четырех уровневой системой оценки. По результатам работы инициативной груп пы Австралийского института управления проектами AIPM совместно с экспертами PMI подготовлены Основы развития компетенции менеджера проекта – PMCDF, согласованные с требованиями PMI к сертификации профессионалов по управлению проектами (PMP).

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

Наиболее известные из них – Модели организационной зрелости управления проектами OPM3 (PMI) и разработанный Ассоциацией инно вационного развития и управления проектами Японии Program and Project Management for Innovation of Enterprises (P2M).

Кроме того, разработано множество национальных стандартов управления проектами, представленных АРМ (Великобритания), VZPM (Швейцария), GPM (Германия), AFITEP (Франция), CEPM (Индия), PROMAT (Южная Корея) и другими. Вот некоторые из наиболее попу лярных национальных стандартов: BS 6079 (British Standards Board, 1996 г.), DIN 69 900 series x-50-100 series (German standards DIN 69 900 to 69 and 69 905), APM BOK (версия. 3.0) (APM Association for Project Managers:

Body of Knowledge, пересм. март 1996 г. (версия 3), High Wycombe, 1996 г.), Australian National Competency Standards for Project Management (AIPM (Sponsor), 1996 г.).

Руководство к своду знаний по управлению проектами (PMBOK) Разработчиком данного руководства является Американский инсти тут управления проектами (PMI – Project Management Institute). PMBoK Guide является американским национальным стандартом управления про ектами, содержащим сумму профессиональных знаний, основанных на лучших практиках (best practices) с использованием навыков, инструмен тов и методов, позволяющих успешно достичь целей проектов в различ ных сферах общественной и бизнес деятельности.

Целью стандарта является:

• унифицировать терминологическое пространство в области управ ления проектами;

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

• использовать данный документ как базовое справочное пособие для сертификации профессионалов по управлению проектами – РМР (Project Management Professionals);

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

Это единственный на сегодняшний день стандарт в области управ ления проектами, который полностью соответствует ISO 9001:2000. Кроме того, он имеет весьма широкое международное распространение.

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

В стандарте описаны разные жизненные циклы проекта и организа ционные структуры исполняющей организации, определены группы про цессов (инициирования, планирования, исполнения, контроля, заверше ния) и их взаимодействие между собой, выделены основные и поддержи вающие процессы, определены девять областей знаний (управление инте грацией, замыслом, временем, стоимостью, качеством, человеческими ре сурсами, коммуникациями, рисками, контрактами и поставками). Стан дарт базируется на процессном подходе. Для каждой области знаний определены входы, выходы и процедуры преобразования (tools and techniques) входных данных в выходные. Полностью определены взаимо действия между всеми процессами, которые включены в области знаний управления проектами.

В настоящее время PMI пошел по пути специализации и расширил PMBoK, выделив в нем следующие области:

• управление проектами со стороны правительств – Government extension to PMBoK;

• управление проектами в строительстве – Construction extension to PMBoK;

• управление стоимостью – Practice Standard for Earned Value Management;

• построение структур декомпозиции работ – Practice Standard for Work Breakdown Structures и др.

С 1999 года PMI PMBoK является национальным стандартом США как «Глоссарий терминов и сокращений» в области PM. Третья редакция PMBoK Guide, датированная 2000 годом, подтверждена в качестве стан дарта ANSI в марте 2001 года. Популярность PMBoK PMI объясняется простотой представления части знаний PM в процессном виде и активной политикой PMI по распространению своего подхода за пределами США.



Pages:   || 2 |
 




 
2013 www.netess.ru - «Бесплатная библиотека авторефератов кандидатских и докторских диссертаций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.