Файл: Подсистемы управления корпоративным проектом (Общие соображения по созданию стандарта.).pdf
Добавлен: 27.06.2023
Просмотров: 49
Скачиваний: 2
СОДЕРЖАНИЕ
Глава 1 Общие соображения по созданию стандарта
1.1 Специализация и детализация
1.2 Классификация проектов как первый этап создания стандарта
1.3 План управления проектом и рамочные стандарты
Глава 2 Проектные отклонения и управление проектными рисками
2.1 Управление проектными рисками
2.2 Классификация методов управления рисками
Глава 3 Механизм планирования управления проектом на предприятии
3.1 Планирование затрат проекта
3.2 Оценка исполнения проекта на примере ООО «Спецэлектромонтаж»
Введение
На первый взгляд понятия проект и стандарт могут показаться трудно совместимыми. Ведь часто даже в определение проекта включают слова об уникальности, не повторяемости целей, условий реализации, результатов проектов. Поскольку это действительно так, что же в таком случае можно стандартизовать в управлении проектами? А если и можно, то нужно ли? Не будет ли это только мешать, сковывать инициативу, навязывать неоптимальные, а то и просто неверные решения? Если для западных менеджеров приоритетными являются психологические аспекты управления и искусство выстраивания межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход.
Сошлемся также на результаты всероссийских конференций "Стандарты в проектах современных информационных систем", где тема стандартов управления проектами была представлена достаточно широко и вызвала живой интерес и дискуссии, как в зале заседаний, так и в кулуарах. В решениях конференций было "признание роли стандартов в организации выполнения отдельных проектов и в постановке проектного дела в целом на предприятиях".
Целью данной работы является изучение стандартов управления проектами.
Для реализации поставленной цели необходимо выполнить ряд задач:
- Изучить специализацию и детализацию;
- Рассмотреть классификацию проектов как первый этап создания стандарта;
- Рассмотреть управление проектными рисками;
- Изучить исполнения проекта примере предприятия и т.д.
При данной работы использованы современные и учебные
Глава 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 году.
По определению Винера, кибернетика – это наука об управлении системами любой природы.
Ее предмет – информационные процессы, связанные с управлением системами, объект – сами системы.
Любое предприятие или организация являются системами, и все элементы управления ими, включая управление рисками, подчиняются общим кибернетическим законам.