- •Дисциплина «управление проектами»
- •1. Общие понятия.
- •1.1. Что такое проект?
- •Временность проекта
- •1.1.2 Уникальные продукты, услуги или результат
- •1.1.3 Постепенное уточнение
- •1.2 Что такое управление проектами?
- •1.4 Родственные виды деятельности.
- •2. Среда управления проектами.
- •2.1 Фазы проекта и жизненный цикл проекта.
- •2.1.1 Характеристика фаз проекта.
- •2.1.2 Характеристики жизненного цикла проекта
- •2.1.3 Типичные жизненные циклы проектов.
- •2.2 Участники проекта.
- •2.3 Влияние организации на проект.
- •2.3.1 Организационные системы.
- •2.3.2 Организационные культуры и стили.
- •2.3.3 Организационная структура.
- •2.3.4 Проектный офис.
- •3. Процессы управления проектами.
- •3.1 Процессы проекта.
- •3.2 Группы процессов.
- •3.3 Взаимодействия процессов.
- •3.3.1 Процессы инициации.
- •3.3.2 Процессы планирования.
- •3.3.3 Процессы исполнения.
- •3.3.4 Процессы управления.
- •3.3.5 Процессы завершения.
- •3.4 Настройка взаимодействия процессов.
- •4. Управление интеграцией проекта.
- •4.1 Разработка плана проекта.
- •4.2 Исполнение плана проекта.
- •4.3 Общее управление изменениями.
- •5. Управление содержанием проекта.
- •5.1 Инициация.
- •5.2 Планирование содержания.
- •5.3 Определение содержания.
- •5.4 Подтверждение содержания.
- •5.5 Управление изменениями содержания.
- •6. Управление сроками проекта.
- •6.1 Определение состава операций.
- •6.2 Определение взаимосвязей операций.
- •6.3 Оценка длительности операций.
- •6.4 Составление расписания.
- •6.5 Управление расписанием.
- •7. Управление стоимостью проекта.
- •7.1 Планирование ресурсов.
- •7.2 Оценка стоимости.
- •7.3 Разработка бюджета.
- •7.4 Управление стоимостью.
- •8. Управление качеством проекта.
- •8.1 Планирование качества.
- •8.2 Подтверждение качества.
- •8.3 Управление качеством.
- •9. Управление человеческими ресурсами проекта.
- •9.1 Организационное планирование.
- •9.2 Назначение персонала.
- •9.3 Развитие команды.
- •10. Управление взаимодействием в проекте.
- •10.1 Планирование взаимодействия.
- •10.2 Распределение информации.
- •10.3 Отчетность по исполнению.
- •10.4 Административное завершение.
- •11. Управление рисками проекта.
- •11.1 Планирование управления рисками.
- •11.2 Идентификация рисков.
- •11.3 Качественный анализ рисков.
- •11.4 Количественный анализ рисков.
- •11.5 Планирование реагирования на риски.
- •11.6 Мониторинг и управление рисками.
- •12. Управление контрактами проекта.
- •12.1 Планирование контрактов.
- •12.2 Планирование заявок.
- •12.3 Получение предложений.
- •12.4 Выбор поставщиков.
- •12.5 Администрирование контрактов.
- •12.6 Закрытие контрактов.
8. Управление качеством проекта.
Управление качеством проекта включает в себя процессы, необходимые для того, чтобы гарантировать, что проект удовлетворит те потребности, ради которых он был предпринят. Оно включает в себя « все действия общего управления, которые определяют политику качества, цели и ответственность и обеспечивают проведение их в жизнь посредством таких действий, как планирование качества, подтверждение качества, управление качеством и улучшение качества в рамках системы качества». Приведем обзор следующих наиболее важных процессов управления качеством проекта:
планирование качества – определение стандартов качества, которые соответствуют проекту, и средств удовлетворения этих стандартов;
подтверждение качества – регулярная общая оценка исполнения проекта с целью подтверждения того, что проект удовлетворяет принятым стандартам качества;
управление качеством – контроль определенных результатов проекта с целью определения их соответствия принятым стандартам качества и определение путей устранения причин неудовлетворительного исполнения.
Эти процессы взаимодействуют друг с другом, также как с процессами из других областей знаний. Каждый процесс может включать в себя действия одного или более лиц или групп лиц, в зависимости от потребностей проекта. Каждый процесс обычно выполняется, по крайней мере, один раз в каждой фазе проекта.
Хотя процессы представлены здесь как дискретные элементы с четко определенными границами, на практике они могут накладываться друг на друга и взаимодействовать способами, детально здесь не описываемыми. Взаимодействие процессов детально рассмотрено в Гл.3.
Предполагается, что основной подход к управлению качеством, описанный в этой главе, должен быть совместимым с подходом Международной Организации по Стандартизации, подробно изложенными в директивах и стандартах ISO серий 9000 и 10000. Этот обобщенный подход должен быть совместим также с:
а). авторскими подходами к управлению качеством, такими как рекомендованные Демингом, Джураном, Кросби и др.;
б). общими подходами, такими как Тотальное управление качеством (TQM), Постоянное Совершенствование (Continuous Improvement) и другими.
Управление качеством проекта должно быть направлено и на управление проектом, и на продукт проекта. Общий термин – продукт – иногда используется в литературе по качеству для обозначения, как продуктов, так и услуг. Неудача в удовлетворении требований качества в любом направлении может иметь серьезные отрицательные последствия для любого или всех участников проекта. Например:
удовлетворение требований потребителя за счет сверхурочной работы команды проекта может привести к отрицательным последствиям в виде повышенной усталости служащих;
сокращение плановых проверок качества с целью уложиться в сроки календарного плана проекта может привести к отрицательным последствиям, если ошибки останутся незамеченными.
Качество – это «обобщенный показатель характеристик объекта, который отражает его способность удовлетворять заявленным и потенциальным потребностям». Заявленные и потенциальные потребности являются входной информацией для разработки требований проекта. Необходимость превратить потенциальные потребности в требования посредством управления содержанием проекта (см. гл.5) является важным аспектом управления качеством.
Команда управления проектом не должна путать качество с сортом. Сорт – это «категория или класс, присваиваемый объектам с одним и тем же функциональным назначением, но различающимся своими техническими характеристиками». Низкое качество – это всегда проблема, а низкий сорт может не представлять проблемы. Например, программный продукт может быть очень высокого качества (без очевидных ошибок, хорошее описание) и низкого сорта (ограниченное число возможностей), или низкого качества (частые сбои, недостаточно полное описание), но высокого сорта (много различных функций). Менеджер проекта и команда управления проектом отвечают за определение и обеспечение требуемых уровней, как качества, так и сорта.
Команда управления проектом также должна знать, что современное управление качеством дополняет управление проектом. Например, обе дисциплины признают важность следующих положений:
удовлетворение заказчика – понимание, управление и влияние на потребности таким образом, чтобы удовлетворить ожидания заказчика. Это требует сочетания соответствия требованиям (проект должен произвести то, что было заявлено) и пригодности для использования (произведенные продукт или услуга должны удовлетворять реальным потребностям);
предотвращение важнее инспекций – стоимость предотвращения (предупреждения) ошибок всегда значительно ниже, чем стоимость их исправления после обнаружения инспекцией;
ответственность руководства – для достижения успеха требуется участие всех членов команды, но за обеспечение необходимыми для успеха ресурсами, отвечает руководство;
процессы внутри фаз – повторяющийся цикл: планирование – исполнение – проверка – воздействие, описанный Демингом и другими, очень похож на комбинацию фаз и процессов, рассмотренных в гл.3, «Процессы управления проектом».
Можно добавить, что инициативы по повышению качества, предпринимаемые исполняющей организацией (такие как Тотальное управление качеством, Постоянное совершенствование и др.), могут улучшить как качество управления проектом, так и качество продукта проекта.
Однако имеется существенное отличие, которое команда управления проектом должна четко осознавать: в силу временной природы проекта в улучшение качества продукта часто должна инвестировать исполняющая организация, особенно в оценку и предотвращение дефектов, так как проект может не продолжаться настолько долго, чтобы возможно было окупить вложения.
