http://books.altspu.ru/files/original/82/82/_[650].png 89ed99c21988c56cf571c7a99acf3a1b http://books.altspu.ru/files/original/82/82/_-_[pdf].pdf 06e794bf749804e226737f56a4b10fb9 PDF Text Text Содержание �Содержание ОБ ИЗДАНИИ Основной титульный экран Дополнительный титульный экран непериодического издания – 1 Дополнительный титульный экран непериодического издания – 2 �Содержание Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования «Алтайский государственный педагогический университет» Основы управления ИТ-проектами Учебное пособие Барнаул ФГБОУ ВО «АлтГПУ» 2017 Об издании - 1, 2, 3. ISBN 978-5-88210-861-7 �Содержание УДК 004(075) ББК 65.39я73 О-753 Основы управления ИТ-проектами [Электронный ресурс] : учебное пособие / сост. Е.Р. Кирколуп, Ю.Г. Скурыдин, Е.М. Скурыдина. – Барнаул : АлтГПУ, 2017. – Систем. требования: PC не ниже класса Intel Celeron 2 ГГц ; 512 Мb RAM ; Windows XP/Vista/7/8/10 ; Adobe Acrobat Reader ; SVGA монитор с разрешением 1024х768 ; мышь. ISBN 978-5-88210-861-7 Рецензенты: Абрамкин Г.П., кандидат физико-математических наук, доцент (Алтайский государственный педагогический университет); Седалищев В.Н., доктор технических наук, профессор (Алтайский государственный университет) В пособии рассмотрены основные понятия и подходы современной методологии управления ИТпроектами. Пособие содержит практическое введение в программу планирования и управления проектами OpenProj. Пособие предназначено для студентов, обучающихся по специальности «Прикладная информатика», для аудиторных и самостоятельных занятий по дисциплинам «Проектный практикум» и «Проектирование ИТ-инфраструктуры предприятия». Рекомендовано к изданию редакционно-издательским советом АлтГПУ 26.01.2017 г. Текстовое (символьное) электронное издание. Системные требования: PC не ниже класса Intel Celeron 2 ГГц ; 512 Мb RAM ; Windows XP/Vista/7/8/10 ; Adobe Acrobat Reader ; SVGA монитор с разрешением 1024х768 ; мышь. Об издании - 1, 2, 3. �Содержание Электронное издание создано при использовании программного обеспечения Sunrav BookOffice. Объём издания - 5 200 КБ. Дата подписания к использованию: 12.04.2017 Федеральное государственное бюджетное образовательное учреждение высшего образования «Алтайский государственный педагогический университет» (ФГБОУ ВО «АлтГПУ») ул. Молодежная, 55, г. Барнаул, 656031 Тел. (385-2) 36-82-71, факс (385-2) 24-18-72 е-mail: rector@altspu.ru, http://www.altspu.ru Об издании - 1, 2, 3. �Содержание СОДЕРЖАНИЕ Введение Понятие и основные элементы ИТ-инфраструктуры предприятия Тестовые задания Практическая работа № 1 по теме «Понятие и основные элементы ИТ-инфраструктуры предприятия» Жизненный цикл ИТ-проекта Тестовые задания Практическая работа № 2 по теме «Жизненный цикл ИТ-проекта» Инициация проекта Тестовые задания Разработка технико-экономического обоснования Разработка устава проекта Практическая работа № 3 по теме «Разработка устава проекта» Идентификация и анализ участников проекта Практическая работа № 4 по теме «Идентификация и анализ участников проекта» Практическая работа № 5 по теме «Идентификация и анализ участников проекта» Планирование проекта План управления проектом Формирование иерархической структуры проекта Определение содержания проекта Тестовые задания Практическая работа № 6 по теме «Организационная структура проекта» Формирование списка работ (операций) проекта Оценка стоимости проекта Разработка расписания проекта Тестовые задания Лабораторная работа № 1. Построение диаграмм Гантта с помощью электронных таблиц Лабораторная работа № 2. Построение диаграмм Гантта в электронных таблицах с использованием функций и макросов Лабораторная работа № 3. Построение диаграмм Гантта в OpenProj �Содержание Разработка расписания проекта методом критического пути Лабораторная работа № 4. Создание и управление проектом с помощью OpenProj Лабораторная работа № 5. Отслеживание хода выполнения работ и фактических затрат с помощью OpenProj Управление человеческими ресурсами проекта Тестовые задания Практическая работа № 7 по теме «Управление человеческими ресурсами проекта» Практическая работа № 8 по теме «Разработка укрупненного календарного плана проекта» Практическая работа № 9 по теме «Анализ календарного плана проекта» Управление стоимостью проекта Лабораторная работа № 6. Расчет параметров состояния проекта Тестовые задания Управление рисками проекта Основные понятия управления рисками Идентификация рисков проекта Качественный анализ рисков Количественный анализ рисков Тестовые задания Практическая работа № 10 по теме «Управление рисками проекта» Управления качеством проекта Тестовые задания Практическая работа № 11 по теме «Управление качеством проекта» Управление коммуникациями проекта Тестовые задания Список использованной литературы �Содержание ВВЕДЕНИЕ Управление проектами – это известная во всем мире методология предпринимательской деятельности. Управление проектом по большей части является типовым методом управления бизнесом, следовательно, не применяется только в тех или иных редчайших ситуациях. Значительная часть работ в рядовых компаниях реализовывается как проекты, тем более что эффективное управление проектами является конкурентным преимуществом раскручивающихся компаний. В последние годы предприятия с серийным производством также переключаются на производство, в котором реализация заказа управляется как проект. Вместе с тем для большинства крупных компаний и холдингов некоторые нововведения уже реализуются в качестве проектов. Вступление Российской Федерации в рыночную экономику потребовало подъема уровня подготовки в области экономико-управленческой деятельности, создания специализированных методов планирования. Результатом этого стало прочное укрепление в различных сферах управления терминов: «проект» и «управление проектом»; проектный подход в данном случае крепко основался, как основной метод управления в ведущих компаниях [1–5]. В настоящем учебном пособии проанализированы важнейшие понятия и подходы инновационной методологии управления ИТ-проектами. В настоящей работе под ИТ-проектом понимается такой проект, который, как правило, применяется для отображения деятельности, тесно связанной с применением или разработкой определенной информационной технологии [5]. Подобное понимание ИТ-проектов включает весьма разнообразные сферы деятельности: создание программных приложений, разработку информационных систем, развертывание ИТ-инфраструктуры и т.п. Пособие включает практическое введение в программу планирования и управления проектами OpenProj. Посредствам OpenProj возможно анализировать проект в произвольной перспективе и стремительно переключаться от одного представления к иному. Посредствам всевозможных режимов просмотра информации о проекте и отчетов в OpenProj возможно найти виды работ, осуществление которых продвигается медленно или стоимость которых превосходит запланированный бюджет. Пособие адресовано студентам, обучающимся по специальности «Прикладная информатика» для аудиторных и самостоятельных занятий по дисциплинам «Проектный практикум» и «Проектирование ИТ-инфраструктуры предприятия». Материал, предоставленный в пособии, включает краткое изложение основ проектного управления, практические и лабораторные работы, последовательное выполнение которых позволяет освоить изучаемые дисциплины. В практических работах описаны проблемные ситуации, решение которых позволит научиться реализовывать определенные этапы ИТпроекта или принимать определенные управленческие решения. Лабораторные работы, в свою очередь, содержат краткие теоретические обоснования по созданию календарных планов проектов, по отслеживанию хода выполнения работ и фактических затрат проектов, по расчету параметров состояния проектов и методические рекомендации по их выполнению. В лабораторных работах № 1 и № 2 описаны способы построения календарного плана в электронных таблицах, в лабораторных работах № 3–5 – способы создания и управления проектами в OpenProj, а в лабораторной работе № 6 – способы расчета параметров состояния проекта. Учебное пособие составлено из материалов публикаций, указанных в списке использованной литературы. В результате освоения дисциплины обучающийся должен: �Содержание Знать: • понятие и основные элементы ИТ-инфраструктуры предприятия; • фазы жизненного цикла ИТ-проекта; • тенденции развития ИТ-индустрии; • понятие ИТ-стратегии; • стратегии автоматизации; подходы к проектированию; • содержание фаз жизненного цикла ИТ-проекта; • связанного с ИТ-проектом; • особенности приобретения ИТ и ИС; • методы оценки стоимости ИТ-проекта; • критерии выбора ИТ и ИС; • стратегии внедрения; • подходы к снижению уровня риска, • методы оценки эффективности ИС предприятия. Уметь: • • • • • • • • • выделять элементы ИТ-инфраструктуры; обосновывать принимаемые проектные решения; определять взаимосвязь между бизнес-стратегией и ИТ-стратегией предприятия; анализировать и делать обоснованный выбор подхода к проектированию; реализовывать фазы жизненного цикла ИТ-проекта; вырабатывать ИТ-стратегию; формировать команду разработчиков ИТ-проекта; ориентироваться на рынке ИТ-решений; оценивать экономическую эффективность ИТ-проекта. Иметь навыки и (или) опыт деятельности: • навыки проектирования ИТ-инфраструктуры предприятия с применением современных методов и инструментария; • навыки выбора элементов ИТ-инфраструктуры; • навыки анализа современного рынка ИТ и ИС; • управления ИТ-проектом; • выработки ИТ-стратегии предприятия; • навыки выбора стратегии внедрения ИС; • навыки выбора стратегии автоматизации; • навыки выбора стандарта и модели жизненного цикла ИТ-проекта; • навыки оценки экономической эффективности ИТ-инфраструктуры предприятия. �Содержание ПОНЯТИЕ И ОСНОВНЫЕ ЭЛЕМЕНТЫ ИТ-ИНФРАСТРУКТУРЫ ПРЕДПРИЯТИЯ Под ИТ-инфраструктурой предприятия понимается различное множество существующих в ней сервисов и систем, сетей, технических и программных средств, данных, автоматизированных процессов. Между различными частями ИТ-инфраструктуры существуют всевозможные взаимосвязи: один процесс может быть обеспечен несколькими автоматизированными системами, при этом системы могут обмениваться между собой данными, системы более низкого уровня могут послужить механизмами реализации для систем более высокого уровня и т.п. Одновременно с этим возможны как явные взаимосвязи, так и опосредованные, но вместе с тем очень значимыми. Например, если и в бухгалтерской, и в CRM-системах содержатся данные о контрагентах, возникает вопрос их координации. В случае если автоматизированная система получает нормативно-справочную информацию из второй системы по протоколу HTTP, то выходит, что ее работоспособность обуславливается работоспособностью HTTP-сервера, который возможно номинально не содержится ни в одной из этих систем. ИТ-инфраструктура предприятия – это не только лишь комплекс ИТ-решений, которые произвольным образом сведены в одном месте. Она выступает в качестве крупной (на порядки превосходящую масштабом всякую из собственных частей) интегрированной системы, обеспечивающей работу предприятия в целом. В этом случае, как и для всякой системы, ее надлежит целенаправленно проектировать и верно эксплуатировать. Если посмотреть с другой стороны, то ее размеры, сложность и сроки жизни подобны тому, что совершать действия с ней, как с обыкновенной автоматизированной системой, не удается. Проектирование и реализация такой системы от начала до конца для обычного человека сложно, так как содержало бы немало случайностей и всевозможных внешних влияний. На помощь в случае ИТ-инфраструктуры на место технического задания и технического проекта приходит ИТ-стратегия. Данная стратегия выступает в качестве системы приоритетов, правил и планов, которые позволяют достигать адекватности ИТ-инфраструктуры надобностям бизнеса. Реализация ИТ-стратегии требует владения всевозможной информацией о ней. Такая информация необходима всем представителям предприятия: ИТ-директору и его подчиненным, руководителям бизнес-подразделений, руководству организации, внешним исполнителям, пользователям, консультантам и т.п. Ориентировочный состав технической документации на ИТ-инфраструктуру предприятия представлен в таблице 1. Таблица 1 Состав технической документации на ИТ-инфраструктуру предприятия Докуме нт ИТ-стратегия Аудитория руководство компании; начальники бизнесподразделений; ИТ-специалисты Соде ржание Цели и задачи ИТ-подразделения, принципы его взаимодействия с бизнес-подразделениям, подход к информатизации компании, основные ИТ-активы, планы развития ИТ-инфраструктуры в среднесрочной перспективе, бюджетная и кадровая политика �Содержание Докуме нт Аудитория Корпоративный тезаурус Стандарты организации области ИТ все сотрудники и контрагенты организации ИТ-специалисты; в внешние исполнители Соде ржание Используемые в компании термины (как в области ИТ, так и в затрагиваемых предметных областях), их источники, переводы, примеры употребления Правила ведения нормативно-справочной информации, форматы данных, протоколы обмена данными, программные интерфейсы, управление требованиями, типовые технические решения, стиль программирования, управление версиями, управление конфигурациями, порядок испытания и тестирования систем, требования к документированию Описание процессов ИТ-специалисты; ИТ-подразделения, начальники бизнесSLA и регламенты подразделений; пользователи Услуги ИТ-подразделения и правила их предоставления бизнес-подразделениям, регламенты получения ИТуслуг бизнес-подразделениями и отдельными пользователями, внутренние процессы и процедуры ИТподразделения Схема информатизации компании руководство компании; начальники бизнесподразделений; ИТ-специалисты; внешние исполнители Кто чем и для чего пользуется: доступность сервисов и систем в разных подразделениях организации, автоматизированные и неавтоматизированные участки работы Схема информационных потоков ИТ-специалисты; внешние исполнители Точки поступления данных в системы, хранение данных, обмен данными между системами, дублирование данных и операций по их вводу Схема взаимной ИТ-специалисты; зависимости внешние исполнители сервисов и систем Использование сервисами и системами данных и механизмов, предоставляемых другими сервисами и системами, критические и некритические зависимости Тестовые задания Практическая работа № 1. по теме «Понятие и основные элементы ИТ-инфраструктуры предприятия» �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. ...это различное множество существующих сервисов и систем, сетей, технических и программных средств, данных, автоматизированных процессов. a) ИТ-инфраструктура предприятия – b) ИТ-стратегия – c) Информационная технология (ИТ) – d) ИТ-проект – 2. ...это процесс, использующий совокупность методов и средств реализации операций сбора, регистрации, передачи, накопления и обработки информации на базе программно-аппаратного обеспечения для решения управленческих задач экономического объекта. a) ИТ-инфраструктура предприятия – b) ИТ-стратегия – c) Информационная технология (ИТ) – d) ИТ-проект – 3. ...представляет собой систему приоритетов, правил и планов, позволяющих добиваться адекватности ИТ-инфраструктуры потребностям бизнеса: a) ИТ-инфраструктура предприятия; b) ИТ-стратегия; c) Информационная технология (ИТ); d) ИТ-проект. 4. Из представленного перечня выберите документы, входящие в документации на ИТ-инфраструктуру предприятия: a) корпоративный тезаурус; b) ИТ-стратегия; c) стандарты организации в области ИТ; d) ИТ-проект; e) описание процессов ИТ-подразделения, SLA и регламенты; f) ИТ-программа. комплект технической 5. Из представленного перечня выберите технологию, не предоставляющую пользователю возможности оказывать влияние на обработку данных: a) пакетная ИТ; b) диалоговая ИТ; c) сетевая ИТ; d) пользовательская ИТ. �Содержание 6. Из представленного перечня выберите технологию, предоставляющую пользователю телекоммуникационные средства доступа к территориально удаленным информационным и вычислительным ресурсам: a) пакетная ИТ; b) диалоговая ИТ; c) сетевая ИТ; d) пользовательская ИТ. 7. Из представленного перечня выберите тип технологий, основанных на локальном применении средств вычислительной техники, установленных на рабочих местах пользователей для решения конкретной задачи специалиста. Они не имеют централизованного автоматизированного хранилища данных, но обеспечивают пользователей средствами коммуникации для обмена данными между узлами сети: a) централизованные технологии; b) децентрализованные технологии; c) комбинированные технологии; d) мультимедийные технологии. 8. Основными целями использования ИТ, по мнению консалтинговой компании A.T. Kearney, являются… a) проникновение на новые рынки; b) внедрение новых продуктов и услуг; c) сокращение затрат; d) совершенствование внутренних операций; e) улучшение качества обслуживания; f) увеличение затрат; g) совершенствование внешних операций; h) снижение качества товаров и услуг. 9. Основной целью автоматизированной информационной технологии является… a) получение посредством переработки первичных данных информации нового качества, на основе которой вырабатываются оптимальные управленческие решения; b) только получение информации нового качества; c) получение посредством хранения и структуризации данных информации высокого качества, на основе которой вырабатываются определенные управленческие решения; d) получение, хранение и переработка информации. 10. Способ построения сети при использовании ИТ на предприятии прежде всего зависит от… a) требований управленческого аппарата к оперативности информационного обмена; b) управления всеми структурными подразделениями фирмы; c) квалификации сотрудников фирмы; d) технических средств, которые используются на предприятии. �Содержание 11. Из представленного перечня выберите основные проблемы, с которыми сталкиваются бизнесорганизации по всему миру: a) фрагментированность ИТ-приложения и данных; b) многоярусность системы, ее построение на разных платформах; c) отсутствие интеграции ИТ с бизнесом; d) слабость управленческих ИТ-процессов; e) интеграция ИТ с бизнесом; f) сильные управленческие ИТ-процессы; g) одноярусность системы, ее построение на одной платформе; h) нефрагментированность ИТ-приложений и данных. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 1 ПО ТЕМЕ «ПОНЯТИЕ И ОСНОВНЫЕ ЭЛЕМЕНТЫ ИТ-ИНФРАСТРУКТУРЫ ПРЕДПРИЯТИЯ» Задание 1 Согласно приведенным в таблице 2 пунктам сделаете сопоставление операционной и проектной деятельности предприятия. Результаты сопоставление предоставьте в виде таблицы 2. Таблица 2 Сопоставление операционной и проектной деятельности предприятия № Ряд сопоставле ний 1. Степень регламентации операций 2. Опорная организационная структура 3. Длительность 4. Связь со стратегией предприятия 5. Характерный результат Опе рационная де яте льность Прое ктная де яте льность Задание 2 Опираясь на собственное представление по проблемам управления проектами по внедрению информационных систем и/или существующего практического опыта участия в аналогичных проектах укажите не менее трех существенных причин неудач ИТ-проектов и предложите несколько способов предотвращения и исключения данных неудач. Результаты представьте в виде таблицы 3. Таблица 3 Причины неудач ИТ-проектов и действия по их предотвращению и исключению № 1. 2. 3. 4. 5. Причины не удач прое ктов Де йствия по пре дотвраще нию (проактивные ) Де йствия по исключе нию после дствий (ре активные ) �Содержание Задание 3 Для предоставления системного подхода к управлению проектами внедрения ИС, правильной организации и координации необходимых проектных работ руководство предприятия выработало постановление о разработке и внедрении процедуры, которая обеспечивает интеграцию процессов управления проектами. Для этого необходимо подготовить предложения по данному вопросу согласно предложенному плану. ● Необходимые мероприятия, которые позволят обеспечить интеграцию процессов на всех этапах выполнения проекта? ● Какова ориентировочная оценка затрат для осуществления данных предложений? ● Необходимые документы, которые надлежит разрабатывать для обеспечения интеграции? ● Необходимые инструменты и методы, которые позволят обеспечить управление процессом интеграции проекта? Контрольные вопросы: 1. Сформулируйте определение ИТ-инфраструктуры предприятия. 2. Определите главные тенденции развития ИТ-индустрии? 3. Определите понятие ИТ-стратегии предприятия. 4. Определите роль ИТ в построении ИС предприятия? 5. Укажите взаимосвязь бизнес-стратегии и ИТ-стратегии предприятия? 6. Укажите существенные элементы ИТ-инфраструктуры предприятия. 7. Определите важнейшие задачи повышения эффективности использования ИТ и ИС на предприятии. �Содержание ЖИЗНЕННЫЙ ЦИКЛ ИТ-ПРОЕКТА Цикл проекта (ЦП) выступает основным элементом представления проектного анализа. Жизненный цикл проекта – это время от первой затраты до последней выгоды проекта. В целом жизненный цикл проекта показывает развитие работы, которая ведется на различных этапах подготовки, реализации и эксплуатации проекта. В описание ЦП входит определение различных этапов разработки и реализации проекта. ЦП является некой определенной схемой или алгоритмом, посредствам которого устанавливается определенная последовательность действий на этапах разработки и внедрения проекта. Существенным при выделении фаз, стадий и этапов проекта может стать обозначение отдельных контрольных точек, при прохождении которых извлекается дополнительная (внешняя) информация и устанавливаются или оцениваются вероятные направления развития проектов. Реализация проекта может потребовать выполнения установленного количества всевозможных мероприятий и работ, которые могут быть разделены на две группы: ● ● основная деятельность, деятельность по обеспечению проекта. Данное разделение не может служить делением процесса осуществления проекта на фазы и стадии, так как предполагаемая деятельность зачастую совпадает во времени. К основной деятельности обычно относят: ● ● ● ● ● ● ● ● анализ проблемы, формирование целей проекта, базовое и детальное проектирование, выполнение технических работ, ремонт, сдачу проекта, эксплуатацию проекта, обслуживание и демонтаж оборудования и т. п. Деятельность по обеспечению проекта, в свою очередь, может быть разделена на: ● ● ● ● ● ● ● организационную, правовую, кадровую, финансовую, материально-техническую, коммерческую, информационную. Отчетливого и однозначного распределения данных работ в логической последовательности и во времени не существует (это относится также к фазам и этапам выполнения проекта), так как решающими являются цели и условия реализации проекта. Программой промышленного развития ООН (UNIDO) предоставлено собственное видение проекта как цикла, состоящего из трех отдельных фаз: прединвестиционной, инвестиционной и эксплуатационной. �Содержание Прединвестиционная фаза представлена следующими стадиями: ● определение инвестиционных возможностей, анализ альтернативных вариантов, ● предварительный выбор проекта – предварительное технико-экономическое обоснование, выводы по проекту и решение об инвестировании. Инвестиционная фаза представлена следующими стадиями: ● ● ● ● ● ● ● ● установление правовой, финансовой и организационной основ для осуществления проекта, приобретение и передача технологий, детальная проектная обработка и составление контрактов, приобретение земли, строительные работы и установка оборудования, предпроизводственный маркетинг, набор и обучение персонала, сдача в эксплуатацию и запуск. Фаза эксплуатации анализируется с точки зрения долгосрочных планов, а также и краткосрочных. В краткосрочном плане анализируется вероятное возникновение проблем, которые могут быть связаны с применением предпочтенной технологии, функционированием оборудования или с квалификацией персонала. В долгосрочном плане к анализу берется выбранная стратегия и определенные затраты на производство и маркетинг, а также полученная прибыль от продаж. Общим аспектом к распределению работ, принадлежащих к различным фазам и стадиям ЦП, может стать подход Всемирного банка. На рисунке 1 представлено шесть основных стадий, представляющих существенную роль в большей части проектов. Данные стадии обозначаются как: идентификация, разработка, экспертиза, переговоры, реализация и завершающая оценка. Настоящие стадии представлены двумя фазами: ● ● фаза проектирования – идентификация, разработка, экспертиза; фаза внедрения – переговоры, реализация и завершающая оценка. Рис. 1. Цикл проекта Идентификация – представляет собой первую стадию цикла проекта. Идентификация – имеет отношение к выбору или генерировании подобных значительных идей, позволяющие обеспечить выполнение существенных задач развития. Концепция проекта может быть определена: ● деятельностью частных или государственных организаций, желающих приобрести преимущества в применении новейших возможностей; �Содержание ● затруднениями или удерживаниями в ходе разработки, которые порождены нехваткой существенных производственных мощностей, малоразвитостью сервиса, нехваткой материальных и человеческих ресурсов или же административными или другими препятствиями; ● готовностью сформировать подходящие условия для создания соответственной инфраструктуры производства и управления; ● готовностью реализовать задачи, поставленные перед предприятием; ● потребностями и поиском допустимых путей их реализации; ● природными катаклизмами (наводнения, засухи, ураганы и землетрясения); ● возможностью предоставления полностью или частично неиспользованных материальных или человеческих ресурсов и вероятностью их применения в других областях; ● потребностью произвести дополнительные денежные вложения. Концепции проекта возникают также в результате: ● капиталовложения других стран, а также потенциалов, возникающих в результате работы по международным договорам; ● инициативы иностранных граждан или организаций произвести некое инвестирование; ● работы организаций по предоставлению двусторонней поддержки и настоящих проектов данных организаций в конкретной стране; ● преобладающих мнений экспертов или же общего согласия в рамках международного сообщества по таким вопросам, как состояние окружающей среды, жители, глобальные новости и т. д. На начальных стадиях проекта стоит поставить акцент на учете всевозможных идей от участников проекта. Отклонение от поставленных целей проекта и непричастность некоторых сторон сравнительно часто является причиной низкого качества реализации проекта. Установление целей предполагает процесс, идущий в двух комплементарных направлениях. Вместе с тем, что потребно уменьшение количества идей по отношению к обсуждаемому проекту, также стоит заметить, что отобранные идеи проекта должны быть детализированы в достаточной мере. Перед тем как утвердить замысел проекта, необходимо ознакомиться с: ● наличием существенных материальных и человеческих ресурсов; ● организационными преградами и государственным постановлениями, которые могут серьезно оказать влияние на рассматриваемый проект; ● объемом и характером спроса на продукцию или услуги, для дальнейшего получения выгоды от реализации проекта; ● порядком размера финансовой и экономической ценности вариантов проекта; ● порядком размера затрат как на первоначальные капиталовложения, так и на возмещение эксплуатационных затрат. Проект может считаться безошибочным и может быть передан на стадию разработки, в случае, если выполнены следующие условия: ● осуществлен отбор различных вариантов проекта; ● определены существенные проблемы, которые могут оказать влияние на участь проекта, и установлено, что они могут быть разрешимы; ● установлены возможные выгоды и затраты; ● определено существование совместной поддержки руководства и прочих участников проекта. Дальнейшей стадией цикла проекта является разработка. Детализация целей проекта и тех средств, с помощью которых эти цели достигаются, представляет существенную часть работы по созданию �Содержание проекта. Существуют различные пути достижения цели на данной стадии цикла. По мере детализации целей проекта и уменьшения количества вариантов и вариантов их осуществления проект становится конкретизированным, и его создание ведется на базе предпочтительных вариантов. В процессе создания проекта определенное место занимает скрининг – основной анализ осуществления проекта. Полагая, что необходимость подобного анализа очевидная, когда речь идет о значительных инфраструктурных проектах. Подобная проверка позволяет определить, есть ли необходимость для осуществления проекта и который из вариантов проекта является оптимальным для достижения его целей. Данный вариант рассмотрения необходим для установления реализуемости или аргументации проекта в общем с учетом его существенных параметров: ● ● ● ● ● ● коммерческую аргументацию, техническую реализуемость, координационную работу, воздействие на окружающую среду, социальные и культурные стороны, финансовую и экономическую производительность. Задачей скрининга не является выявление жизнеспособности конкретной идеи проекта для дальнейшего осуществления ее финансирования. Проверка дает возможность определить оптимальное из допустимых решений в установленных соглашениях и представить, как проект может модифицировать эти условия. Помимо перечисленных общих характеристик, методы скрининга не исключено что могут различаться один от другого точно так, как и рассматриваемые проекты. Охват и длительность проверки зависят от разновидности и характера проекта. При создании проекта основной проблемой может стать установление уровня его полноты. Для любой цели существует группа версий ее достижения. Понятно, что достигнут определенные цели тяжелей, чем другие. В связи с этим, цели проекта для успешной реализации должны быть предельно простыми. Экспертизу проекта должны осуществлять не только люди, проводящие анализ и разработку проекта, но и сторонние эксперты. Экспертиза дает возможность провести доскональный анализ всех сторон проекта и его результатов. На данном этапе закладывается ядро для осуществления проекта. План проекта, установленный на этапе экспертизы, является основой для оценивания благополучности проекта. Экспертизе могут подвергаться и сам проект, и организация, реализовавшая данный проект. Задачей аудита проекта является установление того, насколько основательные результаты проекта превзойдут его негативные последствия. Коммерческая экспертиза требует проведения анализа: ● ● ● спроса на продукцию, мероприятий по маркетингу и вероятных цен; доступности и качества ресурсов и их стоимостной оценки; затрат и прибыли для определения коммерческой жизнеспособности субъекта. Техническая экспертиза содержит оценку: ● ● ● ● доступности и качества необходимых для проекта ресурсов; процессов, материалов, оборудование и надежности технических систем; уровня сервиса и надежности существующей инфраструктуры, которую будет использовать проект; масштаба проекта; �Содержание ● ● пригодности технического плана для местоположения проекта; сроков и графика выполнения технических заданий для реализации проекта. Экологическая экспертиза позволяет оценить влияние проекта на окружающую среду в следующих направлениях: ● ● ● ● снижение биологического разнообразия; перевозка, использование или отдаление опасных или токсичных отходов; загрязнение воздушного бассейна, грунтов и водоемов; засоленность и заболоченность земель. Социальная экспертиза должна ответить на вопросы: ● каким образом структура семьи улучшает или ухудшает перспективы для успеха проекта; ● имеют ли мелкие производители доступ к информации о более широких рынках сбыта и региональной экономике; ● в какой мере люди, которые должны получить выгоду от проекта, имеют доступ или контролируют производственные ресурсы района; ● каким образом система землепользования и землевладения, а также возможности альтернативного трудоустройства могут повлиять на степень заинтересованности в видах деятельности, предложенных согласно проекту, для предполагаемых получателей выгоды от его реализации. Институциональные аспекты экспертизы содержат: ● мотивацию формирования команды проекта; ● определение организационных изменений, необходимых для успешной реализации проекта; ● оценку потенциала и структуры организации, которая осуществляет проект; ● обоснование возможностей реализации проекта в существующей политической, экономической и правовой среде; ● определение критериев, которые используются для оценки правильной и рациональной организации. Финансовая экспертиза дает возможность проверить финансовую жизнеспособность проекта и определить мероприятия, необходимые для обоснованного финансового управления проектом. Кроме того, финансовая экспертиза может также принимать во внимание следующие факторы: ● рентабельность проекта; ● финансовые последствия для заказчиков или инвесторов проекта, включая оценку рисков; ● стандарты финансовой деятельности, которых следует придерживаться во время осуществления проекта. Экономическая экспертиза позволяет оценить: ● является ли оправданным использование проектом национальных ресурсов учитывая наличие конкурентного спроса на эти ресурсы; ● выгоды, которые будут получены в результате реализации проекта, для общества в целом; ● необходимые стимулы для разных участников проекта. После стадии экспертизы проекта представители инвесторов проводят официальную встречу, т.е. переговоры, чтобы подтвердить сроки и условия его финансирования. Эти договоренности потом формулируются как правовые обязательства, изложенные в документах, которые подписываются обеими сторонами. Если переговоры ведутся по проекту кредитного документа, то проект состоит из �Содержание четырех основных разделов: ● характеристика заемщика и кредитора; ● общее описание проекта и категории товаров и услуг с установлением их объема, на который могут быть потрачены кредиты; ● сумма, сроки и процентная ставка по кредиту; ● другие обстоятельства кредитования. Заказчик и инвестор могут договориться о действиях, направленных на улучшение работы, и зафиксировать данную договоренность в обязательствах по таким вопросам: ● ● ● ● установление плана работы; определение процента прибыли инвестору; мероприятия по снижению расходов, дебиторской задолженности и оптимизации запасов; как реорганизовать управление предприятием. Реализация проекта начинается с планирования. В плане осуществления проекта существенной частью является система достижения согласия относительно распределения ролей, ответственности и прав всех участников проекта. Следующим этапом реализации являются проведение переговоров и составление договоров на поставку сырья и технологий, оборудования, материалов, а также составление соглашений на выполнение субконтрактных работ. На этой стадии может быть реализовано инженерно-техническое проектирование (дизайнерские работы), строительство как самого объекта, так и необходимых инфраструктурных элементов проекта, производственный маркетинг и обучение. Также существенным на стадии реализации является контроль. Выделяются три аспекта проверки проекта. Во-первых, инженерно-технический надзор за техническими аспектами проекта, который выполняют технические специалисты, контролирующие, насколько производственные мощности, изготавливаемая продукция, услуги соответствуют техническим требованиям. Во-вторых, контроль заказчиком хода выполнения проекта в общем. В компетенцию контроля входит надзор за ходом реализации проекта и предложения относительно всевозможных модификаций в разработанной структуре или плане реализации проекта. Задачами такого контроля являются: защита участников проекта от внезапных отрицательных неожиданностей, определенный вклад в имеющуюся сумму знаний о всевозможных подходах к проблемам, избежание аналогичных проблем при разработке и реализации других проектов. В-третьих, контроль инвесторами, который имеет две цели – обеспечить реализацию целей проекта и погашение кредита или получение запланированной прибыли от инвестиций. После стадии реализации необходимо оценить риски проекта и вероятный вклад проекта в стабильность жизни людей. Завершающая оценка предусматривает ретроспективный анализ проекта. Она ведется преимущественно тогда, когда проект после реализации находился в эксплуатации от двух до трех лет. Существенным моментом проведения подобной итоговой оценки является определения причин успеха или неудачи проекта. Это дает вероятность обнаружить особенности, которые могут с успехом применяться в прочих проектах. Завершающая оценка также предоставляет менеджерам и заинтересованным пользователям информацию относительно того, на сколько эффективно и полно проекты достигают ожидаемых результатов. Ретроспективность – преимущество завершающей оценки. С этой точки зрения, в ходе оценки можно �Содержание найти пути, с помощью которых удалось бы достичь лучших результатов. Единый стандарт оценки отсутствует, тем не менее, для достижения наибольшей результативности оценки надлежит соблюдать следующие всеобщие условия: ● руководители разработкой и реализацией проекта, должны завершающей оценки; ● объективность оценивания; ● результаты оценки надлежит сделать доступными. участвовать в проведении Процесс проверки рекомендуется проводить в момент, когда итоги могут оказаться наиболее полезными для планирования дальнейших проектов [6]. Тестовые задания Практическая работа № 2 по теме «Жизненный цикл ИТ-проекта» �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Продолжительность времени от первой затраты до последней выгоды проекта называется… a) комплексным циклом проекта; b) жизненным циклом проекта; c) исходным циклом проекта; d) полным циклом проекта. 2. Реализация проекта требует выполнения определенного количества всевозможных мероприятий и работ, которые для удобства рассмотрения можно разделить на следующие группы… a) основную и дополнительную деятельность проекта; b) основную деятельность и деятельность по проверке проекта; c) основную деятельность и деятельность по обеспечению проекта; d) главную и второстепенную деятельность. 3. К основной деятельности проекта обычно относят… a) формирование целей проекта; b) правовую деятельность; c) кадровую деятельность; d) базовое и детальное проектирование; e) сдачу проекта; f) финансовую деятельность; g) анализ проблемы; h) эксплуатацию проекта; i) организационную деятельность; j) информационную деятельность. 4. В деятельности по обеспечению проекта могут быть выделены следующие части… a) формирование целей проекта; b) правовую деятельность; c) кадровую деятельность; d) базовое и детальное проектирование; e) сдачу проекта; f) финансовую деятельность; g) анализ проблемы; h) эксплуатацию проекта; i) организационная деятельность; j) информационная деятельность. �Содержание 5. Программой промышленного развития ООН (UNIDO) предложено видение проекта как цикла, состоящего из следующих фаз… a) начальной, средней, конечной; b) прединвестиционной, инвестиционной, эксплуатационной; c) предшествующей, развивающей, завершающей; d) предэксплуатационной, эксплуатационной, постэксплуатационной. 6. …имеет следующие стадии: определение инвестиционных возможностей, анализ альтернативных вариантов, предварительный выбор проекта – предварительное технико-экономическое обоснование, выводы по проекту и решение об инвестировании. a) прединвестиционная фаза; b) инвестиционная фаза; c) постинвестиционная фаза; d) фаза эксплуатации. 7. …имеет следующие стадии: установление правовой, финансовой и организационной основ для осуществления проекта, приобретение и передача технологий, детальная проектная обработка и составление контрактов, приобретение земли, строительные работы и установка оборудования, предпроизводственный маркетинг, набор и обучение персонала, сдача в эксплуатацию и запуск. a) прединвестиционная фаза; b) инвестиционная фаза; c) постинвестиционная фаза; d) фаза эксплуатации. 8. …как стадия цикла определяет выбор или генерацию базовых идей, обеспечивающих выполнение важнейших задач развития. a) экспертиза; b) идентификация; c) разработка; d) реализация. 9. Проект может считаться выверенным и готовым для передачи на стадию разработки при соблюдении следующих условий… a) выполнен отбор альтернативных вариантов проекта; b) идентифицированы основные организационные и политические проблемы, влияющие на судьбу проекта; c) определены ожидаемые выгоды и затраты, существует поддержка проекта. 10. Обоснование целесообразности осуществления проекта, а также выбор вариантов его реализации с точки зрения оптимальности для достижения цели выполняются на основе… a) синтеза; b) анализа, скрининга; c) дифференциации; d) интеграции. �Содержание 11. Детальный анализ всех аспектов проекта, а также последствий его реализации определяется на этапе... a) экспертизы; b) идентификации; c) разработки; d) реализации. 12. К разновидностям экспертизы проекта относятся… a) коммерческая, финансовая, экономическая; b) экологическая, социальная; c) экологическая, финансовая, экономическая; d) коммерческая, техническая, экологическая, социальная, финансовая, экономическая. 13. Ретроспективный анализ проекта осуществляется на этапе… a) экспертизы; b) завершающей оценки; c) разработки; d) реализации. 14. Структура, содержащая процессы, действия и задачи, решаемые в ходе разработки, функционирования и сопровождения ИТ-проекта в течение ЦП от определения требований до его завершения называется... a) методологией управления ИТ-проектами; b) универсальной концепцией менеджмента; c) непосредственным процессом разработки; d) моделью жизненного цикла проекта. 15. Объектами стандартизации в сфере ИТ не являются… a) b) c) d) e) конструкторские документы; цены на проекты; модели жизненного цикла; требования к безопасности хранения и передачи информации и способы ее обеспечения; форматы хранения данных, обмена и передачи данных. 16. Итерактивную модель разработки предлагает… a) Microsoft Solution Framework (MSF); b) Custom Development Method; c) Extreme Programming (XP); d) Rational Unified Process (RUP). 17. Фазами, которые включает в себя Rational Unified Process (RUP), являются… a) только начало и внедрение; b) только исследование, построение и внедрение; c) начало, исследование, построение и внедрение; d) только начало, построение и внедрение. �Содержание 18. Microsoft Solution Framework (MSF) сходна с RUP и включает следующие фазы… a) анализ, проектирование, разработку, стабилизацию; b) исследование, построение и внедрение; c) начало, исследование, построение и внедрение; d) проектирование, разработку. 19. На разработку бизнес-приложений в большей степени ориентирована… a) Microsoft Solution Framework (MSF); b) Custom Development Method; c) Extreme Programming (XP); d) Rational Unified Process (RUP). 20. Наиболее часто говорят о следующих моделях жизненного цикла… a) каскадной, водопадной и последовательной; b) итеративной, инкрементной и смешанной; c) спиральной, эволюционной и модели Боэма; d) каскадной, итеративной, спиральной. 21. Моделью, предполагающей строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе является... a) каскадная модель; b) итеративная модель; c) спиральная модель; d) модель Моэма. 22. Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель… a) может применяться; b) не должна применяться; c) обязательна к применению. 23. Моделью, предполагающей разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом, является… a) каскадная модель; b) итеративная модель; c) спиральная модель; d) модель Моэма. �Содержание 24. Подход к разработке ИС, заключающийся в ее декомпозиции (разбиении) на автоматизируемые функции, называется… a) модульным; b) объектно-ориентированным; c) структурным; d) сервис-ориентированным. 25. Подход, использующий объектную декомпозицию, когда статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами, называется… a) модульным; b) объектно-ориентированным; c) структурным; d) объектным; e) сервис-ориентированным. 26. Модульный подход к разработке программного обеспечения, основанный на использовании распределенных, слабо связанных компонентов, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам, называется… a) модульным; b) объектно-ориентированным; c) структурным; d) сервис-ориентированным. 27. В самом общем случае SOA предполагает наличие следующих участников… a) поставщика сервиса, потребителя сервиса и посредника сервисов; b) поставщика сервиса, источника сервиса и посредника сервиса; c) потребителя сервисов, приоритетов сервисов и поставщика сервиса; d) поставщика сервиса, потребителя сервиса и реестра сервисов. 28. Стратегической ценностью SOA не является… a) типизация реализации проектов; b) повышение производительности; c) сокращение времени реализации проектов, или «времени выхода на рынок»; d) более быстрая и менее дорогая интеграция приложений и интеграция B2B. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 2 ПО ТЕМЕ «ЖИЗНЕННЫЙ ЦИКЛ ИТПРОЕКТА» Задание 1 Установлено, что сокращение эффективности проектов внедрения связано с несовместимостью или конфликтностью основных компонентов среды (структура организации, уровень знакомства будущих пользователей и членов команды проекта с применяемыми технологиями, конкуренция за ресурсы предприятия с прочими проектами, региональная и национальная специфика: контрагенты предприятия, региональные постановления и распоряжения, общая культура ведения предпринимательской деятельности) с их целями, организацией и методами управления. Выработайте перечень отдельных работ, которые направлены на обеспечение координации проекта с его средой в области показанных задач. Заполните таблицу 4. Таблица 4 Перечень отдельных работ № Работы, направле нные на де йствующих лиц Задачи управле ния прое ктами 1. Определение проекта 2. Организация и формирование команды проекта 3. Создание бюджета 4. Авторизация работ и начало исполнения 5. Контроль исполнения расписания, бюджета и т.п. 6. Оценка хода работ проектом 7. Закрытие проекта планов, расписаний Работы, направле нные на ключе вые факторы и планов, и руководство Задание 2 Предоставьте формальное определение методологии, метода и стандарта. Подберите примеры методологий, методов и стандартов в разрезе предметных областей, приведенных в таблице 5. �Содержание Таблица 5 Примеры методологий, методов и стандартов № Область знаний 1. Управление бизнес-процессами 2. Управление проектами 3. Проведение ТЭО 4. Проектирование информационных систем 5. Моделирование бизнес-процессов Ме тодология Контрольные вопросы: 1. Понятие жизненного цикла ИТ-проекта. 2. Укажите стандарты и модели жизненного цикла ИТ-проекта. 3. Укажите критерии выбора модели жизненного цикла ИТ-проекта? Ме тод Стандарт �Содержание ИНИЦИАЦИЯ ПРОЕКТА Под управлением проектом понимается деятельность, направленная на последовательное достижение ожидаемых результатов в условиях трех ограничений. Она требует интегрального управления многими процессами, их взаимодействием, поиска компромиссов [3]. Сегодня управление проектами вылилось в самостоятельную дисциплину со своими стандартами, методикой, сводом знаний. Она рассматривает процессы, общие для всех проектов и независящие от предметных областей. С целью структурирования процессы управления проектом принято делить на области знаний [5]. 1. Управление интеграцией. 2. Управление содержанием. 3. Управление сроками. 4. Управление стоимостью. 5. Управление качеством. 6. Управление рисками. 7. Управление человеческими ресурсами. 8. Управление коммуникациями. 9. Управление конфигурацией. Управление интеграцией включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координирования различных процессов и действий по управлению проектом в рамках групп процессов управления проектом. Таким образом, целью данного процесса является достижение эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Процессы, входящие в состав управления интеграцией: ● ● ● ● ● ● ● ● Разработка ТЭО проекта. Разработка устава проекта. Разработка плана управления проектом. Руководство и управление исполнением проекта. Осуществление интегрированного управления изменениями. Оценка альтернатив развития проекта. Планирование закрытия проекта и перехода в стадию эксплуатации. Завершение проекта. Управление содержанием включает в себя процессы и действия, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект. Процессы, входящие в состав управления содержанием: ● ● ● ● Формирование требований проекта. Формирование ИСР. Определение содержания проекта. Определение результатов всех стадий ЖЦ ИС. �Содержание ● ● ● ● ● ● Оценка реализуемости требований проекта. Подтверждение содержания проекта. Определение уточненных системных требований. Мониторинг содержания и объема проекта. Оценка готовности пользователей к работе в системе. Планирование обучения конечных пользователей. Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта. Процессы, входящие в состав управления сроками проекта: ● ● ● ● ● Формирование списка работ проекта. Определение последовательности работ проекта. Оценка трудоемкости и продолжительности работ. Разработка базового расписания проекта. Контроль и управление расписанием проекта. Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета. Процессы, входящие в состав управления стоимостью проекта: ● ● ● ● Оценка стоимости проекта. Разработка сметы проекта. Разработка базового плана по стоимости. Управление стоимостью проекта. Процессы управления качеством проекта объединяют все осуществляющиеся в исполняющей организации операции, определяющие политику, цели и распределение ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, для которых он был предпринят. Управление качеством осуществляется посредством системы управления, предусматривающей определенные правила, процедуры и процессы по планированию качества, обеспечению качества и контролю качества, а также операции по их совершенствованию. К процессам управления качеством проекта относятся: ● ● ● ● ● ● Формирование программы качества проекта. Формирование базовой линии требований проекта. Управление требованиями проекта. Осуществление обеспечения качества. Тестирование. Приемка результатов. Процесс управления рисками тесно связан с общим жизненным циклом проекта. На ранних этапах преобладают риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. На стадии реализации доминируют технологические риски, далее возрастает роль рисков, связанных с поддержкой и сопровождением системы. На протяжении всего жизненного цикла проекта возникают новые риски, что требует проведения дополнительных операций анализа и планирования. Согласно ГОСТ Р ИСО/МЭК 152888-2005 цель процесса управления рисками заключается в снижении последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков или ухудшения технических характеристик. В ходе данного процесса проводятся определение, оценка, обработка и мониторинг рисков, возникающих в течение �Содержание полного жизненного цикла, а также вырабатывается реакция на каждый риск в терминах реализации соответствующих мер противодействия риску или его принятия. К процессам управления рисками проекта относятся: ● ● ● ● ● ● Планирование управления рисками. Идентификация рисков. Качественный анализ рисков. Количественный анализ рисков. Планирование реагирования на риски. Мониторинг и управление рисками. Управление человеческими ресурсами проекта – это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта). К процессам управления человеческими ресурсами проекта относятся: ● ● ● ● ● Планирование человеческих ресурсов. Набор команды проекта. Оценка доступности. Развитие и оценка команды проекта. Организация инфраструктуры проекта. Управление коммуникациями проекта – это процессы идентификации и эффективного обеспечения всех участников проекта информацией о проекте, а также создания единого образа проекта внутри организации. К ним относятся: ● ● ● Идентификация участников проекта. Формирование стратегии и плана коммуникаций. Реализация плана коммуникаций и сбор обратной связи. Управление конфигурацией – процесс управления аппаратными средствами, программным обеспечением, данными, а также документацией в ходе разработки, тестирования и использования информационных систем. Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны. К процессам управления конфигурацией проекта относятся: ● ● ● ● ● ● ● Идентификация объектов управления конфигурацией. Планирование инфраструктуры стадии разработки. Установление базовой линии конфигурации проекта. Оценка соответствия базовой линии конфигурации. Контроль конфигурации выделенных элементов проекта. Обеспечение целостности элементов конфигурации. Реконфигурация инфраструктуры проекта. Тестовые задания Разработка технико-экономического обоснования Разработка устава проекта Практическая работа № 3 по теме «Разработка устава проекта» �Содержание Идентификация и анализ участников проекта Практическая работа № 4 по теме «Идентификация и анализ участников проекта» Практическая работа № 5 по теме «Идентификация и анализ участников проекта» �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Модель жизненного цикла информационных систем состоит из следующих стадий… a) разработки и внедрения, эксплуатации и поддержки проекта; b) планирования проекта, проектирования, разработки и внедрения, эксплуатации и поддержки, утилизации и обновления; c) планирования проекта, проектирования, разработки и внедрения проекта; d) проектирования, разработки и внедрения проекта. 2. Оценка новых возможностей в деловой сфере, разработка предварительных системных требований и проверка их осуществимости – это… a) планирование проекта; b) проектирование проекта; c) разработка и внедрение проекта; d) эксплуатация и поддержка проекта. 3. Создание проекта системы, удовлетворяющей требованиям приобретающей стороны и которая может быть реализована, испытана, оценена, применена по назначению, а в последующем списана и/ или обновлена – это… a) планирование проекта; b) проектирование проекта; c) разработка и внедрение проекта; d) эксплуатация и поддержка проекта. 4. Настройка системы в соответствии с требованиями приобретающей стороны, тестирование системы, реализация соответствующих организационно-технических мероприятий, а также развертывание поддерживающих систем, направленных на обеспечение корректной эксплуатации внедренного продукта – это… a) планирование проекта; b) проектирование проекта; c) разработка и внедрение проекта; d) эксплуатация и поддержка проекта. 5. Использование продукта в заданных продолжительной результативности – это… a) планирование проекта; b) проектирование проекта; c) разработка и внедрение проекта; d) эксплуатация и поддержка проекта. условиях функционирования и обеспечение �Содержание 6. Обеспечение удаления рассматриваемой системы и связанных с нею обслуживающих и поддерживающих организационно-технологических подсистем, поддержка планирования перехода на новую версию текущей или на абсолютно новую систему – это… a) планирование проекта; b) проектирование проекта; c) разработка и внедрение проекта; d) утилизация и обновление проекта. 7. Достижение эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта – это… a) управление человеческими ресурсами; b) управление стоимостью; c) управление содержанием; d) управление конфигурацией; e) управление сроками; f) управление интеграцией; g) управление рисками; h) управление качеством; i) управление коммуникациями. 8. Процессы и действия, обеспечивающие включение в проект всех тех и только тех работ, необходимые для успешного выполнения проекта составляют… a) управление человеческими ресурсами; b) управление стоимостью; c) управление содержанием; d) управление конфигурацией; e) управление сроками; f) управление интеграцией; g) управление рисками; h) управление качеством; i) управление коммуникациями. 9. Процессы, обеспечивающие своевременное завершение проекта составляют… a) управление человеческими ресурсами; b) управление стоимостью; c) управление содержанием; d) управление конфигурацией; e) управление сроками; f) управление интеграцией; g) управление рисками; h) управление качеством; i) управление коммуникациями. �Содержание 10. Процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета составляют… a) управление человеческими ресурсами; b) управление стоимостью; c) управление содержанием; d) управление конфигурацией; e) управление сроками; f) управление интеграцией; g) управление рисками; h) управление качеством; i) управление коммуникациями. 11. Комплекс осуществляющихся в исполняющей организации операций, определяющих политику, цели и распределение ответственности в области качества проекта – это… a) b) c) d) e) f) g) h) i) управление человеческими ресурсами; управление стоимостью; управление содержанием; управление конфигурацией; управление сроками; управление интеграцией; управление рисками; управление качеством; управление коммуникациями. 12. Снижение последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков или ухудшения технических характеристик, называется управлением... a) человеческими ресурсами; b) стоимостью; c) содержанием; d) конфигурацией; e) сроками; f) интеграцией; g) рисками; h) качеством; i) коммуникациями. �Содержание 13. Процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта, называется управлением... a) человеческими ресурсами; b) стоимостью; c) содержанием; d) конфигурацией; e) сроками; f) интеграцией; g) рисками; h) качеством; i) коммуникациями. 14. Процесс идентификации и эффективного обеспечения всех участников проекта информацией о проекте, а также создания единого образа проекта внутри организации, называется управлением… a) человеческими ресурсами; b) стоимостью; c) содержанием; d) конфигурацией; e) сроками; f) интеграцией; g) рисками; h) качеством; i) коммуникациями. 15. Процесс управления аппаратными средствами, программным обеспечением, данными, а также документацией в ходе разработки, тестирования и использования информационных систем, называется управлением… a) человеческими ресурсами; b) стоимостью; c) содержанием; d) конфигурацией; e) сроками; f) интеграцией; g) рисками; h) качеством; i) коммуникациями. �Содержание РАЗРАБОТКА ТЕХНИКО-ЭКОНОМИЧЕСКОГО ОБОСНОВАНИЯ Традиционно основной целью подготовки технико-экономического обоснования (ТЭО) ИТ-проекта является получение финансирования на реализацию соответствующей инициативы. Кроме того, корректно составленное ТЭО может решать следующие задачи: ● приоритет проектов в условиях ограниченных ресурсов; ● установление совокупности организационно-технологических мероприятий по обеспечению заявленных успехов от реализации проекта; ● обеспечение заинтересованности руководителей предпринимательских подразделений в проекте; ● вырабатывание основания для оценки соответствия результатов проекта и изначальных планов. Наряду с обозначенными задачами ТЭО возможно включение входной информации в устав проекта, рассматриваемый как основной документ интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную входную информацию, рекомендуется структурировать информацию о выгодах ИТ-проекта таким образом (см. таблицу 6). Таблица 6 Матрица структурирования выгод ИТ-проекта Характе р возде йствия на пре дпринимате льскую де яте льность Создание новых возможностей Повышение эффективности операций Отказ от операций Денежные Сте пе нь опре де ле нности Количественные Измеримые Качественные В соответствии с предлагаемым подходом выгоды в области предпринимательства можно систематизировать по двум факторам: 1) характеру воздействия на предприятие, 2) степени определенности идентифицированных выгод. В результате, любая выгода по проекту размещается «на пересечении» соответствующих значений этих двух факторов. Использование матрицы структурирования выгод начинается с определения характера воздействия на предприятие всякой выгоды. Установлены три типа воздействия: 1. Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам. 2. Повышение эффективности операций: функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно. �Содержание 3. Отказ от операций: информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов. После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности: наблюдаемые (качественные), измеримые, количественные, финансовые. Качественные выгоды могут быть зафиксированы на уровне экспертного мнения или суждения. Данный тип выгод вполне допустим, тем не менее, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для «переноса» качественных выгод в более объективные категории. Измеримые выгоды поддаются измерению. В расположении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения. Аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности. Финансовые выгоды – это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат «обогащения» количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель «выгоды – затраты») и расчета инвестиционных показателей: NPV (чистой приведенной стоимости), IRR (внутренняя норма доходности), периода окупаемости. Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории – наблюдаемой (качественной). И по ходу анализа необходимо как можно большее количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. �Содержание РАЗРАБОТКА УСТАВА ПРОЕКТА Устав проекта – это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава. Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта. К информации, имеющей ключевое значение для составления устава, относятся: ● ● ● ● ● стратегические и тактические цели организации-заказчика; формулировка требований организации-заказчика; ТЭО; контракт; внутрикорпоративная методология управления проектами и соответствующие политики. В уставе проекта должны быть отражены следующие требования: 4. Название проекта. Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. 5. Бизнес-причина возникновения проекта. Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте. 6. Бизнес-цель. Должна быть сформулирована заказчиком, исходя из стратегических и тактических целей компании. 7. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта. Видение организацией-заказчиком, как правило высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта. �Содержание 8. Расписание основных контрольных событий. На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий – это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств. 9. Участники проекта. Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. 10. Окружение проекта. Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика – к использованию его результатов. 11. Допущения относительно организации и окружения, а также внешние допущения. Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. При составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе. 12. Ограничения относительно организации и окружения, а также внешние ограничения. Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ. При составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом. 13. Объем денежных средств, выделенных на достижение бизнес-цели. На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от порядка -20% до 100%. 14. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды (руководителя проекта, спонсора, координатора). Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта – объединение усилий всех лиц, �Содержание участвующих в проекте. Для решения этой задачи руководитель проекта наделяется правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Роль спонсора проекта обычно берет на себя менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект. Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта. Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта. В проект рекомендуют включать руководителей и двух спонсоров проекта – по одному от заказчика и исполнителя. Администратор (координатор) проекта – это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. Устав проекта является установочным документом, описывающим связь проекта с операционной деятельностью компании. По этой причине внесение значительных изменений в текст данного документа не рекомендуется, а при возникновении такой обоснованной необходимости стоит разработать новый устав проекта, более полно отвечающий реалиям реализуемого проекта. В то же время для обеспечения контроля версионности в процессе разработки устава проекта необходимо использовать лист управления документом. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 3 ПО ТЕМЕ «РАЗРАБОТКА УСТАВА ПРОЕКТА» В соответствии с требованиями к уставу проекта необходимо создать устав проекта внедрения автоматизированной системы управления «Первый вуз Алтая» согласно описанным условиям в проблемной ситуации. Проблемная ситуация В ходе осуществления поставленных задач управления проектом по внедрению автоматизированной системы управления высшим учебным заведением (автоматизированной системы управления «Первый вуз Алтая») в Алтайском государственном педагогическом университете согласно соглашению, приведенному ниже необходимо разработать пакет проектных документов. Руководство Алтайского государственного педагогического университета в ходе реализации федеральной целевой программы развития образования и с целью решения задачи повышения эффективности операционной деятельности вуза, и формирования информационно-технологического фундамента для дальнейшего развития научного потенциала и образовательных услуг вуза приняло решение о внедрении автоматизированной системы управления «Первый вуз Алтая». Руководство вуза предполагает, что внедряемая ИТ-система даст возможность для обеспечения: ● организации системы электронного документооборота как внутри университета, так и за его пределами; ● эффективности управления высшим учебным заведением; ● интенсификации научных исследований; ● администрирования учебного процесса и научной деятельности; ● включения в единую университетскую сеть; ● организации интенсивного учебного процесса с использованием современных средств обучения; ● включения в мировое информационное пространство. Представителями со стороны вуза были выражены следующие требования: ● Увеличение результативности применения существенных активов и ресурсов вуза. ● Разработка интегрированного ИТ-решения на базе гибкой, тиражируемой и быстро реагирующей на изменения платформы с единым пользовательским интерфейсом. ● Рост прозрачности функционирования и управляемости вуза за счет обеспечения информации в достаточном аналитическом разрезе для принятия оперативных управленческих решений администрацией вуза. ● Поддержка совместного использования информации разными подразделениями вуза и иерархически-ролевой доступ к ней. ● Урезание административно-управленческих косвенных затрат, в том числе на закрытие финансовой отчетности за период (месяц, квартал, год). На выполнение проекта отводится 15 месяцев с датой окончания не позднее начала ноября 2019 года. Объем денежных средств, выделенных вузом на реализацию проекта, составляет 10,5 млн рублей. Реализация проекта будет произведена силами стороннего исполнителя, системного интегратора «ИТГрафикс». �Содержание ИДЕНТИФИКАЦИЯ И АНАЛИЗ УЧАСТНИКОВ ПРОЕКТА На начальной фазе жизненного цикла информационной системы, фазе планирования, целевой группой всегда является руководство компании, на которое следует обращать особое внимание и наиболее тесно взаимодействовать с ним. Кроме того, на данной фазе руководство компании будет и единственной точкой опоры проекта в организации, поэтому нужно четко себе представлять, чем отличаются руководители среднего звена от прочих сотрудников. Заинтересованная сторона (участник) – это любое лицо, которое само оказывает влияние на проект или подвергается влиянию со стороны проекта и результатов его реализации [5]. Процесс идентификации заинтересованной стороны стоит начинать с построения карты участников проекта, на которой можно произвести классификацию участников проекта по различным категориям. В качестве примера предлагается следующий вариант карты заинтересованных сторон проекта, представленный на рисунке 2. При разработке карты заинтересованных сторон проекта всегда стоит помнить следующие рекомендации. 1. Организация не является единым целым, но представляет собой совокупность отношений между различными заинтересованными сторонами. Построение карты заинтересованных сторон есть первый шаг на пути выявления взаимосвязей между ними. 2. Необходимо выявить всех участников проекта, и в этом аспекте построение красивых и однозначных схем является вторичным по отношению к значимости формирования исчерпывающего списка. 3. Карта заинтересованных сторон не является статической, по мере продвижения проекта она будет уточняться: изначально включенные участники могут быть исключены из рассмотрения, а на поздних этапах могут быть идентифицированы новые. Рис. 2. Пример карты участников проекта После выполнения идентификации заинтересованных сторон следует анализ участников проекта, в рамках которого необходимо выяснить уровень воздействия каждого из участников на проект и произвести оценку их вовлеченности в проект. Для анализа воздействия участников на проект рекомендуется использовать шаблон, приведенный в таблице 7. �Содержание Таблица 7 Анализ воздействия участников проекта Сильное СПОНСОРЫ: уделять значительное внимание их требованиям АГЕНТЫ: активно привлекать их в проект Слабое ВНЕШ НИЕ УЧАСТНИКИ: информировать их по мере необходимости ПОТЕНЦИАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ: привлекать их в проект по мере необходимости Слабое Сильное ---------ПРИОРИТЕТ------Степень организационного влияния участников проекта Воздействие участников на проект внедрения ИС ----------------------УЧАСТИЕ--------------------- Анализ воздействия производится в разрезе двух аспектов. 1. Степень организационного влияния участника проекта. Степень участия заинтересованной стороны проекта в принятии стратегически важных для компании решений, ее влияние на реализацию различных инициатив. Крайне важно при подобном анализе не упустить из рассмотрения и неформальных лидеров организации. 2. Воздействие участников на реализуемый ИТ-проект. Данный показатель характеризует, как конкретный участник может повлиять на проект, насколько важна его поддержка и опасно его неприятие результатов проекта. Иногда результаты данного анализа могут быть довольно неожиданными, например, агенты изменений из отделов, «отдаленных» от проекта, могут потребовать к себе гораздо большего внимания, чем сотрудники отдела, реализующего проект. Данный анализ позволяет правильно расставить приоритеты и интенсивность использования ограниченных ресурсов. Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов (см. таблицу 8): 1. Доверие. Насколько спонсор(ы) и прочие ключевые участники готовы участвовать в проекте и работать с командой до получения итогового результата, насколько можно рассчитывать на их поддержку в критический момент на проекте? 2. Согласие. Получилось ли достичь согласия с этим конкретным участником (группой участников проекта)? Разделяют ли они точку зрения руководителя проекта? �Содержание Таблица 8 Анализ степени сопротивления различных участников проекта Высокое ПАРТНЕРЫ: диалог о диалоге СОЮЗНИКИ: поддерживают ожидания Низкое ПРОТИВНИКИ: Зеркало КОНКУРЕНТЫ: выявление лучшего Низкое Высокое СОГЛАСИЕ ДОВЕРИЕ Поскольку на фазе планирования проекта в основном речь идет именно о руководителях высшего звена – о потенциальных спонсорах проекта, то и результаты данного анализа будут в большей степени применимы именно к этой категории сотрудников. В зависимости от того, в каком из четырех квадрантов образовавшейся матрицы (таблица 8) оказывается тот или иной участник (группа участников), они относятся к нижеуказанным группам, принципы работы с которыми весьма разнятся. Руководителю проекта необходимо установить конструктивный диалог с двумя группами, обладающими высоким уровнем доверия, и сохранять разумную пропорцию их участия. Союзники поддерживают имеющиеся ожидания по проекту, в основном разделяют видение и, скорее всего, заинтересованы в результатах. Конкуренты заставляют команду руководства проекта постоянно конкурировать за ресурсы, обосновывать значимость проекта и искать наиболее оптимальные и менее затратные способы реализации запланированного – по сути, выявляя в последних лучшее. Спонсоры и ключевые участники проекта, обладающие низким уровнем доверия, характеризуются также низким уровнем готовности работать над проектом. Две группы, которые относятся к данной категории, – это партнеры и противники. С партнерами, на первый взгляд, удалось прийти к согласию, но первые их действия свидетельствуют о нерешительности и несоответствии заявленному. Рекомендуется с каждым участником данной категории провести личное общение (беседу), касающееся их обязательств и для идентификации причин, не позволяющих им действовать более решительно и организованно. Противники в отличие от партнеров признают свою неготовность действовать – но конфликт с людьми, открыто выражающими свою позицию, маловероятен, поэтому действия по вовлечению их в проект аналогичны действиям по отношению к партнерам (беседа по вопросам их обязанностей и ответственности). На крупных проектах рекомендуется создавать базу данных участников проекта, в которой будет храниться информация о сотрудниках, способных, так или иначе, оказать влияние на результаты реализации проекта. Хранимая информация включает в себя: ● ФИО и контактную информацию сотрудника; ● сведения об организационной единице, в которой работает сотрудник; ● определение функциональной роли сотрудника; ● категорию получаемых сообщений и их историю. Наличие такой базы данных позволяет менеджеру проекта, во-первых, держать информацию об участниках проекта всегда под рукой, а во-вторых, избегать неловких ситуаций, когда менеджер забывает с кем-то лично побеседовать. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 4 ПО ТЕМЕ «ИДЕНТИФИКАЦИЯ И АНАЛИЗ УЧАСТНИКОВ ПРОЕКТА» На основе материалов проблемной ситуации, необходимо выделить группы участников проекта, произвести предварительный анализ воздействия произвольной группы на результаты проекта, используя таблицу 7. Далее, определив степень участия каждой из этих групп в проекте, необходимо предложить меры по сотрудничеству с ними, заполнив таблицу 9. Таблица 9 Меры по взаимодействию с участниками проекта Группа участников Роль в прое кте Обоснование Ме роприятия �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 5 ПО ТЕМЕ «ИДЕНТИФИКАЦИЯ И АНАЛИЗ УЧАСТНИКОВ ПРОЕКТА» Модель проектной группы в методологии MSF предусматривает выполнение работ проекта представителями соответствующих ролевых кластеров, представленных в таблице 10. Таблица 10 Ведущие ролевые кластеры Ве ха Ве дущие роле вые класте ры Концепция утверждена Управление продуктом Планы проекта утверждены Управление программой Разработка завершена Разработка, удовлетворение потребителя Готовность решения утверждена Тестирование, управление выпуском Внедрение завершено Управление выпуском В целом члены команды могут выполнять несколько ролей. По ряду причин одни ролевые кластеры могут быть совмещены, иные же объединять не рекомендуется. Заполните пустые ячейки в таблице 11, используя предложенные ниже обозначения, и обоснуйте ваше решение: + допустимо; +/– нежелательно; – нельзя. Таблица 11 Совмещение ролевых кластеров Управление продуктом Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Управление программой Разработка Тестирование Удовлетворение Управление потребителя выпуском �Содержание Контрольные вопросы: 1. Из каких стадий состоит модель жизненного цикла информационных систем? 2. Что такое бизнес-цель? 3. Что такое устав проекта? 4. Охарактеризуйте каждую стадию модели ЖЦ ИС. 5. Определение процесса управления содержанием. 6. Определение процесса управления стоимостью Определение процесса управления интеграцией. 7. Определение процесса управления сроками. 8. Определение процесса управления качеством. 9. Определение процесса управления рисками. 10. Определение процесса управления человеческими ресурсами. 11. Определение процесса управления коммуникациями. 12. Приведите классификацию бизнес-выгод. �Содержание ПЛАНИРОВАНИЕ ПРОЕКТА План управления проектом Формирование иерархической структуры проекта Определение содержания проекта Тестовые задания Практическая работа № 6 по теме «Организационная структура проекта» Формирование списка работ (операций) проекта Оценка стоимости проекта �Содержание ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ Процесс разработки плана управления проектом есть процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. Корректно составленный план управления проектом является основным источником информации о том, как проект будет планироваться, оцениваться, контролироваться и закрываться [5]. План управления проектом обновляется и редактируется в рамках процесса осуществления интегрированного управления изменениями проекта, для поддержки версионности документа рекомендуется использовать лист управления документом. План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов. План управления проектом рекомендуется разделять на 3 блока по характеру содержащейся в них информации: 1. Вспомогательные планы управления проектом, в число которых входят: ● ● ● ● ● ● ● ● план управления содержанием проекта; план управления расписанием проекта; план управления стоимостью проекта; план управления качеством проекта; план управления обеспечением персоналом; план управления коммуникациями проекта; план управления рисками проекта; план управления конфигурацией. 2. Базовая линия проекта, состоящая из: ● ● ● ● ● базового расписания проекта; базового плана по стоимости; базового плана по качеству; базового плана по конфигурации; реестра рисков. 3. Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта. �Содержание ФОРМИРОВАНИЕ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ ПРОЕКТА Иерархическая структура работ (ИСР) – это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта. Работы, не включенные в ИСР, находятся за пределами содержания проекта [5]. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. Существуют два основных способа разработки ИСР: «сверху вниз» и «снизу вверх». Приведем описание подхода «сверху вниз». 1. Сбор исходной информации. Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация: ● требования заказчика; ● пул доступных ресурсов; ● конкретная проектная ситуация. 2. Выбор типа ИСР. После получения необходимой информации о факторах, влияющих на ИСР, необходимо определиться с ее типом построения: ● по жизненному циклу, ● по системам, ● по географическим зонам. В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта. Наглядный пример использования такого типа структурирования ИСР – проект разработки программного обеспечения, состоящий из таких фаз, как ● ● ● ● определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на 1-м уровне ИСР. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где 1-й уровень ИСР проекта может состоять из здания А, здания Б и т. д. Что касается следующих уровней ИСР, многие специалисты практикуют гибридные ИСР, сочетающие два или три метода. При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту, это позволит избежать сопротивления новому методу, которое неизбежно возникнет. 3. Определение степени детализации ИСР. �Содержание Принимая во внимание тот факт, что число пакетов влияет на время и стоимость управления проектом, нужно выбрать такое количество пакетов работ, для управления которыми есть время и бюджет. Пакетом работ называется основной элемент управления ИСР, дискретная задача, имеющая определимые конечные результаты, за достижение которых отвечают организационные единицы. Очевидно, пакеты работ должны представлять небольшие результаты и быть управляемыми. Для определения степени детализации ИСР нужна следующая информация: ● количество уровней в ИСР; ● количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны ИСР со следующей детализацией: ● ● ● ● от трех до четырех уровней; от 15 до 40 пакетов работ; от 40 до 80 часов на средний пакет работ; от 3% до 7% общего бюджета рабочих часов на средний пакет работ. Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового. Например, большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, а потому и одинаковые или схожие результаты каждой фазы. Шаблон ИСР представляет собой древовидную структуру работ, детализированную до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения. �Содержание ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ ПРОЕКТА Описание содержания проекта представляет собой формулировку проекта – что необходимо сделать. Процесс разработки предварительного описания содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием. Описание содержанием должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта – оно говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта. Автором данного документа является назначенный уставом проекта руководитель проекта, следовательно, данный документ пишется с позиции исполнителя проекта. К информации, имеющей ключевое значение для составления описания содержания проекта, относятся: ● ● ● ● устав проекта; формулировка требований организации-заказчика; ТЭО; внутрикорпоративная методология управления проектами и соответствующие политики. К описанию содержания проекта выдвигают следующие требования: 1. Название проекта. Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. Утвержденное еще до момента подписания устава проекта, имя не меняется на протяжении жизненного цикла всего проекта. 2. Цели и задачи проекта Цель проекта формулируется, исходя из требований заказчика и указанной в уставе бизнес-причины проекта, при этом она не повторяет формулировки бизнес-цели, отраженной в уставе, а отвечает на вопрос, как эта бизнес-цель будет достигнута. Цель проекта должна представлять собой констатацию сути проекта и давать ответ на вопрос: «Какую уникальную ценность несет проект для клиента и для бизнеса компании?» В свою очередь, задачи проекта представляют собой действия по достижению цели проекта, выполняемые в рамках проекта. Таким образом, задачи проекта представляют собой требования к проекту, формируемые и корректируемые при помощи формальной процедуры построения «дома качества». 3. Требования к проектному решению и результаты проекта. Является элементом базового содержания проекта, входящего в план управления проектом. Описание характеристик реализуемого решения проекта и основных результатов проекта. Для обеспечения связи между требованиями заказчика и результатами проекта рекомендуется использовать функцию качества, точнее, ее вторую итерацию. Выполнение работ, изложенных в описании содержания, должно привести к получению основных �Содержание результатов. Результаты могут включать в себя как промежуточные, например, продукты начальных стадий проекта (описание архитектуры информационной системы), так и конечные (запуск информационной системы в продуктивную эксплуатацию и обеспечение поддержки). В качестве результатов проекта могут выступать как продукты, так и услуги. Информация о количестве и качестве в обобщенном виде тоже должна быть представлена в описании проекта. 4. Границы проекта. Является элементом базового содержания проекта, входящего в план управления проектом. Границы проекта определяют в целом то, что включается в проект, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект. Комплексное рассмотрение проекта подразумевает отражение явным образом функциональных, организационных, технологических и географических границ проекта. Функциональные границы проекта – бизнес-направления, бизнес-процессы, охватываемые проектом автоматизации. При модульной архитектуре внедряемой системы данным пунктом определяются функциональные модули ERP-систем (Enterprise Resource Planning, планирование ресурсов предприятия). Организационные границы проекта определяются, какие подразделения (включая юридические лица) должны участвовать в проекте – кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область генерации требований к внедряемой ИС. Технологические границы – перечисление всех систем и существующих интерфейсов, которые связаны с реализацией рассматриваемого ИТ-проекта или будут им затронуты. При этом указываются процессы, поддерживаемые каждой из систем, и критичность каждой из систем для бизнеса. Географические границы – территориальное распределение проекта: указываются территориально удаленные объекты, подлежащие автоматизации в рамках проекта. 5. Способ реализации проекта. Способ реализации проекта подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. К таким элементам относятся: ● подход (методология реализации проекта); ● ИТ-система управления проектом; ● материалы и инструментарий – описание внедряемого ИТ-продукта с указанием вендора (компании, выпускающей и поставляющей продукты и услуги под своей торговой маркой), названия, класса системы, описания функциональной и технической архитектуры системы, перечисление ее модулей. 6. Первоначальная иерархическая структура работ (ИСР) до пакетов работ. Является элементом базового содержания проекта, входящего в план управления проектом. Иерархическая структура работ проекта – модель, раскрывающая проект уровень за уровнем до такой степени детализации, которая необходима для эффективного планирования и контроля проекта. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. Информация о работах, как правило, доступна в описании используемой методологии. �Содержание 7. Потребность в ресурсах, штатное расписание и организационная структура проекта (трудоемкость, роли проекта, без указания конкретных сотрудников, структура подотчетности и управления проектом). Потребность ресурсов определяется трудоемкостью работ, отраженных в разработанной ранее ИСР. При определении трудоемкости работ важным источником информации является используемая методология проектного управления (внедрения ИС). Организационная структура культурой и внутренними рекомендуется разработать Consulted and/or Informed»), проекта. проекта также во многом определяется методологией и, кроме того, – политиками компании-заказчика. Помимо этого, на данном этапе матрицу ответственности (RACI-матрицу, «Responsible, Accountable, позволяющую распределить комплексную ответственность за задачи 8. Укрупненный календарный план. Укрупненный календарный план разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы 1-го уровня), кроме того, важным источником информации служит используемая методология проектного управления. 9. Критические факторы успеха. Условия, обеспечение которых на проекте может быть залогом успеха. Например: ● ● ● ● ● точно определенные рамки проекта; квалификация персонала проекта; обучение членов команды и пользователей; четкое распределение ролей и ответственности; проработанный рабочий план модели критических факторов успеха. 10. Допущения проекта (со стороны исполнителя). Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. При формировании описания содержания проекта допущения формулируются со стороны организации-исполнителя об организации-заказчике. Примеры допущений: ● проект имеет организационную поддержку со стороны руководства заказчика; ● у организации-заказчика имеется возможность выделить персонал для обеспечения работ по проекту. 11. Ограничения проекта (со стороны исполнителя). Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ. При составлении описания содержания проекта ограничения формулируются со стороны организации-исполнителя об организации-заказчике. 12. Связь с прочими текущими программами и проектами. Любое возможное взаимодействие с другими проектами должно быть отражено в описании содержания проекта. Недостаточно просто констатировать эту связь, необходимо указать, где и как проекты соотносятся друг с другом, а также детально описать, какие ресурсы подпадают под �Содержание совместное использование и в каких функциональных областях организации и когда может вестись работа сразу над несколькими проектами. 13. Первоначально сформулированные риски. На данном этапе, как правило, указываются уже известные риски и основные категории потенциальных рисков (например, внешние, организационные, процедурные, технические, юридические, репутационные и прочие). 14. Смета расходов с указанием порядка величин. Смета есть представление проектных затрат на проект по категориям. 15. Требования к управлению конфигурацией проекта. Указываются объекты управления конфигурацией проекта, в том числе проектная документация, внутренняя политика и производимый продукт. 16. Критерии приемки результатов проекта. Являются элементом базового содержания проекта, входящего в план управления проектом. Представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества. �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Процесс разработки плана… есть процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. a) реализации проектом; b) управления проектом; c) разработки проектом; d) внедрения проектом. 2. План управления проектом может быть… a) подробным, либо детализированным; b) резюмирующим, либо кратким; c) основным, либо дополнительным; d) резюмирующим, либо детализированным. 3. План управления проектом рекомендуется разделять на… по характеру содержащейся в них информации. a) 3 блока; b) 2 блока; c) 4 блока; d) 10 блоков. 4. …в число которых входят: план управления содержанием проекта; план управления расписанием проекта; план управления стоимостью проекта; план управления качеством проекта; план управления обеспечением персоналом; план управления коммуникациями проекта; план управления рисками проекта; план управления конфигурацией. a) вспомогательные планы управления проектом; b) c) d) базовые линии проекта; результаты анализа проекта; планы управления проектом. 5. …состоит из базового расписания проекта, базового плана по стоимости, базового плана по качеству, базового плана по конфигурации и реестра рисков. a) вспомогательная планировка проекта; b) базовая линия проекта; c) дополнительная линия проекта; d) планировка управления проектом. 6. … – это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта. a) иерархическая структура работ; b) проектирование; c) разработка и внедрение; d) утилизация и обновление. �Содержание 7. Основными способами разработки ИСР являются… a) «вертикальный» / «горизонтальный»; b) «положительный» / «отрицательный»; c) «сверху вниз» / «слева направо»; d) «сверху вниз» / «снизу вверх». 8. Основным элементом управления ИСР, дискретной задачей, имеющей определяемые конечные результаты, за достижение которых отвечают организационные единицы, является… a) пакет работ; b) стоимость работ; c) ценность работ; d) метод работ. 9. Древовидная структура работ, детализированная до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения, называется… a) методом ИСР; b) шаблоном ИСР; c) пакетом ИСР; d) моделью ИСР. 10. К информации, имеющей ключевое значение для составления описания содержания проекта, не относится… a) устав проекта; b) формулировка требований организации-заказчика и ТЭО; c) внутрикорпоративная методология управления проектами и соответствующие политики; d) бюджет проекта. 11. Утвержденное еще до момента подписания устава проекта имя на протяжении жизненного цикла всего проекта… a) не меняется; b) меняется; c) может меняться один раз; d) может меняться несколько раз. 12. Бизнес-направления, бизнес-процессы, охватываемые проектом автоматизации, представляют собой… a) технологические границы проекта; b) организационные границы проекта; c) функциональные границы проекта; d) географические границы проекта. �Содержание 13. …границы проекта определяют, какие подразделения (включая юридические лица) должны участвовать в проекте – кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. a) технологические; b) организационные; c) функциональные; d) географические. 14. Перечисление всех систем и существующих интерфейсов, связанных с реализацией рассматриваемого ИТ-проекта, указание процессов, поддерживаемых каждой из систем, а также критичности каждой из систем для бизнеса, представляет собой… границы проекта. a) технологические; b) организационные; c) функциональные; d) географические. 15. Территориальное распределение проекта, указывающее территориально удаленные объекты, подлежащие автоматизации в рамках проекта, представляет собой… границы проекта. a) технологические; b) организационные; c) функциональные; d) географические. 16. …реализации проекта подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. a) b) c) d) способ; метод; уровень; цель. 17. …календарный план разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы 1-го уровня). a) усредненный; b) уменьшенный; c) укрупненный; d) увеличенный. 18. Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения результата проекта, представляет собой… a) допущения проекта; b) цель проекта; c) метод проекта; d) условие проекта. �Содержание 19. На условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта, указывает/ указывают… a) допущения проекта; b) цель проекта; c) условие проекта; d) ограничение проекта. 20. Перечень работ, запланированных для выполнения, называется списком… a) операций; b) контрольных событий; c) методов; d) условий. 21. Перечень основных событий, которые должны быть включены в расписание для мониторинга хода выполнения и управления проектом, с указанием, является ли контрольное событие обязательным или необязательным, называется списком… a) операций; b) контрольных событий; c) методов; d) условий. 22. Метод построения сетевых диаграмм расписания проекта, на которых операции изображаются в виде прямоугольников (называемых «узлами»), а зависимости – соединяющими их дугами, называется методом… a) предшествования; b) опережения и задержки; c) сетевых диаграмм расписания проекта; d) стрелочных диаграмм. 23. Метод построения диаграмм расписания проекта, на которых операции представляются в виде дуг, соединяемых в узлах, показывающих их зависимости, называется методом… a) предшествования; b) опережения и задержки; c) сетевых диаграммы расписания проекта; d) стрелочных диаграмм. 24. Интервалы времени, которые модифицируют взаимосвязи последующими операциями, называются… a) инструментами реализации метода предшествования; b) опережением и задержкой; c) сетевыми диаграммами расписания проекта; d) инструментами реализации метода стрелочных диаграмм. между предшествующими и �Содержание 25. Схематическое отображение плановых операций проекта и (зависимостей) между ними представляет собой реализацию метода… a) предшествования; b) опережения и задержки; c) сетевых диаграмм расписания проекта; d) стрелочных диаграмм. логических взаимосвязей �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 6 ПО ТЕМЕ «ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА» Задание 1 Используя значения критериев, приведенные в таблице 12, укажите в пустых полях таблицы 13 значения, обуславливающие применение того или иного типа организационной структуры. Задание 2 Какой из типов организационной структуры в бόльшей мере подходит для проблемной ситуации. Ответ обоснуйте. Таблица 12 Критерии организационной структуры проекта Ре ше ние прое кта Сложность прое кта Продолжите льность Объе м Важность Сложное Высокая Большая Локальный Стратегический Новое Низкая Средняя Глобальный Тактический Стандартное Средняя Короткая Региональный Операционный Таблица 13 Типы организационной структуры проекта Организационная структура прое кта Крите рии выбора Функциональная Решение проекта Сложность Продолжительность Масштаб Важность Матричная Прое ктная �Содержание ФОРМИРОВАНИЕ СПИСКА РАБОТ (ОПЕРАЦИЙ) ПРОЕКТА Определение списка работ предполагает определение и документирование работ, запланированных для выполнения. Инструментальным средством для определения списка работ, а также для оценки их взаимосвязи и длительности служит иерархическая структура работ (ИСР). Пакеты работ разбивают на операции. Операция – это единица работ, в результате которой создается конкретный результат. Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным для того, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координацию работ. Число операций не должно быть слишком большим, затрудняющим оценку общего состояния проекта с помощью системы отчетности о ходе выполнения проекта. Далее, например, методом мозгового штурма выполняется разбиение пакетов работ на операции. На этом этапе важно проследить, чтобы были определены все операции, необходимые для реализации проекта; при этом длительность (степень детализации) не рассматривается. На следующем этапе выполняется учет степени детализации. Если количество выделенных операций мало, их разбивают на более мелкие, если велико – родственные операции группируют. Степень детализации зависит от цели детализации. Детализация операций для разработки иерархического расписания крупного проекта будет существенно отличаться от степени детализации при разработке расписания выполнения малого проекта. Степень детализации также зависит от количества контрольных событий, которые планируется отразить в расписании проекта. Состав операций может определяться последовательно, методом набегающей волны. Этот метод применяется в крупных или долгосрочных проектах, когда имеется неопределенность относительно выполнения некоторых работ. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время как пакеты работ, расположенные ближе по оси времени, планируются детально. Этот метод рекомендуется применять при создании детальных планов на стадии разработки и производства. Исходной информацией для процесса определения списка работ являются: ● ● ● ● ● методология внедрения ИС; контракт; описание содержания проекта; иерархическая структура работ (ИСР); словарь ИСР. Для определения списка работ используют следующие инструменты и методы: ● ● ● ● декомпозиция; шаблоны; планирование методом набегающей волны; экспертная оценка. Процесс определения списка работ завершается формированием списка операций и уточненным списком контрольных событий. Список операций – перечень работ, запланированных для выполнения. В список операций входят идентификатор операции и описание содержания работ по каждой операции, подробное настолько, чтобы члены команды проекта понимали, какие работы необходимо провести. Список контрольных событий – перечень основных событий, которые должны �Содержание быть включены в расписание для мониторинга хода выполнения и управления проектом, с указанием, является ли контрольное событие обязательным или необязательным. Процесс определения взаимосвязей операций включает в себя идентификацию и документирование логических взаимосвязей между плановыми операциями. Определение взаимосвязей требует хороших знаний технологии и приоритетов проекта. Взаимосвязи операций могут быть последовательными, с собственными отношениями предшествования, а также с опережениями и задержками. В этом случае каждый выходной элемент операции используется как входной элемент другой операции или является частью поставки. Взаимосвязи операций могут быть с перекрытиями, когда еще незавершенная операция имеет достаточно выходных элементов для начала зависящей от нее операции, или с параллельным выполнением операций. Исходной информацией для процесса определения взаимосвязи операций могут быть: 1) описание содержания проекта – содержит определение содержания продукта, включающее в себя характеристики продукта, которые могут повлиять на определение взаимосвязей операций, поэтому во избежание ошибок следует повторно проанализировать определение содержания продукта; 2) методология внедрения ИС; 3) результаты процесса определения состава операций; 4) список операций; 5) параметры операций; 6) список контрольных событий; 7) одобренные запросы на изменение. При определении взаимосвязи используются нижеследующие инструменты и методы. Метод предшествования – метод построения сетевых диаграмм расписания проекта, в котором операции изображаются в виде прямоугольников (называемых «узлами»), а зависимости – соединяющими их дугами. Этот метод еще называется «операции в узлах», он используется в большинстве пакетов программного обеспечения для управления проектами. Метод стрелочных диаграмм – метод построения сетевых диаграмм расписания проекта, где операции представляются в виде дуг, которые соединяются в узлах, показывающих их зависимости. Этот метод еще называется «операции на дугах». Шаблоны расписания сети – стандартизированные шаблоны сетевых диаграмм расписания проекта могут использоваться для ускорения подготовки сетей плановых операций проекта. Они могут включать в себя как весь проект в целом, так и его часть. Определение зависимостей – для определения последовательности операций используется три типа зависимостей: жесткая (или обязательная), нежесткая (или произвольная) и внешняя. Применение опережений и задержек – опережения и задержки представляют собой интервалы времени, которые модифицируют взаимосвязи между предшествующими и последующими операциями. Процесс определения взаимосвязи операций завершается формированием следующих документов. �Содержание Сетевые диаграммы расписания проекта – схематическое отображение плановых операций проекта и логических взаимосвязей (зависимостей) между ними. Сетевая диаграмма расписания проекта может быть построена вручную или при помощи программного обеспечения для управления проектом, например, Spider, MS Project, OpenProj. Она может включать в себя полную детализацию проекта или одну или несколько суммарных операций (пакет операций). На рисунке 3 приведен пример представления расписания проекта в виде диаграммы Гантта, выполненной в OpenProj. Рис. 3. Пример представления расписания проекта в виде диаграммы Гантта Список операций (обновления). Если одобренные запросы на изменения являются результатом процесса определения взаимосвязей операций, то создается обновленный список операций, включающий в себя эти изменения. Параметры операции (обновления). Если одобренные запросы на изменения, являющиеся результатом процесса определения взаимосвязей между операциями, оказывают влияние на список операций, то в соответствующие элементы параметров операций включаются эти одобренные изменения (логические взаимосвязи и соответствующие опережения и задержки). Запрошенные изменения. При разработке логических взаимосвязей, опережений и задержек проекта могут быть выявлены моменты, которые повлекут за собой запрос на изменение списка операций или параметров операций. Запрошенные изменения рассматриваются и утверждаются в рамках процесса общего управления изменениями. �Содержание ОЦЕНКА СТОИМОСТИ ПРОЕКТА Стоимостная оценка – это процесс установления стоимости ресурсов проекта, основанный на определенных фактах и допущениях. Для определения стоимостной оценки, прежде всего, необходимо определить операции (пакет операций), длительность операций и требуемые ресурсы. Процесс оценки и его результат в значительной степени зависят от точности описания содержания, качества доступной информации, от стадии проекта. На процесс стоимостной оценки оказывают влияние время, отведенное для проведения оцениваемой операции, опыт менеджера, инструменты оценивания, заданная точность. Оценка стоимости проекта начинается на предпроектной стадии (до заключения контракта) и выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки стоимости: ● ● ● ● ● оценка порядка величины; концептуальная оценка; предварительная оценка; окончательная оценка; контрольная оценка. На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от -50% до +100%. Точность концептуальной оценки находится в интервале -30% – +50%. Точность предварительной оценки проекта колеблется от -20% до +30%. На этапе окончательной оценки точность колеблется от -15% до +20%. Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку. Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т.д.) для облегчения сравнения проектов и операций внутри проекта. Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь, Интернет, арендованные помещения, а также особые статьи расходов, например, учет уровня инфляции или расходы на непредвиденные обстоятельства. На фазе планирования проекта имеет смысл использовать менее точные и менее затратные способы оценки стоимости. К сведениям, имеющим большую важность для успешной реализации оценки стоимости, относятся: ● финансовая политика; ● организационная политика, которая принята в компании, выполняющей планирование стоимости. Первая определяет структуру основных элементов оценки, вторую необходимо принимать по части обеспечения персоналом и аутсорсинга, что является ключевым элементом калькуляции себестоимости проекта. Оценка «сверху вниз» применяется на ранних стадиях в условиях недостаточной информации о проекте. Производится только одна оценка стоимости всего проекта на самом верхнем уровне. Такая оценка не требует больших усилий, но имеет низкую точность. Оценка по аналогам представляет вид оценки «сверху вниз». Она подразумевает оценку текущего проекта, называемого целевым, на основе фактической стоимости одного или нескольких предыдущих проектов (аналогичных или исходных) близкого размера, сложности и содержания. Менеджеры, выполняющие оценку, могут опираться на инстинктивное чутье, исторические данные или приблизительные расчеты, модифицированные так, чтобы учесть любые различия между целевым и �Содержание аналогичным проектами. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует больших усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость подготовки такой оценки составляет 0,04%–0,15% от общей стоимости проекта. Процесс выработки оценки по аналогии включает в себя определение специфики предварительного планирования: конечные пользователи, цель и формат оценивания, список участников процесса и их роли, доступные ресурсы. Затем следует изучение целевого проекта: его содержания, размера и показателей сложности. Далее происходит обращение к базе данных предыдущих проектов с целью их оценки. Наиболее подходящий проект (проекты) отбирается в качестве аналога. Соотнесение проектааналога и проекта-цели сложностей не вызывает, поскольку они наделены сходным набором характеристик. Затем следует перенести решение, которое позволило достичь цели при выполнении аналога, на целевой проект, корректируя элементы, не имеющие полного соответствия. Чтобы получить денежный эквивалент затраченного времени, нужно умножить количество часов на расценки. Сумма всех оцененных элементов равна общей оценке проекта. Для менеджеров крайне важно умение выявлять скрытые различия между элементами исходного и целевого проектов и оценивать стоимость элемента целевого проекта на основе исходного, в действительности являющегося подобным или аналогичным. Оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует. Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости ИТ-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода – для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов; недостатком является низкая точность (-30%–+50%). Стоимость подготовки параметрической оценки составляет 0,04%–0,45% от общей стоимости проекта. Для того чтобы разработать параметрическую оценку надлежащего качества, необходимо собрать качественную исходную информацию, в которую должны входить: ● основное содержание проекта; ● выбранные параметры проекта; ● историческая информация. Параметрические оценки наиболее часто применяются на стадии определения проекта и на начальных стадиях проектирования, когда еще нет достаточного количества информации для разработки восходящей оценки. Стоимостная оценка должна производиться компетентными сотрудниками, определение которых можно произвести в соответствии со следующими критериями. 1. Специалисты, выносящие оценки, должны обладать достаточным опытом в реализации той работы, оценку которой они производят. Оценки на основе любых методов основываются на �Содержание понимании работы, которую предстоит выполнять. 2. Для выполнения оценки необходимо привлекать непосредственных исполнителей: с одной стороны, это позволит им сразу понять, в рамках каких ограничений им предстоит работать, с другой – у людей появляется гораздо больше мотивации работать с этими оценками, чем с данными, предоставленными кем-то другим. 3. Специалисты, выносящие оценки, должны точно представлять себе цель производимой оценки, иначе можно получить весьма неточные результаты, пригодные лишь для идеальных условий. Один из способов зафиксировать результаты оценки стоимости проекта – формирование сметы проекта. Смета проекта – документ, отражающий разбивку стоимости проекта по основным категориям затрат проекта. Базовый план по стоимости – это распределенный во времени суммарный исходящий денежный поток проекта, используемый для измерения и мониторинга исполнения стоимости проекта. Его разработка производится суммированием оценочных расходов в течение определенного временного периода. Такой план отражает значение оценочных расходов и сроки, когда предполагается их возникновение, при условии следования определенному порядку выполнения проектных задач и работ. Построение базового плана по стоимости начинается со сбора исходной информации, к которой относятся: ● результаты оценки стоимости проекта; ● ИСР; ● расписание проекта. Подготовка базового плана по стоимости представляет собой установление отношения между оценкой стоимости и временными параметрами проекта. Для выстраивания этого соответствия требуются четкие критерии, которые определяют как события проекта, инициирующие выплаты по включенным в базовый план элементам (статьям) расходов, так и время, проходящее между инициирующими событиями и соответствующими им выплатами. Например, при выплате зарплат членам команд управления проектами такую роль играет рабочий график этих сотрудников, который и инициирует расчет в конце каждого месяца. Интервалы – для оплат внутри и вне организации – определяются временем, необходимым для внутренней и внешней коммуникации, утверждения и выполнения административных процедур, а также политикой компаний, которые склонны удерживать у себя деньги столь долго, сколь это представляется возможным, поскольку это сокращает дебиторский цикл, а, следовательно, снижает оборотный капитал компании. Далее следует анализ критериев и их письменное определение, которые позволяют распределить расходы по временным периодам в процессе формирования базового плана. Как только тип базового плана стоимости выбран, статьи расходов, подлежащие включению в него, идентифицированы и критерии формирования определены, можно считать, что основы для распределения расходов по временным периодам заложены. После чего следует процесс обозначения и структурирования статей расходов. Желательно, чтобы проект имел собственную систему обозначения расходов, согласованную с системой обозначения расходов компании или с принятыми в данной отрасли стандартами. Если базовый план стоимости разрабатывается на основе восходящей («снизу вверх») оценки, его элементы можно структурировать в соответствии с ИСР, при помощи пакетов работ из ИСР-проекта. Если же для его построения используется оценка по аналогии или параметрическая оценка, лучше �Содержание задействовать другие методы структурирования. Когда все оценки статей расходов распределены по конкретным временным периодам, необходимо просуммировать расходы по этим периодам. Таким образом, получается информация об инкрементных расходах этих периодов (расходах, имеющих место в течение каждого месяца), которые потребуются на следующем шаге для графического отображения базового плана стоимости. Рис. 4. S-кривая базового плана по стоимости Графическое отображение базового плана стоимости с помощью S-кривой является широко распространенным способом показа базового плана стоимости, выражаемого в виде накопительных расходов (см. рисунок 4). Для вычисления кумулятивных расходов первых двух периодов необходимо прибавить расходы первого периода к расходам второго. Добавив это значение к инкрементным расходам третьего периода, можно получить кумулятивное значение расходов первых трех периодов. Данную процедуру можно продолжать, находя последовательно кумулятивные расходы для первых четырех, пяти и т.д. периодов, а затем построить зависимость кумулятивных расходов от времени. Результатом станет базовый план стоимости в виде S-кривой. Далее, как и при разработке других типов оценки стоимости, базовый план нужно проверять и пересматривать. Отсутствие эффективного базового плана стоимости, даже при наличии оценки стоимости и требований к трудовым ресурсам, представляет собой значительную угрозу для проекта: измерение хода исполнения проекта и потока денежной наличности становится затруднительным, если не невозможным. Имеющийся базовый план стоимости допустимо использовать в качестве базового плана для оценки хода исполнения проекта по методу освоенного объема. Прогнозирование потока денежной наличности – еще одно достоинство, обеспечиваемое эффективным базовым планом: он заблаговременно информирует руководство или заказчика о том, что �Содержание в некоторый момент должны быть доступны определенные фонды, которые потребуются для поставки ресурсов и продолжения реализации проекта. Чтобы базовый план стоимости надлежащим образом выполнял эту роль, он должен быть организован так, чтобы отражать продвижение и ход исполнения на текущую дату. Действия по формированию базового плана стоимости относительно просты, независимо от того, выполняются они вручную или с помощью компьютера. Следует также сказать, что визуальное представление плана в виде S-кривой облегчает его восприятие. �Содержание РАЗРАБОТКА РАСПИСАНИЯ ПРОЕКТА Разработка расписания проекта – итеративный процесс, определяющий плановые даты начала и завершения операций проекта. Разработка расписания производится непрерывно по мере выполнения работ проекта. При этом могут потребоваться проверка и редактирование оценки длительности и ресурсов, чтобы в итоге получить одобренное расписание проекта [5]. Согласованное расписание используется как базовое, по которому будет оцениваться прогресс рисков. Исходной информацией для процесса разработки расписания является описание содержания проекта. Оно включает допущения (документированные факторы, относящиеся к расписанию, которые при разработке расписания считаются достоверными) и ограничения (факторы, ограничивающие свободу выбора команды управления проектом при проведении анализа сети расписания и влияющие на составление расписания проекта). При разработке расписания учитываются два основных типа ограничений по времени: ● требуемые даты для начала или завершения операции, которые можно использовать для ограничения начала или завершения операции; ● контрольные события, вследствие чего получение определенных результатов работ привязывается к определенным датам, изменить которые можно только посредством одобренных изменений. Для разработки расписания рекомендуется использовать следующие инструменты и методы. Диаграмма Гантта – диаграмма, которая использует горизонтальные полосы для представления операций проекта, показывает даты начала и завершения каждой операции и проекта относительно горизонтальной шкалы времени (см. рисунок 3). Диаграмма, построенная по методу критического пути – методу анализа сети расписания, проводимого при помощи модели расписания. Критический путь представляет группу операций, которые не могут быть задержаны без изменения отсрочки, даты завершения всего проекта. При использовании метода критического пути рассчитываются теоретические даты раннего старта и раннего финиша и позднего старта и позднего финиша для всех плановых операций без учета ограничений по ресурсам. Этот расчет производится путем проведения анализа прямого и обратного проходов по путям сети расписания проекта. Полученные даты раннего и позднего старта и финиша показывают периоды времени, в пределах которых следует планировать данную операцию, исходя из ее длительности, логических взаимосвязей, опережений, задержек и прочих ограничений. Диаграмма контрольных событий – инструмент для разработки расписания проекта, построение которого включает следующие действия: ● сбор исходной информации для построения диаграммы; ● построение сетевой диаграммы, отражающей взаимосвязь операций; ● определение уровня детализации контрольных событий – количества контрольных событий, отражаемых на диаграмме; ● выбор контрольных событий, которые являются главными для продвижения проекта; ● упорядочивание контрольных событий – изучение взаимосвязей и определение последовательности их выполнения; ● нанесение контрольных событий на детальное расписание проекта; ● проверка равномерности распределения контрольных событий по расписанию проекта. �Содержание Результатами процесса разработки расписания являются: ● Расписание проекта. Расписание проекта может быть разработано детально или укрупнено как расписание контрольных событий. Расписание может быть представлено в табличном виде или иметь графическое представление в виде сетевых диаграмм, столбиковых горизонтальных диаграмм или диаграмм контрольных событий. ● Данные для модели расписания. Обязательные данные для расписания проекта включают в себя контрольные события расписания, плановые операции, параметры операции и документацию всех имеющихся допущений и ограничений, а дополнительные – требования к ресурсам по периодам времени, альтернативные расписания, резервы на непредвиденные обстоятельства. ● Базовый план расписания – особый вариант расписания проекта, разрабатываемый посредством анализа сети расписания модели расписания, принимается и утверждается командой управления проектом в качестве первоначального (базового) плана расписания с указанными базовым стартом и базовым финишем. Базовый план расписания используют для выявления отклонений фактических сроков выполнения операций от плановых. ● Требования к ресурсам. ● Параметры операции. ● Календарь проекта. ● Запрошенные изменения. В процессе разработки расписания могут появиться запрошенные изменения, которые обрабатываются в процессе общего управления изменениями. ● План управления проектом. План управления проектом обновляется с отражением всех одобренных изменений в способах управления расписанием проекта. При разработке расписания рекомендуется соблюдать следующую последовательность работ: ● ● ● ● ● ● ● ● ● ● ● ● ● определить перечень операций, которые должны быть включены в расписание; определить взаимосвязь операций; определить длительность каждой операции; рассчитать с помощью прямого прохода раннее расписание для каждой операции; рассчитать с помощью обратного прохода позднее расписание для каждой операции; вычислить временной резерв для каждой операции; определить критический путь; сравнить дату предполагаемого завершения проекта с датой завершения проекта по обязательству; подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты; определить ограничения на ресурсы; откорректировать расписание в соответствии с ограничениями на ресурсы; проверить, не планируется ли завершение проекта по откорректированному расписанию раньше даты обязательства; согласовать расписание. Тестовые задания Лабораторная работа № 1 Построение диаграмм Гантта с помощью электронных таблиц �Содержание Лабораторная работа № 2 Построение диаграмм Гантта в электронных таблицах с использованием функций и макросов Лабораторная работа № 3 Построение диаграмм Гантта в OpenProj Разработка расписания проекта методом критического пути Лабораторная работа № 4 Создание и управление проектом с помощью OpenProj Лабораторная работа № 5 Отслеживание хода выполнения работ и фактических затрат с помощью OpenProj �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. …расписания проекта – это итеративный процесс, определяющий плановые даты начала и завершения операций проекта. a) реализация; b) разработка; c) внедрение; d) завершение. 2. При разработке расписания проекта учитываются следующие варианты ограничения по времени… a) требуемые события и контрольные даты; b) требуемые и контрольные события; c) требуемые и контрольные даты; d) требуемые даты и контрольные события. 3. Диаграмма, использующая горизонтальные полосы для представления операций проекта, показывающая даты начала и завершения каждой из операций проекта относительно горизонтальной шкалы времени, носит название диаграммы… a) Гантта; b) критического пути; c) событий; d) дат. 4. Группа операций, которые не могут быть задержаны без изменения отсрочки, даты завершения всего проекта, представляет собой… a) критический путь; b) полный путь; c) события; d) диаграмму дат. 5. Инструмент, используемый для разработки расписания проекта, построение которого включает следующие действия – сбор исходной информации, построение сетевой диаграммы, выбор контрольных событий, нанесение контрольных событий на детальное расписание проекта, проверка равномерности распределения контрольных событий по расписанию проекта, носит название… a) диаграммы Гантта; b) диаграммы контрольных событий; c) критического пути; d) диаграммы дат. 6. Результатами процесса разработки расписания не являются… a) расписание проекта; b) построение сетевой диаграммы, отражающей взаимосвязь операций; c) данные для модели расписания; d) определение уровня детализации контрольных событий. �Содержание 7. Расчет раннего финиша осуществляется по формуле… a) EF = ES + Длительность – 1; b) LS = LF - Длительность + 1; c) float = LS - ES = LF – ES; d) EF = ES - Длительность + 1. 8. Расчет позднего финиша осуществляется по формуле… a) EF = ES + Длительность – 1; b) LS = LF - Длительность + 1; c) float = LS - ES = LF – ES; d) EF = ES - Длительность + 1. 9. Расчет временного резерва осуществляется по формуле… a) EF = ES + Длительность – 1; b) LS = LF - Длительность + 1; c) float = LS - ES = LF – ES; d) EF = ES - Длительность + 1. 10. …включает в себя фактические даты начала и завершения и оставшуюся длительность незавершенных плановых операций. a) линия исполнения проекта; b) диаграмма контрольных событий; c) временной резерв; d) отчетность о прогрессе проекта. 11. …показывает, на какое количество времени каждая операция проекта опережает базовое расписание или отстает от него. a) линия исполнения; b) диаграмма контрольных событий; c) временной резерв; d) отчетность о прогрессе проекта. 12. Диаграмма контрольных событий включает в себя… a) исходную информацию; b) построение сетевой диаграммы, отражающей взаимосвязь операций; c) определение уровня детализации контрольных событий; d) выбор некоторых событий проекта; e) хранение контрольных событий; f) нанесение контрольных событий на детальное расписание проекта. �Содержание ЛАБОРАТОРНАЯ РАБОТА № 1. ПОСТРОЕНИЕ ДИАГРАММ ГАНТТА С ПОМОЩЬЮ ЭЛЕКТРОННЫХ ТАБЛИЦ Цель работы: Изучение построения диаграммы Гантта для элементарных проектов с помощью электронной таблицы MS Excel. Краткое теоретическое обоснование Пример создания диаграмм Гантта в MS Excel Построение диаграмм Гантта стандартными средствами MS Excel Создайте диаграмму Гантта по имеющимся данным из таблицы, содержащей этапы проекта, даты начала и конца и длительностт каждого этапа (таблица 14). Таблица 14 Этапы проекта Этап прое кта Начало Длите льность Коне ц Организационное собрание 29.12.2004 1 29.12.2004 Разработка документации 30.12.2004 11 09.01.2005 Общая схема 13.01.2005 9 21.01.2005 Разработка модуля 1 16.01.2005 15 30.01.2005 Разработка модуля 2 16.01.2005 30 14.02.2005 Разработка модуля 3 03.02.2005 12 14.02.2005 Ввод данных 09.02.2005 12 20.02.2005 Анализ данных 23.02.2005 1 23.02.2005 Отчет по разработке 24.02.2005 4 27.02.2005 Внедрение 02.03.2005 10 11.03.2005 Итоговый отчет 09.03.2005 3 11.03.2005 Итоговое собрание 17.03.2005 1 17.03.2005 Для этого выберем в меню Вставка – Диаграмма – Линейчатая с накоплением. Выделим появившееся окно диаграммы и в меню Работа с диаграммами – Конструктор – Данные – Выбрать данные добавим ряд Начало и Длительность. Там же изменим подписи по горизонтальной оси, выделив ряд Этап проекта. В итоге получим следующую диаграмму (см. рис. 5). �Содержание Рис. 5. Линейчатая диаграмма с накоплением, построенная по данным таблицы 14 На диаграмме (рис. 5) красная часть представляет собой длительность работ, а синяя сдвигает начало выполнения в соответствии со столбцом Начало таблицы 14. В завершении построения выполним следующие шаги: ● Выделим диаграмму. В меню Работа с диаграммами – Макет – Оси – Основная вертикальная ось – Справа налево установим порядок сортировка названий этапов работ в диаграмме как в исходной таблице; ● Выделим синюю часть диаграммы и поменяем цвет заливки на бесцветную (нет заливки); ● Далее еще немного поработав с настройками диаграммы, получим результат, показанный на рисунке 6. Рис. 6. Диаграмма Гантта, построенная по данным таблицы 5 �Содержание Построение диаграмм Гантта с помощью условного форматирования Пусть имеется таблица с перечислением этапов проекта, датами начала и конца и длительностями каждого этапа (таблица 15). Построим диаграмму Гантта по имеющимся данным, используя условное форматирование. Таблица 15 Этапы рекламного проекта Дата начала Дне й Дата окончания Подбор сотрудников для проекта 01.01.2005 5 05.01.2005 Маркетинговые исследования 04.01.2005 5 08.01.2005 Разработка рекламной концепции 09.01.2005 3 11.01.2005 Создание рекламного ролика 10.01.2005 10 19.01.2005 Размещение ролика на ТВ 21.01.2005 6 26.01.2005 Оценка эффективности кампании 30.01.2005 1 30.01.2005 Этапы прое кта Идея построения заключается в том, чтобы заставить Excel заливать ячейку заданным цветом, если она по дате попадает между началом и концом этапа. Для этого выделите весь диапазон, где должна быть диаграмма (в нашем примере – начиная с ячейки D3 и до конца таблицы) и затем жмем на вкладке Главная (Home) кнопку Условное форматирование – Создать правило (Conditional Formatting – New Rule), выбираем последний тип Использовать формулу для определения форматируемых ячеек (Use a formula to determine which cells to format) и вводим аналогичную формулу как показано на рисунке 7. �Содержание Рис. 7. Создание диаграммы с использованием условного форматирования По сути, эта формула делает простую вещь – функция И (AND) проверяет обязательное выполнение двух условий, чтобы дата для текущей ячейки была позже, чем дата начала этапа и раньше даты окончания. Если оба эти условия выполняются, то ячейка находится внутри этапа, т.е. должна быть залита. Нажав на кнопку Формат (Format) можно выбрать необходимый цвет. Порядок выполнения работы Постройте с помощью MS Excel для следующего проекта (см. таблицу 16) диаграммы Гантта. 1. Рассчитайте даты окончания этапов работ по формуле: 2. Создайте диаграмму Гантта стандартными средствами MS Excel. 3. Создайте диаграмму Гантта с помощью условного форматирования. 4. Оформите отчет о лабораторной работе. �Содержание Таблица 16 Этапы работ проекта «Разработка аналитического приложения» Задача Дата начала Срок ре ализации Постановка задачи 11.01.2010 1 Теоретическая отработка 14.01.2010 3 Оптимизация алгоритма 14.01.2010 4 Написание кода VBA 14.01.2010 20 Тестирование алгоритма 01.02.2010 2 Работа над ошибками 02.02.2010 3 Оптимизация алгоритма (2) 05.02.2010 4 Тестирование алгоритма (2) 08.02.2010 5 Работа над ошибками (2) 15.02.2010 2 Отправка заказчику 17.02.2010 1 Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя). ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. ● Ход работы: ○ Таблица Этапы работ проекта «Разработка аналитического приложения» с рассчитанными датами окончания этапов проекта. ○ Две диаграммы Гантта, построенные разными методами. ● Описание диаграмм с указанием их достоинств и недостатков. ● Выводы. �Содержание ЛАБОРАТОРНАЯ РАБОТА № 2. ПОСТРОЕНИЕ ДИАГРАММ ГАНТТА В ЭЛЕКТРОННЫХ ТАБЛИЦАХ С ИСПОЛЬЗОВАНИЕМ ФУНКЦИЙ И МАКРОСОВ Цель работы: Рассмотреть способ построения диаграммы Гантта для простых проектов в электронной таблице MS Excel с использованием функций и макросов. Краткое теоретическое обоснование Пример создания диаграмм Гантта в MS Excel с использованием функций и макросов. Таблица 17 Этапы работ торгового проекта № Этап Коне ц этапа % выполне ни я Заде ржка, дн. Начало этапа Длите льность, дн. 01.03.13 4 50% 1 Переговоры 0 2 Оформление договора 1 2 100% 3 Распределение заказов 0 7 50% 4 Набор персонала -2 8 30% 5 Аренда оборудования 0 5 100% 6 Аренда площадей -1 3 70% 7 Складские работы 0 7 90% 8 Завоз товара на точки продаж -3 9 50% 9 Рекламная компания 0 3 20% 10 Подведение итогов 5 6 50% 11 Банкет 1 20 40% Пусть имеется таблица с перечислением этапов проекта, датой начала, длительностями каждого этапа, задержкой и процентом выполнения работ (таблица 17). Построим диаграмму Гантта по имеющимся данным. �Содержание Рис. 8. Пример формулы для расчета дней начала этапов Для этого предварительно рассчитаем даты начала и конца этапов учитывая только рабочие дни и исключая праздники. Начало первого этапа совпадает с началом проекта, далее можно воспользоваться формулой, как показано на рисунке 8. Обратите внимание на используемую функцию РАБДЕНЬ(нач_дата;количество_дней;праздники), она возвращает дату, отстоящую на заданное количество рабочих дней вперед или назад от начальной даты. Рабочими днями не считаются выходные дни и дни, определенные как праздничные. Здесь нач_дата – начальная дата. Количество_дней – количество дней до или после начальной даты, не являющихся выходными или праздниками. Положительное значение аргумента «количество_дней» обозначает будущую дату; отрицательное – прошедшую дату. В формуле на рисунке 8 к данному аргументу добавляется единица, т.к. новый этап должен начинаться на следующий рабочий день после завершения предыдущего этапа. Праздники – необязательный список из одной или нескольких дат, например, государственных праздников, которые требуется исключить из рабочего календаря. Список может представлять собой диапазон ячеек, содержащих даты, который можно сформировать, например, на отдельном листе (см. рис. 9). �Содержание Рис. 9. Фрагмент листа «Праздники» Чтобы рассчитать даты окончания этапов можно воспользоваться формулой, как показано на рисунке 10. В данной формуле отнимается единица согласно следующему правилу: считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Далее создадим временную шкалу для диаграммы. Чтобы можно было регулировать масштаб данной шкалы, воспользуемся формулой как показано на рисунке 11. Даты в ячейках Н8, D3 и D9 совпадают. Шаг временной шкалы можно задавать, используя счетчик, для вставки которого воспользуемся командой Разработчик – Вставить – Элементы управления формы – Счетчик. Если в основном меню отсутствует вкладка Разработчик, то для ее подключения необходимо воспользоваться следующей командой: Кнопка «Office» – Параметры Excel – Основные – Показывать вкладку «Разработчик» в ленте. �Содержание Рис. 10. Пример формулы для расчета дней окончания этапов Рис. 11. Пример формулы для расчета временной шкалы диаграммы Используя условное форматирование, создадим диаграмму Гантта, предварительно выделив диапазон ячеек, где она будет располагаться. Чтобы на диаграмме были видны проценты выполнения по �Содержание каждому этапу с их подсветкой, воспользуемся формулами как показано на рисунках 12 а) и 12 б). а) б) Рис. 12. Пример использования формул при условном форматировании: а) форматированные ячейки будут показывать процент выполнения этапа, б) форматированные ячейки будут показывать оставшуюся часть этапа Рис. 13. Пример формул условного форматирования временной шкалы Сделаем подсветку рабочих и выходных дней, также используя условное форматирование с помощью формул (см. рис. 13). Предварительно над каждой датой временной шкалы необходимо вычислить день недели, соответствующей даты по формуле ДЕНЬНЕД(дата_в_числовом_формате;тип). В данном примере выбран тип 2, где возвращаются числа от 1 (понедельник) до 7 (воскресенье). Полученный результат нужен только для формул условного форматирования, поэтому его можно скрыть, выбрав цвет шрифта такой же как цвет заливки соответствующих ячеек. �Содержание Иногда бывает так, что приходится иметь дело с большой таблицей, и поэтому было бы здорово, если бы при движении активной ячейки по листу подсвечивались текущая строка и столбец. Самый очевидный путь для решения этой проблемы – это создать макрос, который будет отслеживать изменение выделения на листе, и выделять целую строку и столбец для текущей ячейки. Также желательно иметь возможность при необходимости включать и отключать эту функцию, чтобы такое крестообразное выделение не мешало вводить, например, формулы, а работало только тогда, когда мы просматриваем список в поисках нужной информации. Для этого необходимо создать три макроса (выделения, включения и выключения), которые нужно будет добавить в модуль листа. Откройте лист с таблицей, в которой хотите получить такое координатное выделение. Щелкните правой кнопкой мыши по ярлычку листа и выберите в контекстном меню команду Исходный текст (Source Code). Должно открыться окно редактора Visual Basic. Скопируйте в него следующий текст этих трех макросов: Dim Coord_Selection As Boolean 'глобальная переменная для вкл/выкл выделения Sub Selection_On() 'макрос включения выделения Coord_Selection = True End Sub Sub Selection_Off() 'макрос выключения выделения Coord_Selection = False End Sub 'основная процедура, выполняющая выделение Private Sub Worksheet_SelectionChange(ByVal Target As Range) Dim WorkRange As Range If Target.Cells.Count > 1 Then Exit Sub 'если выделено больше 1 ячейки - выходим If Coord_Selection = False Then Exit Sub 'если выделение выключено - выходим Application.ScreenUpdating = False Set WorkRange = Range("A6:N300") выделение 'адрес рабочего диапазона, в пределах которого видно Intersect(WorkRange, Union(Target.EntireColumn, Target.EntireRow)).Select крестообразный диапазон и выделяем 'формируем Target.Activate End Sub Измените адрес рабочего диапазона на свой – именно в пределах этого диапазона и будет работать созданное выделение. Затем закройте редактор Visual Basic и вернитесь в Excel. Нажмите сочетание клавиш Alt+F8, чтобы открыть окно со списком доступных макросов. Макрос Selection_On, как нетрудно догадаться, включает координатное выделение на текущем листе, а макрос Selection_Off – выключает его. В этом же окне, нажав кнопку Параметры (Options) можно назначить этим макросам сочетания клавиш для удобного запуска. Либо создать две кнопки Разработчик – Вставить – Элементы управления формы – Кнопка и назначить одной – макрос включения, а другой – макрос выключения. Плюсы данного способа: �Содержание ● относительная простота реализации; ● выделение – операция безобидная и никак не изменяет содержимое или форматирование ячеек листа, все остается как есть. Минусы этого способа: ● такое выделение некорректно работает в том случае, если на листе есть объединенные ячейки – выделяются сразу все строки и столбцы, входящие в объединение; ● если случайно нажать клавишу Delete, то очистится не только активная ячейка, а вся выделенная область, т.е. удалятся данные из всей строки и столбца. Другие способы «координатного выделения» можно посмотреть здесь: http://www.planetaexcel.ru/ techniques/3/58/. Порядок выполнения работы Используя пример приведенный выше, постройте с помощью MS Excel для следующего проекта (см. таблицу 18) диаграмму Гантта. Таблица 18 Этапы работ ИТ-проекта Этапы прое кта Коне ц этапа % выполне ни я Заде ржка, дн. Начало этапа Срок ре ализации Организационное собрание 0 11.01.2014 1 100 Разработка документации -1 15 100 Общая схема -3 10 50 Разработка модуля 1 1 25 30 Разработка модуля 2 0 40 10 Разработка модуля 3 3 18 40 Ввод данных -3 14 100 Анализ данных 0 1 50 Отчет по разработке 1 3 100 Внедрение -2 10 60 Работа над ошибками (2) -1 5 70 Отправка заказчику 0 1 100 1. Создайте на отдельном листе список праздничных дат на период данного проекта (см. пример на �Содержание рис. 9). 2. Рассчитайте даты начала и окончания этапов работ с учетом выходных и праздничных дней по формулам, приведенным в примере (см. рис. 8 и 10). 3. Создайте диаграмму Гантта с помощью условного форматирования. 4. Создайте макросы для подсветки строки и столбца (см. пример). 5. Оформите отчет о лабораторной работе. Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя). ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. ● Ход работы: ○ Таблица Этапы работ ИТ-проекта с рассчитанными датами начала и окончания этапов проекта. ○ Диаграмма Гантта. ○ Описание макроса «координатного выделения». ● Описание диаграммы. ● Выводы. �Содержание ЛАБОРАТОРНАЯ РАБОТА № 3. ПОСТРОЕНИЕ ДИАГРАММ ГАНТТА В OPENPROJ Цель работы: Рассмотреть способ построения диаграммы Гантта для простых проектов в OpenProj. Краткое теоретическое обоснование Проекты, которые позволяют применить научный подход к решению задач оперативного планирования и руководства играют важнейшую роль в работе каждого предприятия. Невозможно эффективно организовывать и управлять без четкого плана. Основные принципы разработки проектов давно проверены на практике. Проект позволит правильно спланировать и оперативно управлять выполнением поставленной задачи. Под проектом понимается четко определенная последовательность событий, направленных на достижение некоторой цели, имеющих начало и конец и управляемых людьми посредством таких факторов, как время, стоимость, ресурсы и качество. Создание каждого проекта начинается с определения его цели. Цель должна быть четкой и реальной. Для предотвращения возможных проблем нужно убедиться, что ничто не мешает ее достижению. После того, как цель проекта установлена, следующая задача – определить во всех деталях, как и когда цель будет достигнута. Шаги, которые необходимо предпринять для достижения цели, называются работами (Tasks). Работы могут выполняться одновременно или последовательно. Список работ и времени, необходимого для их выполнения, называется графиком работ, или планом (Schedule). По плану вы можете определить, когда должна начинаться и заканчиваться та или иная работа и как долго она будет продолжаться. Количество времени, отведенное на ее выполнение, называется длительностью (Duration). Можно также определить промежуточные цели, или контрольные точки (Milestone), которые будут использоваться для отражения промежуточных итогов проекта. Контрольные точки помогают организовать работы в логические последовательности или группы. Для выполнения работ необходимы ресурсы (Resources): люди, оборудование, материалы. Так как ресурсы редко бывают доступны непрерывно (например, люди работают преимущественно в рабочее время), то при разработке проекта необходимо учитывать и этот фактор. Кроме ресурсов, для реализации любого проекта необходимы финансовые средства. Каждый ресурс и каждый вид работ имеют определенную стоимость (Cost) в денежном выражении, из которой складывается стоимость всего проекта. Наиболее удобным средством создания и управления проектами является Microsoft Project, который позволяет легко вводить и корректировать график работ, необходимых для достижения целей, поставленных перед проектом. Альтернативным средством создания и управления проектами является OpenProj. С помощью OpenProj можно рассмотреть проект в любой перспективе и быстро перейти от одного представления к другому. Управление проектом заключается в отслеживании состояния работ и определении, выполняются ли они в соответствии с планом. Если выполнение отстает от плана, то следует, либо изменить план, либо принять меры для ликвидации задержки. OpenProj автоматически откорректирует план в соответствии с внесенными изменениями. С помощью различных режимов просмотра информации о проекте и отчетов можно быстро определить виды работ, выполнение �Содержание которых задерживается или стоимость которых превышает бюджет. Когда сложная работа должна быть завершена к определенному сроку, то важными факторами являются время и материальные ресурсы. Ими можно управлять с помощью метода, известного под названием метод критического пути. Этот метод, основанный на анализе ситуаций типа «крышу нельзя настелить, пока не воздвигнуты стены», позволяет предсказать, сколько времени займет проект, какие его работы являются критическими и какие наиболее растянуты во времени. Критические (Critical Tasks) – это такие работы, задержка выполнения которых может отразиться на сроках завершения проекта. Критические работы образуют критический путь (Critical path). Задержка выполнения работ, которые не являются критическими, не повлияет на срок окончания проекта. Метод критического пути – стандартный метод определения критических работ. Он базируется на математической модели, которая учитывает связь между видами работ, их длительностями и условиями доступности ресурсов. OpenProj предлагает различные средства для создания и ведения проекта. Одним из наиболее удобных инструментов является диаграмма Гантта (Gantt Chart), на которой каждая работа представляется в виде полосы, расположенной на временной шкале. Длина полосы определяет длительность работы в выбранном масштабе времени, а края – даты начала и окончания этого вида работ. Связь отдельных видов работ отображается на диаграмме различными стрелками, которые характеризуют тип этой связи. Рядом с полосками-работами указываются ресурсы, назначенные этой работе. Диаграмма Гантта (Gantt Chart) особенно удобна для создания графика работ и отслеживания хода его выполнения. Другим мощным инструментом, который использует OpenProj, является сетевая диаграмма (PERT Chart, PERT – Programme Evaluation and Review Technique – программа оценки и руководства разработками). Сетевая диаграмма отображает зависимости между отдельными видами работ (рис. 14). Каждая работа на этой диаграмме представлена в виде прямоугольника, внутри которого содержится информация о ее названии, сроках начала и окончания, длительности и др. Связи между видами работ отображаются стрелками. Сетевая диаграмма (PERT Chart) будет наиболее информативна, когда требуется сосредоточить внимание на связях между видами работ. Процесс создания проекта После того как определена цель проекта, следует найти лучший путь ее достижения. Чтобы сделать это, необходимо составить список работ, которые нужно выполнить для достижения цели и установить продолжительность каждой работы. Затем эта информация должна быть введена в программу OpenProj для создания графика выполнения работ. �Содержание Рис. 24. Пример сетевой диаграммы В зависимости от цели проекта планирование работ может вестись от даты его начала или от той даты, к которой проект должен быть завершен. Например, если проект предусматривает подготовку к выставке, то он должен быть завершен за несколько дней до ее начала, так как открытие выставки отложить нельзя. В этом случае график выполнения работ будет составляться от конечной даты. Большинство задач для своего выполнения требуют ресурсов: людских, различного оборудования, материалов или любых других, необходимых для выполнения работ. Поэтому на следующем этапе создания проекта надо указать, какие ресурсы будут использованы. Ресурсы могут быть определены для каждого вида работ и в дальнейшем при необходимости в любое время изменены. Обычно OpenProj вычисляет продолжительность каждого вида работ, основываясь на количестве назначенных ресурсов. Кроме того, программа может предоставить информацию, которая поможет управлять ресурсами. Например, OpenProj может определить, кто из работников должен работать сверхурочно и каких затрат это потребует. После того как ресурсы назначены, следует определить и ввести планируемую стоимость каждого ресурса или вида работ, на основании которой будет вычислена общая стоимость проекта. После создания первоначального варианта проекта может оказаться, что он не в полной мере отвечает вашим целям. Например, проект может оказаться слишком продолжительным или его стоимость будет слишком высока. Для решения этих проблем следует оптимизировать график выполнения работ и стоимость ресурсов. Когда создание проекта будет закончено и начнется выполнение работ, можно отслеживать ход его реализации и оперативно корректировать график работ и фактические затраты. Порядок выполнения работы Постройте с помощью OpenProj для проекта «Создание рекламного буклета» (см. таблицу 19) �Содержание диаграмму Гантта. Для этого выполните следующие задания. Таблица 19 Этапы работ проекта «Создание рекламного буклета» Этапы прое кта Заде ржка, дн. Начало этапа Срок ре ализации Разработка содержания 0 13.10.2014 5 дней Разработка эскизов иллюстраций -3 3 дня Написание текста 0 14 дней Создание иллюстраций -5 7 дней Литературное редактирование -3 4 дня Верстка 0 5 дней Разработка макета обложки -8 8 дней Корректура 0 4 дня Цветоделение 0 3 дня Сдача в типографию 0 1 день Коне ц этапа Задание 1. Запуск программы и настройка календаря Запустите программу Пуск – Программы – OpenProj. В меню Инструменты выберите Изменить время работы. В появившемся окне нажмите Настройки и установите 8 часовой рабочий день, 40 часовую рабочую неделю и 20 рабочих дней в месяц. Далее установите праздники (см. рис. 15), щелкнув на соответствующую дату календаря и установив переключатель на Нерабочее время. �Содержание Рис. 15. Настройка календаря Задание 2. Создание списка работ После настройки календаря перейдите к диаграмме Гантта Вид – Диаграмма Гантта, либо щелкнуть на соответствующую пиктограмму на панели инструментов, расположенной слева. Введите по порядку названия работ в поле Название. Введите длительность каждой работы в поле Продолжительность. Задание 3. Создание графика работ В OpenProj удобнее всего создавать график работ с помощью создания связей. Для создания связи между работами нажмите Правка – Добавить связь или щелкните мышкой по пиктограмме . Далее на самой диаграмме, щелкнув левой кнопкой мыши по одному столбцу, проведите связь к другому столбцу. Чтобы установить необходимые настройки связи щелкните мышкой по стрелке и в появившемся окне установите тип связи и время задержки (рис. 16), если это необходимо. При этом обратите внимание на то, что при установке любого типа связи OpenProj сам выравнивает столбцы соответствующих работ и назначает дату начала выполнения работ, поэтому прежде чем устанавливать время задержки необходимо еще раз проанализировать график работ проекта. Чтобы установить значимость выполнения работ необходимо в меню Проект выбрать Информация о задаче/ресурсе и в появившемся окне перейти на вкладку Дополнительно и выбрать необходимый тип ограничения из раскрывающегося списка. �Содержание Рис. 16. Настройка типа связи Для данного проекта установите связи как показано на рисунке 17. Для работ Разработка эскизов иллюстраций, Создание иллюстраций и Разработка макета обложки установите тип ограничения Как можно раньше. Добавьте две задачи в начало проекта Начало работ (длительность 0 дней) и в коней проекта Завершение проекта (длительность 0 дней). На диаграмме Гантта эти задачи отобразятся в виде контрольных точек начала и конца проекта (см. рис. 17). После создания графика работ в меню Вид выберите Сетевой график и посмотрите полученный результат. Рис. 17. Диаграмма Гантта для проекта «Создание рекламного буклета» Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя). ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. �Содержание ● Ход работы: ○ Таблица Этапы работ проекта «Создание рекламного буклета» с рассчитанными датами начала и окончания этапов проекта. ○ Диаграмма Гантта. ○ Сетевая диаграмма. ● Описание диаграммы. ● Выводы. �Содержание РАЗРАБОТКА РАСПИСАНИЯ ПРОЕКТА МЕТОДОМ КРИТИЧЕСКОГО ПУТИ Во многом последовательность шагов при формировании расписания этим способом схожа с уже рассмотренной ранее совокупностью, однако в рамках данного метода ключевым элементом становится расчет критического пути [5]. Рассмотрим пример разработки расписания проекта с использованием метода критического пути. ● Создать перечень операций, которые должны быть включены в расписание (используется ИСР, перечень идентичен нижнему уровню иерархической структуры работ). ● Определить длительность каждой операции. Длительность каждой операции определялась в рамках процессов оценки трудоемкости и определения длительности операций. ● Определить предшествующую операцию для каждой операции. Предшествующая операция каждой операции определялась в течение заключительных этапов составления иерархической структуры работ. ● Рассчитать с помощью прямого прохода (forward pass) раннее расписание (early schedule): ранний старт (ES) и ранний финиш (EF) для каждой операции. При расчете раннего расписания для операций требуется придерживаться нескольких правил составления расписаний (scheduling conventions). Данные правила приняты сообществом по составлению расписаний (scheduling community). В расписании старт первой операции всегда назначается на дату старта проекта. Эта дата является входом плана проекта. Первая дата старта является стартом проекта. Дата раннего финиша – это дата раннего старта плюс длительность операции. При этом применяется следующее правило. Считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Это означает, что если длительность операции составляет один день и если она начинается первого января, то заканчивается данная операция также первого января. В соответствии с данным правилом ранний финиш любой операции равен раннему старту плюс длительность минус один. ● Рассчитать с помощью обратного прохода (backward pass) позднее расписание (late schedule) для каждой операции. Для выполнения обратного прохода необходимо начинать с последней операции, которая была выполнена в раннем расписании. Логическим обоснованием этого является следующее: если раннее расписание определяет самую раннюю дату завершения проекта, то в обратном проходе мы ищем для всех операций самые поздние даты их выполнения, при которых проект мог бы быть полностью выполнен. Мы начинаем с наиболее поздней из дат раннего финиша, соответствующей завершению последней операции. Это время позднего финиша (LF). Для получения времени позднего старта (LS) из времени позднего финиша вычитается длительность. ● Вычислить временной резерв (float ) для каждой операции. При расчете дат раннего и позднего расписания проекта обнаруживается, что иногда даты раннего и позднего расписания совпадают, а для некоторых операций они различны. В данных операциях было отличие между датой раннего старта и позднего старта. Разница между этими датами называется �Содержание временным резервом (float или slack). Временной резерв операции – это количество времени, на которое может быть задержана операция, не вызывая задержки завершения проекта. Для расчета временного резерва каждой операции необходимо вычесть дату раннего старта из даты позднего старта операции. Резерв времени можно также рассчитать путем вычитания даты раннего финиша из даты позднего финиша, так как разница между датами начала и окончания представляет собой длительность выполнения операции, которая остается неизменной для раннего и позднего расписания. ● Определить критический путь (critical path). Критический путь (critical path) – это последовательность операций, имеющих нулевой временной резерв (zero float). Операции с нулевым временным резервом – это операции, задержка которых обязательно влечет за собой задержку окончания всего проекта. Операции такого типа необходимо жестко контролировать, чтобы обеспечить завершение работы над проектом в установленное время. И наоборот, операции, которые не лежат на критическом пути и имеют ненулевой временной резерв, необязательно контролировать так жестко. К тому же, важно знать, выполнение каких операций проекта может быть задержано без изменения даты завершения проекта. Ресурсы операций, имеющих резерв времени, при необходимости могут быть использованы для выполнения обхода (workaround). ● Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства (promise date). После того как было определено расписание самого раннего окончания проекта, следует произвести проверку на реальных данных. Расписание должно определять дату окончания проекта, более раннюю, чем дата обязательства (promise date), которая могла быть уже сообщена участникам проекта. Если это не так, надо бить тревогу. Составленное расписание пока еще не включает задержки, которые могут произойти в случае отсутствия необходимых ресурсов. Расписание не дополнено резервами на случай известных или неизвестных рисков. Также не были учтены обычные отклонения, которые будут возникать между предварительно определенной и действительной длительностью операций проекта. ● Подкорректировать расписание или дату обязательства. Затем надо отрегулировать расписание или дату обязательства. Возможны две ситуации: расписание с датой обязательства более ранней, чем предварительно определенная дата, и расписание с датой обязательства более поздней, чем предварительно определенная дата. Если предварительная дата расписания является более поздней, чем обязательства, то необходимо применять сжатие (crashing) или быстрый проход (tracking). Недостатком этих методов для любого расписания является то, что увеличиваются стоимость проекта или риски, а в некоторых случаях и то, и другое. ● Запросить ресурсы и определить ограничения на ресурсы. ● Отрегулировать расписание в соответствии с ограничениями на ресурсы. ● Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства. ● Подкорректировать расписание или дату обязательства. ● Получить одобрение расписания (согласовать расписание). �Содержание ЛАБОРАТОРНАЯ РАБОТА № 4. СОЗДАНИЕ И УПРАВЛЕНИЕ ПРОЕКТОМ С ПОМОЩЬЮ OPENPROJ Цель работы: Изучение процедуры создания и управления проектом с помощью OpenProj. Порядок выполнения работы Сформируйте проект «Создание рекламного буклета» (см. таблицы 19 и 20) и изучите принцип управления проектом с помощью OpenProj. Для этого выполните следующие задания. Задание 1. Создание графика работ Создайте график работ проекта «Создание рекламного буклета» (см. лабораторную работу №3) Задание 2. Группировка работ Для сложных проектов, состоящих из большого количества видов работ, OpenProj позволяет создать иерархическую структуру, объединив связанные между собой работы в группы. Это сделает проект более наглядным и позволит разделить его на отдельные этапы, благодаря чему управлять им будет гораздо легче. Сначала разделите проект на этапы (например, можно выделить этапы планирования, подготовки материалов и подготовки к печати), объединив отдельные виды работ в группы. Введите названия этих этапов в поле Название таблицы. Первый этап Планирование объединит два вида работ: Разработку содержания и Разработку эскизов иллюстраций. Поэтому поместить название этапа нужно перед первой из них. Щелкните правой кнопкой мыши по строке Разработка содержания и выберите Новый, в таблице работ перед этой строкой появится новая строка для записи. Введите с клавиатуры название этапа (Планирование) и нажмите клавишу Enter. OpenProj отобразит введенное название как работу с длительностью 1 день. Таблица 20 Ресурсы проекта «Создание рекламного буклета» № Ре сурс Количе ство че лове к/е диниц оборудования Оплата/затраты 1 Писатель 1 5000 руб. 2 Редактор 1 110 руб./час 3 Художник 1 80 руб./час 4 Верстальщик 1 80 руб./час 5 Корректор 1 80 руб./час 6 Менеджер 1 150 руб./час 7 Компьютер 4 (для писателя, художника, верстальщика, менеджера) Второй этап Подготовка материалов включает три вида работ: Написание текста, Создание иллюстраций и Литературное редактирование. Название этого этапа вставьте перед работой �Содержание Написание текста. Последний этап Подготовка к печати объединит пять видов работ: Верстку, Разработку макета обложки, Корректуру, Цветоделение, Сдачу в типографию. Название этого этапа нужно вставить перед названием работы Верстка. Теперь укажите, какие работы к какому этапу следует отнести. Для этого сначала выделите работы первого этапа, щелкните правой кнопкой мыши по выделению и выберите в контекстном меню Отступ ( ). Выделенные в таблице названия работ будут сгруппированы. При этом их названия сместятся вправо, а название этапа Планирование отобразится полужирным начертанием и черным цветом. В поле Продолжительность появится информация о длительности данного этапа – 5 дней, которую OpenProj определяет на основании длительности отдельных видов работ, включенных в этот этап. При этом на диаграмме появится новый элемент в виде черной полосы с треугольными зубьями на концах, который обозначает этап проекта (см. рис. 18). Аналогичным образом сгруппируйте остальные виды работ в этапы Подготовка материалов и Подготовка к печати. Рис. 18. Группировка работ Задание 3. Создание таблицы ресурсов Любой проект для своей реализации требует ресурсов. Управление проектом будет более эффективным, если каждому виду работ назначить необходимые ему ресурсы, использование которых позволит планировать стоимость работ более точно. Но прежде чем назначить ресурсы отдельным видам работ, следует создать таблицу ресурсов, в которой будет содержаться вся необходимая информация об их количествах и стоимости. Это значительно облегчит следующую задачу назначения ресурсов. Для вызова таблицы ресурсов нажмите пиктограмму на панели инструментов слева. Заполните эту таблицу информацией только о людских ресурсах без учета оборудования, предполагая, что необходимое для данного проекта оборудование уже имеется. Пример заполнения таблицы ресурсов показан на рисунке 19. �Содержание Рис. 19. Таблица ресурсов Задание 4. Назначение ресурсов Теперь, когда таблица ресурсов составлена, назначение ресурсов отдельным видам работ не представляет особой сложности. Для этого перейдите к диаграмме Гантта, щелкнув по соответствующей пиктограмме на панели инструментов слева. Выберите первый вид работы Разработка содержания. Двойным щелчком левой кнопки мыши вызовите окно Информация о задаче. В появившемся окне перейдите на вкладку Ресурсы и нажмите кнопку (назначить ресурс). Работа Разработка содержания будет выполняться менеджером и писателем. Назначьте ей соответствующие ресурсы. Чтобы выделить одновременно два (и более) ресурса используйте клавишу Ctrl. После того как необходимые ресурсы выделены нажмите кнопку Назначить (см. рис. 20). В окне Назначить ресурсы должно появится количество единиц ресурса – 100%, назначенных данной работе. При этом на диаграмме Гантта появятся названия ресурсов, назначенных этому виду работ. Если назначаемый ресурс будет использоваться частично – неполный рабочий день, то в поле Единицы следует указать число, меньшее 100%. Если же какой-либо вид работ будет выполняться несколькими работниками, то количество единиц одноименных ресурсов для него будет больше 100% (например, если работа будет выполняться тремя писателями, то ставим 300%). �Содержание Рис. 20. Назначение ресурсов Остальные ресурсы назначьте с учетом того, что: ● ● ● ● ● ● ● ● ● Разработку эскизов иллюстраций будут выполнять менеджер и художник; Написание текста выполняет писатель; Создание иллюстраций – художник; Литературное редактирование – редактор; Верстку – верстальщик; Разработку макета обложки – художник; Корректуру – корректор; Цветоделение – верстальщик; Сдачу в типографию – менеджер. OpenProj определяет дату окончания проекта, используя даты окончания каждого вида работ, которые зависят от их длительности. Длительность каждой работы определяется по формуле: �Содержание Когда для некоторой работы добавляете или удаляете людские ресурсы, OpenProj увеличивает или сокращает длительность этого вида работ в соответствии с увеличением или уменьшением количества единиц ресурсов. Общий же объем работ при этом не изменяется. Такое планирование называется принудительным и используется OpenProj по умолчанию при назначении ресурсов. Например, для данного проекта может измениться количество дней для работы Разработка содержания, поэтому если есть необходимость оставить продолжительность выполнения данной работы такой, какой она была изначально, достаточно в соответствующей ячейке указать прежнюю длительность этой работы. Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя) ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. ● Ход работы: ○ Таблица Этапы работ проекта «Создание рекламного буклета» с рассчитанными датами начала и окончания этапов проекта. ○ Таблица Ресурсы проекта «Создание рекламного буклета». ○ Диаграмма Гантта. ○ Сетевая диаграмма. ● Описание диаграмм. ● Выводы. �Содержание ЛАБОРАТОРНАЯ РАБОТА № 5. ОТСЛЕЖИВАНИЕ ХОДА ВЫПОЛНЕНИЯ РАБОТ И ФАКТИЧЕСКИХ ЗАТРАТ С ПОМОЩЬЮ OPENPROJ Цель работы: Изучение процедуры отслеживания хода выполнения работ и фактических затрат с помощью OpenProj. Порядок выполнения работы Откройте проект «Создание рекламного буклета» (см. лабораторную работу № 4) и изучите принцип отслеживания хода выполнения работ и фактических затрат с помощью OpenProj. Для этого выполните следующие задания. Задание 1. Способы оптимизации графика работ После того как закончили ввод основных данных для проекта, внимательно просмотрите его, чтобы выяснить, соответствует ли проект вашим ожиданиям. Достигаются ли цели проекта? Не превышает ли его стоимость ваши возможности? Эффективно ли используются ресурсы? Не слишком ли растянуты сроки его реализации? Если какой-либо из перечисленных недостатков имеет место, то следующим шагом будет оптимизировать план таким образом, чтобы сделать его максимально эффективным. Если было установлено, что продолжительность проекта слишком велика, то, прежде всего, следует определить, какими конкретными видами работ это обусловлено. Эти работы называются критическими и образуют критический путь. После того, как были определены работы критического пути, можно откорректировать их так, чтобы сократить общую продолжительность выполнения проекта. Коррекция работ, которые не лежат на критическом пути, не повлияет на сроки завершения проекта. Наиболее очевидным путем сокращения продолжительности проекта является укорочение критического пути посредством уменьшения длительности отдельных критических работ. Начинать оптимизацию всегда следует с самой длительной работы на критическом пути. Уменьшить продолжительность работы на критическом пути можно также сократив объем работы, предусмотренный для данного вида работ. По умолчанию OpenProj вычисляет длительность работы на основании общего объема работы, количества единиц ресурсов, назначенных данному виду работ, рабочего времени и объема работ, определенного для каждого ресурса. Изменить объем работ можно в режиме использования задачи , уменьшив в поле Работа общий объем работы, запланированный для данного вида работ. Еще один способ уменьшения длины критического пути состоит в удалении или комбинировании работ. Комбинирование заключается в таком планировании, при, котором некоторые виды работ будут выполняться одновременно. Если же сделать это практически не представляется возможным, то можно попытаться найти на критическом пути виды работ, которые могут быть разделены на более мелкие и которые, в свою очередь, могут быть выполнены не последовательно, а одновременно. Это также позволит сократить критический путь, так как некоторые из таких мелких работ станут некритическими. Для уменьшения длины критического пути можно использовать также назначение дополнительных ресурсов критическим работам. В некоторых случаях уменьшения длительности работ на критическом пути можно добиться, назначив ресурсам, которые их выполняют, сверхурочные работы. При этом следует помнить, что сверхурочные работы увеличивают стоимость проекта. �Содержание В качестве примера рассмотрим, как уменьшить длину критического пути, назначив ресурсу Корректор работы в выходные дни. Работа в эти дни впоследствии будет компенсирована предоставлением дополнительных дней отдыха. Для этого перейдите в Ресурсы и двойным щелчком мыши вызовите информацию о ресурсе Корректор. На вкладке Общее щелкните по пиктограмме Изменить рабочее время . Выберите выходные дни и установите переключатель на Не по-умолчанию и выставите необходимое время работы с учетом обеденного перерыва (см. рис. 21). Просмотрите внимательно таблицу и диаграмму Гантта и убедитесь, что длительность работы Корректура теперь составляет 4 календарных дня, а не рабочих, и при этом дата завершения проекта также передвинулась на более раннюю дату. Сохраните базовый план (Инструменты – Контроль – Сохранить базовый план). Это позволит в дальнейшем сравнивать в ходе его выполнения фактические показатели с плановыми. Рис. 21. Назначение сверхурочных работ �Содержание Задание 2. Отслеживание хода выполнения работ Как только будет начато выполнение проекта, вы можете целенаправленно управлять им, отслеживая фактические даты начала и окончания отдельных видов работ, их длительность, процент выполнения, объемы и затраты и сравнивать их с плановыми показателями, сохраненными в базовом плане. Это подскажет вам, как фактические изменения плана повлияют на другие виды работ и на дату окончания проекта, и поможет определить, какие изменения необходимо сделать в графике работ для окончания проекта в срок и в пределах установленного бюджета. Полученная информация поможет также более эффективно планировать будущие проекты. OpenProj позволяет, вводить различную информацию о выполнении работ: даты начала и окончания, длительность, процент выполнения, оставшуюся длительность и др. При этом достаточно ввести только один или два показателя. Все остальные данные будут вычислены автоматически. Например, если ввести 50% выполнения для работы с длительностью 10 дней, то оставшаяся продолжительность этой работы будет определена в 5 дней. Если же будет введена оставшаяся продолжительность работ в 2 дня, то программа вычислит процент выполнения – 80%. Рассмотрим различные способы отслеживания хода реализации проекта. Рис. 22. Диалог «Обновить задачу» Сделайте отметку о прохождении контрольной точки Начало работ. В режиме диаграммы Гантта щелчком мыши выделите строку соответствующую контрольной точке и выберите команду Инструменты – Контроль – Обновить задачу. На экране появится диалог Обновить задачу. В поле % выполнения установите значение 100% (рис. 22). Нажмите кнопку Закрыть. В таблице работ слева от названия контрольной точки Начало работ появится отметка о ее прохождении. Выполнение работы в процентах можно ввести также в диалоге Информация о задаче. Чтобы вызвать этот диалог достаточно два раза щелкнуть левой кнопкой мыши по нужной работе (задаче). В появившемся окне изменить значение в поле % завершения (рис. 23). Используя данный способ, введите 100% для работы Разработка содержания. �Содержание Рис. 23. Диалог «Информация о задаче» Для любой работы можно также ввести отметку о выполнении непосредственно на диаграмме с помощью мыши. Установите указатель мыши у левого края полоски-работы Разработка эскизов иллюстраций. Когда указатель примет форму нажмите левую кнопку мыши и, удерживая ее, доведите курсор до конца полоски. Тем самым будет отмечено 100% выполнения данной работы. Установите любым способом выполнение работы Написание текста – 10%. Обратите внимание, что процент выполнения работ на диаграмме Гантта показывается в виде черной черты на полосе-работе. В ходе выполнения проекта возможны случаи, когда какая-либо работа после частичного выполнения прерывается на некоторое время. При этом необходимо перенести оставшуюся часть работы на более поздний срок. Для этого можно щелкнуть по диаграмме правой кнопкой мыши и нажать Разделить. После этого подвести курсор к полоске-работе, которую необходимо разделить и щелкнуть по ней. Работа будет разделена на две части с разрывом в 1 день (по умолчанию). Проделайте данное действие с работой Разработка макета обложки, предполагая, что после того как она будет выполнена на 50% возникнет необходимость прервать ее выполнение на 1 день. При управлении проектом необходимо постоянно владеть информацией о том, выполняются ли работы в соответствии с графиком, и если нет, то как велики отклонения. Анализируя такие данные, можно своевременно принимать необходимые меры для окончания проекта в срок. После проделанной корректировки следует сохранить новый промежуточный план, чтобы дальнейший ход выполнения работ можно было сравнивать с откорректированным планом. Для этого выберите Инструменты – Контроль – Сохранить базовый план и из раскрывающегося списка выберите Базовый план 1. Задание 3. Получение информации о проекте OpenProj способен сохранять огромное количество информации – гораздо большее, чем он может одновременно отобразить на экране. Поэтому программа предлагает различные режимы �Содержание представления информации в разных форматах, позволяющих значительно облегчить ее восприятие. Каждый раз при работе с OpenProj можно использовать различные виды, или режимы. В большинстве из них можно просмотреть, ввести и отредактировать информацию. По умолчанию и чаще всего используется режим диаграммы Гантта, который представляет наиболее важную информацию о работах в виде легко редактируемой таблицы и наглядной диаграммы. Теперь рассмотрим другие наиболее важные возможности просмотра. Сетевой график (ПЕРТ-диаграмма) отображается после нажатия на пиктограмму . Этот режим отображает работы и зависимости между ними в виде сетевого графика. Каждый вид работы здесь представлен прямоугольником, а стрелки, соединяющие эти прямоугольники, символизируют связи между работами. Внутри каждого прямоугольника указано название работы, ее порядковый номер в таблице, длительность, даты начала и окончания (рис. 24). Используя фильтр, сортировку и группировку можно видоизменять сетевой график и получать графическое представление о завершенных, выполняющихся и не начатых работах и другую информацию. Рис. 24. Фрагмент сетевого графика Режим Ресурсы отображает информацию о ресурсах проекта и их стоимости. Также как и диаграмма Гантта является одним из основных режимов программы. Режим WBS (Структура Декомпозиции Работ) отображает информацию о стоимости видов работ. На данном графике помимо базовой стоимости работ отображается и их фактическая стоимость. Кроме того отдельно вычисляется общая стоимость объединенных в группы работ. Режим RBS отображает информацию о фактической и базовой стоимости ресурсов. позволяют получить детальную информацию о ходе выполнения проекта, его Отчеты стоимости и др. Используя различные виды отчетов и выбирая различные колонки (рис. 25), просмотрите появляющиеся на экране отчеты о проекте. Режимы Использование задачи и Использование ресурса отображают информацию о распределении часов на каждый вид работы и каждый из ресурсов в течение всей продолжительности �Содержание проекта. При этом в данных режимах имеется возможность вносить какие-либо изменения и тем самым влиять на длительность работ проекта. Рис. 25. Фрагмент отчета о задачах с колонками, показывающими освоенный объем Вспомогательные режимы Гистограммы и Графики отображают текущую информацию о степени выполнения работ и загруженности ресурсов в графическом виде. Отображаются в нижней части экрана программы и позволяют одновременно с одним из основных режимов просматривать информацию о проекте. Еще один способ получения краткой информации о проекте позволяет, например, узнать даты начала и конца проекта, общую стоимость и расход средств на данный период, общее число часов и прочее. Чтобы вывести на экран краткую информацию о проекте, выберите Проект – Информация о проекте и на вкладках Общее и Статистика просмотрите имеющуюся информацию о проекте. Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя). ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. ● Ход работы: ○ Диаграмма Гантта с текущими изменениями. ○ Сетевая диаграмма. ○ График WBS. ○ График RBS. ○ Информация об общей стоимости проекта. ○ Информация о фактических затратах. ● Описание диаграмм. �Содержание ● Выводы. Контрольные вопросы 1. Что понимают под проектом? 2. Что необходимо для реализации проекта? 3. Какие программные продукты можно использовать для создания и управления проектами? 4. Какие два основных типа ограничения учитывают при разработке расписания проекта? 5. Какие инструменты и методы используют при составлении расписания проекта? 6. Что такое диаграмма Гантта? 7. Как построить диаграмму по методу критического пути? 8. Как построить диаграмму контрольных событий? 9. Что такое сетевая диаграмма? 10. Перечислите способы оптимизации графика работ. 11. Как можно отследить ход выполнения работ по проекту? 12. Каким образом можно получить информацию о проекте? 13. Какие виды отчетов позволяет получать OpenProj? �Содержание УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА При распределении ролей и ответственности, необходимых для выполнения проекта, следует учитывать следующие моменты [5]. Роль в проекте (проектная роль) – определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между членами команды проекта. Проектную роль можно рассматривать как временную должность в организации (компании). Полномочия – право задействовать ресурсы проекта, принимать решения и утверждать одобрение действий или результатов. Примеры полномочий: выбор способа завершения операции, приемка качества и порядок реагирования на отклонения в проекте. Ответственность – работа, которую член команды проекта должен выполнить для завершения операций проекта. Квалификация – навыки и способности, необходимые для выполнения операций проекта. Отсутствие нужной квалификации у членов команды влияет на расписание проекта, качество выполнения работ, ставит под угрозу цели проекта. Для повышения квалификации планируют проведение обучения членов команды. Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения. Со стороны заказчика ключевыми ролями являются – спонсор проекта и менеджер проекта со стороны заказчика. Спонсор проекта обеспечивает организационную сторону проекта и подтверждает правильность целей проекта. В его ведении находится бюджет проекта. Спонсором проекта может быть отдельный человек или целый комитет, в зависимости от масштабов и сложности проекта. Менеджер проекта со стороны заказчика назначается и в том случае, если осуществление проекта организацией заказчика требует ежедневного управления. В его обязанности входит предоставление ресурсов заказчиков, разрешение проблем и отслеживание состояния проекта. Ключевые роли со стороны исполнителя – руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес-менеджер. Бизнес-менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта (руководитель проекта) отвечает как за успехи, так и за неудачи проекта. В его задачи входит управление сроками, стоимостью, качеством работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя. Команда управления проектом включает координатора проекта, администратора проекта, менеджера по конфигурации. Для крупных проектов к выполнению каждой из этих ролей (функций) могут быть привлечено нескольких человек. На небольших проектах менеджер проекта может совмещать несколько ролей (функций). Масштабные проекты предполагают наличие менеджера по качеству, который ответственен перед бизнес-менеджером исполнителя. В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов. Приведенный список ключевых ролей команды управления проектом является необходимым для управления работами при реализации ИТ-проектов, например, при внедрении информационной системы. Возможны некоторые модификации состава команды в зависимости от сложности и масштабности проекта, например, при необходимости можно включать в нее заместителя руководителя �Содержание проекта, руководителей функциональных направлений (финансы, логистика, персонал и т.д.). Состав команды управления должен быть достаточным, чтобы осуществлять: ● управление ресурсами проекта, в том числе: ○ ○ ○ ○ определение требуемых для достижения целей проекта ресурсов; подготовка предложений по изменению состава группы управления проектом; утверждение персональных изменений в составе рабочих групп проекта; оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов; ● управление сроками выполнения проекта, в том числе: ○ подготовка плана работ проекта; ○ контроль над выполнением проекта; ○ подготовка отчетов о ходе работ проекта; ● управление качеством проекта, в том числе: ○ контроль соответствия разрабатываемых проектных решений техническому заданию; ○ организация экспертизы проектных решений; ● управление рисками проекта, в том числе: ○ анализ рисков проекта; ○ разработка планов мероприятий по снижению рисков; ○ реализация мероприятий по снижению рисков; ● управление проблемами проекта, в том числе: ○ анализ проблем проекта; ○ разработка мероприятий по разрешению проблем проекта; ○ реализация мероприятий по разрешению проблем проекта; ● контроль над организацией работ в проектных группах, в том числе: ○ согласование отчетов о ходе работ; ○ контроль над функционированием системы сбора и распределения информации; ○ контроль документирования проектных результатов. В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для ИТ-проектов: функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик. В проекте один член команды может выступать одновременно в нескольких ролях. Совмещение функций часто встречается в небольших проектах, что позволяет снизить накладные расходы проекта. Но не все обязанности можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных должностей, как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать функции менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика. �Содержание Рис. 26. Пример организационной структуры проекта Иерархические организационные диаграммы (см. рис. 26) являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта. Существуют различные форматы документирования распределения ролей и ответственности членов команды проекта, например, иерархический, матричный или текстовый. Независимо от формата документирования организационные диаграммы позволяют для каждого пакета работ назначить ответственного за его исполнение, а также обеспечивают понимание своей роли и ответственности каждым членом команды. Для отражения иерархии подотчетности на проекте и указания обязанностей каждой из групп, входящих в проектную команду, в документ описания содержания проекта рекомендуется включить матрицу ответственности, наиболее распространенный вариант которой известен как RACI-матрица. Использование данного инструмента особенно актуально в ситуации, когда проектная команда состоит из представителей различных юридических лиц (например, типичная команда на проекте внедрения КИС включает в себя сотрудников заказчика, генерального подрядчика и субподрядчиков). Матрица ответственности решает задачу демонстрации межорганизационного или межгруппового взаимодействия и, как следствие, позволяет избежать недоразумений, которые время от времени возникают в проектах между подразделениями и организациями из-за неясности, к кому следует обращаться по тем или иным вопросам и кто должен принимать по ним решение, а кто – непосредственно реализовать принятую резолюцию. Важно как можно раньше произвести размежевание всех формальных полномочий, прав и обязанностей, пока команда проекта еще не приступила к активной работе. В противном случае, когда у сотрудников сложится собственное представление о своем месте в проекте, расхождения во мнениях по этим вопросам могут перерасти в затяжные конфликты и оказать значительное негативное влияние на график выполнения проекта. �Содержание Для построения матрицы ответственности необходимо: 1. Перечислить основные работы проекта. По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР), но с достаточной степенью детализации для обеспечения возможности указывать разные функции, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации. 2. Перечислить группы/роли внутри проектной команды. По горизонтали в матрице перечисляются группы/роли внутри проектной команды. Обратите внимание на то, что в матрице ответственности группы/роли, а не имена и фамилии отдельных членов коллектива. Персональное закрепление проектных работ производится позднее, на этапе разработки расписания проекта. 3. Закодировать матрицу ответственности. С помощью кодов в ячейках на пересечении соответствующих столбцов с ролями и строк с работами проекта указать степень участия, формальные полномочия и распределение ответственности за выполнение каждой операции. Четкое указание разных уровней формальных полномочий бывает особенно полезно в ситуации, когда множество членов проектной команды желает предъявить особые требования к проекту. На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов (см. таблицу 21). 4. Инициировать использование матрицы и включить процедуру использования ответственности в документ «План управления проектом». матрицы После утверждения матрицы ответственности все дальнейшие изменения в ней должны проходить через процедуру интегрированного управления изменениями при участии авторов первоначальной версии. Преимущество использования структурированного подхода к изменению матрицы ответственности состоит в том, что руководитель проекта получает актуальный документ, на который он может ссылаться при возникновении тех или иных спорных ситуаций, касающихся распределения полномочий в проекте. Таблица 21 Условные обозначения матрицы ответственности (RACI) Обозначе ние Расшифровка Описание Исп. (R) Исполнитель (Responsible) Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя Утв. (A) Утверждающий (Accountable) Отвечает за конечный результат перед вышестоящим руководством. На каждую работу должен быть назначен строго один подотчетный �Содержание Обозначе ние Расшифровка Описание Cогл. (C) Согласующий (Consulted) Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер Н. (I) Наблюдатель (Informed) Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер Процесс назначения персонала должен обеспечить укомплектование работ проекта конкретными лицами. Во многих случаях они становятся известны уже в процессе организационного планирования – предварительные назначения из своей или других компаний [3]. Основным методом назначения персонала являются переговоры и обсуждения с функциональными менеджерами и менеджерами других проектов в своей организации, со сторонними организациями, независимыми специалистами. Основной предмет таких переговоров – привлечение в проект лучших и дефицитных кадров в требуемые сроки. Рассмотрим проектные роли на примере внедрения ИС. Куратор проекта (спонсор) – проектная роль должностного лица, отвечающего за стратегическое управление ходом реализации проекта. Куратор принимает решение по стратегическим вопросам проекта, осуществляет утверждение основных изменений в объеме работ, сроках, этапах, в бюджете проекта, находящихся вне компетенции руководителя проекта. Как правило, куратором проекта (спонсором) является менеджер высшего звена организации. Основные функции: ● общее руководство ходом реализации проекта; ● обеспечение выделения необходимых ресурсов для выполнения проекта, обеспечение финансирования работ; ● рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта; ● получение и анализ сводной отчетности о ходе реализации проекта; ● управление изменениями базовых параметров проекта и решение проблем, находящихся вне компетенции руководителя проекта. Основные полномочия: ● утверждение целей проекта; ● согласование назначения руководителя проекта; ● утверждение общего плана и бюджета проекта; ● получение от руководителя проекта сводной отчетности о ходе его выполнения; ● принятие принципиальных решений при возникновении критических изменений, влияющих на сроки, стоимость и качество результатов проекта. Руководитель проекта – проектная роль должностного лица, ответственного за управление проектом. Руководитель проекта непосредственно отвечает за достижение целей проекта в рамках выделенного бюджета, в соответствии с плановыми сроками осуществления проекта и с заданным уровнем качества. Основные функции: ● формирование команды проекта и команды управления проектом; ● планирование, организация и контроль выполнения работ по достижению целей проекта с требуемыми качеством, затратами и в заданный срок; �Содержание ● распределение ресурсов проекта и организация взаимодействия команды проекта в процессе его выполнения; ● организация взаимодействия с заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта; ● учет фактических затрат ресурсов по исполнению проекта; ● формирование и предоставление куратору отчетности по проекту. Основные полномочия: ● назначение задач команде проекта (отдельным ее членам) и контроль их выполнения; ● требование от команды проекта выполнения своих ролевых функций; ● подтверждение или отклонение отчетов о фактических затратах исполнителей проекта; ● обоснование необходимости и запрос куратору проекта на выделение дополнительных ресурсов на проект; ● обращение к куратору за поддержкой в случае необходимости. Архитектор системы – проектная роль должностного лица, отвечающего за предметную область проекта. Архитектор системы подчиняется непосредственно руководителю проекта. Архитектор системы непосредственно отвечает за разработку информационной системы в соответствии с плановыми сроками проекта и с заданным уровнем качества. На роль архитектора системы назначается специалист, наиболее компетентный по внедряемой информационной системе. Архитектор системы должен знать методологии и технологии построения ИС, стандарты и нормативные документы в области проектирования и создания ИС, разработки и оформления технической документации. Основные функции: ● определение состава, продолжительности и технологии выполнения работ по разработке и внедрению информационной системы; ● определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках, заданных условиями проекта; ● определение квалификационных требований и состава рабочих групп специалистов по направлениям деятельности, распределение их по задачам, организация работ и верификация результатов в процессе реализации проекта; ● обеспечение целостности функциональной архитектуры внедряемой информационной системы; ● организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта; ● планирование и согласование фактических трудозатрат специалистов при исполнении проекта; ● формирование и предоставление руководителю проекта необходимой отчетности; ● анализ хода выполнения и промежуточных результатов создания ИС; ● организация, проведение и документирование процедур передачи заказчику разработанной ИС. Основные полномочия: ● участие в календарном планировании работ по созданию ИС; ● назначение задач рабочим группам проекта и контроль их выполнения; ● требование от исполнителей качественного выполнения порученных задач и своевременной информации о возникающих проблемах; ● обоснование необходимости и запрос руководителю проекта на выделение дополнительных ресурсов на проект. �Содержание Администратор проекта – проектная роль должностного лица, отвечающего за информационное обеспечение руководителя проекта, организацию и ведение документооборота по проекту. Администратор проекта функционально закрепляется за конкретным проектом и подчиняется непосредственно руководителю проекта. Основные функции: ● обеспечение руководителя проекта структурированной информацией, дающей возможность контроля проекта, планов, ресурсов и приоритетов; ● ведение протоколов совещаний; ● обеспечение своевременной подготовки, движения и архивации документов по проекту. Основные полномочия: ● передача и получение от участников проекта необходимой документации по проекту; ● контроль соблюдения участниками проекта установленной системы документооборота; ● требование от конкретных исполнителей по проекту оперативной информации и отчетов о ходе работ по проекту. Для того чтобы закрепить функции и обязанности по проекту, составляют ролевые инструкции или положение по проектной роли. В ролевой инструкции должно быть определено следующее: ● какие цели стоят перед сотрудником, назначенным на данную роль; ● кому подчиняется сотрудник, назначенный на ту или иную роль; ● каковы его функции, обязанности, полномочия. Крайне важное замечание, высказываемое многими экспертами, состоит в том, что определение ролей и ответственности в проекте должны производиться с учетом факторов внешней среды предприятия (см. таблицу 22). На этапе планирования для каждой роли должен быть определен список навыков, необходимых членам команды проекта. Для разработки списка рекомендуется использовать реестр навыков – список категорий и компонентов навыков для определенного класса команды исполнителей проекта (см. таблицу 23). Для обеспечения анализа совокупностей навыков компоненты группируются в четыре категории: технические навыки, административные, навыки межличностного общения, стратегические навыки. Для каждого навыка отмечаются рейтинг критичности и рейтинг способностей. Для оценки рейтинга принято использовать 4-балльную шкалу (см. таблицу 24). Таблица 22 Влияние факторов внешней среды на планирование команды проекта Факторы вне шне й сре ды Влияние на опре де ле ние роле й команды и отве тстве нности Организационные Взаимоотношения организаций или отделов, участвующих в проекте, механизмы взаимодействия между ними Технические Навыки и специальности, необходимые для выполнения проекта, необходимость обеспечения координации между языками программного обеспечения, наличие специфических сложностей при переходе от одной фазы жизненного цикла к другой �Содержание Факторы вне шне й сре ды Влияние на опре де ле ние роле й команды и отве тстве нности Межличностные Официальные и неофициальные отношения между потенциальными членами команды проекта, их должностные обязанности. Культурные или языковые различия между членами команды, которые могут оказать влияние на их рабочие взаимоотношения Политические Цели и интересы потенциальных членов команды проекта, люди (или группы людей), которые имеют неформальное влияние в областях, представляющих важность для проекта, существование неформальных связей между потенциальными участниками проекта Таблица 23 Реестр навыков для команды исполнителей проекта Кате гории навыков Компоне нты навыков Технические навыки Умение управлять проектом и его технологией. Оказание помощи в разрешении проблем проекта. Взаимодействие с техническим персоналом. Участие в достижении компромиссов. Понимание тенденций. Понимание основных задач маркетинга. Наличие навыков системного анализа Навыки межличностного общения и лидерства Оказание помощи в решении проблем. Построение многофункциональной команды. Определение целей. Получение поддержки высшего руководства. Мотивация членов команды. Управление конфликтами Административные навыки Привлечение уникальных специалистов. Навыки эффективного общения. Умение делегировать полномочия. Ведение переговоров с целью обеспечения ресурсами. Календарное планирование. Понимание политик и рабочих процедур. Сотрудничество с другими проектными командами Стратегические навыки Стратегическое планирование. Принятие стратегических решений. Умение работать в условиях риска. Умение лидировать �Содержание Таблица 24 Шкала рейтингов критичности и способностей Ре йтинг Критичность Квалификация 1 Неважно/Маловажно Отсутствие навыков / слабые навыки 2 Важно Базовые навыки 3 Очень важно Высокая квалификация 4 Критично для успеха проекта Уникальная квалификация Тестовые задания Практическая работа № 7 по теме «Управление человеческими ресурсами проекта» Практическая работа № 8 по теме «Разработка укрупненного календарного плана проекта» Практическая работа №9 по теме «Анализ календарного плана проекта» �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Наиболее надежным способом разрешения конфликтов, требующим длительной выработки решения, является… a) поиск компромисса посредством сглаживания; b) принуждение; c) решение проблемы – нахождение единственного правильного решения; d) отстранение от конфликта. 2. Ответственным за принятие решения в случае, если в проект добавлены дополнительные работы, и он выходит за рамки финансирования, является… a) менеджер проекта; b) спонсор; c) топ-менеджер (старший менеджер); d) администратор проекта. 3. Ответственным за принятие решения в случае, если требуется выполнить дополнительную работу, задерживающую проект, является… a) топ-менеджер (старший менеджер); b) менеджер проекта; c) функциональный менеджер; d) спонсор. 4. Ответственным за принятие решения в случае, если член команды не выполняет своих функций, является… a) менеджер проекта; b) члены команды проекта; c) топ-менеджер совместно с функциональным менеджером; d) спонсор. 5. Наиболее частыми причинами конфликтов по проекту являются… a) графики, приоритеты проекта и ресурсы; b) стоимость проекта; c) управление проектом конфликтными сотрудниками; d) курс обмена валют. 6. Низшим уровнем потребностей по теории Маслоу является… a) уровень социальных потребностей; b) уровень физиологических потребностей; c) уровень самоуважения; d) уровень духовных потребностей. �Содержание 7. План управления назначением персонала показывает… a) кто, когда и на какие работы назначен; b) кто что делает, и кто за что отвечает; c) то же, что и матрица ответственности; d) кто сколько заработает в случае успешного выполнения проекта. 8. По теории мотивации Герцберга неудовлетворенность к работе не вызывается… a) неадекватной зарплатой и внутренними правилами компании; b) условиями труда и статусом работника; c) уровнем ответственности за выполняемую работу; d) уровнем образования работника. 9. Концептуальной основой «Теории X» Мак-Грегора является то, что… a) работниками надо жестко управлять, не допускать к принятию решений; b) работники могут проявлять самоуправление и творческий подход к работе; c) работники могут хорошо работать без угрозы наказания; d) работников надо чаще поощрять. 10. …не является фактором развития команды. a) совершенствование кадров; b) обучение; c) повышение по должности; d) тренинг. 11. …не является формой власти менеджера проекта. a) официальная власть; b) вознаграждение; c) экспертиза; d) наказание. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 7 ПО ТЕМЕ «УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА» Задание № 1 Установите для проблемной ситуации проектную команду. Объедините членов команды с соответствующими компетенциями в ролевые группы. Постройте иерархическую структуру подотчетности и укажите обязанности каждой из выделенных групп/ролей, для этого воспользуйтесь матрицей ответственности (RACI). Задание № 2 На основе данных описания проблемной ситуации, результатов задания №1, а также исходя из формализованных в уставе проекта целей проекта произведите разграничение обязанностей сторон (ИТ-Графикс и АлтГПУ) по задачам проекта. Совершив анализ полученного результата, создайте организационную структуру проекта и схему организационного взаимодействия проекта, дополнительно воспользовавшись пунктирной линией для обозначения отношений между членами команды проекта, отличных от иерархически-подотчетных (например, коммуникация, неформальное взаимодействие, экстренное решение интеграционных вопросов). Список ролей, работающих в проекте, приведен в таблице 25. Таблица 25 Критерии организационной структуры проекта Команда со стороны АлтГПУ спонсор проекта; руководитель проекта; системный архитектор; эксперт; администратор проекта. Команда со стороны ИТ-Графикс спонсор проекта; руководитель проекта; системный архитектор; руководитель направления (подпроекта); функциональный консультант; ассистент. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 8 ПО ТЕМЕ «РАЗРАБОТКА УКРУПНЕННОГО КАЛЕНДАРНОГО ПЛАНА ПРОЕКТА» Задание Создайте для проблемной ситуации укрупненный календарный план проекта. В качестве примерного перечня проектных работ используйте материалы лекций, а набор ролей формируйте на основе ресурсного плана проекта, разработанного в практической работе №7. Постройте календарный план работ можно в программе OpenProj и отобразите его с помощью диаграммы Гантта. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 9 ПО ТЕМЕ «АНАЛИЗ КАЛЕНДАРНОГО ПЛАНА ПРОЕКТА» При разработке расписания менеджером проекта были последовательно выполнены следующие действия: 1) на основании нижнего уровня иерархической структуры работ составлен перечень операций, которые должны быть включены в расписание; 2) определена длительность каждой операции; 3) определена логическая последовательность выполнения операций; 4) рассчитано раннее расписание для каждой операции; 5) рассчитано позднее расписание для каждой операции; 6) вычислен временной резерв для каждой операции; 7) определен критический путь; 8) подкорректировано расписание в соответствии с датой обязательства; 9) запрошены ресурсы и определены ограничения на ресурсы; 10) отрегулировано расписание в соответствии с ограничениями на ресурсы. Подготовьте ответы на следующие вопросы: ● Какие ошибки допущены менеджером при разработке расписания? ● К каким последствиям может привести вышеизложенный порядок составления расписания? Контрольные вопросы: 1. Перечислите и охарактеризуйте ключевые роли в ИТ-проекте. 1. Что не является развитием команды? 2. Что не следует рассматривать менеджеру проекта при отборе членов команды? �Содержание УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА Лабораторная работа № 6 Расчет параметров состояния проекта Тестовые задания �Содержание ЛАБОРАТОРНАЯ РАБОТА № 6. РАСЧЕТ ПАРАМЕТРОВ СОСТОЯНИЯ ПРОЕКТА Цель работы: Рассчитать параметры состояния проекта, используя метод анализа освоенного объема. Краткое теоретическое обоснование Управление стоимостью Соблюдение базового плана по стоимости требует немалых усилий и действий менеджера проекта. Процесс управления стоимостью проекта заключается [3]: ● в регулировании факторов, влияющих на стоимость; ● в сборе и актуализации данных об исполнении в программе календарного планирования; ● в анализе отклонений, выявлении фактов изменения и фактическом изменении базового плана по стоимости как документально, так и корректирующими воздействиями на участников проекта. На входе процесса управления стоимостью имеется: ○ базовый план по стоимости и план управления стоимостью; ○ отчеты по исполнению; ○ запросы на изменение. На выходе процесса: ○ уточненные оценки стоимости и бюджета; ○ корректирующие действия; ○ прогноз по завершении – вероятная стоимость всего проекта, основанная на текущей фактической стоимости; ○ закрытие проекта. Основным методом измерения исполнения и управления стоимостью проекта является метод анализа освоенного объема. Преимущество метода над другими методами в том, что он позволяет: ● объединить бюджет, расписание и исполнение, т.е. стоимость, время и объем работ, которые при этом измеряются в одинаковых единицах – денежном эквиваленте; ● вычислять прогнозные показатели выполнения работ и показатели сроков завершения проекта. Любой другой метод, основанный на измерении одного параметра, например, выполнения бюджета или выполнения расписания, не дает полной картины. А это есть риск, в первом случае не уложиться в сроки, а во втором случае не уложиться в бюджет. �Содержание Метод анализа освоенного объема Метод основан на отслеживании трех показателей проекта в определенные контрольные даты (см. таблицу 26). Таблица 26 Показатели стоимости проекта Наиме нование показате ля Плановый объем, ПО Освоенный объем, ОО Фактическая стоимость, ФС Обще принятое обозначе ние Суть Поясне ние Есть плановая стоимость запланированных работ, т.е. сколько денег должны были потратить на контрольную дату Согласно базовому плану по стоимости, каждая работа имеет собственные оценки стоимости и сроков. PV есть стоимость с нарастающим итогом EV (Earned Value) Есть плановая стоимость выполненных работ, т.е. сколько по плану стоило бы то, что сделано на контрольную дату Объемом работы считают бюджет работы. Освоенный объем рассчитывается для каждой работы согласно проценту ее выполнения. EV с нарастающим итогом показывает действительно выполненный объем работ AC (Actual Cost) Есть фактическая стоимость выполненных работ, т.е. во AC также рассчитывается с что обошлось то, что нарастающим итогом сделано на контрольную дату PV (Planned Value) Большие отклонения между значениями параметров PV, EV и AC являются поводом для беспокойства менеджера проекта. Варианты соотношений этих параметров в виде S-кривых приведены на рисунке 27. Сбор данных по исполнению проекта, а именно, оценка доли (процента) завершенности работ проекта, требуют дополнительных трудозатрат членов команды проекта и являются непростой задачей. Трудности сбора и оценки могут быть различного характера: ● необходимо обеспечить временную синхронизацию фактических затратах и объемах выполненных работ; моментов формирования отчетов о ● необходимо обеспечить одинаковое понимание участниками проекта процента завершенности и снимаемых показателей. Например, под процентом выполнения работ многие склонны считать процент затраченного времени, в то время как это есть процент выполненного объема работ. �Содержание Рис. 27. Варианты соотношений параметров PV, EV и AC в виде S-кривых Поэтому в некоторых случаях ограничиваются простым отчетом о состоянии работ проекта. В частности, применяют правило 50/50 (или 20/80, или 0/100), в котором о каждой работе необходимо знать лишь ее состояние – работа начата или работа завершена. В правиле 50/50, если работа начата, то ей дается кредит частичного выполнения в 50% освоенного объема, а оставшиеся 50% зачисляются только после завершения работа. В правиле 0/100 работа не получает кредит частичного выполнения и засчитывается только после полного завершения работы. Другие показатели метода анализа освоенного объема поясняются ниже в таблице 27 – их следует внимательно изучить. Все показатели, кроме Индексов, также измеряются в денежных единицах (руб., USD и т.д.). Анализ освоенного объема проводят обычно в заранее запланированных контрольных точках, или на момент завершения вех проекта и т.д. Рассчитанные для каждой контрольной точки показатели заносят в сводную таблицу (см. таблицу 28). �Содержание Таблица 27 Расшифровка показателей метода анализа освоенного объема Наиме нование показате ля Обще принятое обозначе ние Суть Поясне ние Отклонение по стоимости CV (Cost variance) CV=EV-AC, т.е. разница между действительно выполненной работой и затратами на ее выполнение Отрицательная величина означает перерасход бюджета, переплату. Положительная – недоплату Отклонение по срокам SV (Schedule variance) SV=EV-PV, т.е. разница между действительно выполненной работой и работой, которую ожидалось выполнить на контрольную дату Отклонение от графика работ: отрицательная величина – отставание от расписания, положительная – опережение Индекс выполнения стоимости CPI (Cost performance index) CPI=EV/AC есть объем выполненных работ в расчете на единицу фактических затрат Показатель эффективности выполнения работ – сколько денег получаем с каждой вложенной единицы денег Индекс выполнения сроков SPI (Schedule performance index) SPI=EV/PV есть объем Показатель эффективности выполненных работ на единицу графика – сколько процентов ожидаемой плановой стоимости выполняем от запланированного объема Бюджет по завершении BAC (Budget at completion) Бюджет проекта Общая сумма Прогноз по завершении EAC (Estimate at completion) EAC=BAC/CPI или EAC=AC +(BAC-EV)/CPI Сколько будет в итоге стоить проект, если будет выполняться с текущей эффективностью на контрольную дату Прогноз до завершения ETC (Estimate to complete) ETC=EAC-AC или ETC=(BAC-EV)/CPI Остаток стоимости для завершения проекта, если он будет выполняться с текущей эффективностью на контрольную дату VAC=BAC-EAC Каков будет перерасход бюджета в конце, если проект будет выполняться с текущей эффективностью на контрольную дату Расхождения при VAC (Value at завершении completion) �Содержание Таблица 28 Сводная таблица показателей Отклонение стоимости Контрольные даты Отклонение расписания PV EV AC CV CPI SV SPI EAC ETC VAC Дата 1 ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх Дата 2 ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх ххх Дата N BAC=xxxxxx Ведение такой таблицы важно, поскольку: а) по ней видна тенденция изменения каждого показателя; б) можно делать оценки по прогрессу проекта, строить графики (S-кривые); в) принимать решения по дальнейшей судьбе проекта (продолжать или завершать), принимая во внимание и другие финансовые показатели. Для более глубокого понимания метода анализа освоенного объема и расчета показателей, разберем пример выполнения «дипломного проекта» (таблица 29). За основу примем сетевую диаграмму данного проекта на контрольную дату – 31.03, т.е. конец 30-го дня проекта (рис. 28). Пояснения к сетевой диаграмме приведены на рисунке 29. Таблица 29 Дипломный проект Дата начала Дата окончания Плановая стоимость (руб) Сумма нарастающим итогом (руб) 1. Получить тему ДП 02.03 02.03 200 200 2. Собрать, изучить литературу 03.03 16.03 3000 3200 3. Провести расчеты 03.03 09.03 1000 4200 4. Составить оглавление 17.03 09.03 500 4700 5. Написать содержание 17.03 15.04 7000 11700 6. Начертить чертежи 10.03 24.03 2000 11900 7. Пройти предзащиту 16.04 29.04 4000 15900 Работа �Содержание Рис. 28. Сетевая диаграмма «дипломного проекта» Расчет параметров состояния проекта с выводами приведен в таблице 30. Как видно из данной таблицы, этот проект выполняется с большим превышением бюджета и отставанием по срокам. Менеджеру проекта следует предпринять меры для компромиссного решения по срокам, стоимости и содержанию. В данном случае, сроки не могут быть сдвинуты. Поэтому следует выполнить интенсификацию работ за счет изменения, сокращения содержания (объема, качества) и уменьшения стоимости работ, быстрого прохода оставшихся работ. В реальном проекте, где задействовано много участников, много интересов и много денег, эти изменения должны быть согласованы со всеми стэйкхолдерами (заинтересованными сторонами / причастными сторонами), прописаны в документы проекта и приняты к исполнению. Рис. 29. Пояснения к сетевой диаграмме «дипломного проекта» �Содержание Таблица 30 Расчет параметров состояния «дипломного проекта» с выводами Показате ль Расче т Отве т Вывод PV 200 + 3000 + 1000 + 500 + 3500 + 4000 + 0 12200 На 30-й день должна быть выполнено 12200 руб. из общей стоимости работ 18700 EV 200 + 3000 + 1000 + 250 + 1400 + 2000 + 0 7850 Фактически выполнено 7850 руб. из общей стоимости работ. Здесь 1400 есть 40% от 3500руб., т.к. 30-ый день попадает ровно на середину работы №5 AC 100 + 3500 + 800 + 700 + 2500 + 3000 + 0 10600 Фактически потрачено 10600 руб. BAC 200 + 3000 + 1000 + 500 + 7000 + 4000 + 3000 18700 Бюджет проекта 18700 руб. CV=EV-AC 7850 - 10600 -2750 Превышение бюджета на 2750 руб. SV=EV-PV 7850 - 12200 -4350 Отстаем от расписания – недовыполнено объема на 4350 руб. CPI=EV/AC 7850/10600 0,741 Получаем 0,741 рубль с каждого вложенного рубля SPI=EV/PV 7850/12200 0,643 Выполняем 64% от запланированного объема EAC=BAC/CPI 18700/0.741 25236 Общая стоимость проекта составит 25236 руб. при текущей эффективности ETC=EAC-AC 25236 - 10600 14636 С текущей эффективностью работ потребуется потратить 14636 руб., чтобы закончить проект VAC=BACEAC 18700 - 25236 -6536 Бюджет будет превышен по завершению проекта на 6536 руб., если работать с текущей эффективностью Метод анализа освоенного объема ориентирован на оценку затрат проекта в процессе его исполнения. Он может использоваться также при принятии решения о целесообразности продолжения проекта. В то же время, каждый проект с какого-то момента времени предполагает получение прибыли или экономии. Первую оценку прибыли проводят при обосновании проекта, сравнивая альтернативы выполнения потенциальных проектов, а также сравнивая их с альтернативой невыполнения проекта. Практическая часть Выполните расчет показателей стоимости проекта, используя метод анализа освоенного объема, для следующей проблемной ситуации. После удачного завершения пилотного проекта внедрения ИС было принято решение о тиражировании типового проектного решения (ТПР) на оставшиеся 8 бизнесединиц (БЕ) компании. Согласно плану, тиражирование ТПР на одну БЕ должно было занять 3 месяца при плановых затратах в $123250. Через год было произведено 5 проектов последовательного тиражирования при суммарной фактической стоимости $630750. �Содержание Произведите расчет показателей: ● ● ● ● ● ● ● ● ● ● ● PV; AC; EV; BAC; CV; SV; CPI; SPI; EAC; ETC; VAC. Содержание отчета о лабораторной работе: ● Титульный лист (с указанием названия кафедры, названия дисциплины, ФИО и номера группы студента, ФИО преподавателя) ● Название лабораторной работы. ● Цель лабораторной работы. ● Краткое теоретическое обоснование. ● Ход работы: ○ Расчет показателей стоимости для проблемной ситуации. ● Выводы. Контрольные вопросы: 1. Что такое критический путь? 2. Что такое смета? 3. Что называют базовым планом по стоимости? 4. Что обозначает отчет о состоянии работ 50/50? 5. Что называют освоенным объемом EV? 6. Индекс выполнения стоимости равен 0,78. Что это означает? 7. Индекс выполнения сроков равен 87%. Что это означает? 8. Прогноз по завершении равен 27350 руб. Что это означает? 9. Когда проект считается завершенным, согласно методу анализа освоенного объема? 10. Что предполагается при вычислении прогноза по завершении EAC? �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Базовый план по стоимости представляет собой… a) оценку работ проекта в денежных единицах; b) распределение затрат проекта во времени; c) оценка количества ресурсов и их единичной стоимости; d) расчет заработной платы участников проекта. 2. В модели коммуникации отправитель-получатель, отправитель отвечает за… a) получение подтверждения, что сообщение понято; b) обеспечение сеанса связи по лучшему каналу; c) устранение препятствий к взаимодействию; d) получение подтверждения, что сообщение отправлено (получено). 3. Индекс выполнения сроков 92% означает, что… a) выполняется 92% запланированного объема; b) проект будет задержан по времени на 92%; c) по завершению проекта будет выполнено лишь 92% объема; d) проект опережает сроки выполнения на 92%. 4. Индекс выполнения стоимости равен 0,81. Это означает, что... a) скорость выполнения проекта составляет 0,81 от запланированной; b) потрачено 81% средств бюджета проекта; c) проект получает 81 копейку с каждого вложенного рубля; d) по завершению проекта будет израсходовано лишь 81% бюджета. 5. За коммуникации команды проекта отвечает… a) менеджер проекта; b) администратор сети; c) менеджер по связи; d) спонсор проекта. 6. Лучший метод обеспечить, чтобы собрание шло в нужном направлении – это… a) никому не мешать, позволить участникам собрания принимать все решения; b) генерировать новые идеи; c) лично принимать все решения; d) часто подводить итог происходящему. 7. Лучший способ решения проблемы менеджера проекта с членом команды – это... a) неофициальное письменное обращение; b) официальное устное обращение; c) неофициальное устное обращение; d) официальное письменное обращение. �Содержание 8. Освоенный объем EV – это… a) плановая стоимость фактически выполненных работ на контрольную дату; b) фактическая стоимость выполненных работ на контрольную дату; c) плановая стоимость запланированных работ на контрольную дату; d) фактическая стоимость всех запланированных работ. 9. Повышению уровня коммуникаций способствует… a) отправитель (получатель) показывает заинтересованность в перспективе; b) громкая отчетливая речь; c) медленная речь; d) внешний вид отправителя (получателя). 10. При вычислении прогноза по завершении EAC предполагается, что... a) BAC изменится к концу проекта; b) индекс выполнения стоимости CPI не изменится до конца проекта; c) индекс выполнения сроков SPI не изменится до конца проекта; d) BAC не изменится к концу проекта. 11. При планировании коммуникаций менеджер проекта должен учитывать… a) расписание проекта; b) структуру проекта, отношения отчетности, количество участников; c) иерархическую структуру работ; d) риски проекта. 12. Прогноз по завершении 34750 руб. означает, что… a) 34750 руб. – это общая стоимость проекта; b) если работать с текущей эффективностью, то общая стоимость проекта составит 34750 руб.; c) сумма 34750 руб. будет превышена по завершению проекта; d) стоимость проекта будет превышена на 34750 руб. 13. Простой отчет о состоянии работ 50/50... a) дает денежный кредит 50% на выполнение работ; b) обозначает одно из двух состояний – работа начата и работа завершена; c) устанавливает точный процент выполнения работ в 50%; d) означает, что 50% оплачено и 50% выполнено. 14. Смета представляет собой… a) оценку работ проекта в денежных единицах; b) распределение затрат проекта во времени; c) оценку единичной стоимости ресурсов; d) оценку всей стоимости проекта. �Содержание 15. Согласно методу анализа освоенного объема, проект считается завершенным тогда, когда… a) BAC=PV; b) BAC=EV; c) BAC=AC; d) BAC=PV+EV. 16. Критический путь – это путь… a) сложенный из резервов операций; b) который нужно пройти в первую очередь; c) не имеющий временных резервов; d) который нужно пройти в последнюю очередь. �Содержание УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА Основные понятия управления рисками Идентификация рисков проекта Качественный анализ рисков Количественный анализ рисков Тестовые задания Практическая работа №10 по теме «Управление рисками проекта» �Содержание ОСНОВНЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ РИСКАМИ Риск проекта – это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению – создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и, следовательно, невозможно спланировать действия по реагированию на такой риск. Событие риска – потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту. Вероятность возникновения риска – вероятность того, что событие риска наступит. Все риски имеют вероятность больше нуля и меньше 1 (100%). Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 1 (100%) также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта. Последствия риска, если он случится, выражаются через дни расписания, трудозатраты, деньги и определяют степень воздействия на цели проекта. Величина риска – показатель, объединяющий вероятность возникновения риска и его последствия. Величина риска рассчитывается путем умножения вероятности возникновения риска на соответствующие последствия. Резерв для непредвиденных обстоятельств (или резерв для покрытия неопределенности) – сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня; обычно включаются в базовый план стоимости или расписания проекта. Управленческий резерв – сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать. Планирование реагирования на риски включает разработку плана управления рисками – документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию. Методологию – определяет и описывает подходы, инструменты и источники данных, используемые для работы с рисками. Роли и обязанности – раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта. Бюджетирование – определяет бюджет для управления рисками проекта. Временные рамки – устанавливают частоту процессов управления рисками. Инструменты – раздел определяет, какие методы количественного и качественного анализа рисков рекомендуется применять и в каких случаях. Контроль – раздел, определяющий формат плана реагирования на риски. Отчетность – определяет способы документирования результатов действий по управлению рисками �Содержание и сохранение информации в базе знаний для накопления опыта и извлечения уроков. Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework). MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта. Методы управления проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту (см. таблицу 31) Для ведения крупных проектов «стандартного» набора методов оказывается недостаточно. Таблица 31 Примеры управления рисками Масштаб прое кта Число работ Число подпрое ктов Связность работ Ме тоды управле ния Малый 10-50 Нет Низкая PMI, FMEA, MSF, личный опыт руководителя Средний 50-100 Единицы Низкая, средняя Стандартные методики (ASAP, PJM, PMI), SPICE, COBIT Kрупный 100-1000 От нескольких десятков до нескольких сотен Высокая Проработаны слабо Расшифровка методов управления из таблицы 31: ● PMI (Project Management Institute) – методология управления проектами Института управления проектами, Пенсильвания США. ● FMEA (Failure Mode and Effects Analysis, анализ видов и последствий отказов) – методология проведения анализа и выявления наиболее критических шагов производственных процессов с целью управления качеством продукции. ● ASAP (Accelerated SAP) – методология внедрения ERP-системы SAP R/3 компании SAP. ● PJM (Project Management) – методология внедрения ERP-системы Oracle Appications корпорации Oracle. ● SPICE (Software Process Improvement Capabilities and dEtermination) – оценка и улучшение процессов разработки ПО. ● COBIT (Control Objectives for Information and Related Technologies («Задачи управления для информационных и смежных технологий»)) – представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления ИТ, аудита и ИТбезопасности. Оценку рисков рекомендуется начинать на стадии планирования проекта, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и �Содержание рамок. С появлением каждого нового ограничения или допущения, связанного с проектом, начинает появляться все большее число рисков. Проектная группа должна инициировать мероприятия по обнаружению рисков как можно раньше. По результатам шагов анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план. Ход выполнения этих планов должен подвергаться мониторингу в рамках стандартного процесса управления проектом. На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия: ● утвердить систематический подход к определению рисков, их оценке и обработке. Системный подход предполагает введение классификации рисков, определение событий, влияющих на ход проекта и его результаты, определение способа выражения рисков. В отношении качества, затрат, сроков или технических характеристик определяют способ выражения рисков в соответствующих терминах, включая показатели там, где это возможно; ● идентифицировать риски. К этому действию относят определение исходных событий, связанных с каждым риском в каждой из категорий рисков, а также выявление взаимосвязей между источниками возникновения рисков. Определяют способ выражения рисков в соответствующих терминах и, при возможности, в показателях. �Содержание ИДЕНТИФИКАЦИЯ РИСКОВ ПРОЕКТА Цель процесса идентификации рисков состоит в определении потенциальных рисков, способных повлиять на успех проекта [5]. Идентификацию рисков выполняют члены команды проекта и эксперты по вопросам управления рисками, в ней могут принимать участие заказчики, участники проекта и эксперты в определенных областях. Это итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла могут обнаруживаться новые риски. Частота итерации и состав участников выполнения каждого цикла в каждом случае могут быть разными. В процессе идентификации должны принимать участие члены команды проекта, чтобы у них вырабатывалось чувство собственности и ответственности за риски и за действия по реагированию на них. Идентификация рисков выполняется на основе разработанных ранее планов управления интеграцией, содержанием, сроками, качеством и человеческими ресурсами. Также при разработке плана учитывается опыт выполнения аналогичных проектов. Для идентификации рисков используют следующие методы. ● Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек – члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют. ● Метод Дельфи аналогичен методу мозгового штурма, но его участники не знают друг друга. Ведущий с помощью списка вопросов для получения идей, касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Консенсус и список рисков получается через несколько циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и боязнь неловкого положения при высказывании идеи. ● Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности. ● Карточки Кроуфорда. Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответ. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта. ● Опросы экспертов с большим опытом работы над проектами. ● Идентификация основной причины. Цель этого процесса: выявить наиболее существенные причины возникновения рисков проекта и сгруппировать риски по причинам, их вызывающим. ● Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа – оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда. �Содержание ● Анализ контрольных списков. Контрольные списки представляют собой перечни рисков, составленные на основе информации и знаний, которые были накоплены в ходе исполнения прежних аналогичных проектов. ● Метод аналогии. Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов. ● Методы с использованием диаграмм. К методам отображения рисков в виде диаграмм относятся диаграммы причинно-следственных связей и блок-схемы процессов, которые позволяют проследить последовательность событий, происходящих в данном процессе. Сравнение методов идентификации рисков приведено в таблице 32. Таблица 32 Сравнение методов идентификации рисков Ме тод иде нтификации Пре имуще ства Не достатки Мозговой штурм Способствует взаимодействию членов группы. Быстрый. Недорогой Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы Метод Delphi Нет доминирования одной личности. Может проводиться дистанционно, через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы Занимает много времени. Высокая загрузка ведущего Метод номинальных групп Уменьшается эффект доминирующей личности. Обеспечивает взаимодействие участников. Дает упорядоченный список рисков Требует много времени. Высокая загрузка ведущего Карточки Кроуфорда Быстрый. Легко реализуется. Должен участвовать каждый член группы. Вырабатывается большое количество идей. Можно проводить с группами большеобычного размера. Уменьшает эффект доминирующей личности Меньшее взаимодействие между участниками Опрос экспертов Используется прошлый опыт Эксперт может быть предвзятым. Требует много времени Контрольные списки Конкретный и упорядоченный. Легко использовать Предвзятость. Может не содержать конкретных элементов для данного проекта Метод аналогии Требует много времени. Легко получить Использует прошлый опыт для исключения результаты, не подходящие для данного проблем в будущем. Подобные проекты случая. Аналогия может быть содержат много сходных черт некорректной �Содержание Ме тод иде нтификации Методы с использованием диаграмм Пре имуще ства Ясное представление участвующих процессов. Легкость построения. Для них имеется много компьютерных инструментов Не достатки Иногда вводит в заблуждение. Может занимать много времени Таблица 33 Пример заполнения расширенного журнала рисков Тип риска Описание риска Заказчик может задержать выпуск продукта из-за Технологиче постоянных изменений и ский дополнений требований к продукту Финансовый Заказчик настаивает на бесплатном исправлении всех ошибок (в данном случае речь идет только о тех пунктах, которые мы также можем признать ошибками), что может привести к серьезным финансовым потерям Проактивные ме роприятия Ре активные Ве роят После д Фактор ме роприятия ность ствия риска 1. Разделить требования на «абсолютно необходимые» и «хорошо бы было иметь», до запуска системы выполнять только абсолютно необходимые требования. 2. Убедиться в том, что руководство заказчика понимает и поддерживает подход, что заявки на изменения будут выполняться после завершения основных работ везде, где это возможно 1. Обсудить изменение сроков ввода системы в эксплуатацию из-за накопившегося объема изменений для обеспечения необходимого уровня качества финального продукта 8 6 48 1. Включить в план работ бюджет и время программистов на исправление ошибок по результатам тестирования. 2. Разъяснять ключевым представителям заказчика, что выявление и исправление ошибок является частью технологии разработки ПО 1. В случае невозможност и достижения договоренност и поднять вопрос на уровень управляющего комитета 8 6 48 Идентифицированные риски документируются в так называемых реестрах рисков. В более сложных проектах, где есть необходимость обеспечить высокое качество результата при большом количестве работ, принято использовать расширенные реестры рисков и в них сразу указывать экспертную оценку воздействия риска на проект (см. таблицу 33). �Содержание КАЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ Качественный анализ рисков подразумевает оценку рисков в терминах их возможных последствий, используя установленные критерии. Критерии могут учитывать затраты, официальные и предписанные требования, социально-экономические аспекты и факторы внешней среды, интересы заказчика, приоритеты и иные исходные данные для оценки. Результат процесса качественной оценки – определение градации рисков по их вероятности и последствиям. Основная проблема управления рисками заключается в размере перечня рисков, полученного на этапе идентификации. Управлять всеми выявленными рисками невозможно, так как это требует больших финансовых и кадровых затрат. Основные задачи качественного анализа состоят в разделении рисков на группы и расположении их в порядке приоритетов. Классифицировать риски можно, например, по их временной близости. Так, близкие риски должны иметь более высокий приоритет, чем риски, которые могут случиться в отдаленном будущем. Расположения рисков по степени их важности для дальнейшего анализа или планирования реагирования на риски может быть выполнено путем оценки вероятности их возникновения и воздействия на проект. Качественный анализ рисков – быстрый и недорогой способ установки приоритетов – выполняется на протяжении всего жизненного цикла проекта и должен отражать все изменения, относящиеся к рискам проекта. Рис. 30. Отображение миграции риска A в матрице воздействия риска Матрица вероятностей и последствий – инструмент, позволяющий определять ранг риска отдельно для каждой цели, например, для стоимости, времени или содержания. Ранг риска помогает управлять реагированием на риски. Например, для рисков, расположенных в зоне высокого риска (область красного цвета) матрицы (рис. 30), необходимы предупредительные операции и агрессивная стратегия реагирования. Для угроз, расположенных в зоне низкого риска (зеленый цвет), осуществление предупредительных операций может не потребоваться. Матрица вероятностей и последствий позволяет отслеживать динамическую миграцию рисков. На рисунке 30 показан пример изменения ранга риска A с течением времени. �Содержание КОЛИЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ Количественный анализ рисков обычно выполняется для рисков, которые были квалифицированы в результате качественного анализа. При количественном анализе также оцениваются вероятности возникновения рисков и размеры ущерба/выгоды; здесь анализируются риски, имеющие высокие и умеренные ранги. Выбор методов анализа определяется для каждого проекта и зависит от наличия времени и от бюджета. Исходной информацией для количественного анализа рисков служат: ○ активы организационного процесса; ○ описание содержания проекта; ○ план управления рисками; ○ реестр рисков; ○ план управления проектом. Наиболее распространенным методом количественного анализа является анализ дерева решений. Дерево решений – это графический инструмент для анализа проектных ситуаций, находящихся под воздействием риска. Дерево решений описывает рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария. Дерево решений имеет пять элементов (рисунок 31). Рис. 31. Дерево решений для проектной ситуации, находящейся под воздействием риска �Содержание Точки принятия решений – это моменты времени, когда происходит выбор альтернатив. Точка случайного события (точка возникновения последствий) – момент времени, когда с тем или иным результатом наступает случайное событие. Ветви – линии, соединяющие точки принятия решений с точками случайного события. Ветви, исходящие из точки принятия решений, показывают возможные решения, а линии, исходящие из узлов случайных событий, представляют возможные результаты случайного события. Вероятности – числовые значения, расположенные на ветвях дерева и обозначающие вероятность наступления этих событий. Сумма вероятностей в каждой точке принятия решений равна 1. Ожидаемое значение (последствия) – это расположенное в конце ветви количественное выражение каждой альтернативы. Модель создается слева направо. Построение начинается с отображения точки принятия решения, имеющей вид квадрата. Из этой точки рисуют количество ветвей, равное числу проектных альтернативных решений. В конце каждой ветви рисуют кружок, обозначающий возникновение допустимого случайного события, из которого выходят две ветви – возможные результаты вероятностного события. Ветви дерева берут свое начало в точке принятия решений и разрастаются до получения конечных результатов. Путь вдоль ветвей дерева состоит из последовательности отдельных решений и случайных событий. Пример использования дерева решения Торговая компания открывает новый магазин, который должен быть укомплектован новейшим оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования. Для увеличения эффективности работы компания планирует осуществить внедрение ИС класса ERP. Разработаны три варианта расписания внедрения информационной системы: вариант 1, вариант 2, вариант 3. Длительность проекта рассматривается как параметр первостепенной важности. Расписание внедрения ИС зависит от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ информации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%; соответственно, для поставщика 2 эта вероятность будет равна 40% . Команда проекта разработала сетевые графики трех альтернативных вариантов расписания внедрения ИС при условии, что оборудование уже поставлено, и оценила возможные значения продолжительности проекта. Рассчитаем возможную длительность проекта для каждого точки случайного события: ожидаемая длительность для случайного узла A: (80 дней ∙0,6)+(70 дней ∙0,4)=76 дней; ожидаемая длительность для случайного узла B: (70 дней ∙0,6)+(75 дней ∙0,4)=72 дней; ожидаемая длительность для случайного узла B: (75 дней ∙0,6)+(80 дней ∙0,4)=78 дней; �Содержание Результат дерева решений – вариант расписания с наименьшей продолжительностью, равной 72 дням. Дерево решений – инструмент, который позволяет наглядно провести анализ проектных решений, содержащих несколько путей решения. Такое определение данного метода дает возможность с полным основанием использовать его для принятий решений о продолжении и ходе развития проекта на шлюзах. По итогам проведения качественного и количественного анализа риска необходимо выработать четкое представление о стратегиях, используемых для реагирования на каждый проектный риск. Стратегия реагирования на риски – совокупность методов, которая будет использована для снижения негативных последствий или вероятности реализации идентифицированных рисков. Для каждого риска необходимо выбрать свою стратегию, которая обеспечит наиболее эффективную работу с ним. Существует четыре типовые стратегии реагирования на появление негативных рисков: уклонение, передача, принятие и снижение. 1. Уклонение от риска. Стратегия состоит в полном исключении воздействия риска на проект за счет изменений характера проекта или плана управления проектом. Некоторых рисков, возникающих на ранних стадиях проекта, например, из-за отсутствия четкого определения требований заказчика, можно избежать, затратив дополнительное время и увеличив трудозатраты на их выявление. Однако эта стратегия не может полностью исключить риск. 2. Передача риска. Стратегия передачи риска также исключает угрозу риска путем передачи негативных последствий риска с ответственностью за реагирование на риск на третью сторону. Передача риска обычно сопровождается выплатой премии за риск стороне, принимающей на себя риск и ответственность за его управление. Сам риск при этом не устраняется. Условия передачи ответственности за определенные риски третьей стороне могут определяться в контракте. 3. Принятие риска. Стратегия означает решение команды не уклоняться от риска. При пассивном принятии риска команда ничего не предпринимает в отношении риска и в случае его возникновения разрабатывает способ его обхода или исправления последствий. При активном принятии риска план действий разрабатывается до того, как риск может произойти, и называется планом действий в непредвиденных обстоятельствах. 4. Снижение риска. Стратегия снижения риска предполагает усилие, направленное на понижение вероятности и/или последствий риска до приемлемых пределов. В стратегии снижения используется включение в план проекта дополнительной работы, которая будет выполняться независимо от возникновения риска, как, например, проведение дополнительного тестирования функциональности информационной системы, разработка прототипа системы, дополнительное подключение к работе опытных сотрудников. �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта, называется… проекта. a) риском; b) событием риска; c) величиной риска; d) событием. 2. Риски подразделяются на… a) известные и неизвестные; b) главные и второстепенные; c) основные и дополнительные; d) резюмирующие и детализированные. 3. Потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту, называется… a) риском проекта; b) событием риска; c) величиной риска проекта; d) событием проекта. 4. Все риски имеют вероятность… a) больше или равную нулю и меньше 100%; b) больше нуля и меньше или равную 100%; c) больше нуля и меньше 100%; d) больше или равную нулю и меньше или равную 100%. 5. Показатель, объединяющий вероятность возникновения риска и его последствия, называется … a) риском проекта; b) событием риска; c) событием проекта; d) величиной риска. 6. Сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня, называются… a) резервом для непредвиденных обстоятельств; b) управленческим резервом; c) методологией; d) MSF. �Содержание 7. Сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать, называются… a) резервом для непредвиденных обстоятельств; b) управленческим резервом; c) методологией; d) MSF. 8. …определяет и описывает подходы, инструменты и источники данных, используемые для работы с рисками. a) резерв для непредвиденных обстоятельств; b) управленческий резерв; c) методология; d) MSF. 9. … – раздел, определяющий, какие методы количественного и качественного анализа рисков рекомендуется применять и в каких случаях. a) Управленческий резерв b) Методология c) MSF d) Инструменты 10. …описывает/описывают процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта. a) b) c) d) управленческий резерв; методология; MSF; инструменты. 11. …предполагает/предполагают введение классификации рисков, определение событий, влияющих на ход проекта и его результаты, определение способа выражения рисков. a) системный подход; b) методология; c) MSF; d) инструменты. 12. Относительная шкала последствий… a) разрабатывается каждой организацией самостоятельно; b) разрабатывается всеми организациями вместе; c) всегда одна для всех; d) имеет несколько общих видов. �Содержание 13. …содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший. a) резерв для непредвиденных обстоятельств; b) управленческий резерв; c) матрица вероятности и последствий; d) MSF. 14. Создание подробного списка рисков проекта на собрании, в котором принимает участие 10–15 человек, называется… a) мозговым штурмом; b) методом Дельфи; c) методом номинальных групп; d) карточкой Кроуфорда. 15. Если участники не знают друг друга, а ведущий с помощью списка вопросов для получения идей, касающихся рисков проекта, собирает ответы экспертов, имеет место реализация… a) мозгового штурма; b) метода Дельфи; c) метода номинальных групп; d) карточки Кроуфорда. 16. …позволяет/позволяют идентифицировать и расположить риски в порядке их важности, при этом каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. a) мозговой штурм; b) метод Дельфи; c) метод номинальных групп; d) карточки Кроуфорда. 17. собирается группа из 7–10 экспертов, ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответ, то имеет место реализация... a) мозгового штурма; b) метода Дельфи; c) метода номинальных групп; d) карточки Кроуфорда. 18. …использует накопленные знания и планы по управлению рисками других аналогичных проектов. a) мозговой штурм; b) метод Дельфи; c) метод номинальных групп; d) метод аналогии. �Содержание 19. Ответ на риск должен быть дан не позднее… рабочих дней от даты регистрации вопроса. Если вопрос не будет решен на уровне руководителей проекта, он будет эскалирован на уровень проектного офиса программы внедрения ERP. a) пяти; b) четырех; c) трех; d) двух. 20. Риски определяются в течение следующих фаз проекта… a) инициализации; b) исполнения; c) внедрения; d) внедрения, исполнения и инициализации. 21. Вычисление ожидаемого значения нескольких факторов, называется... a) деревом решений; b) ожидаемым значением; c) графическим методом; d) методом освоенного объема. риска и принятие решения в 22. Затраты на неидентифицированные риски учитываются в статье расходов… a) «управленческий резерв»; b) «бюджет на непредвиденные обстоятельства»; c) «фонд управления рисками»; d) «устав проекта». 23. Матрица вероятности и последствий используется для… a) анализа чувствительности рисков; b) вычисления ожидаемых значений рисков; c) качественного ранжирования рисков по уровням; d) количественного анализа рисков. 24. Список выявленных рисков формируется на выходе процесса… a) планирования управления рисками; b) идентификации рисков; c) качественного анализа рисков; d) количественного анализа рисков. 25. Риски присутствуют в проектах из-за… a) неадекватной толерантности исполняющей организации к рискам; b) неопределенностей относительно желаемого результата; c) невозможности защитить проект извне; d) невозможности защитить проект изнутри. условиях влияния �Содержание 26. Способ обнаружения рисков, основанный на выявлении хороших и плохих внешних и внутренних факторов исполняющей организации, называется... a) метод Дельфи; b) SWOT-анализом; c) анализом документации; d) ТСО. 27. Стратегия, позволяющая выполнить некоторые действия и не учитывать риск впоследствии, называется... a) уклонение от риска; b) принятие риска; c) передача риска; d) влияние на риск. 28. Триггером риска – симптомом, сигнализатором риска не может быть… a) задержка выполнения нескольких операций; b) повторяющиеся однотипные дефекты; c) предсказание члена команды; d) увеличение стоимости. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 10 ПО ТЕМЕ «УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА» Задание 1. Качественный анализ рисков На этапе планирования, ранее, руководителем проекта были определены следующие риски, а также экспертным методом установлены вероятность и последствия их наступления (см. таблицу 34). Таблица 34 Матрица описания рисков на этапе планирования № Описание риска Ве роятность наступле ния После дствие 1 (A ) Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 20% Задержка даты завершения проекта на 1.4 месяца 2 (B ) Некорректная настройка системы (несоответствие первоначальным требованиям) 20% Отказ представителей компании BigCo акцептовать выполненные работы 3 (C ) Сопротивление конечных пользователей, саботаж проектных работ и неприятие результатов проекта 50% Увеличение стоимости проекта на €300 тыс. На выполнение проекта отводится 14 месяцев. Объем денежных средств, выделенных компанией на реализацию проекта, составляет €2 млн. Кроме того, на этапе планирования экспертами для всего проекта была разработана эталонная шкала оценки влияния рисков (таблица 35). Таблица 35 Шкала оценки влияния рисков Количе стве нная Оче нь низкое характе ристика → Объе кт влияния ↓ 0,05 Низкое Уме ре нное Высокое Оче нь высокое 0,1 0,2 0,4 0,8 Стоимость Незначительное увеличение Увеличение <5% Увеличение 510% Увеличение 1120% >20% увеличение Сроки Незначительное увеличение Увеличение сроков <5% Увеличение 510% Увеличение 1120% >20% увеличение Каче ство Изменения незаметны Незначительны е изменения Изменения не требуют согласования Неприемлемое для клиента изменение Достижение конечных результатов невозможно 1. Выстройте матрицу вероятности и последствий риска. Применяя шкалу оценки влияния риска, выделите на матрице 3 ранга воздействия: низкое, среднее и высокое. 2. Применяя шкалу оценки влияния риска, отобразите на матрице вероятностей и последствий указанные риски и определите их приоритетность. �Содержание Задание 2. Количественный анализ рисков Руководство компании CoCompany приняло решение о расширении организационного и географического объема проекта внедрения КИС. В связи с этим руководителю проекта необходимо проанализировать две взаимоисключающие стратегии внедрения КИС на географически распределенных объектах: стратегию большого взрыва и стратегию тиражирования пилотного проекта, – и принять решение о стратегии внедрения КИС. Предполагается, что реализация проекта в соответствии со стратегией большого взрыва займет не более 25 месяцев, тогда как при использовании стратегии тиражирования пилотного проекта – 40 месяцев. Самое ранее завершение проекта позволит компании раньше начать получение отдачи от произведенных инвестиций, произвести запланированное размещение на Лондонской бирже по более высокой ставке на общую сумму €125 млн. Упущенные выгоды в месяц составляют €30 тыс., а размещение без внедренной системы будет произведено на общую сумму в €110 млн. В CoCompany, кроме проекта внедрения КИС, ведутся параллельные проекты, результаты которых необходимы для старта проекта компании BigCo. Кроме того, большая часть ресурсов, которые впоследствии будут использованы на проекте внедрения КИС, задействована на тех проектах. По плану, параллельные проекты должны быть завершены к моменту, когда ресурсы потребуются для реализации проекта внедрения КИС с применением стратегии большого взрыва. Реализация стратегии тиражирования пилотного проекта подразумевает меньшее количество привлекаемых ресурсов и более низкую интенсивность работ. По указанной причине завершение параллельных проектов в срок не является критичным для реализации проекта в соответствии с данной стратегией. К тому же, после успешной реализации «пилота» и получения подтверждения о завершении параллельных проектов у руководителя проекта есть возможность принять решение о тиражировании ТПР сразу на все бизнес-единицы, что добавит к стоимости проекта тиражирования €2 млн. В этом случае продолжительность проекта составит 30 месяцев, и компания успеет произвести размещение по повышенной ставке на общую сумму €125 млн. В ходе экспертного анализа были получены следующие данные. ● Вероятность завершения параллельных проектов в срок и своевременное выделение всех необходимых ресурсов ожидается с вероятностью 0,5. ● С вероятностью 0,2 ожидается завершение работ по параллельным проектам к моменту завершения пилота с незначительными проблемами по высвобождению ресурсов, а с вероятностью 0,3 – сильное отклонение по срокам на параллельных проектах. ● При тиражировании «пилота» сразу на все бизнес-единицы могут возникнуть проблемы с окончательным высвобождением ресурсов с параллельных проектов, тогда продолжительность проекта составит 42 месяца и размещение будет произведено по обычной ставке на общую сумму €110 млн. ● Если в случае успешной реализации «пилота» и получения подтверждения о завершении параллельных проектов руководитель принимает решение о постепенном тиражировании и не возникает проблем с окончательным высвобождение ресурсов с параллельных проектов, то длительность проекта составит 44 месяца, ввиду избыточного количества ресурсов. Также была совершена оценка проектных работ и получены следующие данные. ● Внедрение «большим взрывом» при отклонении установленных проектов от запланированных �Содержание сроков продлится 50 месяцев, поскольку потребуется ждать завершения проектов и возникнут проблемы с интеграцией. ● На основе сделанной оценки стоимости проектных работ было установлено: ○ Проект «большого взрыва» будет стоить €6 млн. ○ Проект «тиражирование пилотного проекта» будет стоить €5 млн. ○ Проект «тиражирование пилотного проекта» сразу на все бизнес-единицы будет стоить €7 млн (= €5 млн + €2 млн). Рассмотрите ситуации при помощи метода «дерево принятия решений», на основе количественной (финансовой) оценки каждого из возможного исходов сформируйте свои рекомендации по выбору стратегии внедрения КИС. Пример расчета рисков методом «дерево принятия решений» [3]: Допустим в проекте есть представление о доработке некоторой системы перед запуском. Система без доработки стоит 200000 руб., с доработкой и новыми возможностями ее ценность возрастает до 300000 руб. Естественно доработка системы стоит 50000 руб., но при этом вероятно внесение дополнительных ошибок в систему. Устранение этих ошибок может стоить 25000 руб. Известно также, что вероятность внесения ошибок доработки составляет 10%. Дерево решений для такой ситуации показано на рисунке 32: прямоугольник есть возможное решение, а кружок есть вероятностное событие риска. Рис. 32. Пример количественного анализа рисков методом «дерево принятия решений» Итак, ожидаемое значение для вероятностного события составляет 247500 руб. и получено сложением ожидаемых значений вариантов – 225000 руб. и 22500 руб. Поэтому в качестве решения выбираем наибольшее значение (247500 >200000), впишем его в прямоугольник. Контрольные вопросы 1. Дайте определение проектному риску. 2. Что такое событие риска? �Содержание 3. Что такое величина риска? 4. Как называют сумму денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня? 5. Какова особенность управленческого резерва? 6. Опишите методологию MSF относительно управления рисками. 7. Что такое матрица вероятности и последствий? Для чего она необходима? 8. Перечислите и охарактеризуйте методы идентификации рисков. 9. Приведите сравнительную характеристику методов идентификации рисков. �Содержание УПРАВЛЕНИЯ КАЧЕСТВОМ ПРОЕКТА Планирование качества нужно начинать на ранних стадиях планирования проекта, поскольку важно в самом начале определить требования к качеству работ и учесть их при разработке плана. На стадии планирования формируется и документируется система мер по обеспечению качества проекта. Цель планирования качества – сделать процессы управления проектами предсказуемыми [5]. Планирование качества проекта начинается с определения объектов, качество которых необходимо обеспечивать. Далее представлено описание процессов, влияющих на обеспечение качества проекта, воздействие которых следует учитывать при разработке плана управления качеством проекта. Планирование управления качеством Планирование управления качеством базируется на стандартах и призвано стать руководством, с помощью которого будет оцениваться качество выполняемого проекта. Данный процесс гарантирует, что заказчик получит проект, отвечающий его требованиям. Планирование управления качеством должно рассматриваться в совокупности с процессом управления возможностями, поскольку планирование качества является частью этого процесса. Если не составлять план управления проектом, сложно будет отследить качество выполняемых задач по проекту и величину отклонений результатов от требований заказчика. Если же планировать управление качеством проекта, то полученные итоги будут соответствовать требованиям заказчика. Данный процесс является критически важным. Владельцами процесса являются менеджер по встречам с заказчиками и менеджер проекта. Кроме того, данный процесс предлагается рассматривать, не разбивая на подпроцессы. Анализ факторов внешней и внутренней среды предприятия Выявление условий, которые могут повлиять на ход выполнения проекта, учет политики в области качества, принятой на предприятии, процедур, предписаний и накопленных знаний из предыдущих проектов. В случае невыполнения этого процесса могут возникнуть противоречия с законодательством или с политикой в области качества, существующей на предприятии. А в случае выполнения данного анализа произойдет выполнение проекта в соответствии с условиями и получение желаемых результатов. Анализ факторов внешней и внутренней среды предприятия является важным процессом обеспечения качества проекта. Владельцем процесса выступает руководитель проекта. Составление плана управления качеством Составление документа, на основании которого будет оцениваться качество выполнения проекта и полученных результатов. Данный документ является критически важным. Составление такого плана позволит выполнить проект в соответствии с условиями и получить желаемые результаты. Владельцем процесса также выступает руководитель проекта. Обеспечение качества Принятие плановых систематических мер (внешних и внутренних), которые обеспечивают выполнение всех предусмотренных процессов, необходимых для удовлетворения требованиям по качеству. Невыполнение данного процесса приведет к получению результатов, не соответствующих требованиям заказчика. Владельцем процесса является руководитель проекта или команда проекта. Исполнение плана проекта �Содержание Проведение мер, обеспечивающих выполнение плана управления качеством. Данный процесс является важным и отвечает за него руководитель проекта или команда проекта. В случае его невыполнения можно получить отклонение результатов проекта от ожиданий заказчика. Управление временем, содержанием и стоимостью Согласование мер по обеспечению выполнения плана управления качеством, учета стоимости и достаточного количества ресурсов для их проведения. Этот процесс является критически важным и в случае его невыполнения произойдет неоправданное увеличение стоимости проекта и сроков его выполнения. Владельцем процесса является руководитель проекта. Контроль качества Мониторинг результатов проекта для установления соответствию стандартам качества. Определение и устранение причин, вызывающих отклонения. Последствием невыполнения данного процесса будет отклонение от ожидаемых результатов, причину которого невозможно установить и исправить. Контроль качества является важным процессом и отвечает за него команда проекта или руководитель проекта. После определения объектов, качество которых необходимо обеспечивать, составляется план обеспечения качества. Данный документ описывает, как команда управления проектом будет осуществлять политику исполняющей организации в области качества. В зависимости от потребностей проекта этот план может быть очень подробным или обобщенным. План содержит в себе список работ, которые необходимо выполнить в сфере управления качеством проекта, а также время (график) выполнения работ. Мероприятия по обеспечению качества должны быть разработаны в самом начале проекта и должны проводиться на основе независимых экспертных оценок. План позволяет выделить именно те работы и время их выполнения, которые необходимы для качественного ведения проекта. Для разработки регламента по управлению качеством на проектах внедрения информационных систем необходимо определить список процедур регламента. Одной из главных составляющих управления проектом является предотвращение потери ценности продукции или услуг за счет снижения их качества. Соответственно, компании, предоставляющие услуги по внедрению информационных систем, накапливают знания о возникающих проблемах и потерях на проектах внедрения и в дальнейшем пытаются предотвратить данные потери. Причины появления потерь качества весьма разнообразны: нарушения технологии, несоответствующее качество ресурсов, человеческий фактор, несовершенство системы управления. Существенным является то обстоятельство, что все эти потери качества появляются при выполнении отдельных процессов и операций. В связи с этим современный менеджмент качества пришел к пониманию, что управлять нужно не качеством продукции или услуг, а качеством исполнения процессов. В частности, это обстоятельство нашло свое отражение в международных стандартах ISO 9000. Обеспечение качества – процесс выполнения плановых систематических операций по качеству, которые обеспечивают выполнение всех предусмотренных процессов, необходимых для того, чтобы проект соответствовал установленным требованиям по качеству. Функцию обеспечения качества может выполнять команда проекта, руководство исполняющей организации, заказчик или спонсор, другие участники проекта. Для контроля качества проекта проводятся аудиторские проверки, целью которых является выяснение соответствия качества проекта стандартам, установленным в плане обеспечения качества. Процесс обеспечения качества включает методы непрерывного улучшения качества будущих проектов. �Содержание Знания и опыт по обеспечению качества, накопленные в текущем проекте, должны использоваться при составлении планов обеспечения качества последующих проектов. Для обеспечения процесса оценки качества проекта на стадии планирования разрабатываются контрольные списки качества – таблицы с инструкциями для проверяющего лица (см. таблицу 36). Пункты контрольного списка должны быть достаточно значимыми, поскольку, если контрольный список будет перегружен, его не будут использовать. Контрольные списки качества – это метрики качества, которые определены для каждого этапа проекта на основании ожиданий заказчика, этим метрикам присвоен свой статус: критический, серьезный, важный. Включение в контрольные списки качества неважных метрик нежелателен, так как иначе данный список не будет использоваться. Преимуществом его применения является простота, даже на малых проектах для данного инструмента не требуется больших затрат ресурсов и времени, при этом с помощью контрольного списка качества можно на этапе выполнения работ отследить, что не было выполнено из требований заказчика. Данные о результатах контроля передаются исполняющей организации для использования в процессе обеспечения качества, повторной оценки и анализа стандартов качества на последующих фазах ЖЦ ИС. Таблица 36 Пример контрольных списков проверки качества Этап прое кта Ожидае мый ре зультат Тип Регулирование настроек Процент настроек, соответствующих описанию в документации (допустимая погрешность 3%) Критичный Определение требований к среде Список требований Критичный Настройка инфраструктуры Список настроек Критичный Разработка функциональных характеристик Количество возникших ошибок при работе. Процент ошибок в ходе работы Критичный Определение параметров разработки и плана тестирования Список параметров разработки. План тестирования. Процент исходов, не учтенных в плане тестирования Критичный Анализ проекта Наличие протоколов по анализу результатов каждой фазы проекта Серьезный Управление изменениями Документирование всех запросов на изменение в соответствии с принятой формой и их сохранение в единой базе Критичный Да Не т Для выполнения операций по обеспечению (оценке) качества используют аудит. Аудит качества – независимая экспертная оценка, которая определяет, насколько операции проекта соответствуют установленным в рамках проекта или организации правилам, процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически не оправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты �Содержание проводятся по запросам заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом: ● анализ исправления замечаний предыдущей проверки; ● проведение проверки проекта в соответствии с контрольными списками; ● оформление отчета о контроле качества; ● информирование команды проекта о появлении новых отчетных документов. Тестовые задания Практическая работа № 11 по теме «Управление качеством проекта» �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Цель планирования качества – сделать процессы управления… a) быстрыми; b) предсказуемыми; c) выполнимыми; d) объективными. 2. Планирование качества проекта начинается с… качество которого необходимо обеспечивать. a) подбора персонала; b) обозначения дат; c) расчета трат; d) определения объектов. 3. Выявление условий, способных повлиять на ход выполнения проекта, учет политики в области качества, принятой на предприятии, процедур, предписаний и накопленных знаний из предыдущих проектов представляет собой анализ… a) факторов внешней и внутренней среды предприятия; b) методов внешней и внутренней среды предприятия; c) участников внешней и внутренней среды предприятия; d) объектов внешней и внутренней среды предприятия. 4. Составление документа, на основании которого будет оцениваться качество выполнения проекта и полученных результатов, представляет собой… a) составление плана управления качеством; b) реализация плана управления качеством; c) структуризация плана управления качеством; d) обеспечение плана управления качеством. 5. Принятие плановых систематических мер (внешних и внутренних), которые обеспечивают выполнение всех предусмотренных процессов, необходимых для удовлетворения требованиям по качеству, означает… a) реализацию качества; b) обеспечение качества; c) структуризацию качества; d) анализ качества. 6. Управление временем, содержанием и стоимостью представляет собой… a) согласование мер по обеспечению выполнения плана управления качеством, учета стоимости и достаточного количества ресурсов для их проведения; b) принятие плановых систематических мер (внешних и внутренних), которые обеспечивают выполнение всех предусмотренных процессов, необходимых для удовлетворения требованиям по качеству; c) составление документа, на основании которого будет оцениваться качество выполнения проекта и полученных результатов; d) выявление условий, которые могут повлиять на ход выполнения проекта, учет политики в области качества, принятой на предприятии, процедур, предписаний и накопленных знаний из предыдущих проектов. �Содержание 7. Не является причинами появления потерь качества… a) нарушение технологии; b) высокое качество ресурсов; c) человеческий фактор; d) совершенство системы управления. 8. Процесс выполнения плановых систематических операций по качеству, обеспечивающих выполнение всех предусмотренных приемов, необходимых для формирования соответствия установленным требованиям по качеству, называется… качества a) обеспечением; b) технологией; c) реализацией; d) разработкой. 9. Независимая экспертная оценка, определяющая, насколько операции проекта соответствуют установленным в рамках проекта или организации правилам, процессам и процедурам, называется… качества a) обеспечением; b) аудитом; c) реализацией; d) разработкой. 10. Схема проведения внутреннего аудита качества проекта включает в себя... a) анализ замечаний; b) проведение проверки проекта в соответствии с контрольными списками; c) оформление отчета о реализации качества; d) информирование команды проекта о появлении новых отчетных документов. �Содержание ПРАКТИЧЕСКАЯ РАБОТА № 11 ПО ТЕМЕ «УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА» Разработайте список процедур управления качеством проекта, необходимые для управления проектом, описанном в проблемной ситуации. Создайте диаграмму Парето. Пример построения диаграммы Парето для «Дипломного проекта»: 1) раскрываем факторы, 2) определяем их значимость, 3) упорядочиваем факторы в порядке возрастания значимости (см. таблицу 37), 4) создаем диаграмму Парето (см. рис. 33). Таблица 37 Перечень факторов для «Дипломного проекта» № 1 2 3 4 5 6 7 8 9 10 Фактор Пропуск этапов подготовки д/п Качество содержания собранного материала Подготовленность студента по теме д/п Эффективность взаимодействия с руководителем Наличие/отсутствие технической базы Структурный подход к построению д/п Наличие темы д/п Поддержка семьи Поддержка друзей Квалификация рецензента по теме д/п Значимость фактора 35 30 10 7 5 4 4 3 1 1 Итого: Нарастающий итог 35 65 75 82 87 91 95 98 99 100 100 Рис. 33. Диаграмма Парето для «Дипломного проекта» Проце нт влияния фактора, % 35 30 10 7 5 4 4 3 1 1 100 �Содержание Простой анализ показывает, что два фактора 1 и 2, составляющие 20% от общего числа факторов, оказывают 65% влияния на успешное завершение проекта. Контрольные вопросы 1. В чем заключается цель планирования качества проекта? 2. С чего начинается планирование качества проекта? 3. Зачем нужен анализ факторов внешней и внутренней среды предприятия? 4. Для каких целей составляют план управления качеством? 5. Что не является причинами появления потерь качества? 6. Что такое обеспечение качества? 7. Что такое аудит качества? 8. Какова схема проведения внутреннего аудита качества проекта? �Содержание УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА Для того чтобы проектные коммуникации наиболее эффективно решали задачи, стоящие перед проектом, еще на фазе планирования проекта необходимо четко сформулировать стратегию коммуникаций [5]. Наиболее важным элементом планирования коммуникаций является идентификация получателей информации, далее следует озаботиться планированием содержания информационных сообщений, которое может значительно меняться в зависимости от адресата. Затем происходит выбор канала коммуникации и определение отправителя. За фактическим выполнением коммуникаций необходимо всегда осуществлять обратную связь, позволяющую корректировать наши действия в дальнейшем. Относительно содержания любое сообщение на проекте должно включать в себя информацию следующего рода. 1. Удовлетворение потребности участников проекта понимать. Участники проекта должны иметь возможность получить объективную, полную и непротиворечивую информацию о целях и задачах проекта и иметь возможность сформировать собственное рациональное мнение о проекте. 2. Удовлетворение потребности участников проекта чувствовать. Заинтересованные стороны должны четко понимать, какие процедуры предусмотрены для организации их участия в принятии решений по проекту, есть ли каналы обратной связи, как они могут быть вовлечены в реализацию наиболее значимой для них части проекта. 3. Удовлетворение потребности участников проекта действовать. Сотрудники должны быть проинформированы, какие средства, методы, инструменты предусмотрены для их скорейшей адаптации в условиях новой организационно-функциональной среды бизнеса организации. Рассмотрим пример стратегии коммуникации. Стратегия должна содержать: 1. Цели и задачи информирования участников проекта. Например, в рамках реализуемой стратегии информирование не сводится исключительно к обеспечению сотрудников необходимой информацией о проекте. Цели информирования направлены на повышение лояльности персонала компании к проекту, что служит достижению конечной цели управления изменениями – обеспечению безболезненного перехода к новому бизнес-стандарту. Перед процессом информирования стоят три основных цели: ● обеспечение целевой аудитории информацией о целях, задачах и результатах проекта: ○ проинформировать сотрудников компании о проекте, его важности и выгодах; ○ обеспечить доступность, корректность и своевременность получения информации о проекте; ○ поддерживать интерес к проекту на всех фазах его реализации; ● обеспечение целевой аудитории информацией об осведомленности проектной команды о предстоящих изменениях в функциональной среде и организационной структуре компании, и о проблемах, связанных с ними: ○ обеспечить своевременность получения информации о предстоящих изменениях целевыми аудиториями; ○ сформировать образ проекта как открытой, прозрачной и доступной инициативы; �Содержание ○ реализовать сбор сведений об ожиданиях/опасениях бизнес-экспертов изменениях; о предстоящих ● обеспечение целевой аудитории информацией о планах по переходу к новым процессам, обязанностям, методам работы: ○ сформировать образ проекта как инициативы, готовой поддерживать обратную связь, отвечать на вопросы и помогать в решении предстоящих проблем; ○ обеспечить заблаговременное информирование конечных пользователей о предстоящих мероприятиях, связанных с управлением изменениями; 2. Роли и обязанности. Указание конкретных лиц, ответственных за проектные коммуникации, и их места в организационной структуре проекта. 3. Целевую аудиторию. Исходя из описанных выше целей информирования, целесообразно выделение трех целевых групп, на которые будут направлены действия, описанные в плане коммуникаций. Различия выделенных групп, характеризуемые степенью ответственности/участия в проекте, иерархией позиции внутри компании, а, следовательно, лояльностью к результатам проекта, обуславливают использованием нескольких каналов и мер информирования для каждой из них. 1) Бизнес-эксперты. Как правило, являются руководителями или ведущими специалистами линейных подразделений, обладают всей полнотой информации о существующих бизнес-процессах в конкретной области, принимают участие в согласовании перечня изменений процессов. 2) Ответственные за преобразования (1-го и 2-го уровня). Первый уровень представлен сотрудниками из числа руководителей дирекций и управлений, которые выступают главной точкой контакта между группой управления изменениями и сетью ответственных за внедрение. Уровень их информированности и активного участия в процессе управления изменениями критичен для реализации проекта. Второй уровень представлен сотрудниками уровня руководителей отделов, которые несут ответственность за реализацию мер по управлению изменениями на локальном уровне, так как являются связующим звеном между сетью ответственных за преобразования и конечными пользователями. Бизнес-эксперты могут входить в число ответственных за преобразования. 3) Конечные пользователи. Сотрудники компании, которые в последующем будут иметь дело с новыми процессами и системой в своей каждодневной работе. Цели информирования в первую очередь направлены на повышение уровня принятия системы именно этой целевой аудиторией. 4. Каналы коммуникаций. К коммуникационным каналам могут относиться как стандартные средства общения (телефон, электронная почта), так и более специфичные (совещания в группах, выездные семинары, сессии вопросов и ответов); кроме того, не следует упускать из виду и каналы коммуникаций, действующие по принципу pull, – это интернет-порталы, базы знаний и т.п. (см. рисунок 34). �Содержание Рис. 34. Каналы коммуникаций и их воздействие 5. Организацию обратной связи по проекту. Необходимость реализации обратной петли управления, в том числе и в коммуникациях, может быть обоснована следующим образом. Эффективное информирование возможно только при двунаправленности проектных коммуникаций – наличии прямого и обратного канала связи. Последний из них обеспечивает контроль первого. Мониторинг эффективности каналов информирования предполагает следующие аспекты: ○ качество информации о проекте, поступающей по установленным официальным каналам информирования; ○ достаточная интенсивность поступающей информации; ○ полнота информации, информирования. поступающей по установленным официальным каналам Реализуя план коммуникаций, необходимо руководствоваться рядом принципов для наиболее оптимального расходования ресурсов и получения запланированного результата – реакции от целевой аудитории. Рассмотрим принципы построения содержания информационного сообщения, которые рекомендуется выполнять при реализации плана коммуникаций. 1. Проявлять уважение к получателю. Следует внимательно относиться к особенностям различных аудиторий: каждый участник проекта поразному заинтересован в итоговом результате проекта и имеет собственное мнение на счет проекта. �Содержание Для каждой заинтересованной стороны содержание информационного сообщения должно соответствовать правилу CLEAR (данную модель рекомендуется использовать в качестве проверочного списка при разработке содержания коммуникации): ● C (Connected) – связанный: должно быть связано с деятельностью участника проекта как сотрудника организации или как заинтересованного лица проекта; ● L (List next steps) – перечень необходимых действий: что необходимо выполнить в ближайшем будущем; ● E (Expectations) – ожидание: ясно сформулированный образ успеха и неудачи проекта для понимания того, к каким результатам стоит стремиться, а какого исхода избегать; ● A (Ability?) – возможности: перечень способов, методов и средств добиться поставленной цели; ● R (Return) – отдача: что конкретно получит соответствующий участник от приложения своих усилий к обозначенной задаче. 2. Исторический контекст. Необходимо ознакомиться с предшествующей профессиональной историей соответствующей заинтересованной стороны – этот аспект оказывает немалое влияние на содержание сообщения и способ его реализации. 3. Простые и лаконичные сообщения. Рекомендуется избегать длинных и громоздких информационных сообщений, а преимущественно использовать короткие и емкие, содержащие по одной мысли. В то же время, при раздельной отправке частей (потенциально) длинного сообщения крайне важно убедиться, что взаимосвязь между частями представлена в достаточной мере четко. 4. Корпоративная лексика и терминология. Предпочтительно при коммуникациях использовать принятые в компании термины и жаргонизмы, это создаст образ «своего человека» – шансы на успех коммуникации значительно повышаются при применении локальных речевых единиц. 5. Аккуратное форматирование и верстка текста. Аккуратно отформатированное сообщение имеет больше шансов быть прочитанным, хотя бы из-за эстетических соображений. Еще один важный момент, который стоит принимать в расчет, – это различная склонность к восприятию информации, характерная для разных людей. В этом отношении типично выделяют визуалов, кинестетиков и аудиалов. Контрольные вопросы 1. Кто отвечает за коммуникации команды проекта? 2. При планировании коммуникаций менеджер проекта должен учитывать? 3. Что или кто способствует повышению уровня коммуникаций? �Содержание ТЕСТОВЫЕ ЗАДАНИЯ 1. Математический инструмент системного подхода к решению сложных проблемам принятия решений, который не предписывает лицу, принимающему решение, какого-либо «правильного» решения, а позволяет ему в интерактивном режиме найти вариант, наилучшим образом согласующийся с его пониманием сути проблемы и требованиями к ее решению, представляет собой… a) эффективность ИТ-проекта; b) критерий эффективности ИТ-проекта; c) совокупную стоимость владения (Total Cosl of Ownership – ТСО); d) метод анализа иерархий (МАИ). 2. Затраты, связанные с приобретением, внедрением и использованием ИС, представляют собой… a) эффективность ИТ-проекта; b) критерий эффективности ИТ-проекта; c) совокупную стоимость владения (Total Cosl of Ownership – ТСО); d) метод анализа иерархий (МАИ). 3. Степень соответствия ИТ-проекта своему назначению, представляет собой… a) эффективность ИТ-проекта; b) критерий эффективности ИТ-проекта; c) совокупную стоимость владения (Total Cosl of Ownership – ТСО); d) метод анализа иерархий (МАИ). 4. По формуле IRR=r при NPV=f(r)=0 рассчитывают… a) коэффициент дисконтирования; b) чистый приведенный доход; c) срок окупаемости (Payback Period, РР); d) норму рентабельности инвестиций. 5. По формуле , где NCFi– чистый денежный поток для i-го периода, Inv – начальные инвестиции, r – ставка дисконтирования (стоимость капитала, привлеченного для инвестиционного проекта) рассчитывают… a) коэффициент дисконтирования; b) чистый приведенный доход; c) срок окупаемости (Payback Period, РР); d) норму рентабельности инвестиций. 6. По формуле , где PV – приведенная стоимость, P – не приведенная стоимость, r – ставка дисконтирования, t – время, когда ожидается сумма, рассчитывают… a) коэффициент дисконтирования; b) чистый приведенный доход; c) срок окупаемости (Payback Period, РР); d) норму рентабельности инвестиций. �Содержание 7. По формулам Tok=n и , где Tok – срок окупаемости инвестиций, n – число периодов, CFt – приток денежных средств в период t, I0– величина исходных инвестиций в нулевой период, рассчитывают… a) коэффициент дисконтирования; b) чистый приведенный доход; c) срок окупаемости (Payback Period, РР); d) норму рентабельности инвестиций. 8. Основными группами методов, позволяющих определить эффект от внедрения любого ИТ-проекта являются… a) финансовые, качественные, вероятностные; b) финансовые, качественные, статистические; c) математические, качественные, статистические; d) финансовые, экономические, политические. 9. Согласно второй модели ТСО, основой для которой является концепция, предложенная Gartner Group, учитываются… IТ-затраты. a) прямые и косвенные; b) фиксированные и текущие; c) бюджетные и внебюджетные; d) полные и неполные. 10. Согласно первой модели ТСО, разработанной компанией Microsoft совместно с Interpose, ИТзатраты в ней разбиваются на следующие категории… a) прямые и косвенные; b) фиксированные и текущие; c) бюджетные и внебюджетные; d) полные и неполные. 11. Среди перечисленных в списке методов укажите финансовые методы оценки экономической эффективности ИТ-проекта. a) чистый приведенный доход/стоимость (Net Present Value, NPV); b) экономическая добавленная стоимость (Economic Value Added, EVA); c) совокупная стоимость владения (Total Cost of Ownership, TCO); d) совокупный экономический эффект (Total Economic Impact. TEI); e) быстрое экономическое обоснование (Rapid Economic Justification, REJ); f) система сбалансированных показателей (Balanced Scorecard); g) метод информационной экономики (Information Economics, IE); h) управление портфелем активов (Portfolio Management); i) метод IT Scorecard; j) метод прикладной информационной экономики (Applied Information Economics); k) метод справедливой цены опциона (Real Option Value, ROV). �Содержание СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 1. Синяк, Н.Г. Управление проектами : пособие / Н.Г. Синяк, В.А. Акулич. – Минск : БГТУ, 2011. – 152 с. 2. Войку, И.П. Управление проектами: Конспект лекций / И.П. Войку. – Псков : Псковский государственный университет, 2012. – 204 с. 3. Куправа, Т.А. Управление проектами. Вводный курс : учебное пособие / Т.А. Куправа. – Москва : Изд-во РУДН, 2008. – 121 с. 4. Мазур, И.И. Управление проектами : учебное пособие / И.И. Мазур, В.Д. Шапиро, Н.Г. Ольдерогге ; под общ. ред. И.И. Мазура. – 2-е изд. – Москва : Омега-Л, 2004. – 664 с. 5. Грекул, В.И. Методические основы управления ИТ-проектами : учебник / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. – Москва : БИНОМ. Лаборатория знаний, Интернет-Университет Информационных Технологий, 2010. – 391 с. 6. Шершенюк, О.М. Проектный анализ. Конспект лекций / О.М. Шершенюк. – Харьков, 2009. – 51 с. �Содержание ИНФОРМАЦИЯ ОБ АВТОРАХ Кирколуп Евгений Романович Скурыдин Юрий Геннадьевич Скурыдина Елена Михайловна �Содержание КИРКОЛУП ЕВГЕНИЙ РОМАНОВИЧ Кандидат технических наук, доцент. e-mail: kirkolup@mail.ru �Содержание СКУРЫДИН ЮРИЙ ГЕННАДЬЕВИЧ Кандидат технических наук, доцент. e-mail: skur@rambler.ru �Содержание СКУРЫДИНА ЕЛЕНА МИХАЙЛОВНА Кандидат технических наук, доцент. e-mail: skudem@rambler.ru � Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Кирколуп, Евгений Романович Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Основы управления ИТ-проектами Subject The topic of the resource 1. Экономика. 2. Экономика организации (предприятия, фирмы) в целом. 3. ИТ-проекты. 4. управление проектами. 5. управление (экономика). 6. тестовые задания Description An account of the resource Основы управления ИТ-проектами [Электронный ресурс] : учебное пособие / Алтайский государственный педагогический университет ; [сост.: Е. Р. Кирколуп, Ю. Г. Скурыдин, Е. М. Скурыдина]. — Барнаул : АлтГПУ, 2017. — 176 с. В пособии рассмотрены основные понятия и подходы современной методологии управления ИТ-проектами. Пособие содержит практическое введение в программу планирования и управления проектами OpenProj. Пособие предназначено для студентов, обучающихся по специальности «Прикладная информатика», для аудиторных и самостоятельных занятий по дисциплинам «Проектный практикум» и «Проектирование ИТ-инфраструктуры предприятия». Creator An entity primarily responsible for making the resource <em>Составители:</em><br />Кирколуп, Евгений Романович<br /><br /> Скурыдин, Юрий Геннадьевич Скурыдина, Елена Михайловна Source A related resource from which the described resource is derived Алтайский государственный педагогический университет, 2017 Publisher An entity responsible for making the resource available Алтайский государственный педагогический университет Date A point or period of time associated with an event in the lifecycle of the resource 12.04.2017 Rights Information about rights held in and over the resource ©Алтайский государственный педагогический университет, 2017 Format The file format, physical medium, or dimensions of the resource pdf, exe Language A language of the resource русский Type The nature or genre of the resource Учебное пособие Identifier An unambiguous reference to the resource within a given context <a href="http://library.altspu.ru/dc/exe/kirkolup.exe">http://library.altspu.ru/dc/exe/kirkolup.exe</a><br /><a href="http://library.altspu.ru/dc/pdf/kirkolup.pdf" target="_blank">http://library.altspu.ru/dc/pdf/kirkolup.pdf</a> ИТ-проекты тестовые задания. управление (экономика) управление проектами экономика Экономика организации (предприятия) в целом