Планирование и управление проектом

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 70-х годов в Америке и на Заподе. В 1976 г. М.Уолкер из фирмы "Дюпон", исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д.Келли из группы планирования капитального строительства фирмы "Ремингтон Рэнд". Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы "Дюпон". В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути - МКП (или CPM - Critical Path Method).

Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока. Благодаря такому успешному началу данный метод управления вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов.

Глава 1. Планирование проекта

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

Полноценная техника планирования включает в себя следующие этапы:

1) Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.

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

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

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

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

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

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

· класс решаемых задач, тиражность готового продукта, вид работ (разработка, развитие, сопровождение);

· выбор схемы ведения работ (модели жизненного цикла) с учетом сложности проекта и возможностей коллектива разработчиков;

· опыт работы в предметной области и на средствах автоматизации разработки;

· оснащенность разработчиков средствами автоматизации и аппаратно-программной базой;

· уровень требований заказчика к срокам и качеству работ.

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

Основная цель планирования, состоит в построении модели реализации проекта.

Аналогичная ситуация часто встречается в проектах разработки и адаптации информационных систем. Заказчик имеет непреодолимое желание получить готовый инструмент как можно быстрее. При этом он имеет только смутное представление о возможностях программного обеспечения, которое он выбрал, и что он хочет автоматизировать. С другой стороны, поставщики программного обеспечения знают очень немного о реальных процессах управления (функциональной, информационной, организационной структурах) в организации заказчика. И только когда они приступают к реализации проекта, начинается процесс взаимного информирования и обучения. Уточнение постановки приводит к существенному, иногда в несколько раз, увеличению объемов работ и изменению их целей и состава.

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

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

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

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

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

Что нужно, чтобы избежать ошибок планирования(несколько советов):

· для проекта должен быть сформулирован список решаемых проблем;

· основная цель проекта (миссия) должна быть доведена до сведения всех участников;

· должны быть идентифицированы риски и, по возможности, исключены случайности;

· необходимо убедиться, что стратегия проекта может быть реализована и удовлетворяет ограничениям по бюджету, срокам и объему (проведен PCTS-анализ осуществимости: Р -- Performance, С -- Cost, Т -- Time, S -- Scope. Затраты являются функцией уровня исполнения Р, времени Т и содержания, объема работ S);

· наличие положительных результатов анализа «за и против» реализации проекта (проведен Force-field -- анализ, заключающийся в описании и количественной оценке факторов, которые могут способствовать и препятствовать осуществлению проекта);

· конечный результат должен быть понятен всем членам команды проекта;

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

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

Основной продукт этапа - документ "Постановка Задачи" (Product Vision).

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

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта от внедрения.

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

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

В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

Далее мы рассмотрим методику Мягкого внедрения и более подробно рассмотрим этот этап.

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

Материально-технические ресурсы - это сырье, материалы, конструкции, комплектующие, энергетические ресурсы, технологические ресурсы и т.д.

Трудовые ресурсы - это те, кто непосредственно осуществляет работу с материально-техническими ресурсами.

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

1. Оптимальное планирование ресурсов

2. Управление материально-техническим обеспечением, в том числе:

· управление закупками ресурсов;

· управление распределением ресурсов.

Понятие ресурсов взаимосвязано с понятием «работа», поскольку ресурсы соотносятся не с проектом в целом, а с определенными работами, выполняемыми в запланированной последовательности, соответствующей календарному плану работ по проекту.

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

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

Как основная составляющая управления проектами ресурсное планирование включает ряд составляющих, в том числе:

· разработку и сбалансированный анализ комплексов работ и ресурсов, направленных на достижение целей проекта;

· разработку системы распределения ресурсов и назначение ответственных исполнителей;

· контроль за ходом работ -- сравнение плановых параметров работ с фактическими и выработка корректирующих воздействий.

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

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

Все затраты можно классифицировать как:

прямые и накладные расходы;

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

постоянные и переменные по признаку зависимости от объема работ;

плата за сверхурочное рабочее время.

Глава 2. Анализ и планирование рисков

Прежде всего, необходимо пояснить какие риски, с чем они связаны. Планируя проект, мы предполагаем, что не все получится так, как запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие несовпадения первоначального согласованного и зафиксированного представления о проекте (project baseline) и того, что получается в действительности, называется отклонениями. Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:

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

2. Управление проблемами. Неприятности наступили, и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии - обеспечить проекту возможность идти так, как запланировано.

3. Управление изменениями. Неприятности оказались достаточно серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа - то, что у финансистов называется «зафиксировать убытки», - это модификация ранее согласованного технического задания, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.

Строго говоря, отклонения могут быть не обязательно связаны с неприятностями. Так, к рисковым событиям относятся и желательные, но не запланированные события. Соответственно и изменения будут носить положительный характер. Однако, большее опасение вызывают изменения со знаком минус, поэтому мы не будем рассматривать «желательные изменения».

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

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

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

1. Планирование управления рисками - выбор подходов и планирование деятельности по управлению рисками проекта.

2. Идентификация рисков - определение рисков, способных повлиять на проект, и документирование их характеристик.

3. Качественная оценка рисков - качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

4. Количественная оценка - количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

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

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

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

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

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

2.3 Качественная оценка рисков

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

Количественная оценка рисков определяет вероятность возникновения рисков и влияние последствий рисков на проект, что помогает группе управления проектами верно принимать решения и избегать неопределенностей. Количественная оценка рисков позволяет определять:

· Вероятность достижения конечной цели проекта

· Степень воздействия риска на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться.

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

· Фактические затраты, предполагаемые сроки окончания.

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

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

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

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

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

Целью мониторинга и контроля является выяснить, было ли:

· Система реагирования на риски внедрена в соответствии с планом

· Реагирование достаточно эффективно или необходимы изменения

· Риски изменились по сравнению с предыдущим значением

· Наступление влияния рисков

· Необходимые меры приняты

· Воздействие рисков оказалось запланированным или явилось случайным результатом.

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

Глава 3. Методика управления проектом

Существуют различные методики управления проектами В данном курсе мы будем придерживаться методики «Мягкого внедрения» ведения проекта. Это методики мягкого и жесткого внедрения.

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

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

Данная технология разработки и внедрения имеет следующие проверенные границы применимости:

· Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.

· Оптимально для проектов сроком до 3х месяцев и трудоемкостью до 1 чел/года. Для изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.

· Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика "ценообразования за весь проект". Это не исключает возможность применения более простой расчетной схемы повременного типа.

· Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.

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

· Методика применима для небольших заказных и серийных систем.

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

Основной продукт этапа - документ "Постановка Задачи" (Product Vision).

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

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта от внедрения.

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

Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут быть выполнены как один).

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

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

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

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

В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)

Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.

Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.

Возможны два варианта взаимодействия "прототип-документация":

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

2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы.

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

Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:

1. Описание программы делается на языке, понятном пользователю.

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

3. Нет необходимости править ТЗ и Документацию одновременно.

4. Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.

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

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

Заключение

Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.

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

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