Читальный зал -->  Международные стандарты управление проектами 

1 2 3 4 5 [ 6 ] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Специализация

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

Детализация

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

Рис. 2.1. Принципы построения стандарта предприятия

стандартов (какими являются и РМВОК, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации (см. рис. 2.1).

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

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

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

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

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

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

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

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

Политика компании по управлению проектами

Процедуры управления проектом

Детальные инструкции по исполнению процедур

Шаблоны документов

Рис. 2.2. Структура стандарта управления проектами

нимать менеджер, но у него перед глазами будет обобщенный опыт ( сын ошибок трудных ) предыдущих поколений.

2.2. План управления проектами и классификация проектов

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

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

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

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

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

Таблица 2.1. Структура типового инвестиционного проекта

1. Подготовка бизнес-плана (ТЭО)

1.1. Описание проекта

1.2. Описание компании

1.3. Обзор рынка и конкуренции

1.4. Инвестиционное планирование

1.5. Операционное планирование

1.6. Планирование финансового обеспечения

2. Реализация проекта

2.1. Образование юридического лица

2.2. Разработка детального финансового плана

2.3. Исследования и разработки

2.4. Набор персонала

2.5. Приобретение оборудования и технологий

2.6. Приобретение земли

2.7. Строительство и монтаж

2.8. Подготовка производства

2.9. Обеспечение сырьем

2.10. Предварительный маркетинг

2.11. Обеспечение финансирования

независимые проекты, например, пакеты работ второго уровня, показанные в структуре инвестиционного проекта (см. табл. 2.1).

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

проекты относятся к различным профессиональным областям деятельности (юрвдическая, финансовая, ИТ, строительная, маркетинговая и т. д.);

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

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

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

Что должно быть отражено в Плане управления проектом

Содержание и границы проекта - цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена.

Ключевые вехи проекта - основные события проекта (milestones) и план их достижения, возможно, с использованием структуры декомпозиции работ (WBS).

Плановый бюджет проекта.

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

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

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

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

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

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

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

Контроль и отчетность- регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.

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

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

Варианты классификации проектов предприятия

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

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

Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями , Обеспечение качества . Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это бьшо принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и вд комбинации.

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

Шаблон Плана управления проектом

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

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

1 2 3 4 5 [ 6 ] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.