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

Введение

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

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

Это действительно так (по крайней мере, в отношении российских менеджеров), и это означает, что работа в определенных пределах и стандартах не только привычна для наших менеджеров (напомним хотя бы советский ГОСТ), но и вполне комфортна. Как насчет управления компанией, для которой наличие и внедрение таких стандартов означает гарантированный уровень качества проекта? И, наконец, тот факт, что практика создания собственных методологий и руководств по управлению проектами широко распространена в крупных западных компаниях, таких как 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).

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