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

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

М. Якубович

Для того чтобы оставаться на месте, нужно очень быстро бежать

Развитие любой бизнес-системы происходит примерно также как и развитие человека: через определенные стадии. Об этом писали гуру менеджмента, такие как Адизес, Грейнер и другие. Однако, в отличие от развития человека, рост бизнес-системы контролируем и зависит от людей, управляющих системой. У владельцев бизнеса есть выбор: можно перестать расти (занять определенную нишу рынка и «заморозиться»: перестать нанимать персонал, наращивать объемы продаж), а можно продолжать рост бизнес-системы (диверсифицировать бизнес, создавать Холдинги и альянсы).
В случае выбора стратегии роста управляющие бизнесом неизбежно столкнутся с необходимостью изменений. Изменения коснутся как минимум организационной структуры бизнес-системы и ее процессов.
Даже если управляющие бизнесом выбрали стратегию нишевого игрока, изменять бизнес-систему им придется. Потому что, как говорила Алиса из страны чудес: «Для того чтобы оставаться на месте, нужно очень быстро бежать».
Большинство бизнес-систем функционируют в динамичной среде. Под «динамизмом внешней среды» мы понимаем огромное количество возможных воздействий на бизнес-систему со стороны внешних по отношению к ней систем, предсказать вероятность и время возникновения которых достаточно сложно. И функционирование в такой среде предполагает необходимость обладать инструментами, позволяющими реагировать на воздействия внешней среды.
Одним из таких инструментов является «управление проектами».
Те из читателей, кто знаком с концепцией сбалансированной системы показателей (ССП), наверное уже отмечали для себя, что связка стратегии с оперативным контуром управления производится через связь стратегических целей и стратегических мероприятий. Так вот, большинство стратегических мероприятий – это проекты.

Рисунок 1 – Концепция сбалансированной системы показателей

В каких отраслях бизнеса использование «управления проектами» принесет наибольший эффект?
Все бизнес-системы можно условно классифицировать на проектно-ориентированные и процессно-ориентированные. Проектно-ориентированные компании – те, в которых управление основным жизненным циклом продукта или услуги осуществляется как проектом.
Считается, что «управление проектами» эффективно используется в таких проектно-ориентированных сферах бизнеса, как разработка программного обеспечения, строительство, медиа-бизнес, НИОКР. Однако, как Вы уже понимаете, управление проектами – это инструмент реализации стратегических инициатив (мероприятий по реализации стратегии), а, значит, его использование может быть эффективно во всех отраслях бизнеса. Более того, некоторые гуру управления проектами выдвинули гипотезу о том, что внедрение управления проектами в неспецифичных для этой дисциплины отраслях (таких как торговля, например) даст еще больший эффект, ибо в сфере разработки программного обеспечения, строительстве, многие инструменты и методы управления проектами уже использовались, а в других отраслях бизнеса при реализации крупномасштабных мероприятий царит беспорядок.
На рисунке 2 приведена матрица применения управления проектами.

Рисунок 2 – Применение управления проектами в различных бизнес-системах

Реализация стратегии осуществляется не только благодаря проектам: ведь и в оперативном контуре бизнес-системы деятельность направлена на достижение стратегических целей. Но, как правило, достижение амбициозных целей требует значительных ресурсов и сопряжено с уникальными задачами, поэтому управление проектами выступает как основной инструмент реализации стратегии.
Процессы и проекты
В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) издания 2004 года - стандарте управления проектами de facto - проект определяется как «временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов».
Под «временным предприятием» – в данном случае имеется в виду ограниченное во времени мероприятие, имеющее четкую дату начала и окончания работ. Определение термина «уникальный» в «Новом словаре русского языка» - «единственный в своем роде, неповторимый, редкий, исключительный». Перефразируем определение из PMBok и получим: проект – это мероприятие, имеющее четкую дату начала и окончания, предназначенное для достижения установленных целей и получения уникальных результатов, определенных требованиями заказчика.
Как нам кажется, из этого определения не совсем понятно, все ли мероприятия считать проектами.
В ИСО 9000:2000 приводится следующее определение процесса:
Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы. [1]
В этом же стандарте приводится определение проекта:
Проект – уникальный процесс, состоящий из совокупности скоординированной и управляемой деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включающий ограничения сроков, стоимости и ресурсов. [1]
Это определение термина «проект» близко по смыслу к определению из PMBok, однако в определении проекта фигурирует термин процесс. Чем же тогда отличается «проект» от «процесса», а «управление проектами» от «процессного подхода к управлению»?
1. И проект, и процесс состоят из работ
2. Они выполняются людьми
3. Они имеют ограничения по срокам, стоимости и ресурсам
4. Они планируются, исполняются и контролируются
Отличия заключаются в том, что:
1. Проект имеет уникальную структуру работ, которая создается только на время выполнения проекта, а структура работ процесса, как правило, не меняется при его итерациях.
2. В некоторых проектах цели проекта по мере его развития уточняются.
3. Характеристики продукции проекта определяются по мере развития проекта.
Примеры, демонстрирующие отличия:
1) строительство объекта (здания, промышленной установки) начинается задолго до завершения разработки проектно-строительной документации; окончательные характеристики строящегося объекта уточняются уже в ходе строительства.
2) одна из современных технологий разработки программного обеспечения под названием XP (Extremal Programming) строится на концепции постепенного уточнения характеристик продукта по мере написания программного кода.
3) статистика проектов разработки программного обеспечения гласит, что одним из пяти наиболее существенных рисков, повлиявших на срыв сроков окончания проекта, является раздувание требований к продукту по мере исполнения работ проекта. [2]
В принципе, основные отличия проекта от процесса сводятся к тому, что структура работ проекта претерпевает те или иные изменения по ходу самого проекта. Необходимость уточнения структуры работ по ходу выполнения проекта предъявляет особые требования к системе управления проектами.
В следующей таблице представлены области знаний, применяемые для управления процессами и проектами.

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

Области знаний в управлении процессами Области знаний в управлении проектами Управление конфигурацией Управление содержанием проекта
Управление закупками Управление поставками проекта Управление расписанием процесса Управление сроками проекта Управление стоимостью процесса Управление стоимостью проекта Управление качеством процесса
Управление качеством проекта
Управление человеческими ресурсами процесса
Управление человеческими ресурсами проекта

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

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

Управление интеграцией проекта
В кибернетике известен закон Эшби, гласящий о том, что только разнообразие может справиться с разнообразием. Под разнообразием в кибернетике понимается число различаемых объектов или различаемых состояний объекта. Существенным следствием закона Эшби является то, что разнообразие на входе системы должно (по крайней мере) соответствовать разнообразию на выходе для системы в целом. «Это существенно важное следствие закона Эшби о разнообразии систем, которое гласит, что управление может быть обеспечено только в том случае, если разнообразие средств управляющего (в данном случае всей системы управления) по крайней мере не меньше, чем разнообразие управляемой им ситуации.» [3]
Проект как система находится в гораздо более динамичной внешней среде, что обусловлено его уникальностью, а потому, исходя из следствия закона Эшби, характеризуется гораздо большим числом объектов управления или их состояний. То есть проект, в отличие от процесса, гораздо более непредсказуем. Это и вынуждает использовать при управлении проектами большее количество методов и инструментов нежели при управлении процессами.
Итак, ответ на вопрос о том, для каких работ целесообразно использовать управление проектами очевиден: управление проектами эффективно использовать для управления уникальными работами или работами, требования к результатам которых могут часто изменяться или уточняться под воздействием динамичной внешней среды.

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

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

Рисунок 3 – Проектный треугольник

Всякой ли уникальной работой надо управлять как проектом?
До того момента пока все руководители компании не имеют четких правил, по которым они смогут определить что есть «проект», а что «процесс», неразбериха будет сохраняться и эффективность управления бизнес-системой будет от этого страдать.
Часто в практике бизнеса возникают ситуации, когда есть некоторая работа, которая имеет внешние признаки проекта, но ее длительность составляет примерно неделю-две, в составе рабочей группы - сотрудники одного отдела, а стоимость работы не превышает, допустим, трех тысяч долларов. Управление этой работой как проектом, предполагает разработку ряда документов, полезность которых при управлении работой может быть небольшой. Стоит ли управлять выполнением этой работы как проектом?
Для того, чтобы уменьшить внутри компании неопределенность относительно того, что есть проект, а что процесс, руководителям компании следует раз и навсегда договориться об этом. Договоренность оформляется установлением признаков проекта. Например, в составе Стандарта предприятия по управлению проектами будет содержаться документ, в котором будет написано, что всеми работами, подпадающими под определение проекта, стоимостью более 3000 долларов, длительностью более месяца и с составом участников более двух человек из разных отделов, в компании управляют как проектами.
Наличие подобной записи не исключает внештатных ситуаций, однако, предотвращает потери времени на принятие решения «проект – не проект».
Основные инструменты и методы управления проектами
Итак, сталкиваясь с проблемой, которую ранее в компании с функциональной структурой (жесткая иерархия, выделенная по принципу специализации) не решали (например, открытие филиала, внедрение системы автоматизации и т.п.), руководство такой компании имеет как минимум два варианта.
Первый - решение этой проблемы надо поставить как задачу руководителю одного из функциональных подразделений. Второй - решать проблему в рабочей группе из специалистов разных отделов. Если задача не требует компетенций сотрудников из разных функциональных областей, то ее решит руководитель того отдела, к чьей специализации относится данная задача. Если же задача требует взаимодействия специалистов нескольких специальностей, подчиненных руководителям разных отделов, находящихся на одном уровне иерархии, то ее лучше решать в рабочей группе.
Скорее всего, при данном варианте для работы рабочей группе потребуются несколько другие инструменты управления, нежели те, которые использовали в рамках функциональной структуры руководители отделов.
Почему? Во-первых, рабочая группа создается на время, только для решения данной задачи, а после ее решения должна быть расформирована. В рабочей группе будут работать сотрудники разных специализаций и координировать их деятельность сложнее, нежели специалистов своего отдела. Во-вторых, нужны инструменты, позволяющие сформулировать проблему, которая стоит перед рабочей группой, найти альтернативы решения проблемы, превратить выбранную альтернативу в мероприятие с четкими сроками реализации и бюджетом, декомпозировать мероприятие на составные части и т.д. В-третьих, в ходе работы рабочей группы, возможно, будут часто изменяться требования к результатам работы (если они вообще есть), уточняться цели, либо высшее руководство будет менять сроки или бюджет, выделенный на получение результатов. И для управления этими изменениями рабочей группе тоже нужны новые инструменты управления.
Для решения уникальной задачи нам, прежде всего, надо открыть проект, назначить руководителя проекта и поручить ему сформировать рабочую группу.
Для того, чтобы придать официальный статус проекту, как мероприятию, имеющему целью решение некоторой задачи, многие компании используют документ «Устав проекта». В Уставе проекта обычно описываются цели проекта, результаты, которые должны быть получены по окончанию проекта, требования к результатам, ограничения по срокам реализации проекта и бюджету. После утверждения Устава проекта руководитель проекта официально утверждается в своей роли (некоторые компании еще издают Приказ о старте проекта) и начинает формирование рабочей группы.
По одной из теорий, жизненный цикл команды (а по сути рабочая группа – это команда) выглядит так:
1. Формирование
2. Срабатывание
3. Нормализация
4. Нормальное функционирование
5. Реорганизация
6. Расформирование
Стадия формирования — это стадия изучения, характеризующаяся периодом нервического возбуждения. Люди будут задавать вопросы: “Чего от меня ожидают?”, “Подойду ли я?”, “Что мне предстоит делать?” и “Каковы правила игры?”.
Руководителю проекта нужно сделать следующие шаги:
• помочь членам команды познакомиться друг с другом;
• дать команде четкое направление и ясную цель;
• вовлечь членов команды в разработку планов, уточнение ролей и определение способов совместной работы;
• предоставить команде информацию, необходимую для начала работы
На стадии срабатывания возникает впечатление, что дела идут все хуже и хуже. Члены группы теряют терпение из-за отсутствия успехов и стремятся работать, но не знают, как добиться результатов. Команда борется за определение своей миссии, своих целей, ролей, исполняемых членами команды, и соглашений относительно того, как совместно работать.
Чтобы успешно преодолеть эту стадию, руководителю проекта следует:
• решить вопросы власти и полномочий;
• разработать и реализовать соглашения о порядке принятия решений и о том, кто принимает решения;
• изучить сильные и слабые стороны каждого члена команды
• поощрять членов команды принимать на себя все большую ответственность и новые обязательства.
На стадии нормирования команда вырабатывает некоторые основные правила (или нормы), регулирующие совместную работу. Возникает чувство коллективной общности, выражаемое понятием “мы”, люди начинают сотрудничать, открываются каналы общения, крепнет доверие. Для того чтобы провести команду через стадию нормализации, руководителю проекта следует:
• в полной мере использовать навыки, знания и опыт членов команды;
• поощрять людей уважать друг друга и отвечать уважением на уважение;
• призывать людей засучить рукава и сотрудничать.
Стадия нормального функционирования характеризуется тем, что команда обретает уверенность в своих возможностях. Люди достигают согласия в вопросах о том, что такое команда и чего она пытается достичь, члены команды свободно и продуктивно обмениваются информацией и мнениями, конфликты направляются в конструктивное русло, а проблемы, связанные с работой, решаются творчески. Команда начинает гордиться своими достижениями.
На этой стадии руководителю проекта предлагается следующее:
• помочь команде понять способы управления изменениями;
• выступать представителем и защитником команды в отношениях с другими группами и посторонними людьми;
• отслеживать ход работы и отмечать успехи.
На стадии расформирования уровни мотивирования членов группы могут снижаться по мере того как приближается момент получения результата: ведь группа сработалась и многим понравилось работать в этой группе, решая новую для себя задачу. А сейчас придется снова вернуться к своим обязанностям и лишь в курилке вспоминать о былых совместных подвигах. Но ведь это подходящий момент для того, чтобы начать реализацию новых сложных задач и возобновить стадию формирования в развитии группы!
На этапе старта проекта руководителю очень важно учесть роли, которые, как считается, должны выполняться в эффективной рабочей группе. О ролях в команде проекта можно почитать в книге М. Белбина. Кроме того, важно подобрать на каждую роль человека, с соответствующим психотипом. А в этом руководителю проекта поможет, например, методика типирования MBTI.
Параллельно с формированием группы руководителю проекта нужно рассчитать для высшего руководства сроки решения задачи и бюджет. Но до этого очень важно определиться с продуктами (результатами) проекта и требованиями к ним. Для этого руководитель рабочей группы должен уточнить у высшего руководства, кто является Заказчиком проекта, который будет принимать продукты проекта. Именно Заказчик проекта должен предъявлять требования к продуктам проекта, а задача руководителя проекта - собрать и проанализировать требования к продуктам проекта. И вот тут, по опыту, начинаются самые серьезные сложности. Как сказал собственник одной компании: «В нашей компании очень серьезная проблема с тем, что внутренний Заказчик не адекватен и не может грамотно сформулировать требования к продуктам проекта». А ведь от полноты требований к продуктам проекта зависит то, сколько раз его придется переделывать по ходу проекта. Вот и приходится руководителю проекта находить баланс между сбором подробных требований и временем, затрачиваемым на эту задачу. В моей практике нередки случаи, когда руководителю проекта приходилось разрабатывать требования к продуктам проекта за Заказчика, а потом согласовывать с ним.
Итак, первое, что надо сделать после подписания Устава проекта, оформить содержание проекта в виде документа Техническое задание, Требования или что-то подобное.
После того, как требования согласованы, начинаем разрабатывать содержание проекта в виде иерархии работ для создания продуктов проекта. Некоторые неопытные руководители проекта пропускают этот этап по разным причинам, но я не рекомендую Вам делать это. В разработке структуры работ проекта будет полезно использовать такой метод как создание Иерархической структуры работ (ИСР, или в английской терминологии WBS). Назначение ИСР – очертить рамки проекта и не забыть какую -либо работу. Потому что любая, не учтенная в плане работ работа, – это дополнительные сроки на ее реализацию и дополнительные затраты для проекта.

Рисунок 4 – ИСР проекта

Далее, все работы нижнего уровня ИСР объединяются в сетевой график. Для каждой операции сетевого графика устанавливается длительность, операции-предшественники (кроме стартующей операции, у нее предшественника нет) и операции-последователи (кроме финиширующей операции, у нее последователя нет). Используя еще один метод управления проектами – метод критического пути, можно рассчитать длительность всего проекта, резервы по времени для каждой операции и критический путь, на котором лежат операции, не имеющие резерва. Что это дает руководителю проекта? Во-первых, более-менее реалистичные сроки реализации всех работ по проекту, во-вторых, сфокусированность на операциях критического пути, в-третьих – модель сроков проекта, на которой можно проигрывать сценарии типа: «а что, если исполнитель сорвет сроки операции Х, что будет с длительностью всего проекта»?

Рисунок 5 - Сетевой график проекта

Но, сроки проекта, полученные с учетом только параметра длительности операций, могут быть неточными, т.к. не учитывается загрузка ресурсов на проекте. Поэтому руководитель проекта должен назначить исполнителей на каждую задачу, установить загрузку исполнителей, проверить – не возникает ли перегрузок ресурсов, и в случае возникновения перегрузок – выровнять загрузку ресурсов, при этом пересчитать параметры сетевого графика. В решении этой трудоемкой задачи может помочь специализированное ПО типа MS Project.
Следующая задача – определение бюджета проекта. В простейшем случае, стоимость проекта рассчитывается как стоимость всех работ, из которых состоит проект. В продвинутых компаниях к стоимости работ проекта прибавляют бюджет на управление идентифицированными рисками проекта (иногда еще и бюджет на непредвиденные риски) и получают совокупный бюджет проекта.
Итак, после проделанной работы руководитель проекта может заявлять высшему руководству сроки и бюджет решения задачи.
Бывает так что в этот момент проект, для которого высшее руководство получило представление о сроках и стоимости, может быть остановлен: слишком долго ждать результатов или слишком дорого они обойдутся компании. Но это решение обосновано, а не основано на интуиции или сборе мнений. И иногда лучше потратить время на расчет сроков и бюджета проекта, чем начать проект, а потом, вложив в него огромные деньги, понять, что продукт проекта уже никому не нужен.
Но если проект все же решили отпустить на стадию реализации, то не сомневайтесь: обязательно по ходу проекта возникнут уточнения в требованиях, либо желание сократить сроки или выстрелят неучтенные риски, которые повлияют на сроки и стоимость работ.
Для внесения в проект изменений должна быть разработана система управления изменениями, которая в простейшем случае состоит из:
1. Правил внесения изменений в проект (процедуры)
2. Программного продукта, для учета изменений
3. Организационных единиц, для принятия решений по изменениям.
В одной из компаний, в которой автор статьи внедрял управление проектами, проекты по выводу нового продукта на рынок вместо запланированного года длились два. Проанализировав причины, руководство пришло к выводу о том, что основной причиной является огромное количество изменений в требованиях, которые вносили внутренние заказчики проекта. При этом, изменения не влекли за собой анализ того, а как реализация данных требований скажется на сроках и бюджете проекта. После внедрения системы управления изменениями картина резко изменилась: фактические сроки проекта незначительно отличались от запланированных, и по каждому предложению изменить требования проводился серьезный анализ влияния изменения на сроки и бюджет. Это нововведение позволило компании выводить продукты на рынок практически без опоздания по срокам.
Корпоративная система управления проектами
Допустим, компания научилась управлять реализацией проектов таким образом, что продукты проекта выпускается с характеристиками, удовлетворяющими требования Заказчика, в установленные сроки и с допустимым превышением бюджета. Но очень редко бывает так, что все проекты компании успешны. Как правило, успешность проектов в компаниях, где культура управления проектами только начинает формироваться во многом зависит от личности руководителя проекта. Кроме того, при управлении несколькими проектами одновременно, в которых будут использоваться общие ресурсы, возникает потребность собирать и анализировать большое количество данных. Динамичность проекта сказывается на том, что по сравнению с процессом, в проекте приходится гораздо чаще принимать решения, и цена этих решений велика. Для решения этой задачи в компании внедряется Информационная система управления проектами (ИСУП).
Для снижения зависимости успеха проекта от силы руководителя проекта компании нужны четкие регламенты, на основании которых руководитель проекта может принимать решения. Кроме того, ему нужны шаблоны стандартных документов по управлению проектом, методики их создания и т.д. Всё это входит в состав Стандарта предприятия по управлению проектами.
Корпоративная система управления проектами КСУП объединяет в себе три взаимосвязанные подсистемы: регламентирующую (Стандарт предприятия по управлению проектами) , информационную (часто ее называют ИСУП – информационная система управления проектами) и организационную структуру управления проектами. Внедрение КСУП, как правило, предполагает изменение оргструктуры компании (например, создание специального отдела– проектного офиса, в задачи которого будет входить разработка и поддержание стандарта по управлению проектами, накопление лучшего опыта и создание базы знаний по проектам, развитие ИСУП).
Создание Корпоративной системы управления проектами (КСУП) может способствовать:
1) Повышению вероятности того, что компания не будет расходовать ресурсы на проекты, не соответствующие ее стратегии.
2) Предоставлению руководителю проекта структурированной методики реализации проекта и достоверных данных, необходимых ему для принятия решений на основании показателей, а не собственной интуиции.
3) Уменьшению неопределенности результатов новых проектов.
Стандарт предприятия по управлению проектами основывается, как правило, на сводах знаний («рамочных» руководствах) и стандартах по управлению проектами. К таким документам относится, в частности, Руководство к Своду знаний по управлению проектами (Project Management Body of Knowledge Guide (PMBoK Guide)) Американского института управления проектами (PMI), признаваемый многими как стандарт де-факто, и стандарт ISO 10006:1997, не противоречащий PMBoK и даже придавший наиболее важным положениям PMBoK статус стандарта де-юре.
Фактически Стандарт предприятия по управлению проектами состоит из совокупности документов: Политики, процедур, инструкций и шаблонов документов (см. рисунок 6)

Рисунок 6 – Состав Стандарта предприятия по управлению проектами

Все эти документы находятся в иерархической зависимости и выстраиваются в виде пирамиды, при чем наиболее абстрактным документом является Политика компании в управлении проектами. В этом документе в довольно общих чертах описываются принципы и подходы к управлению проектами в компании. Процедуры управления проектом описывают как минимум группы процессов управления. Вполне возможно, что в Процедурах будут описываться отдельные процессы управления проектом. Шаблоны документов представляют собой документы, с некоторыми типовыми разделами, которые должны быть заполнены адекватной информацией. Например, шаблон Устава проекта, шаблон Плана проекта и т.д.
Некоторые из слоев документации пирамиды могут в начальной версии Стандарта отсутствовать. Создание Стандарта предприятия по управлению проектами как работа представляет собой сложный и длительный проект. Более того, Стандарт не является чем-то «застывшим» и аксиоматичным, он должен постоянно развиваться и совершенствоваться. Стандарт – не догма, а руководство к действию!
Стандарт по управлению проектами позволяет обеспечить:
• Единую терминологию в области управления проектами
• Понимание принципов и процессов управления проектами в организации.
• Разграничение полномочий и ответственности при реализации проектов.
• Повышение эффективности принимаемых управленческих решений.
• Снижение трудоемкости разработки документов для управления проектами.
Создание Стандарта предприятия по управлению проектами фактически сводится к адаптации рамочных стандартов к условиям функционирования и потребностям компании.
Хотелось бы остановиться на еще одном моменте – проектирование описания правил управления проектом. Для создания точных и выверенных регламентирующих документов рекомендуется создавать модель процессов управления проектом. Модель процессов управления проектом может входить в состав Стандарта по управлению проектами в качестве рекомендательной и включать в себя все процессы, описанные в том или ином рамочном стандарте. Спроектировать данную модель можно, к примеру, на базе процессов, описанных в PMBok, и с использованием нотации описания процессов IDEF0. Что дает модель процессов управления проектом для руководителя проекта?
Руководителю проекта очень важно иметь достоверные данные о ходе проекта в любой момент времени. Кроме этого, часто возникает необходимость проверить какую-то гипотезу по проекту, смоделировать ситуацию, контролировать загрузку исполнителей проектов, сроки и бюджет нескольких, одновременно выполняющихся, проектов. Именно для решения этих задач создается Информационная система управления проектами (ИСУП). Информационная система управления проектами (ИСУП) – это набор программных продуктов и приложений, которые позволяют обеспечить информационную поддержку жизненного цикла проектов, эффективное планирование и контроль хода выполнения работ.
Эффективное использование ИСУП для управления проектами компании невозможно без процедур и шаблонов документов, так что документарная часть и ИСУП тесно связаны между собой.
Заключение
Итак, управление проектами – это основной инструмент реализации стратегии компании, связывающий стратегический и тактический контур управления компанией.
А создание КСУП – это разработка системы эффективного управления ограниченными ресурсами компании для выполнения уникальных работ. КСУП должна развиваться и постоянно совершенствоваться, а вместе с ней должны расти знания и навыки персонала, работающего в КСУП. Только в этом случае компания сможет успевать реагировать на разнообразие внешней среды, в которой она существует!

Литература:
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 стр.
5. М. Белбин. Типы ролей в командах менеджеров. Издательство: HIPPO. Год издания: 2004 г., 220 стр.
6. Отто Крегер, Дженет Тьюсон. Типы людей и бизнес. Издательство: Астрель, 2006 г.,
464 cтр.

НАШИ ДАТЫ

29.12.2011
КГ REZУЛЬТАТ завершила маркетинговые исследования для инвест-проекта на рынке продуктов питания в РБ.

23.12.2011
Евгений Зуев завершил проект по обучению управленческого звена одного из крупнейших проектных институтов в Республике Беларусь. Тема обучения "Менеджмент - от личной эффективности к эффективному управлению людьми".

02.12.2011
Центр Поддержки Предпринимательства КГ REZУЛЬТАТ заврешил опрос руководителей белорусских предприятий по теме: "Актуальные инструменты повышения эффективности продаж."

30.11.2011
КГ REZУЛЬТАТ завершила исследования по заказу торговой сети в Республике Беларусь.

05.11.2011
Осуществлена подготовка предложений по реструктуризации коммерческой службы для белорусского производителя газового оборудования РБ.

01.11.2011
Антонина Пожидаева провела тренинг-семинар для ведущего в Республике Беларусь предприятия по продаже автотехники на тему " Управление продажами – технология достижения результатов".