Файл: Подсистемы управления корпоративным проектом (Общие соображения по созданию стандарта).pdf

Введение

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

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

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

Для реализации поставленной цели необходимо выполнить ряд задач:

- Изучить специализацию и детализацию;

- Рассмотреть классификацию проектов как первый этап создания стандарта;

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

- Изучить исполнения проекта примере предприятия и т.д.

При данной работы использованы современные и учебные

Глава 1 Общие соображения по созданию стандарта

1.1 Специализация и детализация

Стандарты проектами уровня в части обычно имеют определяемую документами общего характера (эти документы "рамочными").

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

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

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

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

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

Предметом безусловно, и процессы проектами. Общее возможных процессов в виде пространства, на рис.1. По координат отложены измерения, упоминаются в стандартах, быть предложены и например уровни календарные периоды. Каждая этого пространства собой элементарный управления. Например, “рисков на внедрения системы”.^[2]

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

Собственно этих процедур и основной объем А если более точным, стандартом предприятия понимаем совокупность объясняющих или как, в последовательности, в сроки, с каких шаблонов выполнять те иные действия в управления проектами. Количество документов зависит степени детализации и может достаточно велико (десятков до документов). На 2 они в виде пирамиды (зиккурата), обычно выстраивается вниз по пробуждения аппетита у кто организует и работы на и соответствующего развития стандарта.^[3]

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

Рис. 1. Пространство управления

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

1.2 Классификация проектов как первый этап создания стандарта

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

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

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

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

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

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

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

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

Плановый проекта

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

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

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

Управление - процедуры работы с с возникающими и изменениями, соответствующих проектных Обеспечение качества - и регламенты мероприятий, на обеспечение как результатов (продукта), и процессов проекта и работ.^[5] Контроль и - регламент проведения по анализу проекта, формы отчетности. Преимущества шаблонов очевидны - на консультантах, подходов, времени на документации проекта. Недостатки есть, отметим здесь два. Создание шаблонов - достаточно трудоемкое, а их использовать нет, неизвестно.

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

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

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

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

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

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

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

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

Кому-может показаться, создать шаблон управления проектом просто, только иметь рукой "" стандарты, PMBoK и ISO и разбираться в области. На деле, совсем не В большинстве рамочный стандарт лишь понятийный и общие принципы. Более дело осложняется и тем, необходимая информация в рамочных стандартах "" по разным и ее так-просто " выстроить, и к общему ".

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

Эта методология и шаблоны документов и существо стандарта проектами уровня А процесс стандарта напоминает на каждом витке которой становятся все специализированными, а - все более

Глава 2 Проектные отклонения и управление проектными рисками

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

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

Основные понятия теории управления

Наиболее общей наукой об управлении является кибернетика. Ее возникновение связывается с появлением книги Норберта Винера "Кибернетика, или управление и связь в животном и машине" в 1948 году.

По определению Винера, кибернетика – это наука об управлении системами любой природы.

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

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