ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 09.11.2023
Просмотров: 40
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
| Министерство науки и ВЫСШЕГО ОБРАЗОВАНИЯ Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования «Уральский государственный экономический университет» (УрГЭУ) |
КОНТРОЛЬНАЯ РАБОТА
по дисциплине
Управление проектами
Тема:
«Стандарты в сфере управления проектами»
| Институт непрерывного и дистанционного образования Направление подготовки Менеджмент Направленность (профиль) Менеджмент организации Кафедра Менеджмента Дата защиты: ________________ Оценка: ________________ | | |
Содержание
Введение 3
1 Общие соображения по созданию стандарта……………..………………….…5
2 Классификация проектов как первый этап создания стандарта 7
2.1 Что должно быть отражено в плане управления проектом 10
3 Проектные отклонения. Риски, проблемы, изменения 11
3.1 Управление рисками 15
3.2 Управление проблемами 16
3.3 Управление изменениями 16
4. Организационные структуры в проектах 17
5. Тактика и стратегия внедрения стандарта управления проектами 19
Заключение 22
Список использованных источников 24
Вторая часть. План проекта по созданию бизнеса 28
Введение
Стандарт в широком смысле слова — образец, эталон, модель, принимаемые за исходные для сопоставления с ними др. подобных объектов. Стандарты – способ упорядочить всякую деятельность (строительство мостов, создание компьютерных программ, управление проектами). Одни виды деятельности (например, производство консервов) упорядочиваются сравнительно легко, другие (реализация проектов) сложнее. Выпуском стандартов может заниматься и профессиональное сообщество (например, многочисленные изыскания софтверной индустрии, придуманные «разработчиками для разработчиков»), и коммерческие, и международные организации (ISO), и государство.[2]
Часто даже в определение проекта включают слова об уникальности, неповторяемости целей, условий реализации, результатов проектов. Поскольку это действительно так, что же в таком случае можно стандартизовать в управлении проектами? А если и можно, то нужно ли? Не будет ли это только мешать, сковывать инициативу, навязывать неверные решения? Если для западных менеджеров приоритетными являются психологические аспекты управления и искусство выстраивания межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских менеджеров) и означает, что работа в рамках определенных ограничений и стандартов, является для наших менеджеров не просто привычной (вспомним хотя бы советские ГОСТы), но и вполне комфортной. А что тогда говорить о руководстве компании, для которого наличие и исполнение таких стандартов означает гарантированный уровень качества выполнения проектов?
И, наконец, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др. Все эти соображения вызывают интерес, что побудило меня рассмотреть эту тему.
Цель работы: формирование глубоких теоретических и практических знаний в области изучения управления проектами, выделить стандарты в сфере управления и как они работают.
Задачи работы:
1) Изучить теоретический материал дисциплины «управление проектами»
2) Ответить на теоретические вопросы, выполнить практическое задание.
1. Общие соображения по созданию стандарта. Специализация и детализация
Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI) и стандарт ISO 10006:1997. Смысл и содержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.
Специализация означает включение в стандарт предприятия тех и только тех положений, которые имеют отношение к проектной деятельности именно на этом предприятии и в привязке к реалиям этого предприятия. Прежде всего, из этого следует, что такие реалии должны быть четко определены. Ну, а определять реалии надо в четко определенных понятиях, измеримых показателях и т.п. В связи с этим стандарт предприятия неизбежно должен содержать описание и классификацию проектов компании.
Проекты компании могут относиться к различным профессиональным областям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и т.д.), иметь различную сложность с точки зрения решаемых задач, различный масштаб с точки зрения привлекаемых ресурсов и предполагаемого результата. Могут выделяться некоторые категории проектов, специфические с точки зрения конкретных отраслей. Например, в стандарте компании Enron, специализировавшейся в своё время в области электроэнергетики, отдельно рассматривались международные проекты, как предъявляющие особые требования к законодательной базе, к персоналу, оборудованию, экономической инфраструктуре, логистике и т.д.
Организационные структуры и персонал проекта также являются предметом специализации. В стандарте предприятия могут не только фиксироваться стандартные проектные роли (руководитель проекта, администратор, менеджер по качеству, и т.д.), но и определяться структура и принципы формирования органов управления проектами. Примером такой специализации может служить двухуровневая управленческая структура в проектах внедрения ERP систем.
Для всех постоянных (определенных штатной структурой) подразделений, тем или иным образом связанных с исполнением проектов, должны быть определены принципы их участия в проектах - виды выполняемых работ, порядок выделения и отзыва персонала, формы и размеры получаемого вознаграждения.
Для руководства этих подразделений должны быть определены их права и обязанности по отношению к организационным структурам проекта. Для сотрудников, привлекаемых в проект, должны быть определены правила регламентирующие их работу в проекте, в том числе, регулирующие вопросы двойного подчинения и материального стимулирования.
2. Классификация проектов как первый этап создания стандарта
Ключевым моментом в создании стандарта управления проектами является осмысление того, какие проекты выполняются на предприятии, каковы их отличия, что между ними общего. Эти вопросы связаны с практикой управления проектами и отражаются в стандарте предприятия.
Среди западных коллег распространено мнение, что профессиональный руководитель проектов может успешно реализовать любой проект, независимо от того, к какой области он относится - от строительства атомной электростанции до разработки программного обеспечения. Из этого возникают вопросы: какое количество времени нужно и есть ли такой запас? Какое необходимо количество консультантов и какой квалификации? Сколько нам будет стоить такой руководитель проектов сам по себе и сколь велики будут дополнительные расходы?
Это особенно важно для предприятий, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения "универсального" руководителя проекта, и пути снижения стоимости его "содержания", является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых подпроектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и т. д. В крупных банках филиалы создаются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным для того, чтобы сформировать для каждого вида проектов (подпроектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и т. д.
Но как раз эта информация и составляет сущность основного документа, с которого должен начинаться любой проект - Плана управления проектом (в различных источниках можно найти и другие названия подобного документа - Устав проекта, Определение проекта). Таким образом, могут быть подготовлены специализированные шаблоны Плана управления проектами, фиксирующие совершенно конкретные методы управления проектами, рекомендованные на данном предприятии для данного типа проектов. А вслед за ними и другие типовые шаблоны.
2.1 Что должно быть отражено в плане управления проектом
Содержание и границы проекта - цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена.
Ключевые вехи проекта - основные события проекта (milestones) и план их достижения, возможно, с использованием структуры декомпозиции работ (WBS).
Плановый бюджет проекта
Предположения и ограничения - предпосылки, на основе которых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание начальных рисков.
Требования и стандарты - перечень нормативных и регламентирующих документов или их отдельных положений, которые следует соблюдать в ходе выполнения работ проекта.
Подходы к выполнению проекта - концепция предполагаемого решения (возможно несколько альтернативных вариантов), методы разработки и базовые информационные технологии.
Организационная структура - ответственность и порядок взаимодействия участников, имена и обязанности ключевых фигур проекта
Управление проектной документацией - структура, среда хранения и процедура создания и сопровождения документов проекта, перечень шаблонов документов.
Управление отклонениями - процедуры работы с рисками, с возникающими проблемами и изменениями, форм соответствующих проектных документов.
Обеспечение качества - перечень и регламенты проведения мероприятий, направленных на обеспечение качества, как результатов проекта (продукта), так и процессов управления проекта и выполнения работ.
Контроль и отчетность - регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.
Преимущества типовых шаблонов очевидны - экономия на консультантах, унификация подходов, сокращение времени на подготовку документации проекта. Недостатки тоже есть, мы отметим здесь только два. Создание таких шаблонов - дело достаточно трудоемкое, а будут их использовать или нет, заранее неизвестно. Это зависит от воли и настойчивости руководства предприятия. Второе - есть опасение, что наличие таких шаблонов будет сковывать инициативу и самостоятельность руководителя проекта, и он не сможет адекватно реагировать на нештатные ситуации. Нам кажется, что эти сложности окажутся не столь критичными, если шаблоны будут удобны, а их специализация и детализации будут оптимальными для данного предприятия и его проектов. А это уже вопрос качества работы консультантов и аналитиков, создающих стандарт.
Сколько разных шаблонов Плана управления проектом целесообразно иметь в стандарте? Для того чтобы ответить на этот вопрос необходимо построить классификацию проектов, выполняемых на предприятии. Причем, очевидно, что для каждого предприятия это будет уникальная классификация. Собственно, с построения такой классификации и должно начинаться создание стандарта.
Нужно отметить то, что вряд ли возможно построить единую древовидную классификацию проектов предприятия. Скорее всего, это будут несколько классификаций по различным основаниям, связанным с определенными разделами Плана. Рассмотрим некоторые из них:
Классификация по предметным областям и по продуктам в рамках этих областей позволяет специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты. Эту классификацию как раз можно выстроить по иерархическому принципу. Например, "информационные технологии" - "проекты системной интеграции" - "создание интегрированных систем управления проектами".