Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

Это действительно так (по крайней мере, в отношении российских менеджеров), и это означает, что работа в определенных пределах и стандартах не только привычна для наших менеджеров (напомним хотя бы советский ГОСТ), но и вполне комфортна. Как насчет управления компанией, для которой наличие и внедрение таких стандартов означает гарантированный уровень качества проекта? И, наконец, тот факт, что практика создания собственных методологий и руководств по управлению проектами широко распространена в крупных западных компаниях, таких как Oracle, IBM, Pricewaterhouse Coopers, Andersen Consulting, SAP AG, Siemens и т. д.

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

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

Объект исследования - дистрибьюторская компания.

Объектом исследования является разработка и управление проектом по настройке системы управления в системе управления компанией.

1 Общие соображения по созданию стандарта. Специализация и детализация

Стандарты управления проектами предприятия с точки зрения методологии обычно имеют основу, определяемую документами довольно общего характера (иногда эти документы называют «рамочными»). Эти документы включают в себя Свод знаний по управлению проектами Американского института управления проектами (PMI), признанный многими международными стандартами де-факто, и ISO 10006: 1997, который придал де-юре статус некоторых из наиболее важных положений PMBoK. Смысл и содержание перехода от базовых стандартов (которые являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия заключается в их специализации и уточнении.

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

На первый взгляд дизайн и стандартные концепции могут показаться сложными для взаимодействия. Действительно, часто даже определение проекта включает слова об уникальности, неповторении целей, условиях реализации и результатах проекта. Как это может быть нормализовано в управлении проектами? И если это возможно, нужно ли это? Будет ли это не только мешать, мешать инициативе, навязывать решения, которые не являются оптимальными или даже просто неверными? В то время как западные менеджеры отдают приоритет психологическим аспектам управления и искусству построения межличностных отношений в проекте, их национальные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских лидеров) и означает, что работа в рамках определенных ограничений и норм является не только привычной для наших лидеров (давайте вспомним хотя бы советский ГОСТ), но и тоже очень удобно. А потом, как насчет управления компанией, для которой наличие и внедрение таких стандартов означает гарантированный уровень качества реализации проекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание стандарта управления проектами включает в себя следующие этапы:

разработка концепции;
разработка корпоративной методологии управления проектами;
разработка оперативного стандарта управления проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятие «система» является неоднозначным, что естественно, но общность характерных признаков позволяет выразить систему в том, что:

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

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

Проектирование как система определяется следующими основными свойствами.

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

2. Влияние на проект взаимодействия объективных и субъективных факторов.

3. Динамичность случайных процессов.

4. Целостность (возникновение) системы, то есть наличие таких свойств, которые не присущи элементам системы (подсистемам), рассматриваемым отдельно, вне системы.

5. Сложные информационные процессы из-за множества взаимосвязей между элементами системы.

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

7. Многофункциональность системных элементов (например, функция системного администрирования включает в себя следующие функции: планирование, учет, контроль, анализ, управление операциями).

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

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

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

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

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

Процессы управления сложными (в частности экономическими) системами характеризуются следующими правами.

1. Управление осуществляется путем сбора, обработки и анализа информации. Основной функцией любой системы управления является получение информации и определение из нее поведения управляемой системы.

2. Управление осуществляется по принципу обратной связи: контрольные действия формируются на основе информации о реакции объекта на предыдущие контрольные действия. Этот контроль позволяет достичь цели не путем непосредственного измерения внешних помех, а путем анализа изменений состояния контролируемой системы с течением времени.

3. Наличие посредников при осуществлении прямых и обратной связи. Это приводит ко многим конкретным требованиям к организации таких систем и качеству их управления.

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

5. Воздействие контроля включает в себя уменьшение разнообразия управляемой системы, необходимое для эффективности управления. Это задача управления сложной системой. (Закон необходимого разнообразия, сформулированный У. Р. Эшби, определяет, что приведение множества состояний управляемой системы к подмножеству, включающему только состояния, рациональные по отношению к цели, определяется избирательной способностью системы управления вследствие до величины уменьшения разнообразия объекта управления, которое должно быть достигнуто).

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

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

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

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

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

Стандарты управления проектами компании с точки зрения методологии часто имеют основу, определяемую общими документами, называемыми рамочными документами. Эти документы включают Знания об управлении проектами Американского института управления проектами, признанные многими фактическими международными стандартами, и стандарт 1BO 10006: 1997, смысл и содержание которого состоят из его опыта и деталей.

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

Вдоль оси координат находятся измерения, перечисленные в стандартах кадра; другие могут быть предложены, например, уровни управления, календарные периоды. Каждая точка в этом пространстве представляет элементарный процесс управления, например, «планирование рисков на этапе внедрения системы».

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

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

3 Проектные отклонения. Риски, проблемы, изменения

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

Прежде всего, мы объясняем термин «отклонения», это необходимо, потому что в литературе по управлению проектами это интерпретируется по-разному.

План управления проектом является точкой опоры или отправной точкой для всей последующей разработки проекта. Однако, уже планируя проект, мы предполагаем, что не все пойдет точно так, как планировалось. И фактическое выполнение проекта обычно подтверждает эти опасения. Несоответствия согласованной первоначальной фиксированной идеи проекта (базовой линии проекта) и того, что фактически получается, обычно называют отклонениями.

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

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

Управление отклонениями в основном сводится к управлению проблемами, которое обычно может включать три этапа:

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

2. Управление проблемами. Проблемы возникли и необходимо выяснить их происхождение, степень влияния на проект и способы их преодоления. Цель этого шага - предоставить проекту возможность следовать плану.

3. Изменить управление. Проблемы были довольно серьезными, и они не могли с ними справиться без ущерба для проекта. Целью этого этапа является изменение ранее согласованных продуктов и услуг, сроков и затрат труда, управления и технологических процессов и т. д.

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

Полный цикл контроля отклонения соответствует первому сценарию, в котором:

1) при планировании проекта был выявлен риск, но его использование не привело к желаемому результату;

2) проблема, возникшая в результате возникновения события риска, не была успешно решена;

3) все это привело к необходимости изменения плана проекта.

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

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

Особый интерес с точки зрения анализа отклонений представляют сценарии 4 и 5, соответствующие случаю проблем, которые не считаются рисками. Причиной может быть нетипичная ситуация или «потеря» риска из-за недостаточных управленческих навыков. Анализ причин и серьезности последствий может привести к решению о том, что для некоторых категорий проектов, как правило, неуместно глубоко управлять управлением рисками, но довольно просто решать проблемы, когда они возникают. Для других категорий проектов, с другой стороны, необходимо резко усилить работу с рисками.

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

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

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

Риск - это возможный риск отрицательного результата. Концепция риска объединяет оценку вероятности и последствий неблагоприятного события.

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

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

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

Самым простым и в то же время необходимым рассмотрением стандарта является формальная сторона управления рисками, а именно:

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

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

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

Ключевым шагом в управлении рисками является разработка системы мер по их устранению или снижению. Методы оптимизации и снижения риска включают в себя:

1) диверсификация объектов / проектов;

2)разделение рисков с партнерами, другими субъектами хозяйствования;

3) страхование;

4) избежание риска.

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

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

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

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

3.2 Управление проблемами

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

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

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

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

3.3 Управление изменениями

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

Изменение проекта - это изменение ранее согласованных продуктов и услуг, сроков и затрат труда, процессов управления и технологических процессов и т. д.

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

Например, что касается серьезности последствий, изменения могут быть классифицированы следующим образом:

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

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

Рисунок 3 - Области потерь

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

Часто стратегия изменений определяется тем, что, по крайней мере, на одной из осей изменения не должны приводить к выходу из области запланированных потерь. А это означает необходимость смещения в одном или двух других измерениях одновременно. Поэтому, если известно, что клиент ориентирован в первую очередь на достижение запланированного уровня качества продукции, то должны быть предусмотрены варианты изменений, связанных с манипулированием ресурсами и / или сроками (стратегия «Упрямый клиент»).

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

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

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

Рисунок 4 - Стратегии изменений в проекте

4 Организационные структуры в проектах

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

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

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

функциональная структура, в том числе использование существующей функциональной иерархической структуры организации. Руководитель проекта обеспечивает только общую координацию работы;
дивизионная форма управления организацией (тип функциональной структуры, созданной на основе региональных, продуктовых или технологических особенностей;
структура проекта. Этот подход предполагает, что проектный пакет работ разрабатывается независимо от иерархической структуры организации;
матричная структура. Промежуточная форма, которая сочетает в себе преимущества дизайна и функциональных структур управления. Можно выделить три разновидности матричной структуры организации: слабая матрица, когда координатор проекта отвечает за координацию деятельности проекта, но имеет ограниченную власть над ресурсами; сбалансированная матрица, когда руководитель проекта координирует всю работу и разделяет ответственность за достижение цели с руководителями функциональных отделов; жесткая матрица, когда руководитель проекта обладает наивысшими полномочиями, но также несет полную ответственность за реализацию мероприятий проекта.

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

5 Тактика и стратегия внедрения стандарта управления проектами

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

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

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

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

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

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

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

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

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

6 Дополнительные преимущества от внедрения стандарта

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

Стандарт не заменяет эту литературу, но его роль в целевом обучении персонала компании может быть очень значительной. Здесь, по нашему мнению, будет уместна следующая параллель. С точки зрения процессов управления проектами, стандарт предприятия специализируется и детализирует требования базовых стандартов (таких как ISO 10006 или PMBOK PMI). Таким же образом, с точки зрения квалификации управленческого персонала, стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или NTK).

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

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

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

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

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

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

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

Заключение

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

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

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

Однако, как и любое достижение в области качества, наличие этого стандарта имеет значительный маркетинговый эффект и укрепляет позиции компании на рынке. Очень часто, чтобы получить выгодный контракт, компания должна показать, что она знает, как управлять проектами и как это делать. Фактически, почти каждый крупный тендер на разработку ИТ-систем обязательно включает требования к управлению проектами. Иногда эти требования специфичны, например: «Как будет организована команда проекта, учитывая участие многих сторон в проекте? Как будут поддерживаться отношения с разными партнерами? «Чаще всего они формулируются в наиболее общей форме: «Они предоставляют информацию о процессах управления компанией, позволяя отслеживать и контролировать все аспекты, связанные с проектом, включая...».

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

Список использованной литературы

Баронин, С.А. Основы менеджмента, планирования и контроллинга в недвижимости: Учебное пособие / С.А. Баронин. – М.: НИЦ ИНФРА– М, 2016. – 160 c.
Бланк, И.А. Основы финансового менеджмента. В 2– х т.Основы финансового менеджмента / И.А. Бланк. – М.: Омега – Л, Эльга, 2017. – 1330 c.
Веснин, В.Р. Основы менеджмента: Учебник / В.Р. Веснин. – М.: Проспект, 2016. – 320 c.
Глухов, В. В. Менеджмент: для экономических специальностей / В. В. Глухов. – Санкт– Петербург: Питер Пресс, 2017. – 600 с.
Гончаров, В. И. Менеджмент: учебное пособие / В. И. Гончаров. – Минск: Современная школа, 2016. – 635 с.
Егоршин, А.П. Основы менеджмента: Учебник для вузов / А.П. Егоршин. – Н. Новг.: НИМБ, 2018. – 320 c.
Исаченко, И.И. Основы самоменеджмента: Учебник / И.И. Исаченко. – М.: НИЦ ИНФРА– М, 2017. – 312 c.
Зиновьев, В. Н. Менеджмент: учебное пособие / В. Н. Зиновьев, И. В. Зиновьева. – Москва: Дашков и Кº, 2016. – 477 с.
Ковалев, В.В. Основы теории финансового менеджмента / В.В. Ковалев. – М.: Проспект, 2017. – 544 c.
Коротков, Э. М. Менеджмент: учебник для бакалавров / Э. М. Коротков. – Москва: Юрайт, 2016. – 640 с.
Костин, В. А. Менеджмент: учебное пособие / В. А. Костин, Т. В. Костина. – Москва: Гардарики, 2017. – 334 с.
Круи, М. Основы риск – менеджмента / М. Круи, Д. Галай, Р. Марк. – Люберцы: Юрайт, 2016. – 390 c.
Круглова, Н. Ю. Основы менеджмента: учебное пособие / Н. Ю. Круглова. – Москва: КноРус, 2018. – 499 с.
Маркевич, А.Л. Основы экономики, менеджмента и маркетинга для морских специальностей рыбопромыслового флота / А.Л. Маркевич. – М.: МОРКНИГА, 2017. – 267 c.
Менеджмент: учебник / [С. И. Ашмарина и др.]; под редакцией С. И. Ашмариной. – Москва: Читай: Рид Групп, 2016. – 572 с.
Менеджмент: учебное пособие / В. Н. Зиновьев, И. В. Зиновьева. – Москва: Дашков и К, 2017. – 477 с.
Менеджмент: пособие / И. В. Балдин, Г. Е. Ясников. – Минск: БГЭУ, 2017. – 305 с.
Менеджмент: учебник для высших учебных заведений по экономическим специальностям / [А. В. Игнатьева и др.]; под редакцией М. М. Максимцова, М. А. Комарова. – Москва: ЮНИТИ– ДАНА, 2018. – 320 с.