Корпоративные стандарты управления проектами реферат
Обновлено: 04.07.2024
Система управления отдельным проектом создается менеджером проекта для обеспечения управления собственным проектом. Создание эффективной системы управления проектом затрудняется, если нет корпоративных положений, регламентирующих организационную структуру, процессы и методики управления проектами.
При построении системы управления проектами должны быть:
· Определены полномочия менеджера проекта, основные принципы формирования команды проекта и привлечения исполнителей на проект;
· Согласована и утверждена команда управления проектами;
· Разработаны и утверждены планы выполнения работ проекта;
· Определены процедуры управления проектами, включая планирование, организацию исполнения, контроля и управления изменениями, сдачи-приемки результатов;
· Разработана система мотивации.
Основными документами, на которые опирается менеджер проекта, выстраивая систему управления проектами, являются:
· Регламенты управления проектами;
· Сводный план проекта;
· Рабочие документы по исполнению проекта (отчетность, журнал изменений, протоколы совещаний и др.).
Корпоративная система управления проектами представляет собой комплекс организационных, методических, технических, программных и информационных средств, принятых в компании в качестве типовых и используемых в ней для управления проектами.
Корпоративная система управления проектами предполагает совместное (единовременное) развитие трех компонент:
1) Нормативно-регламентного и методологического обеспечения (стандарта);
2) Технического и информационного обеспечения;
3) Организационного и кадрового обеспечения.
Модели зрелости управления проектами в организации
Модели, описывающие этапы (уровни) развития организации, называются моделями уровней зрелости. Модели зрелости управления проектами в организации позволяют комплексно оценить уровень развития корпоративной системы управления проектами. Большинство моделей выделяют несколько уровней развития системы. Каждый уровень зрелости характеризуется определенным состоянием проработанности и применения методологии и инструментов проектного менеджмента, квалификации персонала и корпоративной культуры управления проектами.
По отношению к проектной деятельности можно выделить два основных типа организаций:
1) Процессно-ориентированные. Специфика бизнеса таких предприятий предполагает процессный подход к управлению основной деятельностью (массовое, конвейерное и поточное производство). Проектное управление используется для внутренних проектов, в основном связанных с развитием организации: реорганизации, внедрения информационных систем, создания новых продуктов и т.д.;
2) Проектно-ориентированные. Данные предприятия не только используют проектный подход к управлению процессами развития, но и основной процесс производства (проектное и мелкосерийное производство) организуется и управляется в виде проектов и портфелей проектов.
Корпоративные стандарты управления проектами
Корпоративный стандарт может включать как документы, определяющие общие принципы реализации проектов в компании (корпоративная политика по управлению проектами, общие положения и классификация проектов), так и детальное описание процессов и методик (нормативно-регламентная и методическая документация).
Типовая структура нормативно-регламентной базы включает следующие документы:
· Общие положения и терминология;
· Классификация и описание объектов управления (проектов, программ, портфелей проектов);
Известное изречение Вернера Карла фон Гейзенберга, лауреата Нобелевской премии по физике, гласит: "Мы имеем дело не с законами природы, а с нашим представлением о них". Так и понятие Project Management в мировой практике трактуется неоднозначно в зависимости от выбранной модели, подхода к структуре знаний, типа и вида проектов и других факторов. Весьма разнообразны переводы самого термина Project Management на русский язык: управление проектом (проектами), проектный менеджмент, менеджмент проекта (проектов), проджект-менеджмент. Неоднозначен и смысл, вкладываемый в понятия "менеджмент проектов" и "управление проектами". [4]
Понятие "проект" в разных моделях и стандартах также трактуется с разных позиций. В процессной модели (ISO 9000, 10006) проект рассматривается как процесс, а в рамках "менеджерской", или организационно-деятельностной, модели (ICB IPMA) - определяется через "предприятие", "усилие" и "деятельность".
В разных документах термин проект определяется по разному.
В таблице ниже приведены примеры определений:
Проект:
- это предприятие, которое характеризуется принципиальной уникальностью условий его деятельности, таких как цели (задачи), время, затраты и качественные характеристики, отличающееся от других подобных предприятий специфической проектной организацией;
- это предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в неизвестный путь в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем, чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач;
- это уникальный набор скоординированных действий, с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами выполнения.
IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee. Bremen: Eigenverlag, 1999. - p. 23.
Проект
это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам.
ISO/TR 10006: 1997 (E).
Quality Management - Guidelines to quality in project management - p. 1.
Проект
это временное предприятие (усилие), осуществляемое (предпринятое) для создания уникального продукта или услуги.
A Guide to the Project Management Body of Knowledge. PMI Standards Committee. 2000 Edition, 2000. - p. 4.
Проект
это уникальная совокупность взаимосвязанных действий (работ), с определенными датами начала и окончания, предназначенных для успешного достижения общей цели.
Australian Institute for Project Management. National Competence Standard for Project Management - Guidelines 1996. - p. 18.
Проект
это уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения.
British Standard BS 6079-1:2000. Project management - Part 1: Guide to Project management - p. 2.
После того как Россия стала активно проявлять активность на международном рынке, мы стали перенимать опыт и практику ведения бизнеса за рубежом. Появилось новое и модное словосочетание project management. Но мало просто взять и перенять термины, надо понять как управляют проектами, применить свои знания, использовать уже накопленные, все проанализировать и выработать свою политику и стратегию управления проектами. Многие крупные фирмы разрабатывают собственные стандарты. Но в рамках данного реферата, мы постараемся ознакомится с двумя наиболее известными стандартами в области управления проектами.
Успешность ведения проектов дает фирме шанс зарекомендовать себя как сильного игрока и привлечь новых заказчиков.
Звучит очень позитивно, но мало ахотеть управлять проектами, еще надо знать как это делать и главное уметь воплощать идеи в жизнь. [1]
По результатам опроса 250 менеджеров ведущих запахных компаний, были получены следующие результаты не вопрос о том, насколько успешно прошло внедрение управления проектами в их компаниях:
Только12.7% опрошенных сказали, что введение управления проектами в их компаниях было "очень успешным". Большинство опрошенных считали, что введение управления проектами было "успешным" (41.8%) или "успешным до некоторой степени" (32.7%).
Добиться успехов и освоиться в новом деле помогают стандарты. В них собранный многие практики и выработаны лучшие рекомендации ведения проектов. Зачастую надо использовать не один какой то стандарт, а профиль стандартов.
«Для корректного применения описания профилей стандартов должны содержать :
- определение целей, которых хотелось бы достичь применяя данный профиль;
- перечисление функций продукта или процесса стандартизации, определяемого данным профилем;
- формализованные сценарии применения базовых стандартов и спецификаций, включенных в данный профиль;
- перечень требований к системе или к её компонентам, которые определяют соответствие профиля требованиям к тестированию соответствия;
- перечислении набора стандартов и других документов, которые составляют профиль, с точным указанием используемых положений, редакций и ограничений, способных оказать влияние на достижение корректного взаимодействия объектов стандартизации при использовании данного профиля;
По мнению В.В. Липаева базовые стандарты, которые образуют профиль стандартов используемых в фирме, выглядят следующим образом:
Основу профилей управления проектами составляют две группы: стандарты менеджмента качества процессов жизненного цикла систем – CMMI :2003 и менеджмента (административного управления) системой качества (требования) – ISO 9001:2000 . Так как эти стандарты имеют много общего и трудно выделить их преимущества, то при реальной разработке крупных проектов целесообразно уделять приоритет одной из групп в зависимости от особенностей конкретного проекта и предшествовавшего опыта специалистов предприятия.
Некоторым преимуществом применения стандарта ISO 9001 для управления проектами ПС, является его развитие и детализация требований в специальном руководстве ISO 90003:2004 для программных средств. В этом руководстве цитируются каждое требование ISO 9001 , оно комментируется и снабжается особенностями реализации процессов управления для конкретных проектов программных средств. Кроме того, при описании ряда процессов управления проектом для их уточнения и конкретизации делаются ссылки на основные стандарты, регламентирующие жизненный цикл ПС: ISO 12207, ISO 15504, ISO 9126 , а в приложении проводится сопоставление требований этого стандарта с процессам управления и с рекомендациями стандарта ISO 12207 .
Существуют разные способы представления стандартов. Например стандарты по области охвата можно разбить на следующие:
На схеме видны различные стандарты и методологии, используемые в проектной работе.
На данный момент не существует общих международных стандартов проектного менеджмента, поскольку считается не целесообразно создавать стандарты по широкому кругу вопросов, да и маловероятно, что удастся все охватить.
Вообще нельзя рассматривать стандарт как четкие рекомендации как надо вести проект и как управлять ресурсами в проекте, чтобы добиться максимальной эффективности и отдачи. Стандарт просто не может быть уникальным решением для любого типа проекта. Все очень специфично, это надо понимать и учитывать при использовании стандарта.
Основными международными стандартами по менеджменту качества и управлению конфигурацией в проектах являются ISO 9000:2000, 10005, 10006, 10007 и другие, которые в ряде стран приняты и в виде национальных стандартов.
Свод знаний и систем сертификации ряда стран:
PMBOK и P 2 M
Я предлагаю рассмотреть два стандарта PMBOK и P2M. Именно их поскольку интересно сравнить американский и японский подходы.
«Из национальных стандартов наиболее распространенным документом в области PM, используемым специалистами многих стран, является PMI PMBOK Guide. С 1999 года PMI PMBOK является национальным стандартом США как "Глоссарий терминов и сокращений" в области PM. Третья редакция PMBOK Guide, датированная 2000 годом (предыдущие издания - 1987-й и 1996-й), подтверждена в качестве стандарта ANSI в марте 2001 года.
Однако, как отмечают сами разработчики PMBOK, " ни один документ не может вместить в себя всю сумму знаний". Методическая простота PMBOK PMI достигнута за счет описания упрощенной модели PM в процессном виде, которая используется для управления одним обособленным проектом. То, что трудно или невозможно представить в виде процессов (например, стратегический менеджмент проектов, менеджмент по проектам, мультипроектное управление и многое другое), в этом документе должного отражения не нашло.
PMBoK - это свод установленных стандартов (введенный силами PMI - Project Management Institute), широко используемых профессионалами во многих отраслях экономики и бизнеса, на основе которых проводится сертификация на получение звания PMP (профессионал по управлению проектами). PMBoK включает девять основных областей знаний, представленных в виде пяти групп процессов, как показано на рис. 1.
Группы процессов и Области знаний в Управлении проектами
Источник: Богданов и Партнеры
Для успешного завершения проекта команда проекта должна:
- выбрать из групп процессов управления проектом (также называемых
"группы процессов") подходящие процессы, необходимые для достижения
- использовать определенный подход для согласования планов и
спецификаций продукта с требованиями к продукту и проекту;
- исполнять требования, чтобы соответствовать нуждам, желаниям и
ожиданиям участников проекта;
- уравновешивать противоречащие требования по объему, времени,
стоимости качеству, ресурсам и рискам, чтобы произвести качественный
Процессы PMBoK
Области знаний из PMBoK:
· Разработка Плана проекта, Планирование содержания, Определение содержания
· Управлением расписанием и стоимостью проекта
· Управление качеством
· Управление рисками
P2M (сокращение от Project and Program Management for Enterprise Innovation) описывает управление инновационными проектами и программами в рамках организации.
Отличие этой методологии заключается в ориентированности не на продукт, а на улучшение организации в результате выполнения проектов. Иными словами, стандарт описывает, как сочетать выполняемые проекты и программы с бизнес-стратегией компании и использовать полученный в результате выполнения проектов опыт для развития и продвижения к стратегическим целям.
Недостающее звено трилеммы
Р2М-мышление - от сложной проблемы к моделям проекта
Р2М — это новаторский стиль внедрения решения для управления проектами на уровне предприятия — охватывает видение, профиль, стратегию и архитектуру.
По сути Р2М это результат опроса топ-менеджеров. Первое впечатление согласовывалось с теорией Квинна, которая гласит, что новаторские решения возникают на стыке между производством и сферой услуг.
Суть управления интеграцией программ в Р2М
Сравнение PMBoK (4-е издание) и P2M
P 2 M : Проект относится с процессу создания ценности основанному на спецификациях, в которых рекомендуется как использовать время и ресурсы, включая внешние обстоятельства.
PMBoK : Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.
В PMBoK понятие проекта осталось неизменным, в P2M акцент делается на таких особенностях проекта, как создание ценности в результате выполнения проекта и неопределенности как одного из условий проекта. Кроме того, в P2M к ограничениям проекта относятся не только ресурсы, но отмечается и то, что одно из ограничений проекта - это внешние обстоятельства.
Как резюме, P2M отмечает, что проект описывается рядом характеристик:
- проект - это активность по созданию ценного конечного продукта для выполнения определенной миссии;
- при успешном завершении проекта формируется инновация или отличие в существующем продукте либо новый продукт или услуга;
- проект характеризуется временной природой с определенными датами начала и окончания;
- на проект влияют факторы неопределенности. [8]
Автор считает, что определение проекта данное в P2M, более развернуто и понятно.
В P 2 M , определение звучит немного по другому: проектный менеджмент это профессиональное умение создавать продукт, удовлетворяющий миссии и цели проекта, путем организации проектной команды, использования специальных методов и приемо эффективного использования внутренних ресурсов и эффективной организации всего рабочего процесса.
Важно отметить, что в японском стандарте управление проектом возможно с использованием только тех методов и приемов, которые соответствуют этическим и социальным нормам, а также законодательству и прочим стандартам, которые применяет спонсор проекта.
Примерно эти же требования провозглашаются в этическом кодексе менеджера проекта - отдельном документе PMI, упоминаемом в PMBoK вскользь (3 раза на 275 страницах) , тогда как в P2M они являются неотъемлемой принадлежностью дисциплины управления проектами. [8]
PMBoK представляет процессную модель управления проектом так же, как и раньше, описывая входы, выходы, а также методы и средства для реализации процессов:
P2M дает более системную картину процессов управления проектом:
В новом PMBoK имеется похожая схема, но более детально проработанная. Выглядит она так:
Стандарты можно разнести по разным областям применимости. В зависимости от потребностей и целей следует использовать разные наборы стандартов. Градация приведена в таблице:
С другой стороны, если проект достаточно большой и в нем заинтересовано большое число разнородных участников, то стандарты служат защитой от "самодеятельности", конфликта интересов, необоснованных решений и неквалифицированной работы. В конечном счете, дополнительные затраты на разработку, внедрение и использование корпоративных стандартов по PM компенсируются экономией времени, снижением рисков, лучшей координацией деятельности участников, но для того чтобы внедрение использования стандартов начало приносить свои плоды надо, чтобы персонал понимал важность и необходимость использования стандартов.
На данный момент глобализация стандартизации в области PM ведет к унификации требований к компетентности менеджеров и специалистов, а также к выработке стандартов на унифицированную терминологию и практику. Это способствует формированию единого профессионального языка и пониманию взаимосвязанных работ в организационно распределенных проектных командах [4].
Рассмотрение стандартом PMBOK и P2M показало, что методы и пути стандартизации в Америке и Японии значительно отличаются и упор в каждом из стандартов делается на разные моменты. Но это вполне закономерно, учитывая то, насколько разная культура у этих двух стран, это влечет за собой и разные ценности, а так же и пути достижения цели.
Важно понимать, что нельзя написать стандарты на все случаи жизни. Есть области, которые могут быть зафиксированы в стандартах, есть же те, которые никак не поддаются стандартизации и это надо учитывать.
Можно заметить, что в разных стандартах применяются разные методы и подходы к описанию проектного управления. Все очень субъективно и зависит от много, начиная от культуры и традиций страны, в которой создавался стандарт и заканчивая различными подходами к самой стандартизации и структурированности деятельности в РМ. В качестве объектов стандартизации, как правило, выбраны различные глоссарии, процессы и методы.
3. Программная инженерия. Учебник. Липаев В.В.
5. Американский национальный стандарт ANSI/PMI 99-001-2004 PMBoK
6. Японский стандарт P2M
На первый взгляд понятия проект и стандарт могут показаться трудно совместимыми. Ведь часто даже в определение проекта включают слова об уникальности, неповторяемости целей, условий реализации, результатов проектов. Поскольку это действительно так, что же в таком случае можно стандартизовать в управлении проектами? А если и можно, то нужно ли? Не будет ли это только мешать, сковывать инициативу, навязывать неоптимальные, а то и просто неверные решения? Если для западных менеджеров приоритетными являются психологические аспекты управления и искусство выстраивания межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских менеджеров) и означает, что работа в рамках определенных ограничений и стандартов, является для наших менеджеров не просто привычной (вспомним хотя бы советские ГОСТы), но и вполне комфортной
Содержание работы
Введение
1. Общие соображения по созданию стандарта. Специализация и детализация
2. Классификация проектов как первый этап создания стандарта
2.1 Что должно быть отражено в плане управления проектом
2.2 План управления проектом и рамочные стандарты
3. Проектные отклонения. Риски, проблемы, изменения
3.1 Управление рисками
3.2 Управление проблемами
3.3 Управление изменениями
4. Организационные структуры в проектах
5. Тактика и стратегия внедрения стандарта управления проектами
6. Дополнительные преимущества от внедрения стандарта
Заключение
Список используемой литературы
Файлы: 1 файл
Ct.doc
Прежде всего, отметим, что вряд ли возможно построить единую древовидную классификацию проектов предприятия. Скорее всего, это будут несколько классификаций по различным основаниям, связанным с определенными разделами Плана. Рассмотрим некоторые из них.
Классификация по предметным областям и по продуктам в рамках этих областей позволяет специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты. Эту классификацию как раз можно выстроить по иерархическому принципу. Например, "информационные технологии" - "проекты системной интеграции" - "создание интегрированных систем управления проектами".
Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями, Обеспечение качества . Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.
Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов как "Время и материалы" и "Фиксированная цена".
Таким образом, можно вести речь, например, о шаблоне "План управления проектом создания концепции (продукт) информационной системы (предметная область) стоимостью свыше $ 100 тыс. (масштабность) с контрактом в форме "время и материалы" (форма оплаты и учета работ)", как о макрошаблоне, получаемом простой сборкой из нескольких более мелких (микро) шаблонов отдельных разделов Плана. Кроме того, в макрошаблон должны быть включены и некоторые дополнительные разделы, которые не могут быть определены на микроуровне (такие, например, как "Сроки работ по этапам"). Микрошаблоны могут быть глубоко специализированными - насколько это позволяет соответствующая классификация и накопленный на предприятии опыт.
Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются и другие ситуации. Например, в IBM принята классификация проектов по сложности (комплексности). В соответствии с этой классификацией проекты делятся на обычный бизнес (Business as Usual - BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно эта классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов Плана.
2.2 План управления проектом и рамочные стандарты
Кому-то может показаться, что создать шаблон плана управления проектом достаточно просто, надо только иметь под рукой "рамочные" стандарты, например PMBoK и ISO 10006 и разбираться в предметной области. На самом деле, это совсем не так. В большинстве случаев рамочный стандарт дает лишь понятийный аппарат и общие методологические принципы. Более того, дело осложняется еще и тем, что необходимая информация в самих рамочных стандартах "рассыпана" по разным разделам и ее не так-то просто "собрать, выстроить, и привести к общему знаменателю".
Проиллюстрируем это на примере не самого сложного раздела плана "Организационная структура проекта". В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно!
Таким образом, на основе "рамочной" методологии должна быть создана методология "корпоративная", в которой основные положения, требования, принципы и практики управления проектами конкретизированы и систематизированы применительно к управлению проектами на данном предприятии на основе анализа конкретной специфики выполняемых предприятием проектов.
Эта корпоративная методология и специализированные шаблоны документов и составляют существо стандарта управления проектами уровня предприятия. А процесс создания стандарта напоминает спираль, на каждом новом витке которой методики становятся все более специализированными, а шаблоны - все более детализированными.
3. Проектные отклонения. Риски, проблемы, изменения
Прежде всего, поясним термин "отклонения", это необходимо, поскольку в литературе по управлению проектами он трактуется неоднозначно. В предыдущем разделе мы рассказали о Плане управления проектом - основополагающем документе, содержащем согласованное всеми участниками документально зафиксированное представление о проекте. Другими словами, План управления проектом является "точкой опоры" или исходной базой для всего последующего развития проекта.
Однако, уже планируя проект, мы предполагаем, что не все получится именно так, как запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие несовпадения первоначального согласованного и зафиксированного представления о проекте (project baseline) и того, что получается в действительности, и называются обычно отклонениями. Понимаемый в этом смысле термин "отклонения" эквивалентен термину "deviations", используемому в англоязычной литературе.
Вместе с тем, в англоязычной литературе принят и другой термин - "exceptions", который в русских изданиях также переводится как отклонения. Этим термином обозначают не только несовпадение фактических и плановых результатов, но и причины этих несовпадений, а также методы и технологии (exceptions management), позволяющие справляться с такими ситуациями в проекте с минимальными потерями. Именно эту более широкую трактовку мы и будем иметь в виду в дальнейшем, говоря об отклонениях.
К традиционным областям управления проектами, так или иначе связанным с отклонениями, относятся риски, проблемы и изменения. И хотя не во всех стандартах эти понятия объединяются общим понятием отклонения , наличие взаимосвязей между ними очевидно. Понимание этих связей и адекватное отражение их в стандарте управления проектом поможет не только правильно выстроить процедурную и документарную части стандарта, но и что еще более важно, обеспечит возможность систематического контроля и анализа отклонений, как в отдельном проекте, так и в масштабах предприятия в целом.
Отметим, что соображения, представленные в этом разделе, не являются какими-то отвлеченными рассуждениями и основаны на материалах действующего стандарта управления проектами компании IBS. Мы благодарны компании за предоставленную возможность использования этих материалов, и коллективу разработчиков (Илья Виноградов, Мария Чукова) за возможность использования этих материалов.
Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:
Управление рисками. Неприятности еще не наступили, но существует возможность возникновения нежелательных и незапланированных событий, которые могут привести к тому, что цели проекта (одна или несколько) не будут достигнуты. Цель этой стадии - предотвратить неприятности до их возникновения или, по крайней мере, встретить их во всеоружии.
Управление проблемами. Неприятности наступили и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии - обеспечить проекту возможность идти так, как запланировано. стандарт проект специализация детализация
3.1 Управление рисками
Самое простое, и вместе с тем необходимое, что должно быть отражено в стандарте - формальная сторона управления рисками, а именно:
Процедуры, регламентирующие основные этапы работы с рисками - идентификация рисков, мониторинг и анализ рисков, разработка планирование и реализация мероприятий по противодействию рискам.
Шаблоны документов, отражающих процесс работы с рисками - карточка риска, журнал рисков проекта и т.д.
Из всего многообразия методов управления рисками для стандарта должны быть отобраны те из них, которые адекватны проектам, в которых они будут применяться. Здесь мы имеем в виду, прежде всего, стоимость реализации управленческих процедур.
Так, при анализе рисков может допускаться сознательное огрубление оценок для каких-то конкретных категорий проектов, например, для проектов малой стоимости или сложности.
3.2 Управление проблемами
Авторы в этом вопросе предпочитают следовать духу и букве таких стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых этот процесс называется "problems/issues management", что в русском переводе лучше всего, на наш взгляд, выглядит именно как "управление проблемами".
Под проблемой в проекте понимается любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует ответа - изучения и решения для того, чтобы проект мог идти так, как запланировано. Другими словами - проблема, это исключительные обстоятельства, которые должны быть под контролем (то есть, управляемы) с момента их возникновения.
Обычно проблемы делят на две категории - на проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом - problems, и эскалируемые проблемы - issues, которые для их разрешения требуется поднять на верхние уровни управления, в том числе, внешние по отношению к проекту.
В стандарте должна быть отражена формальная сторона управления проблемами:
Процедуры, регламентирующие основные этапы работы с проблемами - выявление проблемы, мониторинг и анализ проблемы, принятие решения и его исполнение, закрытие проблемы.
Шаблоны документов, отражающих процесс работы с проблемами - карточка проблемы, журнал проблем проекта и т.д.
Для анализа проблем могут разрабатываться специальные таблицы решений. Например, для определения такой важнейшей характеристики проблемы, как приоритетность ее решения, может использоваться матрица приоритетов.
3.3 Управление изменениями
Приводя примеры, иллюстрирующие работу с рисками и проблемами, мы опирались на традиционные для управления проектами ценности - ресурсы, сроки, качественные характеристики продукта. Понятно, что и управляющие воздействия, связанные с противодействием рискам или с решением проблем, ограничены этими же рамками.
Изменение в проекте – это модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.
В качестве традиционных мероприятий по изменениям ресурсов, используемых в проекте, применяются, например, увеличение интенсивности работ, материальное стимулирование, замена или привлечение дополнительных исполнителей и субподрядчиков. Если имеется возможность маневрирования сроками, то речь может идти об изменении сроков завершения отдельных работ, смещении вех внутри проекта или даже об увеличении общего срока завершения проекта. Наконец, в каких-то случаях приходится прибегать и к наименее желательным мерам, связанным со снижением требований к качественным характеристикам, заменой и даже исключением продукта.
С точки зрения тяжести последствий изменения могут быть классифицированы, например, следующим образом:
Плановые потери (учтены в плане управления проектом).
Допустимые потери (незначительные незапланированные затраты).
Нежелательные потери (значительные незапланированные затраты).
Недопустимые потери (незапланированные затраты, которые являются неприемлемыми для одного или нескольких участников проекта).
Для каждого проекта изначально (пусть приблизительно) может быть определена степень влияния тех или иных изменений на величину вероятных потерь, возникающих при реализации этих изменений. На Рис. 5 эта информация представлена в виде диаграммы, в которой изменения связаны с областями потерь. Разумеется, и типы возможных изменений и их расположения по областям является свойством конкретных проектов, а точнее, видов проектов. Поэтому, такие диаграммы могут быть включены в стандарт предприятия как характеристика видов проектов, определенных в классификации проектов.
Ограничения на изменения по ресурсам, времени, продуктам могут быть жесткими в различной степени и в зависимости от этого в проектах возникают достаточно типичные ситуации, которые также могут быть описаны заранее. Рассмотрим некоторые такие ситуации.
Функция "чтения" служит для ознакомления с работой. Разметка, таблицы и картинки документа могут отображаться неверно или не в полном объёме!
Работа состоит из введения, 2 глав, заключения, списка использованной литературы и приложений.
Глава 1. Теоретические и методологические основы разработки корпоративной системы управления проектами.1 Понятие корпоративной системы управления проектами
Под корпоративным управлением проектами сегодня принято понимать применение знаний, навыков, инструментов и методов к организационной и проектной деятельности для достижения целей организации посредством проектов [8]. В настоящее время все большее количество фирм, организаций и корпораций начинают интересоваться вопросом построения корпоративных систем управления проектами, так как системное управление проектами несет ряд важных выгод для организации, таких как снижение затрат проекта, следование срокам, усиление контроля качества. Корпоративная система управления проектами - это комплексное решение, состоящее из 4 основных компонентов: корпоративной методологии управления проектами, автоматизированной информационной системы управления проектами, обученного управлению проектами персонала и специализированных структур, обеспечивающих выполнение процессов проектного управления [4].
В корпоративной системе управления проектами субъектами управления являются активные участники проекта, которые взаимодействуют между собой и внешними контрагентами при выработке и принятии различных управленческих решений, объектом управления КСУП является проект или проекты и их элементы и характеристики. КСУП предлагает комплексное решение по управлению всеми аспектами проектов: по управлению содержания и объему работ, стоимостью, закупками и поставками, временем, качеством, коммуникациями, рисками, человеческим ресурсами и интеграцией.
Существование корпоративной системы управления проектами внутри компании позволяет ей достигать заданные цели в установленный срок с оптимальными затратами. К преимуществам существования корпоративной системы управления проектами внутри компании принято относить:
· Повышение эффективности и обеспечение выполнения проектов по качеству, бюджету, составу и объему, ресурсам и срокам
· Координация взаимодействия между сотрудниками и подразделениями
· Определение единых правил и формализация процессов и отчетности
· Создание базы знаний и передача накопленного опыта для реализации будущих проектов
· Повышение ответственности проектного персонала и индивидуальная оценка вклада каждого сотрудника
· Управление портфелем проектов
.1.1 Корпоративная методология управления проектами
Под корпоративной методологией управления проектами (КМУП) понимают стандарты, обязательные для всех участников проекта. Эти стандарты регламентируют то, какие роли есть в проекте, какие существуют процессы управления проектами, включает в себя шаблоны документов, необходимых по управлению проектами (устав проекта, календарный план, структурная декомпозиция работ проекта и т.д.).
Существуют различные источники, в которых содержится методологические знания по управлению проектами: профессиональные стандарты по управлению проектами, авторские концепции и различные научные статьи по
Читайте также: