Содержание устава проекта. Реферат на тему устав проекта

Устав проекта: разработка, содержание и примеры

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

Место устава в процессах инициации

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

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

Основные выходы процесса инициации проекта

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

1. Ответственность менеджера ограничивается созданием нового продукта.
2. PM обеспечивает создание продукта и его производство.
3. Менеджер отвечает не только за создание и производство новой продукции, но и за его продажу в течение заданного периода времени.

Выписка из модели процессов инициации проекта

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

Состав и структура устава

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

• функцию постановки задачи;
• функцию согласования;
• авторизационную функцию;
• функцию повышения дисциплины;
• консолидационную функцию;
• интеграционную функцию.

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

1. Обоснование выполнения уникальной задачи развития.
2. Цели, задачи и результаты.
3. Имя и фамилию PM, границы его ответственности и полномочия.
4. Определение и структуру продукта.
5. Интересы и ожидания участников.
6. Критерии успеха.
7. Принципы организации и управления проектом.

Типовая структура устава проекта

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

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

Форма устава проекта

Форма приложения к уставу проекта

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

projectimo.ru

Устав проекта (шаблон)

<Название компании>

Устав проекта

Название проекта

Устав проекта “Название проекта”

Информация о документе

Дата документа Версия документаСтатус документа Ответственный

История изменений

2

Устав проекта “Название проекта”

Содержание

Устав проекта “Название проекта”

Введение

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

Задачи документа:

Зафиксировать причину проекта

Определить ключевые параметры проекта - срок, стоимость, качество

Назначить роли участников проекта - руководителя проекта и команду проекта

Задать порядок управления проектом – общие правила (политики) на основании которых будет вестись управление проектом, права и обязанности всех участников проекта.

Дополнительно в Уставе проекта может быть определено:

Список основных контрольных событий

Ключевые риски проекта – риски определенные на этапе инициации проекта. Детальная информация по рискам детально в плане проекта.

4

Устав проекта “Название проекта”

1 Обоснование проекта

В данном разделе дается краткая информация из принятого бизнес кейса (концепции) проекта для сведения проектной команды. Эта информация важна для определения проекта.

1.1Краткое описание проекта

Кто заказчик проекта?

Кто клиент проекта?

Что является результатом проекта?

В одну строку ключевые параметры проекта

1.2Решаемые проблемы/возможность

1 23

1.3 Бизнес цели

1 23

1.4 Критерии успеха

Определяем критерии успеха для выше поставленные целей.

№Цель Критерий

1 23 45

1.5 Связи и зависимости

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

1 23

5

Устав проекта “Название проекта”

6

Устав проекта “Название проекта”

2 Определение проекта

2.1 Результаты проекта

1 23 45

2.2 Критерии приемки результатов проекта

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

№ Результат Критерий и порядок его приемки

1 23

2.3 Исключено из проекта

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

№Исключение

1 23

2.4 Время

Начало проекта Срок выполнения проектаКритерии успеха

2.5 Стоимость

Сумма затрат проекта Источник финансированияКритерии успеха

7

Устав проекта “Название проекта”

2.6 Другие требования

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

№Требование

1 23 45 67 89

2.7 Допущения и ограничения

№Допущение/Ограничение

1 23 45

8

Устав проекта “Название проекта”

3 Организационная структура проекта

3.1 Управляющий комитет проекта

Спонсор проекта Куратор проектаДиректор направления 1

Директор направления 2 Менеджер со стороны Партнера 1

Менеджер со стороны Партнера 2

3.2 Руководство проектом

Руководитель проекта Помощник руководителя проекта

3.3 Команда проекта

3.4 Ключевые лица со стороны заказчика

9

Устав проекта “Название проекта”

4 Права и обязанности

4.1Права и обязанности руководителя проекта

1.…

2.…

3.…

4.2Права и обязанности управляющего комитета

1.…

2.…

3.…

4.3Права и обязанности члена команды

4.…

5.…

6.…

10

studfiles.net

Что такое устав проекта. Примеры устава проекта.

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

Разработка устава проекта – это процесс разработки устава проекта.

В стандарте PMBOK 5 – разработка устава проекта относится к области знаний управление интеграцией проекта .

Перечислим список тех пунктов, которые может включать в себя устав проекта :

В самом просто виде устав может выглядеть как-то так:

Я, великий царь и владыка сея компании, хочу для увеличения каналов продаж запустить к 30 декабря сего года новый интернет магазин компании,  через который пользователи могли бы выбирать продукты нашей компании и через интернет оплачивать их.  Проект необходимо реализовать с помощью наших старых партнеров “Фирмы ИТ-спецы”. Общая сумма работ не должна превысить 100 золотых монет.  Кроме меня в этом проекте также заинтересованы отделы маркетинга и обслуживания клиентов, поэтому нужно включить их в работу.

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

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

Бизнес-вопросы.

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

Технологические вопросы.

• Возможно ли осуществить запрос бизнеса? Если нет, то что именно из запросов бизнеса возможно реализовать?
• С помощью каких решений можно реализовать потребности бизнеса? Какое решение для этого подходит лучше всего?
• Реализовывались ли в нашей компании подобные решения ранее? Как это делалось?

Структурные вопросы (эти вопросы учитывают возможные влияния законов и культуры компании на проект).

• Какие государственные стандарты могут повлиять на проект? Например, если ИТ-решение потребует сертификацию, то это необходимо учитывать, чтобы заложить возможные издержки на это в проект.
• Какова корпоративная культура и стратегия компании, в которой вы работаете? Как стандарты принятые в компании влияют на ваш проект? Например, вы запускаете сайт и ваша компания работает в этом направлении с одним давно проверенным вендором. Следовательно, вы должны учесть это при разработке устава проекта.
• Что сейчас происходит на рынке? Легко ли вам будет найти ресурсы для реализации проекта?

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

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

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

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

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

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

С Уважением,

Олег Лялик.

Оцените Ваш уровень тайм-менеджмента и получите рекомендации к действию.

Книга-тренер по тайм-менеджменту. Скачать бесплатно.

Есть ли жизнь в офисе?

Читайте также:

time-management.by

Разработка устава проекта. Методическое пособие

Мадорская Ю.М.

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

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

Устав проекта определяет каркас проекта в 5 измерениях:

• ЦЕЛИ и ТРЕБОВАНИЯ
• ЗАДАЧИ
• РИСКИ
• УЧАСТНИКИ
• ПРАВИЛА

Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).

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

Чтобы определить каркас проекта в этих измерениях необходимо:

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

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

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

Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.

Рассмотрим подробнее эти задачи.

Для описания задач воспользуемся методологией функционального моделирования IDEF0.

Модель процесса разработки устава проекта

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

Точка зрения: Руководитель проекта.

Контекст:  Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит  PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.

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

На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.

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

Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.

Рисунок 1. Контекстная диаграмма А0

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

Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.

Рисунок 2. Диаграмма А1 «Выполнить проект»

Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта, нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.

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

Введенные на первых двух диаграммах потоки, определены в таблице ниже.

Таблица 1. Потоки данных для А0-А1

Далее нас интересует детализация процесса «Разработать устав проекта»:

Рисунок 3. Диаграмма А1.1. «Разработать устав проекта»

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

Таблица 2. Потоки данных для А1.1

Первоочередная задача подготовки и оценки проекта  – понять и определить систему целей. Все цели проекта должны быть взаимоувязаны, даже те, которые невозможно зафиксировать в явной форме. Выявление и согласование целей – сложная задача, результаты которой определяют его успех или провал   [1]. Чаще всего она не решается «с наскока», а некоторые важные цели мимолетно всплывают и тонут в несущественных деталях, подменяясь на составляющие их подцели. Задача руководителя проекта – держать в фокусе максимально полную картину, начиная с самого верхнего уровня.

На диаграмме процесса A.1.1.1, раскрывающей  процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников —  сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта  и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.

Рисунок 4. Диаграмма процесса A.1.1.1 «Выявить и проработать систему целей проекта»

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

Хорошая практика формулирования целей заложена в принципах SMART [2].  Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта.  Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным.

Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли [1].

Таблица 3. Потоки данных для А1.1.1

Расширенный материал по формированию системы целей с иллюстрациями приведен в статье Цели проекта — упущенные возможности?

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

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

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

Для каждого риска рекомендуется прорабатывать поля, описанные в определении потока Риски проекта (см Таблицу 4).

Еще один прием, позволяющий более точно определить каркас проекта — это описание его границ. Границы описываются за счет указания целей и задач, которые не входят в проект. Таким образом, более точно определяется развитие проекта, которое будет считаться успешным.

Рисунок 5. Диаграмма процесса A.1.1.2 «Провести стратегическое планирование».

Таблица 4. Потоки данных для А1.1.2

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

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

Рисунок 6. Диаграмма A1.1.3 процесса «Спроектировать организационную структуру проекта»

Таблица 5. Потоки данных для А1.1.3

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

Заключение

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

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

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

Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/project_charter/ , свободный. — Загл. с экрана

Литература

1. Тимофеев А.Н. Почему падают ИТ-проекты? //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/why-it-fails/, свободный. — Загл. с экрана
2. Duncan Haughey. Smart Goals //Project Smart.-2017. [электронный ресурс] — Режим доступа :https://www.projectsmart.co.uk/smart-goals.php, свободный. — Загл. с экрана

reqcenter.pro

Смотрите также

• 
  Реферат на тему арабские цифры
• 
  Реферат вегетарианство плюсы и минусы
• 
  Маркетинг как философия бизнеса реферат
• 
  Безопасность пищи и питания реферат
• 
  Реферат математические методы в юриспруденции
• 
  Содержательные теории мотивации реферат менеджмент
• 
  Реферат наблюдение за домашними животными
• 
  Правовые формы использования земель реферат
• 
  Реферат световое загрязнение окружающей среды
• 
  Реферат гражданская война в ливии
• 
  Наука как феномен культуры реферат