Обеспечение проектной деятельности. 6358.03.01_РУ.01_1_БИОР. Оглавлени естр

• Название: Оглавлени естр
• Анкор: Обеспечение проектной деятельности
• Дата: 09.04.2022
• Размер: 0.78 Mb.
• Имя файла: 6358.03.01_РУ.01_1_БИОР.pdf
• Тип: Документы; #457328
• страница: 3 из 5

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

17
проекта по различным категориям. В качестве примера предлагается следующий вариант карты заинтересованных сторон проекта, представленный на рисунке 1.
Рисунок 1. Карта участников проекта
При разработке карты заинтересованных сторон проекта всегда стоит помнить следующие рекомендации:
1. Организация не является единым целым, но представляет собой совокупность отношений между различными заинтересованными сторонами. Построение карты заинтересованных сторон есть первый шаг на пути выявления взаимосвязей между ними.
2. Необходимо выявить всех участников проекта, и в этом аспекте построение однозначных схем является вторичным по отношению к значимости формирования исчерпывающего списка.
3. Карта заинтересованных сторон не является статической, по мере продвижения проекта она будет уточняться: изначально включенные участники могут быть исключены из рассмотрения, а на поздних этапах могут быть идентифицированы новые.
После выполнения идентификации заинтересованных сторон следует анализ участников проекта, в рамках которого необходимо выяснить уровень воздействия каждого из стейкхолдеров
(физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям) на проект и произвести оценку их вовлеченности в проект.
Анализ воздействия производится в разрезе двух аспектов:
1) степень организационного влияния участника проекта.
Степень участия заинтересованной стороны проекта в принятии стратегически важных для компании решений, ее влияние на реализацию различных инициатив. Крайне важно при подобном анализе не упустить из рассмотрения и неформальных лидеров организации;
2) воздействие участников на реализуемый ИТ-проект.
Данный показатель характеризует, как конкретный участник может повлиять на проект, насколько важна его поддержка и опасно его неприятие результатов проекта.
Этот анализ позволяет правильно расставить приоритеты и интенсивность использования типично ограниченных ресурсов, в том числе на реализацию стратегии коммуникаций.
Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов:

18 1) доверие: насколько спонсор(ы) и прочие ключевые участники готовы участвовать в проекте и работать с командой до получения итогового результата, насколько можно рассчитывать на их поддержку в критический момент на проекте;
2) согласие: получилось ли достичь согласия с этим конкретным участником (группой участников проекта); разделяют ли они точку зрения руководителя проекта.
Поскольку на фазе планирования проекта в большей степени говорят именно о руководителях высшего звена – о потенциальных спонсорах проекта, то и результаты данного анализа будут в большей степени применимы именно к этой категории сотрудников.
В зависимости от того, в каком из четырех квадрантов образовавшейся матрицы (рисунок 2) оказывается тот или иной участник (группа участников), они относятся к нижеуказанным группам, принципы работы с которыми весьма разнятся.
Рисунок 2. Вовлеченность участников проекта
Руководителю проекта необходимо установить конструктивный диалог с двумя группами, обладающими высоким уровнем доверия, и сохранять разумную пропорцию их участия:
– союзники поддерживают имеющиеся ожидания по проекту, в основном разделяют видение и, скорее всего, заинтересованы в результатах;
– конкуренты заставляют команду руководства проекта постоянно соперничать за ресурсы, обосновывать значимость проекта и искать наиболее оптимальные и менее затратные способы реализации запланированного.
Спонсоры и ключевые участники проекта, обладающие низким уровнем доверия, характеризуются также низким уровнем готовности работать над проектом. Две группы, которые относятся к данной категории, – это партнеры и противники:
– партнеры: рекомендуется с каждым участником данной категории провести личную беседу, касающуюся его роли в проекте, его обязательств;
– противники: в отличие от партнеров признают свою неготовность действовать, но конфликт с людьми, открыто выражающими свою позицию, маловероятен, поэтому действия по вовлечению их в проект аналогичны действиям по отношению к партнерам: общение, беседа по вопросам их обязанностей и ответственности.
На крупных проектах рекомендуется создавать базу данных участников проекта, в которой будет храниться информация о сотрудниках, способных так или иначе оказать влияние на результаты реализации проекта. Хранимая информация включает в себя:
– ФИО и контактную информацию сотрудника;

19
– сведения об организационной единице, в которой работает сотрудник;
– определение функциональной роли сотрудника;
– категорию получаемых сообщений и их историю.
1.7 Использование функции качества
Функция качества – это инструмент для работы с заказчиком, который позволяет встроить его требования в проект, цель которого – убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения требований проекта и установления характеристик решения до формирования проектных работ и выстраивания программы обеспечения качества.
Процесс построения «дома качества» (разновидность принципиального плана, который обеспечивает средства межфункционального проектирования и взаимосвязи) – предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.
Типовая структура «дома качества» приведена на рисунке 3.
Рисунок 3. Функция качества проекта – «дом качества»
Его заполнение производится в несколько этапов.
Подготовка требований заказчика. Требования заказчика – важнейшая информация при построении «дома качества». Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях выявляется в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества десятью требованиями заказчика, в противном случае использование инструмента становится громоздким.
Определение требований проекта. В отличие от требований заказчика требования проекта сформулированы в терминах конкретных действий, при помощи которых команда планирует и реализует проект. Сформулированные таким образом требования проекта должны быть доступны для выполнения измерения и контроля достижения по завершении проекта. Следует различать два вида требований проекта: условия заказчика и предложения команды для их выполнения, как правило, содержащиеся в соответствующей методологии.

20
Формирование матрицы взаимосвязей. На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, происходит их попарное сравнение.
Формирование матрицы отношений. Заполнение матрицы отношений – это ключевой шаг построения «дома качества». Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика.
Субъективная оценка через сравнительный анализ. На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами.
Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.
Объективная оценка через установку конечных целей. Для обеспечения измерения и последующего контроля реализации требований проекта, а через них – и обеспечения требований заказчика, необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.
2 ПЛАНИРОВАНИЕ ПРОЕКТА
2.1 План управления проектом
Процесс разработки плана управления проектом – это процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. Корректно составленный план управления проектом является основным источником информации о том, как проект будет планироваться, оцениваться, контролироваться и закрываться. План управления проектом обновляется и редактируется в рамках процесса осуществления интегрированного управления изменениями проекта, для поддержки версионности документа рекомендуется использовать лист управления документом.
План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов.
План управления проектом рекомендуется разделять на 3 блока по характеру содержащейся в них информации:
1. Вспомогательные планы управления проектом, в число которых входят:
– план управления содержанием проекта: документ, описывающий процессы, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта;
– план управления расписанием проекта определяет, как будут осуществляться контроль и управление расписанием проекта;

21
– план управления стоимостью проекта: руководство по разработке и планированию плановых операций и плана управления содержанием проекта;
– план управления качеством проекта описывает то, как команда управления проектом будет осуществлять свою политику качества;
– план управления обеспечением персоналом: документ, содержащий информацию о периоде времени, на который сотрудник привлекается к участию в проекте, а также сведения о планах по обучению персонала, требованиях сертификации и соответствия нормативным документам. Является входом для решения задачи по оценке работы членов команды и наблюдения за деятельностью команды;
– план управления коммуникациями проекта включает в себя процессы, необходимые для генерации, сбора, распространения, хранения и конечного размещения информации проекта;
– план управления рисками проекта регламентирует меры по обеспечению контроля рисков проекта и структуру документации по управлению рисками в проекте;
– план управления конфигурацией, в котором излагается концепция и определяются средства для автоматизации процесса, а также расписываются все роли и деятельности в зависимости от стадии жизненного цикла ИС.
2. Базовая линия проекта, состоящая из:
– базового расписания проекта;
– базового плана по стоимости;
– базового плана по качеству;
– базового плана по конфигурации;
– реестра рисков.
3. Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.
2.2 Формирование иерархической структуры проекта
Иерархическая структура работ (ИСР) – это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта.
Работы, не включенные в ИСР, находятся за пределами содержания проекта.
Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта.
Существуют два основных способа разработки ИСР: сверху вниз и снизу вверх. Рассмотрим подход сверху вниз:
1. Сбор исходной информации.
Для разработки ИСР необходима следующая информация:
– требования заказчика;
– пул доступных ресурсов;
– конкретная проектная ситуация.
2. Выбор типа ИСР.
После получения необходимой информации о факторах, влияющих на структуру ИСР, необходимо определиться с типом построения ИСР: по жизненному циклу, по системам, по географическим зонам.

22
В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на первом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта. Хороший пример использования такого типа структурирования ИСР – проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т.д. Что касается следующих уровней ИСР, многие специалисты практикуют гибридные ИСР, сочетающие два или три метода.
При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту, это позволит избежать сопротивления новому методу, которое неизбежно возникнет.
3. Определение степени детализации ИСР. Принимая во внимание тот факт, что число пакетов влияет на время и стоимость управления проектом, нужно выбрать такое количество пакетов работ, для управления которыми есть время и бюджет. Пакетом работ называют дискретную задачу, имеющую определимые конечные результаты, за достижение которых отвечают организационные единицы. Пакеты работ должны представлять небольшие результаты и быть управляемыми.
Для определения степени детализации ИСР нужна следующая информация:
– количество уровней в ИСР;
– количество и средний размер пакета работ, принятые в отрасли.
Так, для большинства средних и малых ИТ-проектов характерны ИСР со следующей детализацией:
– от трех до четырех уровней;
– от 15 до 40 пакетов работ;
– от 40 до 80 часов на средний пакет работ;
– от 3 до 7 % общего бюджета рабочих часов на средний пакет работ.
Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового. Например, большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, а потому и одинаковые или схожие результаты каждой фазы. Шаблон ИСР представляет собой древовидную структуру работ, детализированную до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения.
2.3 Определение содержания проекта
Описание содержания проекта представляет собой формулировку проекта – что необходимо сделать. Процесс разработки предварительного описания содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием.

23
Описание содержания должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.
Автором данного документа является назначенный уставом проекта руководитель проекта, следовательно, данный документ пишется с позиции исполнителя проекта.
К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:
– устав проекта;
– формулировка требований организации-заказчика;
– ТЭО;
– внутрикорпоративная методология управления проектами и соответствующие политики.
Требования к описанию содержания проекта с обязательными разделами следующие:
• Название проекта. Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. Утвержденное еще до момента подписания устава проекта, имя не меняется на протяжении жизненного цикла всего проекта.
• Цели и задачи проекта. Цель проекта формулируется, исходя из требований заказчика и указанной в уставе бизнес-причины проекта, при этом она не повторяет формулировки бизнес- цели, отраженной в уставе, а отвечает на вопрос, как эта бизнес-цель будет достигнута. Цель проекта должна представлять собой констатацию сути проекта и давать ответ на вопрос: «Какую уникальную ценность несет проект для клиента и для бизнеса компании?» В свою очередь, задачи проекта представляют собой действия по достижению цели проекта, выполняемые в рамках проекта. Таким образом, задачи проекта представляют собой требования к проекту, формируемые и корректируемые при помощи формальной процедуры построения «дома качества».
• Требования к проектному решению и результаты проекта. Является элементом базового содержания проекта, входящего в план управления проектом. Описание характеристик реализуемого решения проекта и основных результатов проекта. Для обеспечения связи между требованиями заказчика и результатами проекта рекомендуется использовать функцию качества.
Выполнение работ, изложенных в описании содержания, должно привести к получению основных результатов. Результаты могут включать в себя как промежуточные, например, продукты начальных стадий проекта (описание архитектуры информационной системы), так и конечные
(запуск информационной системы в продуктивную эксплуатацию и обеспечение поддержки). В качестве результатов проекта могут выступать как продукты, так и услуги. Информация о количестве и качестве в обобщенном виде тоже должна быть представлена в описании проекта.
• Границы проекта. Является элементом базового содержания проекта, входящего в план управления проектом. Границы проекта определяют в целом то, что включается в проект, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект. Комплексное рассмотрение проекта подразумевает отражение явным образом функциональных, организационных, технологических и географических границ проекта. Функциональные границы проекта: бизнес-направления, бизнес-процессы, охватываемые проектом автоматизации. При модульной архитектуре внедряемой системы данным пунктом определяются функциональные модули ERP-систем (организационная стратегия интеграции

24
производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности). Организационные границы проекта: определяется, какие подразделения (включая юридические лица) должны участвовать в проекте – кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область генерации требований к внедряемой
ИС. Технологические: перечисление всех систем и существующих интерфейсов, которые связаны с реализацией рассматриваемого ИТ-проекта или будут им затронуты, с указанием процессов, поддерживаемых каждой из систем, и критичности каждой из систем для бизнеса.
Географические: территориальное распределение проекта: указываются территориально удаленные объекты, подлежащие автоматизации в рамках проекта.
• Способ реализации проекта. Способ реализации проекта подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. К таким элементам относятся:
– подход (методология реализации проекта);
– ИТ-система управления проектом;
– материалы и инструментарий – описание внедряемого ИТ-продукта с указанием вендора, названия, класса системы, описания функциональной и технической архитектуры системы, перечисление ее модулей.
• Первоначальная иерархическая структура работ (ИСР) до пакетов работ. Является элементом базового содержания проекта, входящего в план управления проектом. Иерархическая структура работ проекта – модель, раскрывающая проект уровень за уровнем до такой степени детализации, которая необходима для эффективного планирования и контроля проекта. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. Информация о работах, как правило, доступна в описании используемой методологии.
• Потребность в ресурсах, штатное расписание и организационная структура проекта
(трудоемкость, роли проекта, без указания конкретных сотрудников, структура
подотчетности и управления проектом). Потребность ресурсов определяется трудоемкостью работ, отраженных в разработанной ранее ИСР. При определении трудоемкости работ важным источником информации является используемая методология проектного управления (внедрения
ИС). Организационная структура проекта также во многом определяется методологией и, кроме того, – культурой и внутренними политиками компании-заказчика. Помимо этого, на данном этапе рекомендуется разработать матрицу ответственности (RACI-матрицу: устанавливает степень ответственность каждого участника проектной команды за выполнение отдельных этапов и задач проекта), позволяющую распределить комплексную ответственность за задачи проекта.
• Укрупненный календарный план. Укрупненный календарный план разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы уровня 1), кроме того, важным источником информации служит используемая методология проектного управления.
• Критические факторы успеха. Условия, обеспечение которых на проекте может быть залогом успеха. Например:
– точно определенные рамки проекта;

25
– квалификация персонала проекта;
– обучение членов команды и пользователей;
– четкое распределение ролей и ответственности;
– проработанный рабочий план модели критических факторов успеха.
• Допущения проекта (со стороны исполнителя). Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения результата проекта. Допущения обусловливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
– проект имеет организационную поддержку со стороны руководства заказчика;
– у организации-заказчика имеется возможность выделить персонал для обеспечения работ по проекту.
При формировании описания содержания проекта допущения формулируются со стороны организации-исполнителя об организации-заказчике.
• Ограничения проекта (со стороны исполнителя). Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ.
• Связь с прочими текущими программами и проектами. Любое возможное взаимодействие с другими проектами должно быть отражено в описании содержания проекта. Недостаточно просто констатировать эту связь, необходимо указать, где и как проекты соотносятся друг с другом, а также детально описать, какие ресурсы подпадают под совместное использование и в каких функциональных областях организации и когда может вестись работа сразу над несколькими проектами.
• Первоначально сформулированные риски. На данном этапе, как правило, указываются уже известные риски и основные категории потенциальных рисков (например, внешние, организационные, процедурные, технические, юридические, репутационные и т.д.).
• Смета расходов с указанием порядка величин. Смета есть представление проектных затрат на проект по категориям.
• Требования к управлению конфигурацией проекта. Указываются объекты управления конфигурацией проекта, в том числе проектная документация, внутренние политики и производимый продукт.
• Критерии приемки результатов проекта. Являются элементом базового содержания проекта, входящего в план управления проектом. Представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества.