Определение содержания проекта
Описание содержания проекта представляет собой формулировку проекта – что необходимо сделать. Процесс разработки предварительного описания содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием.
Описание содержанием должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.
Автором данного документа является назначенный уставом проекта руководитель проекта, следовательно, данный документ пишется с позиции исполнителя проекта.
К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:
устав проекта;
формулировка требований организации-заказчика;
ТЭО;
внутрикорпоративная методология управления проектами и соответствующие политики.
В Таблица 9 приведены требования к описанию содержания проекта: перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению. Аналогично уставу проекта для поддержания версионности разрабатываемого документа и отслеживания его статуса рекомендуется использовать лист управления документом, шаблон которого был приведен в разделе об уставе проекта.
Таблица 9.
Требования к описанию содержания проекта
№
|
Раздел
|
Пояснения
|
1.
|
Название проекта
|
Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. Утвержденное еще до момента подписания устава проекта, имя не меняется на протяжении жизненного цикла всего проекта
|
2.
|
Цели и задачи проекта
|
Цель проекта формулируется, исходя из требований заказчика и указанной в уставе бизнес-причины проекта, при этом она не повторяет формулировки бизнес-цели, отраженной в уставе, а отвечает на вопрос, КАК эта бизнес-цель будет достигнута. Цель проекта должна представлять собой констатацию сути проекта и давать ответ на вопрос: «Какую уникальную ценность несет проект для клиента и для бизнеса компании?»
В свою очередь, задачи проекта представляют собой действия по достижению цели проекта, выполняемые в рамках проекта. Таким образом, задачи проекта представляют собой требования к проекту, формируемые и корректируемые при помощи формальной процедуры построения «дома качества» (см. соответствующий раздел)
|
3.
|
Требования к проектному решению и результаты проекта
|
Является элементом базового содержания проекта, входящего в план управления проектом.
Описание характеристик реализуемого решения проекта и основных результатов проекта. Для обеспечения связи между требованиями заказчика и результатами проекта рекомендуется использовать функцию качества, точнее, ее вторую итерацию (см. соответствующий раздел).
Выполнение работ, изложенных в описании содержания, должно привести к получению основных результатов. Результаты могут включать в себя как промежуточные, например, продукты начальных стадий проекта (описание архитектуры информационной системы), так и конечные (запуск информационной системы в продуктивную эксплуатацию и обеспечение поддержки). В качестве результатов проекта могут выступать как продукты, так и услуги. Информация о количестве и качестве в обобщенном виде тоже должна быть представлена в описании проекта
|
4.
|
Границы проекта
|
Является элементом базового содержания проекта, входящего в план управления проектом.
Границы проекта определяют в целом то, что включается в проект, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект. Комплексное рассмотрение проекта подразумевает отражение явным образом функциональных, организационных, технологически и географических границ проекта.
Функциональные границы проекта:
бизнес-направления, бизнес-процессы, охватываемые проектом автоматизации. При модульной архитектуре внедряемой системы данным пунктом определяются функциональные модули ERP-систем.
Организационные границы проекта:
определяется, какие подразделения (включая юридические лица) должны участвовать в проекте – кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область генерации требований к внедряемой ИС.
Технологические:
перечисление всех систем и существующих интерфейсов, которые связаны с реализацией рассматриваемого ИТ-проекта или будут им затронуты, с указанием процессов, поддерживаемых каждой из систем, и критичности каждой из систем для бизнеса.
Географические:
территориальное распределение проекта: указываются территориально удаленные объекты, подлежащие автоматизации в рамках проекта
|
5.
|
Способ реализации проекта
|
Способ реализации проекта подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. К таким элементам относятся:
подход (методология реализации проекта);
ИТ-система управления проектом;
материалы и инструментарий – описание внедряемого ИТ-продукта с указанием вендора, названия, класса системы, описания функциональной и технической архитектуры системы, перечисление ее модулей
|
6.
|
Первоначальная иерархическая структура работ (ИСР) до пакетов работ
|
Является элементом базового содержания проекта, входящего в план управления проектом.
Иерархическая структура работ проекта – модель, раскрывающая проект уровень за уровнем до такой степени детализации, которая необходима для эффективного планирования и контроля проекта. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. Информация о работах, как правило, доступна в описании используемой методологии (см. раздел, посвященный формированию ИСР)
|
7.
|
Потребность в ресурсах, штатное расписание и организационная структура проекта (трудоемкость, роли проекта, без указания конкретных сотрудников, структура подотчетности и управления проектом)
|
Потребность ресурсов определяется трудоемкостью работ, отраженных в разработанной ранее ИСР. При определении трудоемкости работ важным источником информации является используемая методология проектного управления (внедрения ИС).
Организационная структура проекта также во многом определяется методологией и, кроме того, – культурой и внутренними политиками компании-заказчика.
Помимо этого, на данном этапе рекомендуется разработать матрицу ответственности (RACI-матрицу), позволяющую распределить комплексную ответственность за задачи проекта (см.соответствующий раздел)
|
8.
|
Укрупненный календарный план
|
Укрупненный календарный план разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы уровня 1), кроме того, важным источником информации служит используемая методология проектного управления
|
9.
|
Критические факторы успеха
|
Условия, обеспечение которых на проекте может быть залогом успеха.
Например:
точно определенные рамки проекта;
квалификация персонала проекта;
обучение членов команды и пользователей;
четкое распределение ролей и ответственности
проработанный рабочий план модели критических факторов успеха.
Ниже см. модель критических факторов успеха, распределенных по этапам ЖЦ проекта внедрения ИС
|
10.
|
Допущения проекта (со стороны исполнителя)
|
Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг.
Пример допущений:
проект имеет организационную поддержку со стороны руководства заказчика;
у организации-заказчика имеется возможность выделить персонал для обеспечения работ по проекту.
Обратите внимание, что при формировании описания содержания проекта допущения формулируются со стороны организации-исполнителя об организации-заказчике
|
11.
|
Ограничения проекта (со стороны исполнителя)
|
Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11].
Пример ограничений проекта:
внесение изменений в содержание проекта производится...
Обратите внимание, что при составлении описания содержания проекта ограничения формулируются со стороны организации-исполнителя об организации-заказчике
|
12.
|
Связь с прочими текущими программами и проектами
|
Любое возможное взаимодействие с другими проектами должно быть отражено в описании содержания проекта. Недостаточно просто констатировать эту связь, необходимо указать, где и как проекты соотносятся друг с другом, а также детально описать, какие ресурсы подпадают под совместное использование и в каких функциональных областях организации и когда может вестись работа сразу над несколькими проектами
|
13.
|
Первоначально сформулированные риски
|
На данном этапе, как правило, указываются уже известные риски и основные категории потенциальных рисков (например, внешние, организационные, процедурные, технические, юридические, репутационные и т.д. ). См. соответствующий раздел
|
14.
|
Смета расходов с указанием порядка величин
|
Смета есть представление проектных затрат на проект по категориям, в качестве примера см. шаблон в соответствующем разделе.
Для определения количества привлекаемых ресурсов используйте информацию из заполненного файла
|
15.
|
Требования к управлению конфигурацией проекта
|
Указываются объекты управления конфигурацией проекта, в том числе проектная документация, внутренняя политика и производимый продукт. См. соответствующий раздел
|
16.
|
Критерии приемки результатов проекта
|
Являются элементом базового содержания проекта, входящего в план управления проектом.
Представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества. Приемка же самого продукта осуществляется в соответствии с рассмотренной ранее процедурой приемки результатов проекта (см. соответствующий раздел)
|
Критические факторы успеха
Рисунок 7. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы
Проект, будучи инициативой с весьма ограниченными ресурсами, всегда направлен на оптимальное их использование. По этой причине в реализации имеет смысл уделять внимание обеспечению того или иного критического фактора успеха только в тот момент времени, когда это действительно важно для проекта, и снижать интенсивность привлечения ресурсов в прочие моменты времени, когда эти ресурсы могут быть задействованы на обеспечении решения прочих задач. На Рисунок 7 отражена модель, описывающая значимость каждого из критических факторов успеха на различных этапах ЖЦ ИС. Указанные баллы отражают нормированные по десятибалльной шкале оценки значимости критических факторов на соответствующих стадиях.
Наличие спонсора из числа высшего руководства компании
Наличие спонсора у проекта зачастую предопределяет результат проекта [3]. Данный фактор имеет особенно большое значение в начале проекта, когда необходимо обеспечить политическую поддержку проекта и необходимые ресурсы; не меньшее значение он имеет в конце проекта, когда необходимо обеспечить принятие и переход к продуктивной эксплуатации системы в полном объеме в запланированный срок.
Компетентный состав команды
В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем, Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора. В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны – как основных носителей знаний о бизнес-процессах компании, с другой – для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании [4, 6].
Межфункциональная координация
Интеграционный, т.е. комплексный, характер решения накладывает серьезные требование на межфункциональную координацию, как среди членов проектной команды, так и владельцев бизнес-процессов. Данный фактор имеет высокое значение в начале проекта, когда все участники из различных подразделений формируют общие цели проекта, и в конце, когда необходимо проанализировать достижения соответствующих целей и, убедившись, что не возникло межфункциональных противоречий, завершить проект [4].
Обеспечение «умного» реинжиниринга бизнес-процессов
Построение системы вокруг неоптимизированных процессов не имеет смысла, это чревато «автоматизацией бардака». Владельцы бизнес-процессов должны иметь представление о том, как и какие процессы будут автоматизированы. Во многих методологиях внедрения, включая aSAP, предполагается, что процессы в компании будут по большей части перестроены в соответствии с логикой, реализованной в системе, в связи с чем данный фактор приобретает еще большую значимость. Данный фактор имеет большое значение на фазе концептуального проектирования, когда производится анализ существующих бизнес-процессов и проектирование новых бизнес-процессов в системе.
Привлечение конечных пользователей
С самого начала проекта конечные пользователи должны быть активно вовлечены в проект. Они должны осознавать важность внедрения системы, а их разумные требования не должны быть проигнорированы. Очевидно, что их участие особенно важно на стадии формирования требований к системе, а также при миграции данных и интеграционном тестировании.
Принятие системы сотрудниками
Принятие системы пользователями позволяет в короткие сроки получить запланированный эффект от её внедрения и, следовательно, сократить время окупаемости проекта. Принятие во многом основано на том, понимают ли сотрудники концепцию, реализованную в системе; таким образом, аналогично реинжинирингу бизнес-процессов, данный фактор имеет наибольшую значимость на этапе концептуального проектирования
Мотивация сотрудников и членов проектной команды
Сотрудники должны быть заинтересованы в достижении целей проекта, это снизит возможное сопротивление и повысит лояльность к системе. Также надо иметь в виду, что конфликтующие цели должны быть устранены из системы мотивации сотрудников. Наибольшую значимость данный фактор приобретает на последнем этапе проекта, когда от членов проектной команды требуется наибольшее усилие для обеспечения работоспособности системы и устранения выявленных недостатков.
Продуманная стратегия коммуникаций
Коммуникации как внутри проектной группы, так и за её пределами (с будущими пользователями) являются важным аспектом, обеспечивающим успех проекта внедрения. О целях, задачах и объеме проекта должно быть известно всем участникам проекта; кроме того, участники должны быть в кратчайшие сроки информированы обо всех происходящих изменениях, как внутри проекта, так и в деятельности организации. Для решения задачи регулярной информированности должен быть выстроен план и стратегия коммуникации. Особую важность данный параметр имеет на первых двух стадиях проекта, когда в тесном сотрудничестве с менеджментом компании определяются цели и план проекта; также его значимость повторно возрастает на финальной стадии, ибо на этом этапе проектная команда должна провести большое количество информационных семинаров перед выводом системы в продуктив.
Обеспечение обучения и тренингов
Стратегия и план обучения должны быть сформированы на начальных этапах проекта, а не после его завершения, причем в них должна учитываться необходимость развития компетенции как технических специалистов, администраторов системы, так и конечных пользователей. Кроме того, надо иметь в виду, что при обучении сотрудники должны не только приобретать технические навыки (тренинги) работы в системе, но и получать понимание концепций, реализованных в ERP-системе. Обучение работе в системе должно быть включено отделом управления человеческим капиталом в план развития релевантных сотрудников, а также должна быть предусмотрена возможность обучения новых сотрудников и тех, кому требуется повторное обучение.
|
