Методические основы управления ИТ-проектами

Инициация проекта

Разбить на страницы
Показывать лекцию целиком

Адаптация модели жизненного цикла проекта

В данном учебном пособии по управлению ИТ-проектами в качестве концептуальной основы используется модель жизненного цикла информационных систем (ЖЦ ИС), описанная в стандарте ГОСТ Р ИСО/МЭК 15288. В соответствии с данным стандартом запуск каждого нового проекта подразумевает создание (или адаптацию уже имеющейся) модели ЖЦ, состоящей из стадий.

Процесс создания (или адаптации уже имеющейся) модели ЖЦ начинается с определения целей и результатов каждой из стадий, образующих структуру работ для детализированного моделирования процессов реализации ИТ. [10]

Исходя из допущений базового стандарта, а также типовых этапов ЖЦ ИТ и принятой последовательности их реализации, авторами предлагается следующая модель ЖЦ ИТ, определяющая последовательность изложения материала в книге.

  • Планирование проекта
  • Проектирование
  • Разработка и внедрение
  • Эксплуатация и поддержка
  • Утилизация и обновление
    •

    В таблице ниже представлены цели каждой из выделенных стадий ЖЦ (см. табл. 1.1).

    Приведенные этапы есть стадии жизненного цикла информационной системы и не тождественны жизненному циклу проекта. Жизненный цикл продукта отражает, что нужно сделать для создания, эксплуатации, поддержки и утилизации данного продукта, а жизненный цикл проекта - как нужно организовывать и управлять работой. Фаза ЖЦ продукта может включать в себя все этапы ЖЦ проекта (см. рис. 1.1 (а, б)), и, в соответствии со стандартом ГОСТ Р ИСО/МЭК 15288 [10], предусматривает наличие этапов планирования, оценки и контроля, а также процесса принятия решения - шлюза (см. рис. 1.1. (а)), через который происходит переход на следующий этап ЖЦ ИС и который является точкой мониторинга качества и точкой принятия решения о целесообразности продолжения проекта [10]. Необходимо отметить, что планирование, оценка и контроль характерны для любого цикла управления (например, цикл Деминга). Таким образом, использование их, в том числе на этапе "Эксплуатация и поддержка", носящем выраженный операционный (не проектный) характер, вполне обосновано.

    Цели этапов жизненного цикла информационной системы
    Этап (ГОСТ Р ИСО/ МЭК 15288) Этап (адаптированный) Цель этапа
    Замысел Планирование проекта Оценка новых возможностей в деловой сфере, разработка предварительных системных требований и проверка их осуществимости. Концептуальное планирование всего ЖЦ ИС
    Разработка Проектирование Создание проекта системы, которая удовлетворяет требованиям приобретающей стороны и может быть реализована, испытана, оценена, применена по назначению, поддержана при применении, в последующем списана и/или обновлена
    Производство Разработка и внедрение Разработка (настройка) системы в соответствии с требованиями приобретающей стороны, тестирование системы, реализация соответствующих организационно-технических мероприятий и развертывание поддерживающих систем, направленных на обеспечение корректной эксплуатации внедренного продукта
    Применение Поддержка применения Эксплуатация и поддержка Использование внедренного продукта в заданных условиях функционирования и обеспечение продолжительной результативности. Осуществление в процессе эксплуатации материально-технического снабжения, технического обслуживания и текущего ремонта, которые обеспечивают непрерывное функционирование рассматриваемой системы и устойчивое предоставление услуг, поддерживающих ее применение
    Изъятие и списание Утилизация и обновление Обеспечение удаления рассматриваемой системы и связанных с нею обслуживающих и поддерживающих организационно-технологических подсистем. Поддержка планирования перехода на новую версию текущей или на абсолютно новую систему

    Рассмотрение каждой стадии ЖЦ ИТ в качестве отдельного проекта позволяет (по сути, делает единственно возможным) применять метод планирования по принципу набегающей волны, который значительно понижает рискованность проекта и повышает шансы на успех [9].

    (рис 1.1) (а,б) Примеры соотношения жизненного цикла информационной системы и жизненного цикла проекта

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

    С целью структурирования процессы управления проектом принято делить на области знаний. Ниже перечислены области знаний, составляющие процессы проектного управления. Предложенный перечень сформирован на основе рекомендаций лучших мировых практик и содержится в стандарте управления проектами [1,10, 23].

  • Управление интеграцией
  • Управление содержанием
  • Управление сроками
  • Управление стоимостью
  • Управление качеством
  • Управление рисками
  • Управление человеческими ресурсами
  • Управление коммуникациями
  • Управление конфигурацией
    •

    Описание содержания каждой из перечисленных выше областей знаний и соответствующих им процессов приводится в табл. 1.2.

    Области знаний проектного управления
    Область знаний Описание Процессы
    Управление интеграцией Управление интеграцией включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координирования различных процессов и действий по управлению проектом в рамках групп процессов управления проектом. Таким образом, цель данного процесса состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Эффективное взаимодействие на стадии планирования заключается в формировании базовой линии проектаУтвержденная для проекта совокупность планов по областям знаний с включенными одобренными изменениями. Служит для сравнения с фактическим ходом проекта для оценки степени отклонения факта от плана. (project baseline), на стадии оценки - в сравнении с базовой линией и корректировке в соответствии с ней на стадии контроля
  • Разработка ТЭО проекта.
  • Разработка устава проекта.
  • Разработка плана управления проектом.
  • Руководство и управление исполнением проекта.
  • Осуществление интегрированного управления изменениями.
  • Оценка альтернатив развития проекта.
  • Планирование закрытия проекта и перехода в стадию эксплуатации.
  • Завершение проекта.
    •
    Управление содержанием Управление содержанием включает в себя процессы и действия, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект [1,23]
  • Формирование требований проекта.
  • Формирование ИСР.
  • Определение содержания проекта.
  • Определение результатов всех стадий жц ис.
  • Оценка реализуемости требований проекта.
  • Подтверждение содержания проекта.
  • Определение уточненных системных требований.
  • Мониторинг содержания и объема проекта.
  • Оценка готовности пользователей к работе в системе.
  • Планирование обучения конечных пользователей
    •
    Управление сроками Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта [23]
  • Формирование списка работ проекта.
  • Определение последовательности работ проекта.
  • Оценка трудоемкости и продолжительности работ.
  • Разработка базового расписания проекта.
  • Контроль и управление расписанием проекта
    •
    Управление стоимостью Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета [23]
  • Оценка стоимости проекта.
  • Разработка сметы проекта.
  • Разработка базового плана по стоимости.
  • Управление стоимостью проекта
    •
    Управление качеством Процессы управления качеством проекта объединяют все осуществляющиеся в исполняющей организации операции, определяющие политику, цели и распределение ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, для которых он был предпринят. Управление качеством осуществляется посредством системы управления, предусматривающей определенные правила, процедуры и процессы по планированию качества, обеспечению качества и контролю качества, а также операции по их совершенствованию
  • Формирование программы качества проекта.
  • Формирование базовой линии требований проекта.
  • Управление требованиями проекта.
  • Осуществление обеспечения качества.
  • Тестирование.
  • Приемка результатов
    •
    Управление риском Процесс управления рисками тесно связан с общим жизненным циклом проекта. На ранних этапах преобладают риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. На стадии реализации доминируют технологические риски, далее возрастает роль рисков, связанных с поддержкой и сопровождением системы. На протяжении всего жизненного цикла проекта возникают новые риски, что требует проведения дополнительных операций анализа и планирования.Согласно ГОСТ Р ИСО/ МЭК 15288-2005 [10] цель процесса управления рисками заключается в снижении последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков или ухудшения технических характеристик. В ходе данного процесса проводятся определение, оценка, обработка и мониторинг рисков, возникающих в течение полного жизненного цикла, а также вырабатывается реакция на каждый риск в терминах реализации соответствующих мер противодействия риску или его принятия
  • Планирование управления рисками.
  • Идентификация рисков.
  • Качественный анализ рисков.
  • Количественный анализ рисков.
  • Планирование реагирования на риски.
  • Мониторинг и управление рисками
    •
    Управление человеческими ресурсами Управление человеческими ресурсами проекта - это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта [13,17])
  • Планирование человеческих ресурсов.
  • Набор команды проекта.
  • Оценка доступности.
  • Развитие и оценка команды проекта.
  • Организация инфраструктуры проекта
    •
    Управление коммуникациями Управление коммуникациями проекта - это процесс идентификации и эффективного обеспечения всех участников проекта информацией о проекте, а также создания единого образа проекта внутри организации
  • Идентификация участников проекта.
  • Формирование стратегии и плана коммуникаций.
  • Реализация плана коммуникаций и сбор обратной связи
    •
    Управление конфигурацией Управление конфигурацией - процесс управления аппаратными средствами, программным обеспечением, данными, а также документацией в ходе разработки, тестирования и использования информационных систем. Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны.Задачи управления конфигурацией проекта:
  • определение стратегии управления конфигурацией, включающей следующие вопросы:
  • - определение полномочий на запрет или разрешение доступа, реализацию и контроль изменений элементов конфигурации;
  • определение места и условий хранения элементов конфигурации, включая требования к окружающей среде, а в случае информации - требования к хранению носителей информации в соответствии с назначенными уровнями целостности, защищенности и безопасности;
  • определение критериев или событий, соответствующих началу контроля конфигурации и сопровождения базовых линий в процессе эволюции конфигураций;
  • определение стратегии аудита и ответственности за гарантии непрерывной целостности и защищенности информации, описывающей конфигурацию;
    •
  • идентификация элементов, которые необходимо контролировать в процессе управления конфигурацией;
  • поддержка информации о конфигурации на приемлемом уровне целостности и защищенности. Для этого рекомендуется:
  • поддерживать записи о конфигурации в течение всего жизненного цикла и архивировать их в соответствии с соглашениями, законодательством или передовым производственным опытом;
  • описывать конфигурацию в соответствии с производственным или технологическим стандартами там, где это возможно.
  • регистрировать обоснования для изменений базовой линии конфигурации и связанные с этим данные о соответствующих разрешениях;
  • гарантирование того, что изменения базовой линии конфигурации соответствующим образом идентифицируются, записываются, оцениваются, утверждаются, проводятся и верифицируются. Для этого рекомендуется:
  • регистрировать этапы конфигурации;
  • управлять выполнением записей, изменениями и утверждениями текущего статуса конфигурации и статуса всех предыдущих конфигураций для подтверждения корректности, своевременности, целостности и защищенности информации;
  • проводить аудит для проверки соответствия базовой линии УК требованиям к результатам проекта
    		•
  • Идентификация объектов управления конфигурацией.
  • Планирование инфраструктуры стадии разработки.
  • Установление базовой линии конфигурации проекта.
  • Оценка соответствия базовой линии конфигурации.
  • Контроль конфигурации выделенных элементов проекта.
  • Обеспечение целостности элементов конфигурации.
  • Реконфигурация инфраструктуры проекта
    •

    Каждый из этапов ЖЦ ИТ и ЖЦ проекта предусматривает совокупность задач, с полной матрицей которых можно ознакомиться в Приложении 1.

    В рамках конкретных проектов предложенные этапы ЖЦ ИТ, а также и отдельно взятые процессы ЖЦ ИТ могут быть индивидуально отобраны, идентифицированы и, при необходимости, модифицированы для достижения измененных целей и результатов соответствующих стадий.

    Сделанные изменения должны быть задокументированы. Общие требования к процедуре модификации таковы: любой новый процесс жизненного цикла определяется и документируется в терминах его назначения, целей и результатов. Ответственным за такого рода модификации является, как правило, руководитель соответствующего проекта. В то же время утверждение адаптированной, сокращенной или дополненной модели ЖЦ ИС обычно производит офис управления проектами или иная организационная единица, в круг обязанностей которой входит поддержание целостности и актуальности корпоративной методологии управления проектами [8].

    Приведенная процедура и шаблон документирования модификации ЖЦ ИТ являются одним из возможных вариантов оформления соответствующих действий над ЖЦ ИТ.

    Процедура адаптации модели ЖЦ ИС

    При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия.

  • Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают (но не ограничиваются) перечисленное ниже:
  • стабильность и разнообразие среды функционирования;
  • коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;
  • новизну, размеры и сложность;
  • дату начала и продолжительность применения;
  • вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения,
  • доступность;
  • вновь возникающие технологические возможности;
  • бюджетный профиль и доступные организационные ресурсы;
  • готовность предоставления услуг обеспечивающими системами.
    •
  • При наличии свойств, критичных по отношению к системе, руководитель проекта должен учесть структуры ЖЦ, которые рекомендованы или установлены в качестве обязательных стандартами, соответствующими области критичности.
  • Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта:
  • правообладатели системы;
  • заинтересованные стороны соглашения, заключенного организацией;
  • стороны, вносящие вклад в организационные функции.
  • Руководитель проекта определяет новую (модифицированную) модель жизненного цикла системы в терминах стадий, их назначения, целей и результатов, которые достигаются вследствие применения процессов жизненного цикла в пределах каждой стадии.
  • Проектный офис принимает решение об адаптации базовой модели.
  • Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной (под)системы) или общекорпоративный характер по решению проектного офиса, по результатам апробации предложенной РП модификации.
    • Шаблон адаптации модели жизненного цикла информационной системы
    Описание причины:
    Действия Базовый Модифицированный Характеристики модифицированного этапа/процесса
    Этап Процесс Этап Процесс Назначение Цель Результат
    _
    _
    Дата подачи заявки (руководитель проекта):
    Дата принятия решения (проектный офис):
    Дата начала применения:

    Разработка технико-экономического обоснования

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

  • приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;
  • определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта;
  • обеспечение заинтересованности руководителей бизнес-подразделений в проекте;
  • формирование основы для оценки соответствия результатов проекта и первоначальных планов.
    •

    Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время всего лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].

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

    В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается "на пересечении" соответствующих значений двух обозначенных факторов.

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

  • Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
  • Повышение эффективности операций:функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
  • Отказ от операций:информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
    •
    Матрица структурирования выгод ИТ-проекта (адаптировано из [7])
    ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС
    Создание новых возможностей Повышение эффективности операций Отказ от операций
    СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ Финансовые
    Количественные
    Измеримые
    Качественные

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

  • Качественные: выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.
  • Измеримые:выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
  • Количественные:аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
  • Финансовые:это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.
    •

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

    Формирование бизнес-цели проекта

    Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).

    Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.

    Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО, или бизнес-кейс, проекта.

    Разработка устава проекта

    Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.

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

  • стратегические и тактические цели организации-заказчика;
  • формулировка требований организации-заказчика;
  • ТЭО ;
  • контракт;
  • внутрикорпоративная методология управления проектами и соответствующие политики.
    •

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

    В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

    Требования к уставу проекта
    № Раздел Пояснения
    1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
    2. Бизнес-причина возникновения проекта Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
    3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта "
    4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
    5. Расписание основных контрольных событий На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18]
    6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта"
    7. Окружение проекта Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) [20]
    8. Допущения относительно организации и окружения, а также внешние допущения Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
  • o компетенции команды проекта достаточно для выполнения предпроектного обследования;
  • o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта.
    •  Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе
    9. Ограничения относительно организации и окружения, а также внешние ограничения Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11]. Пример ограничений проекта:
  • увеличение стоимости проекта не более чем на 10%;
  • не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.
    •  Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
    10. Объем денежных средств, выделенных на достижение бизнес-цели На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% [18]
    11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [8,18]. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проектАвторы рекомендуют включать в проект руководителей и двух спонсоров проекта - по одному от заказчика и исполнителя. . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
  • утверждать бизнес-цели проекта , включая расписания и бюджет, и вносимые в них изменения;
  • назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;
  • формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;
  • вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов;
  • принимать решения о внесении изменений в базовую линию проекта.
    •  Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18]. Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта [18]
    Шаблон листа управления документом
    Авторы
    Файл
    Дата создания
    Дата последнего редактирования
    Количество страниц
    Версия Дата изменения Краткое описание изменения Автор изменения Подпись
    01
    02
    Согласование документа
    Замечания
    № Дата поступления Наименование документа Автор замечания Подпись
    1.
    2.
    Обработка замечаний
    № Дата обработки Версия документа, учитывающая замечание Исполнитель Подпись
    1.
    2.
    (рис 1.2) Модель комплексного анализа участников и окружения проекта (Burnett, 1980). На рисунке ИКС - исследовательская команда спонсора

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

  • информация в уставе, а также сделанные в нем допущения соответствуют исходным данным, которые содержатся в стратегических и тактических целях организации-заказчика, задокументированных предварительных требованиях организации-заказчика, ТЭО, контракте и внутрикорпоративных политиках и методологиях;
  • все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями;
  • в самом документе отсутствуют противоречия;
  • список рассылки устава проекта включает все функциональные группы, сотрудники которых должны войти в проектную команду, а в идеале - и всех участников проекта внутри организации-заказчика.
    •

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

    Идентификация и анализ участников проекта

    Заинтересованная сторона (участник, или стейкхолдерОт английского stakeholder - "заинтересованная сторона". ) - это любое лицо, которое само оказывает влияние на проект или подвергается влиянию проекта и результатов его реализации [5].

    На начальной фазе ЖЦ ИС, фазе планирования, целевой группой всегда является руководство компании, на которое следует обращать особое внимание и наиболее тесно взаимодействовать с ним. Кроме того, на данной фазе руководство компании будет и единственной точкой опоры проекта в организации, поэтому нужно четко себе представлять, чем отличаются руководители среднего звена от прочих сотрудников [5].

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

    (рис 1.3) Пример карты участников проекта (адаптировано из [5])
  • Организация не является единым целым, но представляет собой совокупность отношений между различными заинтересованными сторонами. Построение карты заинтересованных сторон есть первый шаг на пути выявления взаимосвязей между ними.
  • Необходимо выявить всех участников проекта, и в этом аспекте построение красивых и однозначных схем является вторичным по отношению к значимости формирования исчерпывающего списка.
  • Карта заинтересованных сторон не является статической, по мере продвижения проекта она будет уточняться: изначально включенные участники могут быть исключены из рассмотрения, а на поздних этапах могут быть идентифицированы новые.
    •

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

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

    Анализ воздействия участников проекта (адаптировано из [5])

    Анализ воздействия производится в разрезе двух аспектов.

  • Степень организационного влияния участника проекта

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

  • Воздействие участников на реализуемый ИТ-проект
    •

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

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

    Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов [5].

  • Доверие

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

  • Согласие

    Получилось ли достичь согласия с этим конкретным участником (группой участников проекта)? Разделяют ли они точку зрения руководителя проекта?

    •

    Поскольку на фазе планирования проекта мы в большей степени говорим именно о руководителях высшего звена - о потенциальных спонсорах проекта, то и результаты данного анализа будут в большей степени применимы именно к этой категории сотрудников.

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

  • Союзники

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

  • Конкуренты

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

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

  • Партнеры

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

  • Противники
    •

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

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

  • ФИО и контактную информацию сотрудника;
  • сведения об организационной единице, в которой работает сотрудник;
  • определение функциональной роли сотрудника;
  • категорию получаемых сообщений и их историю.
    •

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

    Формирование требований проекта

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

    Организация и проведение результативного интервью

  • Подготовка

    Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована, с тем чтобы точно определить целевую аудиторию. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику.

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

  • "Большая картинка"
  • Место (под)процесса в сквозном процессе
  • Интерфейс с предшествующим процессом
  • Интерфейс с последующим процессом
    •
  • Описание процесса
  • Что? (типовой результат и его потребитель)
  • Как? (последовательность шагов и показатели эффективности)
  • Кто? (роли и присущая им квалификация)
  • Чем? (используемые средства, инструменты, расходуемые ресурсы)
  • Документы
  • Входящие документы
  • Исходящие документы
  • Регламентирующие документы
  • Проведение

    Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.

    (рис 1.4) Принцип структурирования информации о бизнес-процессе

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

  • Дальнейшие действия

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

    В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Пример шаблона протокола представлен в табл. 1.8.

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

  • Определены ли факторы ценности для заказчика?
  • Усвоила ли команда проекта эти факторы?
  • Были ли факторы ценности интегрированы в процессы и проектные продукты?

    • Инструментом, который позволяет обеспечить положительные ответы на эти вопросы, является функция качества или "дом качества", речь о котором пойдет ниже, в разделе, посвященном формированию требований проекта.

    Шаблон протокола интервью
    УПРАВЛЕНИЕ ДОКУМЕНТОМ
    Автор
    Дата создания
    ИНФОРМАЦИЯ О ВСТРЕЧЕ
    Время и дата
    Порядковый номер
    Адрес/ место
    УЧАСТНИКИ ВСТРЕЧИ
    Со стороны заказчика [ФИО, должность]
    Со стороны исполнителя [ФИО, должность]
    РЕЗУЛЬТАТЫ ОБСУЖДЕНИЯ
    Пункт повестки/ вопрос Результаты обсуждения Ответственный Сроки выполнения
    .
    .
    .
    СТАТУС ПРОТОКОЛА
    Согласовано [ФИО, должность]
    Утверждено [ФИО, должность]
    ИНФОРМАЦИЯ О СЛЕДУЮЩЕЙ ВСТРЕЧЕ
    Время/ Дата
    Место

    Использование функции качества

    Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

    Процесс построения "дома качества" - предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.

    На рис. 1.6 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.

  • Подготовка требований заказчика(рис 1.5) Схема и рекомендации по проведению интервью

    Требования заказчика - важнейшая информация при построении "дома качества". Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.

  • Определение требований проекта(рис 1.6) Функция качества проекта ("домик" качества)

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

  • Формирование матрицы взаимосвязей

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

  • Формирование матрицы отношений

    Заполнение матрицы отношений есть ключевой шаг построения "дома качества". Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].

  • Субъективная оценка через сравнительный анализ

    На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.

  • Объективная оценка через установку конечных целей

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

    •
    Страницы:

    Адаптация модели жизненного цикла проекта

    В данном учебном пособии по управлению ИТ-проектами в качестве концептуальной основы используется модель жизненного цикла информационных систем (ЖЦ ИС), описанная в стандарте ГОСТ Р ИСО/МЭК 15288. В соответствии с данным стандартом запуск каждого нового проекта подразумевает создание (или адаптацию уже имеющейся) модели ЖЦ, состоящей из стадий.

    Процесс создания (или адаптации уже имеющейся) модели ЖЦ начинается с определения целей и результатов каждой из стадий, образующих структуру работ для детализированного моделирования процессов реализации ИТ. [10]

    Исходя из допущений базового стандарта, а также типовых этапов ЖЦ ИТ и принятой последовательности их реализации, авторами предлагается следующая модель ЖЦ ИТ, определяющая последовательность изложения материала в книге.

  • Планирование проекта
  • Проектирование
  • Разработка и внедрение
  • Эксплуатация и поддержка
  • Утилизация и обновление
    •

    В таблице ниже представлены цели каждой из выделенных стадий ЖЦ (см. табл. 1.1).

    Приведенные этапы есть стадии жизненного цикла информационной системы и не тождественны жизненному циклу проекта. Жизненный цикл продукта отражает, что нужно сделать для создания, эксплуатации, поддержки и утилизации данного продукта, а жизненный цикл проекта - как нужно организовывать и управлять работой. Фаза ЖЦ продукта может включать в себя все этапы ЖЦ проекта (см. рис. 1.1 (а, б)), и, в соответствии со стандартом ГОСТ Р ИСО/МЭК 15288 [10], предусматривает наличие этапов планирования, оценки и контроля, а также процесса принятия решения - шлюза (см. рис. 1.1. (а)), через который происходит переход на следующий этап ЖЦ ИС и который является точкой мониторинга качества и точкой принятия решения о целесообразности продолжения проекта [10]. Необходимо отметить, что планирование, оценка и контроль характерны для любого цикла управления (например, цикл Деминга). Таким образом, использование их, в том числе на этапе "Эксплуатация и поддержка", носящем выраженный операционный (не проектный) характер, вполне обосновано.

    Цели этапов жизненного цикла информационной системы
    Этап (ГОСТ Р ИСО/ МЭК 15288) Этап (адаптированный) Цель этапа
    Замысел Планирование проекта Оценка новых возможностей в деловой сфере, разработка предварительных системных требований и проверка их осуществимости. Концептуальное планирование всего ЖЦ ИС
    Разработка Проектирование Создание проекта системы, которая удовлетворяет требованиям приобретающей стороны и может быть реализована, испытана, оценена, применена по назначению, поддержана при применении, в последующем списана и/или обновлена
    Производство Разработка и внедрение Разработка (настройка) системы в соответствии с требованиями приобретающей стороны, тестирование системы, реализация соответствующих организационно-технических мероприятий и развертывание поддерживающих систем, направленных на обеспечение корректной эксплуатации внедренного продукта
    Применение Поддержка применения Эксплуатация и поддержка Использование внедренного продукта в заданных условиях функционирования и обеспечение продолжительной результативности. Осуществление в процессе эксплуатации материально-технического снабжения, технического обслуживания и текущего ремонта, которые обеспечивают непрерывное функционирование рассматриваемой системы и устойчивое предоставление услуг, поддерживающих ее применение
    Изъятие и списание Утилизация и обновление Обеспечение удаления рассматриваемой системы и связанных с нею обслуживающих и поддерживающих организационно-технологических подсистем. Поддержка планирования перехода на новую версию текущей или на абсолютно новую систему

    Рассмотрение каждой стадии ЖЦ ИТ в качестве отдельного проекта позволяет (по сути, делает единственно возможным) применять метод планирования по принципу набегающей волны, который значительно понижает рискованность проекта и повышает шансы на успех [9].

    (рис 1.1) (а,б) Примеры соотношения жизненного цикла информационной системы и жизненного цикла проекта

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

    С целью структурирования процессы управления проектом принято делить на области знаний. Ниже перечислены области знаний, составляющие процессы проектного управления. Предложенный перечень сформирован на основе рекомендаций лучших мировых практик и содержится в стандарте управления проектами [1,10, 23].

  • Управление интеграцией
  • Управление содержанием
  • Управление сроками
  • Управление стоимостью
  • Управление качеством
  • Управление рисками
  • Управление человеческими ресурсами
  • Управление коммуникациями
  • Управление конфигурацией
    •

    Описание содержания каждой из перечисленных выше областей знаний и соответствующих им процессов приводится в табл. 1.2.

    Области знаний проектного управления
    Область знаний Описание Процессы
    Управление интеграцией Управление интеграцией включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координирования различных процессов и действий по управлению проектом в рамках групп процессов управления проектом. Таким образом, цель данного процесса состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Эффективное взаимодействие на стадии планирования заключается в формировании базовой линии проектаУтвержденная для проекта совокупность планов по областям знаний с включенными одобренными изменениями. Служит для сравнения с фактическим ходом проекта для оценки степени отклонения факта от плана. (project baseline), на стадии оценки - в сравнении с базовой линией и корректировке в соответствии с ней на стадии контроля
  • Разработка ТЭО проекта.
  • Разработка устава проекта.
  • Разработка плана управления проектом.
  • Руководство и управление исполнением проекта.
  • Осуществление интегрированного управления изменениями.
  • Оценка альтернатив развития проекта.
  • Планирование закрытия проекта и перехода в стадию эксплуатации.
  • Завершение проекта.
    •
    Управление содержанием Управление содержанием включает в себя процессы и действия, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект [1,23]
  • Формирование требований проекта.
  • Формирование ИСР.
  • Определение содержания проекта.
  • Определение результатов всех стадий жц ис.
  • Оценка реализуемости требований проекта.
  • Подтверждение содержания проекта.
  • Определение уточненных системных требований.
  • Мониторинг содержания и объема проекта.
  • Оценка готовности пользователей к работе в системе.
  • Планирование обучения конечных пользователей
    •
    Управление сроками Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта [23]
  • Формирование списка работ проекта.
  • Определение последовательности работ проекта.
  • Оценка трудоемкости и продолжительности работ.
  • Разработка базового расписания проекта.
  • Контроль и управление расписанием проекта
    •
    Управление стоимостью Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета [23]
  • Оценка стоимости проекта.
  • Разработка сметы проекта.
  • Разработка базового плана по стоимости.
  • Управление стоимостью проекта
    •
    Управление качеством Процессы управления качеством проекта объединяют все осуществляющиеся в исполняющей организации операции, определяющие политику, цели и распределение ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, для которых он был предпринят. Управление качеством осуществляется посредством системы управления, предусматривающей определенные правила, процедуры и процессы по планированию качества, обеспечению качества и контролю качества, а также операции по их совершенствованию
  • Формирование программы качества проекта.
  • Формирование базовой линии требований проекта.
  • Управление требованиями проекта.
  • Осуществление обеспечения качества.
  • Тестирование.
  • Приемка результатов
    •
    Управление риском Процесс управления рисками тесно связан с общим жизненным циклом проекта. На ранних этапах преобладают риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. На стадии реализации доминируют технологические риски, далее возрастает роль рисков, связанных с поддержкой и сопровождением системы. На протяжении всего жизненного цикла проекта возникают новые риски, что требует проведения дополнительных операций анализа и планирования.Согласно ГОСТ Р ИСО/ МЭК 15288-2005 [10] цель процесса управления рисками заключается в снижении последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков или ухудшения технических характеристик. В ходе данного процесса проводятся определение, оценка, обработка и мониторинг рисков, возникающих в течение полного жизненного цикла, а также вырабатывается реакция на каждый риск в терминах реализации соответствующих мер противодействия риску или его принятия
  • Планирование управления рисками.
  • Идентификация рисков.
  • Качественный анализ рисков.
  • Количественный анализ рисков.
  • Планирование реагирования на риски.
  • Мониторинг и управление рисками
    •
    Управление человеческими ресурсами Управление человеческими ресурсами проекта - это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта [13,17])
  • Планирование человеческих ресурсов.
  • Набор команды проекта.
  • Оценка доступности.
  • Развитие и оценка команды проекта.
  • Организация инфраструктуры проекта
    •
    Управление коммуникациями Управление коммуникациями проекта - это процесс идентификации и эффективного обеспечения всех участников проекта информацией о проекте, а также создания единого образа проекта внутри организации
  • Идентификация участников проекта.
  • Формирование стратегии и плана коммуникаций.
  • Реализация плана коммуникаций и сбор обратной связи
    •
    Управление конфигурацией Управление конфигурацией - процесс управления аппаратными средствами, программным обеспечением, данными, а также документацией в ходе разработки, тестирования и использования информационных систем. Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны.Задачи управления конфигурацией проекта:
  • определение стратегии управления конфигурацией, включающей следующие вопросы:
  • - определение полномочий на запрет или разрешение доступа, реализацию и контроль изменений элементов конфигурации;
  • определение места и условий хранения элементов конфигурации, включая требования к окружающей среде, а в случае информации - требования к хранению носителей информации в соответствии с назначенными уровнями целостности, защищенности и безопасности;
  • определение критериев или событий, соответствующих началу контроля конфигурации и сопровождения базовых линий в процессе эволюции конфигураций;
  • определение стратегии аудита и ответственности за гарантии непрерывной целостности и защищенности информации, описывающей конфигурацию;
    •
  • идентификация элементов, которые необходимо контролировать в процессе управления конфигурацией;
  • поддержка информации о конфигурации на приемлемом уровне целостности и защищенности. Для этого рекомендуется:
  • поддерживать записи о конфигурации в течение всего жизненного цикла и архивировать их в соответствии с соглашениями, законодательством или передовым производственным опытом;
  • описывать конфигурацию в соответствии с производственным или технологическим стандартами там, где это возможно.
  • регистрировать обоснования для изменений базовой линии конфигурации и связанные с этим данные о соответствующих разрешениях;
  • гарантирование того, что изменения базовой линии конфигурации соответствующим образом идентифицируются, записываются, оцениваются, утверждаются, проводятся и верифицируются. Для этого рекомендуется:
  • регистрировать этапы конфигурации;
  • управлять выполнением записей, изменениями и утверждениями текущего статуса конфигурации и статуса всех предыдущих конфигураций для подтверждения корректности, своевременности, целостности и защищенности информации;
  • проводить аудит для проверки соответствия базовой линии УК требованиям к результатам проекта
    		•
  • Идентификация объектов управления конфигурацией.
  • Планирование инфраструктуры стадии разработки.
  • Установление базовой линии конфигурации проекта.
  • Оценка соответствия базовой линии конфигурации.
  • Контроль конфигурации выделенных элементов проекта.
  • Обеспечение целостности элементов конфигурации.
  • Реконфигурация инфраструктуры проекта
    •

    Каждый из этапов ЖЦ ИТ и ЖЦ проекта предусматривает совокупность задач, с полной матрицей которых можно ознакомиться в Приложении 1.

    В рамках конкретных проектов предложенные этапы ЖЦ ИТ, а также и отдельно взятые процессы ЖЦ ИТ могут быть индивидуально отобраны, идентифицированы и, при необходимости, модифицированы для достижения измененных целей и результатов соответствующих стадий.

    Сделанные изменения должны быть задокументированы. Общие требования к процедуре модификации таковы: любой новый процесс жизненного цикла определяется и документируется в терминах его назначения, целей и результатов. Ответственным за такого рода модификации является, как правило, руководитель соответствующего проекта. В то же время утверждение адаптированной, сокращенной или дополненной модели ЖЦ ИС обычно производит офис управления проектами или иная организационная единица, в круг обязанностей которой входит поддержание целостности и актуальности корпоративной методологии управления проектами [8].

    Приведенная процедура и шаблон документирования модификации ЖЦ ИТ являются одним из возможных вариантов оформления соответствующих действий над ЖЦ ИТ.

    Процедура адаптации модели ЖЦ ИС

    При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия.

  • Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают (но не ограничиваются) перечисленное ниже:
  • стабильность и разнообразие среды функционирования;
  • коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;
  • новизну, размеры и сложность;
  • дату начала и продолжительность применения;
  • вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения,
  • доступность;
  • вновь возникающие технологические возможности;
  • бюджетный профиль и доступные организационные ресурсы;
  • готовность предоставления услуг обеспечивающими системами.
    •
  • При наличии свойств, критичных по отношению к системе, руководитель проекта должен учесть структуры ЖЦ, которые рекомендованы или установлены в качестве обязательных стандартами, соответствующими области критичности.
  • Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта:
  • правообладатели системы;
  • заинтересованные стороны соглашения, заключенного организацией;
  • стороны, вносящие вклад в организационные функции.
  • Руководитель проекта определяет новую (модифицированную) модель жизненного цикла системы в терминах стадий, их назначения, целей и результатов, которые достигаются вследствие применения процессов жизненного цикла в пределах каждой стадии.
  • Проектный офис принимает решение об адаптации базовой модели.
  • Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной (под)системы) или общекорпоративный характер по решению проектного офиса, по результатам апробации предложенной РП модификации.
    • Шаблон адаптации модели жизненного цикла информационной системы
    Описание причины:
    Действия Базовый Модифицированный Характеристики модифицированного этапа/процесса
    Этап Процесс Этап Процесс Назначение Цель Результат
    _
    _
    Дата подачи заявки (руководитель проекта):
    Дата принятия решения (проектный офис):
    Дата начала применения:

    Разработка технико-экономического обоснования

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

  • приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;
  • определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта;
  • обеспечение заинтересованности руководителей бизнес-подразделений в проекте;
  • формирование основы для оценки соответствия результатов проекта и первоначальных планов.
    •

    Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время всего лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].

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

    В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается "на пересечении" соответствующих значений двух обозначенных факторов.

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

  • Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
  • Повышение эффективности операций:функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
  • Отказ от операций:информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
    •
    Матрица структурирования выгод ИТ-проекта (адаптировано из [7])
    ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС
    Создание новых возможностей Повышение эффективности операций Отказ от операций
    СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ Финансовые
    Количественные
    Измеримые
    Качественные

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

  • Качественные: выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.
  • Измеримые:выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
  • Количественные:аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
  • Финансовые:это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.
    •

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

    Формирование бизнес-цели проекта

    Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).

    Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.

    Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО, или бизнес-кейс, проекта.

    Разработка устава проекта

    Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.

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

  • стратегические и тактические цели организации-заказчика;
  • формулировка требований организации-заказчика;
  • ТЭО ;
  • контракт;
  • внутрикорпоративная методология управления проектами и соответствующие политики.
    •

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

    В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

    Требования к уставу проекта
    № Раздел Пояснения
    1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
    2. Бизнес-причина возникновения проекта Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
    3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта "
    4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
    5. Расписание основных контрольных событий На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18]
    6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта"
    7. Окружение проекта Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) [20]
    8. Допущения относительно организации и окружения, а также внешние допущения Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
  • o компетенции команды проекта достаточно для выполнения предпроектного обследования;
  • o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта.
    •  Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе
    9. Ограничения относительно организации и окружения, а также внешние ограничения Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11]. Пример ограничений проекта:
  • увеличение стоимости проекта не более чем на 10%;
  • не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.
    •  Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
    10. Объем денежных средств, выделенных на достижение бизнес-цели На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% [18]
    11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [8,18]. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проектАвторы рекомендуют включать в проект руководителей и двух спонсоров проекта - по одному от заказчика и исполнителя. . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
  • утверждать бизнес-цели проекта , включая расписания и бюджет, и вносимые в них изменения;
  • назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;
  • формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;
  • вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов;
  • принимать решения о внесении изменений в базовую линию проекта.
    •  Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18]. Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта [18]
    Шаблон листа управления документом
    Авторы
    Файл
    Дата создания
    Дата последнего редактирования
    Количество страниц
    Версия Дата изменения Краткое описание изменения Автор изменения Подпись
    01
    02
    Согласование документа
    Замечания
    № Дата поступления Наименование документа Автор замечания Подпись
    1.
    2.
    Обработка замечаний
    № Дата обработки Версия документа, учитывающая замечание Исполнитель Подпись
    1.
    2.
    (рис 1.2) Модель комплексного анализа участников и окружения проекта (Burnett, 1980). На рисунке ИКС - исследовательская команда спонсора

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

  • информация в уставе, а также сделанные в нем допущения соответствуют исходным данным, которые содержатся в стратегических и тактических целях организации-заказчика, задокументированных предварительных требованиях организации-заказчика, ТЭО, контракте и внутрикорпоративных политиках и методологиях;
  • все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями;
  • в самом документе отсутствуют противоречия;
  • список рассылки устава проекта включает все функциональные группы, сотрудники которых должны войти в проектную команду, а в идеале - и всех участников проекта внутри организации-заказчика.
    •

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

    Идентификация и анализ участников проекта

    Заинтересованная сторона (участник, или стейкхолдерОт английского stakeholder - "заинтересованная сторона". ) - это любое лицо, которое само оказывает влияние на проект или подвергается влиянию проекта и результатов его реализации [5].

    На начальной фазе ЖЦ ИС, фазе планирования, целевой группой всегда является руководство компании, на которое следует обращать особое внимание и наиболее тесно взаимодействовать с ним. Кроме того, на данной фазе руководство компании будет и единственной точкой опоры проекта в организации, поэтому нужно четко себе представлять, чем отличаются руководители среднего звена от прочих сотрудников [5].

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

    (рис 1.3) Пример карты участников проекта (адаптировано из [5])
  • Организация не является единым целым, но представляет собой совокупность отношений между различными заинтересованными сторонами. Построение карты заинтересованных сторон есть первый шаг на пути выявления взаимосвязей между ними.
  • Необходимо выявить всех участников проекта, и в этом аспекте построение красивых и однозначных схем является вторичным по отношению к значимости формирования исчерпывающего списка.
  • Карта заинтересованных сторон не является статической, по мере продвижения проекта она будет уточняться: изначально включенные участники могут быть исключены из рассмотрения, а на поздних этапах могут быть идентифицированы новые.
    •

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

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

    Анализ воздействия участников проекта (адаптировано из [5])

    Анализ воздействия производится в разрезе двух аспектов.

  • Степень организационного влияния участника проекта

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

  • Воздействие участников на реализуемый ИТ-проект
    •

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

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

    Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов [5].

  • Доверие

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

  • Согласие

    Получилось ли достичь согласия с этим конкретным участником (группой участников проекта)? Разделяют ли они точку зрения руководителя проекта?

    •

    Поскольку на фазе планирования проекта мы в большей степени говорим именно о руководителях высшего звена - о потенциальных спонсорах проекта, то и результаты данного анализа будут в большей степени применимы именно к этой категории сотрудников.

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

  • Союзники

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

  • Конкуренты

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

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

  • Партнеры

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

  • Противники
    •

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

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

  • ФИО и контактную информацию сотрудника;
  • сведения об организационной единице, в которой работает сотрудник;
  • определение функциональной роли сотрудника;
  • категорию получаемых сообщений и их историю.
    •

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

    Формирование требований проекта

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

    Организация и проведение результативного интервью

  • Подготовка

    Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована, с тем чтобы точно определить целевую аудиторию. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику.

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

  • "Большая картинка"
  • Место (под)процесса в сквозном процессе
  • Интерфейс с предшествующим процессом
  • Интерфейс с последующим процессом
    •
  • Описание процесса
  • Что? (типовой результат и его потребитель)
  • Как? (последовательность шагов и показатели эффективности)
  • Кто? (роли и присущая им квалификация)
  • Чем? (используемые средства, инструменты, расходуемые ресурсы)
  • Документы
  • Входящие документы
  • Исходящие документы
  • Регламентирующие документы
  • Проведение

    Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.

    (рис 1.4) Принцип структурирования информации о бизнес-процессе

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

  • Дальнейшие действия

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

    В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Пример шаблона протокола представлен в табл. 1.8.

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

  • Определены ли факторы ценности для заказчика?
  • Усвоила ли команда проекта эти факторы?
  • Были ли факторы ценности интегрированы в процессы и проектные продукты?

    • Инструментом, который позволяет обеспечить положительные ответы на эти вопросы, является функция качества или "дом качества", речь о котором пойдет ниже, в разделе, посвященном формированию требований проекта.

    Шаблон протокола интервью
    УПРАВЛЕНИЕ ДОКУМЕНТОМ
    Автор
    Дата создания
    ИНФОРМАЦИЯ О ВСТРЕЧЕ
    Время и дата
    Порядковый номер
    Адрес/ место
    УЧАСТНИКИ ВСТРЕЧИ
    Со стороны заказчика [ФИО, должность]
    Со стороны исполнителя [ФИО, должность]
    РЕЗУЛЬТАТЫ ОБСУЖДЕНИЯ
    Пункт повестки/ вопрос Результаты обсуждения Ответственный Сроки выполнения
    .
    .
    .
    СТАТУС ПРОТОКОЛА
    Согласовано [ФИО, должность]
    Утверждено [ФИО, должность]
    ИНФОРМАЦИЯ О СЛЕДУЮЩЕЙ ВСТРЕЧЕ
    Время/ Дата
    Место

    Использование функции качества

    Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

    Процесс построения "дома качества" - предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.

    На рис. 1.6 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.

  • Подготовка требований заказчика(рис 1.5) Схема и рекомендации по проведению интервью

    Требования заказчика - важнейшая информация при построении "дома качества". Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.

  • Определение требований проекта(рис 1.6) Функция качества проекта ("домик" качества)

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

  • Формирование матрицы взаимосвязей

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

  • Формирование матрицы отношений

    Заполнение матрицы отношений есть ключевой шаг построения "дома качества". Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].

  • Субъективная оценка через сравнительный анализ

    На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.

  • Объективная оценка через установку конечных целей

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

    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^