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

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

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

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

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

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

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

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

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

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

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

ИЗДАТЕЛЬСТВО

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

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

ББК 65.050. У Управление проектами : учебное пособие / М.В. Тихонова У 66 [и др.]. – СПб. : Изд-во СПбГУЭФ, 2012. – 83 с.

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

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

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

ББК 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 Management 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времени и около 15-20% средств, затрачиваемых на осуществление проектов и программ. В России же, где организационная система и методы управления гораздо слабее, чем на Западе, эффект от внедрения методов окажется еще более значительным. В настоящее время управление проектами становится необходимым фактором обеспечения конкурентного преимущества предприятий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

class='zagtext'> ТЕМА 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 года эта организация называлась International Telegraph and Telephone Consultative Committee (ITTCC) – международный консультативный комитет по телефонии и телеграфии.

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

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

Internet Activity Board (IAB) – совет управления деятельностью Промышленные консорциумы.

Object Management Group (OMG) – группа управления объектами. Разрабатывает, в частности, стандарты CORBA, UML, XMI, Х/Open – консорциум, организованный группой поставщиков компьютерной техники.

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

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

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

Компоненты содержания РМ и соответствующие стандарты Компоненты содержания РМ Стратегический ISO 10006, ICB IPMA, PM ISO Инструментальный Операционный Технический ISO/IEC TR 16326:1999, 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 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 г.).

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

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

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

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

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

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

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

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

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

• управление проектами со стороны правительств – Government • управление проектами в строительстве – Construction extension to • управление стоимостью – Practice Standard for Earned Value • построение структур декомпозиции работ – Practice Standard for Work Breakdown Structures и др.

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

Многие специалисты используют этот стандарт в качестве основы для своей деятельности и потому искренне считают его де-факто международным. Однако, как отмечают разработчики PMBoK, «ни один документ не может вместить в себя всю сумму знаний». Методическая простота PMBoK PMI достигнута за счет описания упрощенной модели PM в процессном виде, которая используется для управления одним обособленным проектом. То, что трудно или невозможно представить в виде процессов (например, стратегический менеджмент проектов, мультипроектное управление и многое другое), в этом документе должного отражения не нашло.

Во второй половине 1980-х гг. анализ накопленного обширного материала о многочисленных неудачах реализации тысяч проектов стран ЕС и США поставил под сомнение первоначально завышенные ожидания относительно возможностей управления проектами и попытку выявить корни возникающих перед проектно-ориентированными организациями проблем. Обращение к вопросам эффективности управления выявило острую потребность в разработке системы управления качеством проекта.

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

Порожденный многочисленными проблемами обеспечения качественного выполнения процессов проекта настоящий стандарт является первым (и основополагающим) из стандартов рассматриваемого профиля, где основной упор был сделан на процессы. В нем процессы по проекту сгруппированы в две категории: процессы управления проектом и процессы, связанные с продуктом проекта (то есть те процессы, которые касаются исключительно продукта проекта, такие как проектирование, производство, проверка). Описанию последних посвящен отдельный стандарт ISO 9004-1. ISO 10006 представлен десятью группами процессов управления проектом. Первая группа представляет процесс разработки стратегии, который фокусирует проект на удовлетворение потребностей заказчика и определяет направление хода работ проекта. Вторая группа охватывает управление взаимосвязями процессов. Остальные восемь групп – это процессы, связанные с проектным заданием, сроками, затратами, ресурсами, кадрами, информационными потоками, риском и материально-техническим снабжением (закупками).

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

Стандарт заимствует ключевые определения из ISO 8402, включая такие термины, как проект, продукт проекта, план проекта, участник проекта, процесс, оценка хода работ. Для всех процессов управления проектом (планирование, организация, мониторинг и контроль) применяются процессы и задачи менеджмента качества.

В большой мере стандарт по содержанию основан на PMBoK 1996, совпадение имеется вплоть до названий областей знаний управления проектами. Это первый из стандартов ISO серии 9000, в котором применен процессный подход.

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

Рис. 2.2. Профессиональные международные и национальные Компетентность менеджеров проектов и специалистов в области PM определяется следующими компонентами (рис. 2.3):

профессиональный образ мышления;

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

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

Рис. 2.3. Компоненты профессиональной компетентности менеджеров проектов и их нормирование посредством стандартов Определение профессиональной компетентности происходит посредством сертификационных испытаний и в разных странах проводится по-разному. Например, международная сертификация IPMA предусматривает 4 уровня компетентности и проводится асессорами, уполномоченными IPMA. Процедура испытаний длится от одного до трех дней, в зависимости от уровня притязаний кандидата, и предусматривает его обязательное личное участие. Таким же образом выстраиваются системы сертификации в странах, принявших стандарт IPMA в качестве базового. В Австралии AIPM предусматривает 7 уровней компетентности, и оценка проводится в несколько этапов. PMI (США) предусматривает один уровень компетентности, а экзамен проводится в течение нескольких часов одного дня. С 2000 года сертификационные испытания не требуют личного присутствия кандидата и осуществляются посредством дистанционной сдачи экзаменов через Интернет в уполномоченной организации. Для допуска к экзамену надо пройти отбор на основании отправленных ранее документов; основной критерий отбора – наличие достаточного опыта профессиональной деятельности по PM.

Ни одна из систем сертификационных испытаний не свободна от недостатков. Главное же их различие заключается в концептуальном подходе к проекту. При преобладании процессного подхода наиболее адекватная модель PMI, при главенстве системного подхода, – модель AIPM, если же в основу положен «менеджерский» подход, целесообразно использование модели IPMA, APM, GPM и др.

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

Требования к знаниям определяются «Сводами знаний» (Body of Knowledge). Они образуют систему требований к знаниям, опыту, мастерству менеджеров проектов и специалистов по PM. Своды знаний поддерживаются и развиваются международными и национальными профессиональными ассоциациями. В настоящее время ассоциации более чем в 20 странах имеют официальные национальные Body of Knowledge on Project Management (PMBoK) и национальные системы сертификации. Эти Своды знаний представлены в виде национальных систем требований к профессиональной компетентности или национальных стандартов по отдельным вопросам PM.

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

Ряд не входящих в IPMA стран (в том числе США, Австралия и Япония) имеет собственные Своды знаний и системы сертификации.

International Competence Baseline (ICB) – официальный международный Свод знаний в области PM, который поддерживается и развивается IPMA. Для 32 стран-членов IPMA он является основой для разработки национальных Сводов знаний; в настоящее время утвержденные национальные Своды знаний, соответствующие ICB, имеют 16 стран.

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

ICB издан на английском, немецком и французском языках. Основой для него послужило несколько национальных разработок: Body of Knowledge of APM (Великобритания); Beurteilungsstruktur, VZPM (Швейцария); PM-Kanon, PM-ZERT/GPM (Германия); Criteres d’analyse, AFITEP (Франция).

Каждая входящая в IPMA национальная ассоциация ответственна за разработку и утверждение собственных Национальных требований по компетентности (National Competence Baseline – NCB) со ссылкой на ICB и в соответствии с ним, а также с учетом национальных особенностей и культуры. Национальные требования оцениваются специальным Комитетом IPMA на соответствие ICB и основным критериям сертификации согласно стандарту EN 45013.

ICB служит основой для разработки и использования в качестве национальных систем требований и стандартов национальных Сводов знаний в странах, которые входят в IPMA. Национальные Своды знаний и процедуры сертификации имеются и в ряде стран, не являющихся членами IPMA, в частности, в США, Австралии, Южной Корее и в некоторых других странах. Из национальных стандартов наиболее распространенным документом в области PM, используемым специалистами многих стран, является PMI PMBoK Guide.

Стандарты управления проектами разработки Об управлении проектами в области разработки программного обеспечения прямо или косвенно говорят стандарты:

• ISO 12207 в части определения процессов жизненного цикла и их характеристик;

• серия стандартов ISO 9000:2000 в части управления качеством • группа стандартов CMM/CMMI в части определения уровня зрелости организации-разработчика в отношении способности разработки качественного программного обеспечения;

• ISO/IEC15504 (SPICE) в части самооценки организации-разработчика.

Рис. 2.4. Использование сетевых технологий в PM Стандарт ISO Стандарт ISO 12207 в России принят как ГОСТ Р ИСО/МЭК 12207-99.

Он разработан Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России; принят и введен в действие постановлением Госстандарта России от 23 декабря 1999 г.

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

Стандарт определяет процессы, работы и задачи, которые используются:

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

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

Серия стандартов ISO 9000:2000 устанавливает общие требования к системе менеджмента качества любой организации, желающей продемонстрировать свою способность стабильно давать продукцию, отвечающую требованиям потребителя и соответствующим нормативным требованиям и способствующую повышению степени удовлетворенности потребителя.

Стандарт основан на трех основополагающих идеях:

• ориентация на потребителя;

• процессный подход;

• постоянное улучшение.

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

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

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

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

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

Группа стандартов CMM/CMMI была создана SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона.

Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г. Основная идея стандарта состоит в использования модели CMM (Capability Maturity Model – модель зрелости возможностей) для приписывания каждой организации определенного уровня, с тем, чтобы организации можно было бы сравнивать по уровням. Список уровней приведен в таблице 2.1.

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

Определенный Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса Управляемый Менеджмент качества ПО. Управление процессом на Оптимизируемый Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов Деление на уровни позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки. Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (таблица 2.2).

System Engineering CMM (SE-CMM) Ориентирован на вопросы системного печивает безопасный процесс разработки, в том числе и безопасность членов команды создателей Software Acquisition CMM Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПО. Эти стандарты не были хорошо согласованы между собой – одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались.

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель зрелости возможностей. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Pages:     |

1

| 2 |