Файл: Стандарты управления проектами (Проектные отклонения. Риски, проблемы, изменения).pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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