Инспектор
Вы можете этот курс.
Опубликован: 25.01.2011 | Уровень: для всех | Доступ: платный | ВУЗ: Национальный исследовательский университет "Высшая Школа Экономики"
Лекция 3:
Планирование проекта
Аннотация: План управления проектом. Формирование иерархической структуры проекта. Построение ИСР. Определение содержания проекта. Критические факторы успеха. Формирование списка работ (операций) проекта. Определение логической последовательности выполнения работ. Оценка трудоемкости и потребности в ресурсах
Определение длительности операций. Исходная информация процесса определения длительности операций. Результаты процесса оценки длительности операций. Концептуальная оценка стоимости проекта. Формирование сметы. Шаблон сметы проекта. Проверка качества составления сметы проекта. Разработка базового плана по стоимости проекта.
Ключевые слова: план управления проектом, лист, шаблон, управление стоимостью, план управления качеством, расписание проекта, реестр рисков, разделы, иерархическая структура работ, ИСР, содержание проекта, пакеты работ, работ, выход, пространство, руководитель проекта, значение, Устав проекта, ТЭО, матрица ответственности, контрольные события, переход к продуктивной эксплуатации, методология внедрения, ASAP, определение, документирование, операции, единица, список, смета, команда, разбиение, детализация, метод набегающей волны, список операций, идентификатор, параметры операций, взаимосвязи операций, входной, сетевая диаграмма, отображение, spider, project, пакет операций, запрос, проектная операция, ресурсы операции, календарь ресурсов проекта, АС, проектная процедура, стоимостная оценка, опыт, точность, оценка стоимости, цикла, стоимость, связь, Интернет, расходы, калькуляция себестоимости, фактическая стоимость, конечные, улучшение, информация, математическая модель, поток, базовый план по стоимости, график, оборотный капитал, анализ, место, представление
План управления проектом
Процесс разработки плана управления проектом есть процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. Корректно составленный план управления проектом является основным источником информации о том, как проект будет планироваться, оцениваться, контролироваться и закрываться. План управления проектом обновляется и редактируется в рамках процесса осуществления интегрированного управления изменениями проекта (см. соответствующий раздел), для поддержки версионности документа рекомендуется использовать лист управления документом, шаблон которого представлен в табл. 1.6.
План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов.
План управления проектом рекомендуется разделять на 3 блока по характеру содержащейся в них информации.
- Вспомогательные планы управления проектом, в число которых входят:
- Базовая линия проекта, состоящая из:
- Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.
Рассмотрению основных вспомогательных планов управления и элементов базовой линии проекта, равно как и описанию ключевых методов и процедур составления этих планов, посвящены отдельные разделы данной книги.
Формирование иерархической структуры проекта
Иерархическая структура работ ( ИСР ) - это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта. Работы, не включенные в ИСР, находятся за пределами содержания проекта [18].
Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта.
Построение ИСР
Существуют два основных способа разработки ИСР: "сверху вниз" и "снизу вверх". Далее приводится описание подхода "сверху вниз".
- Сбор исходной информации.
Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:
- требования заказчика;
- пул доступных ресурсов;
- конкретная проектная ситуация.
- Выбор типа ИСР
После получения необходимой информации о факторах, влияющих на структуру ИСР, необходимо определиться с типом построения ИСР: по жизненному циклу, по системам, по географическим зонам.
В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта. Хороший пример использования такого типа структурирования ИСР - проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т. д. Что касается следующих уровней ИСР, многие специалисты практикуют гибридные ИСР, сочетающие два или три метода.
При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту, это позволит избежать сопротивления новому методу, которое неизбежно возникнет.
- Определение степени детализации ИСР
Принимая во внимание тот факт, что число пакетов влияет на время и стоимость управления проектом, нужно выбрать такое количество пакетов работ, для управления которыми есть время и бюджет. Вообще говоря, пакетом работ мы будем называть основной элемент управления ИСР, дискретную задачу, имеющую определимые конечные результаты, за достижение которых отвечают организационные единицы. Очевидно, пакеты работ должны представлять небольшие результаты и быть управляемыми.
Для определения степени детализации ИСР нужна следующая информация:
- количество уровней в ИСР ;
- количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны
ИСР со следующей детализацией:
- от трех до четырех уровней;
- от 15 до 40 пакетов работ;
- от 40 до 80 часов на средний пакет работ;
- от 3% до 7% общего бюджета рабочих часов на средний пакет работ [18].
Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового. Например, большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, а потому и одинаковые или схожие результаты каждой фазы. Шаблон ИСР представляет собой древовидную структуру работ, детализированную до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения.
Определение содержания проекта
Описание содержания проекта представляет собой формулировку проекта - что необходимо сделать. Процесс разработки предварительного описания содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием.
Описание содержания должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта - он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.
Автором данного документа является назначенный уставом проекта руководитель проекта, следовательно, данный документ пишется с позиции исполнителя проекта.
К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:
- устав проекта;
- формулировка требований организации-заказчика;
- ТЭО;
- внутрикорпоративная методология управления проектами и соответствующие политики.
В табл. 2.1 приведены требования к описанию содержания проекта: перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению. Аналогично уставу проекта для поддержания версионности разрабатываемого документа и отслеживания его статуса рекомендуется использовать лист управления документом, шаблон которого был приведен в разделе об уставе проекта.
| № | Раздел | Пояснения |
|---|---|---|
| 1. | Название проекта | Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. Утвержденное еще до момента подписания устава проекта, имя не меняется на протяжении жизненного цикла всего проекта |
| 2. | Цели и задачи проекта | Цель проекта формулируется, исходя из требований заказчика и указанной в уставе бизнес-причины проекта, при этом она не повторяет формулировки бизнес-цели, отраженной в уставе, а отвечает на вопрос, КАК эта бизнес-цель будет достигнута. Цель проекта должна представлять собой констатацию сути проекта и давать ответ на вопрос: "Какую уникальную ценность несет проект для клиента и для бизнеса компании?" В свою очередь, задачи проекта представляют собой действия по достижению цели проекта, выполняемые в рамках проекта. Таким образом, задачи проекта представляют собой требования к проекту, формируемые и корректируемые при помощи формальной процедуры построения "дома качества" (см. соответствующий раздел) |
| 3. | Требования к проектному решению и результаты проекта | Является элементом базового содержания проекта, входящего в план управления проектом. Описание характеристик реализуемого решения проекта и основных результатов проекта. Для обеспечения связи между требованиями заказчика и результатами проекта рекомендуется использовать функцию качества, точнее, ее вторую итерацию (см. соответствующий раздел). Выполнение работ, изложенных в описании содержания, должно привести к получению основных результатов. Результаты могут включать в себя как промежуточные, например, продукты начальных стадий проекта (описание архитектуры информационной системы), так и конечные (запуск информационной системы в продуктивную эксплуатацию и обеспечение поддержки). В качестве результатов проекта могут выступать как продукты, так и услуги. Информация о количестве и качестве в обобщенном виде тоже должна быть представлена в описании проекта |
| 4. | Границы проекта | Является элементом базового содержания проекта, входящего в план управления проектом. Границы проекта определяют в целом то, что включается в проект, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект. Комплексное рассмотрение проекта подразумевает отражение явным образом функциональных, организационных, технологических и географических границ проекта. Функциональные границы проекта: бизнес-направления, бизнес-процессы, охватываемые проектом автоматизации. При модульной архитектуре внедряемой системы данным пунктом определяются функциональные модули ERP-систем. Организационные границы проекта: определяется, какие подразделения (включая юридические лица) должны участвовать в проекте - кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область генерации требований к внедряемой ИС. Технологические: перечисление всех систем и существующих интерфейсов, которые связаны с реализацией рассматриваемого ИТ-проекта или будут им затронуты, с указанием процессов, поддерживаемых каждой из систем, и критичности каждой из систем для бизнеса. Географические: территориальное распределение проекта: указываются территориально удаленные объекты, подлежащие автоматизации в рамках проекта |
| 5. | Способ реализации проекта | Способ реализации проекта подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. К таким элементам относятся:
|
| 6. | Первоначальная иерархическая структура работ ( ИСР ) до пакетов работ | Является элементом базового содержания проекта, входящего в план управления проектом. Иерархическая структура работ проекта - модель, раскрывающая проект уровень за уровнем до такой степени детализации, которая необходима для эффективного планирования и контроля проекта. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. Информация о работах, как правило, доступна в описании используемой методологии (см. раздел, посвященный формированию ИСР ) |
| 7. | Потребность в ресурсах, штатное расписание и организационная структура проекта (трудоемкость, роли проекта, без указания конкретных сотрудников, структура подотчетности и управления проектом) | Потребность ресурсов определяется трудоемкостью работ, отраженных в разработанной ранее ИСР. При определении трудоемкости работ важным источником информации является используемая методология проектного управления (внедрения ИС). Организационная структура проекта также во многом определяется методологией и, кроме того, - культурой и внутренними политиками компании-заказчика. Помимо этого, на данном этапе рекомендуется разработать матрицу ответственности (RACI-матрицу), позволяющую распределить комплексную ответственность за задачи проекта (см.соответствующий раздел) |
| 8. | Укрупненный календарный план | Укрупненный календарный план разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы уровня 1), кроме того, важным источником информации служит используемая методология проектного управления |
| 9. | Критические факторы успеха | Условия, обеспечение которых на проекте может быть залогом успеха. Например:
|
| 10. | Допущения проекта (со стороны исполнителя) | Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для
достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
|
| 11. | Ограничения проекта (со стороны исполнителя) | Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11]. Пример ограничений проекта: внесение изменений в содержание проекта производится... Обратите внимание, что при составлении описания содержания проекта ограничения формулируются со стороны организации-исполнителя об организации-заказчике |
| 12. | Связь с прочими текущими программами и проектами | Любое возможное взаимодействие с другими проектами должно быть отражено в описании содержания проекта. Недостаточно просто констатировать эту связь, необходимо указать, где и как проекты соотносятся друг с другом, а также детально описать, какие ресурсы подпадают под совместное использование и в каких функциональных областях организации и когда может вестись работа сразу над несколькими проектами |
| 13. | Первоначально сформулированные риски | На данном этапе, как правило, указываются уже известные риски и основные категории потенциальных рисков (например, внешние, организационные, процедурные, технические, юридические, репутационные и т.д. ). См. соответствующий раздел |
| 14. | Смета расходов с указанием порядка величин | Смета есть представление проектных затрат на проект по категориям, в качестве примера см. шаблон в соответствующем разделе. Для определения количества привлекаемых ресурсов используйте информацию из заполненного файла |
| 15. | Требования к управлению конфигурацией проекта | Указываются объекты управления конфигурацией проекта, в том числе проектная документация, внутренние политики и производимый продукт. См. соответствующий раздел |
| 16. | Критерии приемки результатов проекта | Являются элементом базового содержания проекта, входящего в план управления проектом. Представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества. Приемка же самого продукта осуществляется в соответствии с рассмотренной ранее процедурой приемки результатов проекта (см. соответствующий раздел) |
