Максим Якубович

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

Что стоит за модой на управление проектами?

Введение

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

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

Что такое проект? Что такое управление проектом? Чем оно отличается от управления процессами? Каким объектом эффективно управлять с использованием методик Project management? Эти вопросы, наверное, мучают не одного управляющего и собственника компании. Попробуем изложить свои мысли в статье.

Процессы и проекты

В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) издания 2004 года - стандарте управления проектами de facto - проект определяется как «временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов».

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

В ИСО 9000:2000 приводится следующее определение процесса:

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

В том же стандарте дается определение проекта:

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

Это определение близко по смыслу к определению из PMBok, но вводит в заблуждение: проект – это процесс?

Чем же тогда отличается «проект» от «процесса», а «управление проектами» от «процессного подхода к управлению»?

Выясним, какие общие характеристики есть у процесса и проекта.
1. И проект, и процесс состоят из работ
2. Оба они выполняются людьми
3. Они имеют ограничения по срокам, стоимости и ресурсам
4. Они планируются, исполняются и контролируются

Отличия заключаются в том, что:
1. Проект имеет уникальную структуру работ, которая создается только на время выполнения проекта, а структура работ процесса, как правило, не меняется при его итерациях.
2. В некоторых проектах цели проекта по мере его развития уточняются.
3. Характеристики продукта проекта определяются по мере развития проекта.

Примеры:
1) строительство объекта (здания, промышленной установки) начинается задолго до завершения разработки проектно-строительной документации; окончательные характеристики строящегося объекта уточняются уже в ходе строительства.
2) одна из современных технологий разработки программного обеспечения под названием XP (Extremal Programming) строится на концепции постепенного уточнения характеристик продукта по мере написания программного кода.
3) статистика проектов разработки программного обеспечения гласит, что одним из пяти наиболее существенных рисков, повлиявших на срыв сроков окончания проекта, является раздувание требований к продукту по мере исполнения работ проекта.

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

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

Таблица 1 – Области знаний при управлении проектами и процессами
Области знаний в управлении процессами Области знаний в управлении проектами

Управление конфигурацией Управление содержанием проекта

Управление закупками Управление поставками проекта

Управление расписанием процесса Управление сроками проекта

Управление стоимостью процесса Управление стоимостью проекта

Управление качеством процесса Управление качеством проекта

Управление человеческими ресурсами процесса Управление человеческими ресурсами проекта

Управление коммуникациями проекта

Управление рисками проекта

Управление интеграцией проекта

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

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

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

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

Отличие циклов управления в проектах и процессах

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

В PMBok выделают пять групп процессов:
Группа процессов инициации.
Группа процессов планирования.
Группа процессов исполнения.
Группа процессов мониторинга и контроля.
Группа завершающих процессов.

Что значит «управлять проектом»?

Управлять проектом – значит прилагать знания, навыки, инструменты и методы к объекту управления для удовлетворения требований, предъявляемых Заказчиком к проекту. Выполняется управление проектом с помощью реализации процессов управления проектами. В PMBoK при рассмотрении управления проектом как системы используется процессный подход. Важно понимать, что процессы управления проектом (условимся называть их «управленческими процессами») отличаются от работ по созданию продукта проекта (назовем их «рабочими процессами»). Результатами управленческих процессов являются воздействия на рабочие процессы с целью получения совокупного результата проекта.

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

Всякой ли уникальной работой надо управлять как проектом?

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

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

Стоит ли управлять выполнением этой работы как проектом?

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

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

Договоренность оформляется установлением признаков проекта.

Например, в составе Стандарта предприятия по управлению проектами будет содержаться документ «Критерии отнесения работ к проектам», в котором будет написано, что всеми работами, подпадающими под определение проекта, стоимостью более 1000 долларов и длительностью более трех недель, в нашей компании управляют как проектами.

Допустим, сотрудник медиа-компании, ответственный за создание рекламного ролика, озадачен вопросом: данной работой ему следует управлять как проектом или как процессом?

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

Но даже в такой ситуации может возникнуть вопрос: а есть ли в составе документов компании четкое описание процесса создания ролика в виде процедуры?

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

Что такое КСУП и необходимость ее создания

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

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

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

Корпоративная система управления проектами КСУП объединяет в себе две взаимосвязанные подсистемы: регламентирующую (Стандарт предприятия по управлению проектами) и информационную (часто ее называют ИСУП – информационная система управления проектами).

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

Стандарт предприятия по управлению проектами основывается, как правило, на сводах знаний («рамочных» руководствах) и стандартах по управлению проектами. К таким документам относится, в частности, Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge Guide (PMBoK Guide)) Американского института управления проектами (PMI), признаваемый многими как стандарт де-факто, и стандарт ISO 10006:1997, не противоречащий PMBoK и даже придавший наиболее важным положениям PMBoK статус стандарта де-юре.

Фактически Стандарт предприятия по управлению проектами состоит из совокупности документов: Политики, процедур, инструкций и шаблонов документов

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

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

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

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

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

Спроектировать данную модель можно, к примеру, на базе процессов, описанных в PMBok, и с использованием нотации описания процессов IDEF0. Для автоматизации работы по разработке модели эффективно использовать case-средства, такие, например, как BPWin (англоязычный продукт) или IDEF0.EMTool (интерфейс продукта на русском языке). Что дает модель процессов управления проектом для менеджера?

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

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

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

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

Заключение

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

Литература:

1. ГОСТ Р ИСО 9000-2001 «Системы менеджмента качества. Основные положения и словарь».
2. Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения. Том ДеМарко, Тимоти Листер, Издательство p.m.Office, 2005 г.
3.Мозг Фирмы. Стэффорд Бир. Перевод с английского проф. М. М. Лопухина. http://www.qm-s.com/pub.php?pub=4
4. Руководство к своду знаний по управлению проектами (PMBOK Guide 2000) Издательство: Project Management Institute, 2005 г. Мягкая обложка, 240 стр.

дата: 00.00.0000 00:00:00 просмотров: 2848

рейтинг:

(Нет голосов)