Главная страница

Практическое задание по проектному менеджменту (Все задания цели. Задание. Концепция проекта


Скачать 433.65 Kb.
НазваниеЗадание. Концепция проекта
Дата30.03.2023
Размер433.65 Kb.
Формат файлаdoc
Имя файлаПрактическое задание по проектному менеджменту (Все задания цели.doc
ТипДокументы
#1026940


Практическое задание по проектному менеджменту (Все задания целиком)

  1. Задание. 1. КОНЦЕПЦИЯ ПРОЕКТА

Каждая группа должна выдвинуть проектную инициативу и зафиксировать ее в следующем документе: КОНЦЕПЦИЯ ПРОЕКТА «___________________________ »

1. Сущность проекта.

2. Сфера применения проекта.

3. Потребности рынка, ради удовлетворения которых предпринимается проект.

4. Описание продукта проекта.

5. Основные цели, ключевые результаты проекта.

6. Ограничения проекта (сроки, бюджет и т. д.).

7. Критические факторы успеха:

Удовлетворение требований качества

Соблюдение ограничений «время-цена-качество»

Создание добавленной стоимости среды – то есть увеличение потенциала организации

Достижение финансовых параметров (например, целевого возврата инвестиций)

Достижение стратегических целей

Группам необходимо представить первый вариант дерева целей.

  1. Задание. 2. Каждая группа должна разработать ИСР

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

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

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

Результат распечатать.

Методический материал (Шпаргалка)

Иерархические структуры работ (ИСР), Work Breakdown Structures (WBS) –это ориентированная на результат поставки иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов поставки.

С помощью ИСР структурируется и определяется все содержание проекта.

Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.

ИСР разбивается на следующие уровни: проект, задача, подзадача, пакет работ, работа, операция.

Для составления общей ИСР необходимо описание цели реализации проекта (продукта проекта) и результатов поставки проекта, краткое содержание работ по достижению результатов поставки проекта

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

Для пакета работ определяют график выполнения, сметную стоимость, осуществляют контроль.

Все элементы ИСР имеют специальную кодировку, смысл которой — присвоить каждому элементу уникальный номер.
ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ИСР

Правило 1. Каждый элемент ИСР должен обеспечивать достижение ощутимого результата.

Правило 2. Каждый элемент ИСР должен являться результатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

Правило 4. Результаты пакетов работ должны быть уникальными и отличаться от результатов других пакетов работ того же уровня.

Правило 5. Процесс разработки ИСР должен обеспечивать корректировку ИСР в случае изменения объема работ по проекту.

Правило 6. Все результаты в явном виде должны быть включены в ИСР.

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

Правило 8. Все пакеты работ должны быть совместимы с организационной структурой и структурой затрат.

Правило 9. Результаты должны быть четко определены так, чтобы исключить дублирование объемов работ внутри элементов ИСР, в целом по организации или отдельными ответственными за выполнение работ.

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

Существует несколько популярных способов проведения декомпозиции:

  • По фазам жизненного цикла

Например, ваш проект выполняется по таким фазам: Продажа, Аналитика, Проектирование, Дизайн, Продакшн, Верстка и т.д. Вы можете представить все эти объекты на первом уровне, чтобы дальше разбить их на более измеримые кусочки.

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

  • По ключевым результатам проекта (deliverables)

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

Эти результаты удобно отразить на первом уровне, чтобы заказчик ясно и точно видел, что будет сдано ему по завершению проекта. Здесь важно помнить, что если результат не представлен на ИСР, то в проекте он не будет получен.



  • по организационной структуре проекта

Например, в вашем проекте есть 4 структуры, которые вовлечены в реализацию проекта:

бизнес-заказчик. Он может отвечать за результаты:

    • бизнес требования к системе

    • подготовленные к загрузке в систему данные

    • обученные пользователи

    • бизнес-тестирование и т.д.

ИТ со стороны заказчика. Они могут отвечать за:

    • серверы

    • закупленные лицензии

    • интерфейс обмена с другими учетными системами и т.д.

вендор (поставщик программного продукта) отвечает за:

    • аудит технической архитектуры

  • компания — внедренец программного обеспечения (ваша структура)

    • техническое задание

    • настройка системы

    • доп. программирование системы и т.п.

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

  • По источникам финансирования

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

  • По подпроектам



Иногда можно использовать смешанный подход: на первом уровне фазы проекта, на втором организационные структуры, на третьем — результаты.

Главное — не запутайтесь. Важно, чтобы выбранный подход к декомпозиции позволил оценить весь объем проекта.

  1.  Глубина декомпозиции должна позволять оценить объем пакета работ (остальное можно детализировать в ходе проекта)

  2. Корректная ИСР — это структура без дублирования, с примерно одинаковыми по объему работ элементами и понятная заказчику1



  1. По подсистеме «Управление сроками»

Из задания 2 Определить последовательности операций, используя например Метод диаграмм предшественников. Определить взаимосвязи методом стрелочных диаграмм. Построить расписание проекта (сетевую диаграмму). Определить время проекта




п/п

Этапы реализации проекта

(из ИСР)

Предыдущие

Продолжительность

1













  1. По подсистеме «Управление качеством».

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

Задание 2 определить по продукту или по процессу все ГОСТы, стандарты, которые необходимо учесть в проекте.

Пример диаграмма Ишикавы






  1. По подсистеме «Управление рисками»

Каждой группе определить  риски, уровни вероятности возникновения рисков и их последствий используя таблицу 1 и 2
Таблица матрица ответственности



п/п

Этапы реализации проекта

(из ИСР)

риск

оценка вероятности возникновения риска(1)

оценки воздействия (2)

Оценка последствия

(1*2)




























































































Таблица 1. Семиуровневая оценка вероятности возникновения риска




Таблица 1 Семиуровневая оценка вероятности возникновения риска

Интервал вероятностей

Значение вероятности, используемое для вычислений

Словесная формулировка

Числовая оценка

От 1% до 14%

7%

крайне маловероятно

1

От 15% до 28%

21%

низкая вероятность

2

От 29% до 42%

35%

скорее нет

3

От 43% до 57%

50%

50-50

4

От 58% до 72%

65%

возможно

5

От 73% до 86%

79%

весьма правдоподобно

6

От 87% до 99%

93%

почти наверняка

7



Таблица 2 Определение шкалы оценки воздействия для четырех целей проекта

Определенные условия для шкалы оценки степени возможного влияния риска (показаны только примеры негативных воздействий)

Цель проекта

Показаны значения по относительной и числовой шкалам

Очень низкое

Низкое

Умеренное

Высокое

Очень высокое

0,05

0,10

0,20

0,40

0,80

Стоимость

Незначительное увеличение

Увеличение < 5%

Увеличение 5-10%

Увеличение 10-20%

Увеличение > 20%

Сроки

Незначительное увеличение

Увеличение < 5%

Увеличение 5-10%

Увеличение 10-20%

Увеличение > 20%

Содержание (объем)

Изменения незаметны

Незначительные изменения

Значительные изменения

Неприемлемое для клиента изменение

Достижение конечных результатов невозможно

Качество

Изменения незаметны

Незначительные изменения

Изменения требуют согласия клиента

Неприемлемое для клиента изменение

Достижение конечных результатов невозможно

Матрица воздействия (вероятностей и последствий) рисков





  1. По подсистеме «Управление человеческими ресурсами»

Задание 1. Каждой группе определить статус ключевых участников, их компетенции и ответственность и время участия.



п/п

Этапы реализации проекта

(из ИСР)

Участники проекта

Квалификационный уровень

Время работы

Условия привлечения




















Задание 2. Составить матрицу ответственности

Таблица матрица ответственности



п/п

Этапы реализации проекта

(из ИСР)

Участники проекта









































Для каждого участника проекта определить квалификационный уровень и обобщенную трудовую функцию, использую профессиональный стандарт http://fgosvo.ru/docs/101/69/2

Работа по составлению матрицы ответственности:

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

Традиционные подходы и рекомендации


В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI». В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ.

Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).

Ответственность и полномочия: как избежать ошибок?


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

  1. Работать над МО всей командой, стараясь заполнить ее в единственную сессию.

  2. Сначала заполнять все ячейки с ответственностью, исключить ситуацию, когда остаются строки без символа «О».

  3. Придерживаться методики RACI, избегая расширения состава полномочий из разряда «Исполнитель», «Согласование», которые, по сути, не несут в содержании ответственности.

  4. Исключить ситуацию пустых столбцов в МО.

  5. Составить несколько вариантов МО, начиная с верхнего уровня и соблюдая принцип лаконичности.

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

  1. Допустить ситуацию, когда в одной ячейке проставлено два символа.

  2. Перегрузить МО символами, тем самым девальвируя ее работопригодность.

  3. После утверждения МО «положить ее под сукно» и забыть, тем самым исключив смысл применения МО в качестве инструмента прямого контроля промежуточных результатов и спроса с ответственных ресурсов по задачам проекта 2.

Таблица Условные обозначения матрицы ответственности - RACI

"R" Исполнитель (Responsible)

Лежит ответственность за выполнение поставленной задачи. На каждую задачу должно приходиться не менее одного Исполнителя. Степень ответственности распределяется Утверждающим

"A" Утверждающий (Accountable)

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

"С" Консультант (Consulted)

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

"I" Информируемый (Informed)

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

Основными принципами принятия решений с помощью RACI являются:

  1. Избежание очевидных событий, например "присутствовать на заседаниях".

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

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

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

Вертикальный анализ (по функциональным ролям) позволяет выявить соответствующие проблемы: Если у Вас получилось:

  • много R, в таком случае нужно задать себе вопрос, может ли определенный человек быть ответственным за такое количество действий;

  • нет пустых ячеек - нужно ли втягивать людей в такое количество операций?

  • нет R или А - можно ли ликвидировать эту функциональную роль?

  • Много А - правильно ли распределяются обязанности? Могут ли другие люди быть подотчетными в этих процессах?




При горизонтальном анализе рассматриваются действия Если у вас получилось, что

  • нет R, то тогда никто не несет ответственности за процесс, и он не будет выполнен;

  • много А — будет путаница, так как любой Утверждающий имеет свое видение, как должно быть осуществлено действие;

  • много С — надо понять, нужно ли в реальности консультироваться с таким количеством различными функциональными ролями;

  • много I — может быть ситуация, где определены роли. Правильное использование RACI поможет достичь таких целей, как:

    • повышение производительности за счет четко структурированной иерархической системы;

    • снижение производственных ошибок, таких, как производство брака, за счет выяснения нужных технических характеристик;

    • увеличение производительности путем устранения дублирования и пересортицы на производстве;

    • модернизированная организационная структура без лишних функциональных элементов;

    • улучшение процесса планирования в связи с большим участием членов команды в результате строительства коммуникационных линий (консультирование и информирование).3



  1. По подсистеме «Управление стоимостью»

Задание 1 оценить количество ресурсов, необходимых для реализации работ проекта.

Задание 2 разработать сметы и бюджета проекта.



п/п

Этапы реализации проекта

(из ИСР)

Необходимый ресурс

Цена

Объем ресурса

Затраты



















Задание 3 определить источники и методы финансирования проекта.



ИТОГОВОЕ ПО ПРОЕКТУ СОСТАВИТЬ ОТЧЕТ И ПРЕЗЕНТАЦИЮ ПРОЕКТА.

1 http://pmwebinars.ru/blog/wbs-cdr-isr-chast-2.html

2 http://projectimo.ru/komanda-i-motivaciya/matrica-otvestvennosti.html

3 http://www.cfin.ru/management/people/instructions/RACI.shtml


написать администратору сайта