Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.
Устав проекта – это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками. Он разрабатывается в ходе инициации проекта – до решения о его начале.
Устав проекта определяет каркас проекта в 5 измерениях:
Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).
И хотя на этапе инициации проекта, пока не выполнено детальное планирование, точно определить потребность в ресурсах довольно сложно, вполне возможно выявить ограничения по ресурсам, которые придется учитывать при планировании.
Чтобы определить каркас проекта в этих измерениях необходимо:
На практике результаты выполнения этих задач могут фиксироваться в разных документах, таких как: договор, устав проекта, план управления рисками, техническое задание. Структура и объем каждого документа, а также распределение по ним этих данных определяется спецификой каждой компании и зависит от выбранной методологии и технологии управления проектами. При использовании современных технологий управления проектами эти документы не разрабатываются самостоятельно, а генерируются как отчеты на основе единой проектной базы, содержащей трассируемые данные по всем измерениям проекта.
Устав проекта может быть как внутренним документом, так и документом, согласуемым с внешними сторонами проекта, фактически выполняя роль контракта между заказчиком и исполнителем. Последний подход чаще используется зарубежом.
Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.
Рассмотрим подробнее эти задачи.
Для описания задач воспользуемся методологией функционального моделирования IDEF0.
Цель моделирования: показать основные этапы, необходимые для начала проекта, их взаимосвязь и результаты, приводящие к формированию отчетного документа «Устав проекта», а также определить основные требования к процессу разработки устава проекта и требования к содержанию устава проекта.
Точка зрения: Руководитель проекта.
Контекст: Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.
Допущения: Процесс подготовки и выполнения проекта итеративен и многие задачи часто выполняются в параллель, поэтому приведенное в модели разбиение на этапы отражает информационные зависимости между процессами, но не означает, что процессы всегда выполняются в такой последовательности.
На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.
Предполагается, что в организации есть корпоративный стандарт управления проектами, в котором определены основные правила ведения проектов. В этом случае в уставе проекта вводятся ссылки на данный стандарт и указываются только те данные, которые являются специфичными для выполняемого проекта. Если такого стандарта нет, это означает, что такие правила нужно определять каждый раз индивидуально для каждого проекта.
Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.
Разработка устава проекта (см. рис 2) является подготовительным этапом и по его результатам принимается решение об инициации проекта. Важность этого этапа сложно переоценить, т.к. от него зависит «быть или не быть» проекту. Кстати, те, кто пропускают этот этап в начале проекта, в итоге вынуждено возвращаются к этому вопросу позже, уже израсходовав некоторую часть ресурсов двух организаций.
Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.
Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта , нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.
При этом стоит помнить, что изменение ключевых ограничений проекта, отраженных в уставе, может существенно изменить картину по всем измерениям – начиная от требований, заканчивая сроками и бюджетом. Это может испугать неопытных руководителей и увести от проведения измений в явном виде. Однако суть от этого, конечно, не переменится – если изменения есть, их лучше зафиксировать и довести до участников проекта.
Введенные на первых двух диаграммах потоки, определены в таблице ниже.
Таблица 1. Потоки данных для А0-А1
| Имя потока | Определение потока |
| Данные проекта | * данные, дополнительные к исходным данным, которые были получены в ходе разработки устава проекта * |
| Исходные данные проекта | * любые исходные данные, полученные до организации проекта. Это могут быть требования заказчика, данные о предметной области проекта и др. * |
| Корпоративный стандарт УП | * стандарт предприятия, определяющий требования к процессам управления проектами. Может включать правила выполнения, детальное описание процессов, шаблоны документов. Степень детализации определяется в рамках каждого предприятия. Данный стандарт может являться частью стандартов СМК * |
| Корректировки | * предложения по изменению проекта * |
| План проекта | * оперативный план проекта с назначенными ресурсами, на основании которого выполняются работы * |
| Проектная база или редактор | * инструмент для разработки проекта, в зависимости от выбранной технологии управления проектом – документоориентированной или ориентированной на данные * |
| Результаты проекта | * все результаты, полученные в ходе выполнения проекта * |
| Руководитель проекта | * лицо со стороны исполнителя проекта, отвечающее за координацию и исполнение проекта * |
Прежде чем разбирать сам процесс необходимо познакомиться с определениями потоков данных:
Таблица 2. Потоки данных для А1.1
| Имя потока | Определение потока |
| Заинтересованные стороны | * стороны и лица, которые принимают решения или оказывают влияние на лиц, принимающих решения относительно хода проекта. Под сторонами подразумеваются организационные структуры, участвующие в проекте, под лицами — конкретные персоны, принадлежащие или нет данным организационным структурам. * |
| Критерии SMART | * требования к формулированию целей * |
| Критерии отсева проектов | * правила определения проектов, которые не должны браться в работу * |
| Орг-структура проекта | * организационная структура проекта * |
| Система целей проекта | * согласованная система целей проекта и ожиданий заинтересованных лиц, включающая измеряемые показатели и критерии достижения целей * |
| Стратегический план проекта | * включает основные этапы и результаты проекта, методы контроля хода проекта, риски проекта * |
| Правила детализации СП | * корпоративные правила детализации (декомпозиции) задач и результатов стратегического плана * |
| Правила взаимодействия | * корпоративные правила организации взаимодействия с заказчиком и внутри проекта, например, время отклика на запрос * |
| Правила оформления УП | * корпоративные правила оформления отчетного документа «Устав проекта» * |
Первоочередная задача подготовки и оценки проекта – понять и определить систему целей. Все цели проекта должны быть взаимоувязаны, даже те, которые невозможно зафиксировать в явной форме . Выявление и согласование целей – сложная задача, результаты которой определяют его успех или провал . Чаще всего она не решается «с наскока», а некоторые важные цели мимолетно всплывают и тонут в несущественных деталях, подменяясь на составляющие их подцели. Задача руководителя проекта – держать в фокусе максимально полную картину, начиная с самого верхнего уровня.
На диаграмме процесса A.1.1.1, раскрывающей процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников — сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.
Обычно цели проекта организуются в одну или несколько иерархий. Это означает, что для каждой цели верхнего уровня должны быть определены конкретные задачи, за счет выполнения которых предполагается достигнуть цели проекта. Например, если цель верхнего уровня — снизить затраты на изготовление продукции, то она может быть достигнута различными путями — снижением заработной платы, накладных расходов, автоматизацией производства и т.п., но это не значит, что в проекте будут использованы все способы, поэтому необходимо указать конкретные способы достижения цели, выбранные для данного проекта. Этот процесс также помогает оценить достижимость выбранной цели.
Хорошая практика формулирования целей заложена в принципах SMART . Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта. Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным .
Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли .
Таблица 3. Потоки данных для А1.1.1
Расширенный материал по формированию системы целей с иллюстрациями приведен в статье ?
После разработки системы целей возможно приступить к более детальному планированию, хотя на данном уровне оно все равно остается в рамках стратегического — описываются основные этапы проекта и их результаты. Фактически, это продолжение разработки иерархии целей. Теперь определяются конкретные задачи и их результаты, которые помогут их достичь. (см рис. 5)
Кроме этого необходимо определить события, которые могут воспрепятствовать достижению целей — риски проекта, а также методы, которые позволят отслеживать ход выполнения проекта, т.е. понимать, насколько мы близки к цели.
Риски проекта сильно влияют на его план и ресурсы, т.к. в нем[плане] должны быть предусмотрены меры по их предотвращению или хотя бы по снижению негативных последствий.
Еще один прием, позволяющийболее точно определить каркас проекта — это описание его границ. Границы описываются за счет указания целей и задач, которые не входят в проект. Таким образом, более точно определяется развитие проекта, которое будет считаться успешным.
Таблица 4. Потоки данных для А1.1.2
| Имя потока | Определение потока |
| Границы проекта | * цели, требования и задачи, не входящие в проект * |
| Задачи по предупреждению рисков | * задачи, которые необходимо учесть в плане работ, чтобы предупредить риски* |
| Методы контроля хода проекта | * процедуры определения состояния (хода) проекта, в т.ч. периоды отчетности, формы отчетности * |
| Риски проекта | * событие, наступление которого может привести к нарушению обязательств по проекту. Риск проекта описывается по следующей схеме: 1. Название — кратко отражает причину возникновения риска 2. Причина — полное описание причины возникновения риска 3. Возможное событие — событие, наступление которого возможно в следствие данной причины и которое может привести к нарушению обязательств по проекту 4. Результат — последствия наступления события для проекта 5. Предотвращение — меры по предотвращению причины события или самого события 6. Смягчение — меры по смягчению последствий наступления события Также необходимо указать статус и тип обработки. * |
| Этапы и результаты | * список или иерархия основных этапов проекта, а также результаты, которые должны быть получены на каждом этапе * |
После того, как стратегический план проекта разработан, можно переходить к формированию организационной структуры проекта. На данном этапе определяются участники проекта и их роли, определяется их область ответственности. Также устанавливаются официальные коммуникации проекта.
Орг-структура проекта должна соответствовать целям и задачам проекта. Плохо организованные люди способны завалить даже самый простой проект.
Таблица 5. Потоки данных для А1.1.3
Когда все элементы каркаса собраны, еще раз оценивается его жизнеспособность и реализуемость проекта.
Разработка устава проекта — это подготовительный этап, от результата которого зависит успех проекта. Структуру устава проекта хорошо использовать как справочник и чек-лист для оценки возможности успешно завершить проект. А вопросы, которые будут возникать в ходе разработки устава, позволяют на раннем этапе выявить и устранить конфликты и даже своевременно принять решение о закрытии проекта, если станет очевидным, что цели проекта недостижимы в текущих условиях.
Отношение к уставу проекта, как к простой формальности, отражает непрофессиональный взгляд на процессы управления проектами и вскрывает непонимание процессов, которые стоят за разработкой данного документа.
В рассмотренной схеме процессов показаны информационные связи между процессами. Выполнение процессов без их учета, хотя и часто встречается на практике, приводит к несогласованным результатам. В таких случаях необходимо проводить дополнительные итерации согласования результатов каждого этапа.
Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017.. - Загл. с экрана
Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.
Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:
Иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Хотя это не соответствует классической методологии, по которой устав готовится только для уже оцененного и утвержденного к реализации проекта.
Важно! Начинать работу по проекту без подписанного устава – это самая плохая услуга, которую можно оказать самому себе как руководителю проекта. Не определив и не согласовав цели и содержание того, что вы будете делать, вы рискуете очень быстро оказаться в ситуации, когда сроки прошли, бюджета закончился, сделано «не то и не там», а ваша карьера РМа в этой Компании бесславно закончилась. Более того, подписание устава у заинтересованных сторон – это отличный индикатор того, действительно ли они заинтересованные или просто делают вид. В случае, если проект спущен «сверху», Спонсор назначен, а Заказчик и сам не понимает, зачем ему это нужно – лучше постараться с этого проекта ноги унести, а если не получится – по крайней мере осознать, как не остаться в результате единственным виноватым за неуспех (об этом мы еще поговорим).
Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория – это хорошо, но не всегда понятно:
- Начальные условия – живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. Я заказала дизайн-проект, мне нарисовали квартиру моей мечты, осталось только сделать.
- Цель – сделать ремонт в квартире площадью 65 метров в строгом соответствии с дизайн-проектом не позже чем к такому-то числу и не больше чем за такие-то деньги.
- Содержание и результаты (Scope and deliverables) – на выходе должны быть полностью замененные коммуникации (сантехника, электрика, отопление), новая входная дверь, новая сантехника, косметический ремонт (плитка в санузле, ламинат, обои и потолки во всех комнатах), заказанная и установленная кухня, полностью все освещение и вся мебель. Что не буду делать: отдирать стяжку пола (что ей стало-то за 15 лет), делать теплые полы и звукоизоляцию, и менять окна (они хорошие, только 2 года назад поставила).
- Ключевые требования и характеристики – все должно быть в строгом соответствии с дизайн-проектом (см.пачку приложенных чертежей и смету), если что-то сделать нельзя или дороже больше чем на 10% – надо согласовывать на семейном совете. Разводку электрики и сантехники надо согласовать с местным ЖЭКом.
- Бюджет и сроки (Cost and Timelines) – 2 млн. рублей на все, включая мебель и кухню (30% на черновую отделку и коммуникации, 20% на чистовую, включая сантехнику, 20% на кухню и 30% на мебель). Срок – максимум 4 месяца, т.к. мы всего на 4 месяца договорились к родителям переехать, в крайнем случае можно добавить еще 2 недели (поживем в гостинице). Приоритеты бюджет-качество-сроки (лучше в гостинице поживем, пока штукатурка будет сохнуть, но денег на тепловую пушку для сушки не выделим и клеить обои на мокрую штукатурку тоже не будем).
- Ключевые участники (Key Stakeholders) – я, муж, родители, бригада, с которой я уже договорилась, соседи (надо уточнить, когда у них дети спят), ЖЭК (с ними надо проект согласовать).
- Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – допущения: соседи нескандальные, работать можно весь световой день, бригада адекватная и не будет бухать на объекте, курс доллара глобально не вырастет и стройматериалы сильно не подорожают; ограничения: нельзя работать после 22.00, не могу приезжать контролировать работу в будни (работаю), первая выплата бригаде возможна только в апреле (закончится депозит, где деньги на ремонт лежат); риски: возможно, ошибочно посчитана смета и денег на все не хватит, в дизайн-проекте ошибка, такую перепланировку узаконить нельзя, т.е. придется ремонт останавливать и все переделывать.
Ну и напоследок. Меня часто спрашивают, насколько детальным должен быть устав проекта? Точного рецепта здесь нет, но в общем случае – детализация устава проекта должна быть такой, чтобы в случае какого-то серьезного запроса на изменение в проекте вы могли обратиться к уставу как к истине в последней инстанции и сказать «нет, мы это не делает, т.к. это не приближает нас к цели проекта или противоречит характеристикам результата». По большому счету, если проект дошел до такого состояния, что запросы на изменение с уставом уже не «бьются» – похоже, ваш проект закончился неудачей и его лучше закрыть, требования и ограничения пересмотреть и начать новый.
Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).
Продолжаем серию материалов о том, что нужно предусмотреть и сделать до начала проекта, чтобы он оказался успешным. Сегодня наш эксперт Максим Якубович рассказывает, зачем и как составлять Устав проекта.
В трех предыдущих статьях серии «Что нужно сделать до старта проекта» я рассказал, что перед стартом необходимо:
Для старта проекта еще следует определить ключевые роли в нем (о том, что это за роли читайте ) и написать документ, в котором руководитель проекта и заказчик договариваются об общем видении начинания.
Документ, с которого проект стартует, называют Уставом проекта (или Паспортом проекта).
Устав проекта - это документ, с которого начинается проект и по которому происходит оценка его успешности.
Опытный руководитель прописывает его так, чтобы оговорить в нем все важные аспекты работы с заказчиком. На внешних проектах Устав не так важен, т.к. есть контракт, но, несмотря на это, некоторые руководители разрабатывают и его.
Для чего? Документ позволяет лучше понять важные аспекты проекта. Контракт обычно громоздкий и напичкан юридическими терминами, а Устав пишется на языке, понятном участникам проекта.
В популярном подходе к управлению проектами - PMBOK - в состав «Устава проекта» входят следующие разделы:
На своих проектах я часто использовал шаблон Устава, структура которого немного отличалась, от предложенной в PMBOK, но содержала все разделы, кроме списка заинтересованных сторон, описания сферы ответственности и уровня полномочий руководителя проекта (пример - ниже). Как правило, компания, которая идет по пути стандартизации проектной деятельности, разрабатывает шаблон Устава под специфику своей деятельности и этот шаблон используется для старта всех проектов.
Разработчики PMBOK считают, что в разработке документа должны участвовать спонсор, заказчик и руководитель проекта.
В тех проектах, которыми руководил я, Устав разрабатывал руководитель проекта, привлекая к его обсуждению технических специалистов и экспертов в предметной области. Предполагаю, что в некоторых компаниях он может разрабатываться спонсором, заказчиком, руководителем программы проектов или руководителем проектного офиса, а руководитель проекта является рецензентом этого документа и подписывает его.
Следует отметить, что Устав не является договором, но может дополнять его и служить внутренним документом для команды и заказчика.
В некоторых компаниях практика такова, что он становится документом после утверждения которого проект считается официально признанным в компании (это характерно для внутренних проектов, в которых заказчик и руководитель работают в одной компании).
Когда заказчик пытается изменить содержание проекта, добавляя новые цели или новые требования к результатам, руководитель проекта должен иметь возможность изменить Устав и заверить подписью заказчика новую версию. Таким образом, управляя версиями документа, руководитель защищает свой проект от расширения рамок без расширения сроков и бюджета.
При закрытии проекта именно Устав позволяет заказчику и руководителю подвести итоги проекта и определить степень его успешности.
Мой опыт внедрения Устава в четырех компаниях показал, что этот документ приживается легко и воспринимается то-менеджерами и акционерами как необходимый документ. А в некоторых компаниях его важность была настолько оценена, что внутренние заказчики и спонсоры с каждым новым проектом уделяли ему все больше внимания.
Для понимания структуры документа приведу пример Устава внедрения CRM-системы.
УСТАВ ПРОЕКТА
Автоматизация процессов CRM. Версия 1.0
Как видите, документ в приведенной выше форме получается достаточно компактным, но вместе с тем содержит важные разделы для согласования единого видения у заказчика и руководителя проекта. Приведенный шаблон Устава не единственно возможный вариант. Подумайте над структурой документа и доработайте ее для собственных проектов.
Мне кажется, что Устав очень важный документ для проекта. Он создается в интересах руководителя. Отсутствие этого документа лишает руководителя проекта возможности обращаться к заказчику в случае изменения договоренностей и снижает шансы завершить проект успешно.
После создания документа, руководитель проекта может приступить к разработке детального плана действий.
Правильный старт, на мой взгляд, не менее важен, чем четкий и понятный план проекта.
Максим Якубович
Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».
Опыт работы в сфере управления проектами - более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания - 10 лет. Около 2200 студентов, прошедших обучение на его семинарах.
Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий
1 УТВЕРЖДАЮ декабря 2012 г. УТВЕРЖДАЮ декабря 2012 г. Внедрение программного продукта Устав проекта На 20 стр. Утверждено Приказом от декабря 2012 г. Согласовано: ФИО Должность Подпись Дата Екатеринбург, 2012 г. 1
2 Содержание КРАТКОЕ РЕЗЮМЕ ДЛЯ РУКОВОДСТВА...3 ТЕРМИНОЛОГИЯ... 3 ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТЕ... 4 ТАБЛИЦА 1. ЦЕЛИ И КРИТЕРИИ УСПЕШНОСТИ ПРОЕКТА...4 ГРАНИЦЫ ПРОЕКТА...5 В ПРЕДЕЛАХ ГРАНИЦ ПРОЕКТА:... 5 ЗА ПРЕДЕЛАМИ ОБЪЕМА ПРОЕКТА:... 5 ВЫХОДНАЯ ПРОДУКЦИЯ (РЕЗУЛЬТАТЫ) ПРОЕКТА:...5 ТАБЛИЦА 2. ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ:... 6 ТАБЛИЦА 3. РАСЧЕТНАЯ СТОИМОСТЬ И ОТНОСИТЕЛЬНАЯ ОЦЕНКА:... 7 ТАБЛИЦА 4. РАСЧЕТНЫЙ ГРАФИК:... 7 ПРОЕКТНЫЕ ДОПУЩЕНИЯ... 8 ПОДХОД К РЕАЛИЗАЦИИ ПРОЕКТА...8 ОРГАНИЗАЦИЯ ПРОЕКТА...11 ТАБЛИЦА 5. УЧАСТНИКИ ПРОЕКТА, ИХ ФУНКЦИИ И ОТВЕТСТВЕННОСТЬ...11 ТАБЛИЦА 6. ЭКСПЕРТЫ РАБОЧИХ ГРУПП...15 УПРАВЛЕНИЕ ПРОЕКТОМ
3 Краткое резюме для руководства Настоящий документ описывает основные положения, процедуры управления и ограничения проекта по внедрению программного продукта: Терминология Заказчик компания Исполнитель компания Проект совместная инициатива Заказчика и Исполнителя по организации работ для достижения целей Проекта. Проектная команда совместная команда руководителей и специалистов для работы в проекте. Стороны Заказчик и Исполнитель. Список требований реестр функциональных и нефункциональных потребностей Заказчика, сформированный в проекте. История - элемент списка требований, который описывается стандартным шаблоном: Я как (роль) могу (действие) для того, чтобы (цель). Описание Истории также должно включать критерии принятия выполнения. История содержит: ID уникальный идентификатор просто порядковый номер. Название краткое описание истории. Важность степень важности данной задачи для Заказчика Например, 10. Или 150. Чем больше значение, тем выше важность. Оценка начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в Баллах. Критерии приемки краткое пояснение того, как завершенная задача будет продемонстрирована, протестирована и принята в конце спринта. По сути, это простой тестовый сценарий типа Сделайте это, сделайте то должно получиться то-то. Баллы - относительно значение, используемое для оценки Истории не связанное конкретно с часами или днями. Оценка проводится в рамках каждого этапа Итерация (Спринт) повторяющийся временной интервал в проекте, в ходе которой создается функциональный рост программного обеспечения и реализуются функциональные требования заказчика. Жестко фиксирован по времени. Длительность одного спринта в проекте принимается длительностью 1 неделя. Совещание по ошибкам/проблемам - встреча, проводимая в конце спринта, в ходе которой определяются сильные и слабые стороны команды проекта в прошедшем спринте, формируются новые знания о процессах реализации проекта. 3
4 Демонстрация - Встреча, обычно назначенная на конец текущего или начала следующего спринта, в ходе, которой члены команды демонстрируют прогресс за прошедший спринт. Общие сведения о проекте Автоматизация процессов управления с помощью Таблица 1. Цели и критерии успешности проекта Цель Критерий достижения цели (показатель) Лицо, утверждающее критерии успешности 1. 4
5 Границы проекта Проекта имеет следующие границы: В пределах границ проекта: Поставка согласованного количества пользовательских лицензий Системы. Развертывание Системы на аппаратном обеспечении Заказчика. Подготовка сред разработки и тестирования. Проведение анализа бизнес-процессов Заказчика. Настроенные типы документов и моделей для модуля. Подготовка документов и моделей процесса Обучение пользователей Заказчика принципам работы в системе. Настройка справочников. Настройка интеграции с внешними системами со стороны Подготовка пользовательских отчетов. Подготовка пользовательских инструкций. За пределами объема проекта: Приобретение аппаратного обеспечения для надлежащей работы Системы в соответствии с рекомендациями разработчика Системы. Подготовка рекомендаций по совершенствованию процессов Заказчика. Настройка системы на рабочих компьютерах пользователей Заказчика Выходная продукция (результаты) проекта: Выходной продукт (результат) 1: Выходной продукт 2: Выходной продукт 3: 5
6 Выходной продукт 4: Таблица 2. Заинтересованные стороны: Организация (подразделение) Каким образом затронуто / в каком качестве участвует? 6
7 Таблица 3. Расчетная стоимость и относительная оценка: Название этапа Сроки (начала-окончания) Стоимость (руб.) Оценка в Баллах Стоимость услуг составляет рублей. Относительная оценка трудозатрат составляет 317 Баллов. Стоимость неисключительных прав использования системы: Общая длительность проекта оценена в календарных месяца. Таблица 4. Расчетный график: Контрольная точка Дата завершения Выходная продукция (завершенная) 7
8 Проектные допущения Перечисленные ниже допущения являются предположениями, базирующимися на текущем понимании условий проекта и принятые для целей предварительной расчетной оценки задач и графика проекта. Если эти допущения в дальнейшем не подтвердятся, то работы и расчетные оценки проекта должны быть соответствующим образом пересмотрены. Допущение 1: Допущение 2: Допущение 3: Подход к реализации проекта Проект реализуется в соответствии со следующими принципами и положениями. В части «Администрирования»: В проекте назначается руководитель проекта со стороны Заказчика. В проекте назначается менеджер проекта со стороны Исполнителя. Представители руководства со стороны Заказчика и Исполнителя назначаются кураторами проекта. Менеджер проекта формирует проектную команду. Стороны ориентированы на создание мотивированной команды проекта. Основным документами проекта является График реализации проекта, Устав проекта и Список требований, который согласовывается между Сторонами. В части «Планирования и управления» объемом проекта: Перед его стартом этапа Стороны должны проводить планирование этапа и формировать критерии готовности и тестирования этапа. В планировании каждого этапа участвует соответствующая рабочая группа экспертов из предметных специалистов Заказчика В планировании участвуют: - от имени Исполнителя: все члены команды или ключевые лица, которые полностью уполномочены действовать от имени членов, которых они представляют; - от имени Заказчика: Руководитель проекта и сформированная рабочая группа экспертов для каждого этапа. Команда Исполнителя формирует Список требований из Историй, которые включают необходимый и желаемый функционал для реализации, полученный в результате интервьюирования экспертов; 8
9 Руководитель проекта для каждого этапа формирует приоритеты для Историй из Списка требований, которые включают необходимый и желаемый функционал для реализации; Наиболее важные Истории реализуются в первую очередь; Истории с высоким приоритетом должны содержать больше деталей, чем менее приоритетные. Поэтому Команда Исполнителя проводит детализацию приоритетных Историй совместно с членами рабочей группы и формирует критерии готовности Историй; Команда Исполнителя проводит оценку количества Баллов для каждой приоритезированной Истории, изложенной в Списке требований проекта; Планирование итерации перед каждой итерацией команда Исполнителя формирует план работ (какие Истории будут сделаны за этот спринт) на данную итерацию в соответствии с важностью из Списка требований на данный этап и цель итерации. Руководитель проекта со стороны Заказчика согласовывает план реализуемых Историй за итерацию и цель итерации. Общее количество Баллов для реализуемых Истории не должно превышать общее количество Баллов для всего проекта, указанное выше в разделе: «Расчетная стоимость и относительная оценка». Список требований по проекту: Содержит начальный список Историй вместе с начальным значением приоритета Истории; и начальным значением Баллов для каждой из этих Историй. Список требований никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные Истории. Список требований постоянно обновляется по ходу реализации проекта и уточнению требований. Заказчик должен назначить приоритет для Историй, которые формируют План этапа Команда проекта проводит постоянный анализ требований с целью проработки и уточнения требований для последующих итераций и этапов. Команда проводит оценку только проанализированных требований и готовых к реализации Историй. 9
10 В части «Реализации»: Проектная команда ориентирована на итерационную разработку проекта. Каждая итерация (спринт) содержит недельный объем работ. В части «Управления изменениями»: Заказчик может вносить поправки в Истории, которые входят в минимальный набор Историй этапа в любой момент во время этапа, без дополнительной оплаты, при следующих условиях: Заказчик не вносит изменения в Истории текущей Итерации, следуя согласованному плану Итерации; Новая История (Новые Истории) и/или вариации существующей Истории (Историй) могут быть введены, если существующая История (Истории) с эквивалентным числом Баллов удаляется или существующие Истории уменьшаются на эквивалентное число Баллов, так что общее число Баллов Этапа остается постоянным в течение проекта. В части критериев готовности и приемки: История должна считаться Завершенной и должна называться Завершенной Историей, когда следующие пункты применимы к Истории: Решение удовлетворяет Критериям приемки для этой Истории и успешно протестировано. Функции, включающие Историю, готовы к эксплуатации: 1. Функционал, описанный в Истории доступен на рабочем сервере Заказчика. 2. Функционал доступен на рабочих местах сотрудников Заказчика, которые являются пользователями данного функционала. 3. Функционал протестирован пользователями данного функционала. Руководители проекта подписали Акт тестирования Истории/Историй. Подведение итогов тестирования Историй еженедельно на Демонстрации новых реализованных историй. В части мониторинга прогресса проекта: Прогресс проекта руководители проекта оценивают на регулярных совещаниях проектной команды (Демонстрация), которые проходят один раз в неделю в конце итераций по пятницам. Прогресс проекта оценивается по «Завершенным» историям. На демонстрации должны присутствовать: от имени Исполнителя: все члены команды; и от имени Заказчика: Руководитель проекта и эксперты из рабочей группы по данному этапу. 10
11 Стороны должны проводить Совещание по ошибкам/проблемам для каждой Итерации, вслед за завершением Демонстрации для этой Итерации. На Ретроспективе должны присутствовать: от имени Исполнителя: все члены команды; и от имени Заказчика: Руководитель проекта и Куратор проекта. Стороны должны обсудить, как и почему не были достигнуты (если применимо) любые из целей, какие есть проблемы по реализации проекта; стороны должны рассмотреть области улучшения и разработать список действий для исправления этих областей в следующей Итерации и/или Этапе (в соответствующих случаях). Организация проекта Приведенный ниже список участников и заинтересованных сторон описывает организацию данного проекта: Таблица 5. Участники проекта, их функции и ответственность Роль Ф.И.О. Функции и ответственность Обеспечивает финансирование проекта Определяет генеральные цели проекта и критерии успеха. Основные функции: Инициатор проекта Куратор проекта со стороны Заказчика Утверждение целей и критериев успешности проекта; Принятие решения о начале проекта и о завершении проекта (в связи с достижением целей либо о досрочном завершении проекта); Подписывает акты сдачи-приемки услуг со стороны Заказчика; Оказывает поддержку руководителю проекта при решении вопросов, выходящих за пределы компетенции руководителя проекта. Разрешает ресурсные конфликты и утверждает, при необходимости, приоритеты задач проекта. Основные функции: Принятие промежуточных и итоговых результатов этапов проекта (визирование актов сдачи-приемки услуг со стороны Заказчика); Общие функции контроля выполнения проекта. 11
12 Роль Ф.И.О. Функции и ответственность Общее руководство проектом составление плана этапов, согласование плана Итераций и целей итераций, предоставление ресурсов, контроль за реализацией согласованного объема работ, контроль выполнения проекта в рамках бюджета и сроков, прямая ответственность за достижение результатов проекта. Основные функции: Определяет видение проекта; Утверждает план этапов проекта; Отвечает за формирование Списка требований; Отвечает за приоритезацию реализуемых требований; Контроль, обоснование и документирование любых изменений требований Заказчика к результатам проекта; «Единый голос» со стороны Заказчика по Управлению изменениями в Списке требований; Руководител ь проекта со стороны Заказчика Управление графиком встреч специалистов Исполнителя со специалистами Заказчика; Доступность для команды проекта на уровне 100%; Ответственность за предоставление запрошенной специалистами Исполнителя у специалистов Заказчика информации (документы, копии баз данных, удаленный доступ к информационным ресурсам и т.д.); Тестирование функций Системы; Ведение пользователей Системы; Подведение итогов по отдельным этапам проекта и по проекту в целом; Принятие результатов итераций и этапов проекта (визирование актов сдачи-приемки услуг со стороны Заказчика); Разрешение конфликтов в ходе выполнения проектов, в случае их возникновения; Мотивирование экспертов рабочих групп Заказчика; Информирование Инициатора и Куратора проекта о ходе выполнения работ. 12
13 Роль Ф.И.О. Функции и ответственность Эксперт см. Таблицу 6. Роль эксперта в бизнес-процессах Заказчика. групп» рабочей «Эксперты группы рабочих Основные функции: Участие в обследовании бизнес-процессов, предоставление исходных данных. Изучение функций Системы; Тестирование функций Системы; Ввод информации в Систему; Участие в Демонстрации завершенных Историй Куратор проекта со стороны Исполнителя Обеспечивает достижение целей проекта и критериев успеха. Основные функции: Подписывает акты сдачи-приемки услуг со стороны Исполнителя; Инициирует изменений, усиливающих продуктивность команды; Устраняет проблемы, которые возникают в процессе работы команды проекта; При необходимости проводит мероприятия в рамках проекта; Осуществляет долгосрочное планирование по проекту. 13
14 Роль Ф.И.О. Функции и ответственность Руководител ь проекта Общее руководство проектом составление плана этапов, согласование плана Итераций и целей итераций, со стороны предоставление ресурсов, контроль за реализацией Исполнителя согласованного объема работ, прямая ответственность за достижение результатов проекта. Основные функции: Утверждает план этапов проекта; Отвечает за формирование Списка требований; Контроль, обоснование и документирование любых изменений требований Заказчика к результатам проекта; «Единый голос» со стороны Исполнителя по Управлению изменениями в Списке требований; Управление графиком встреч специалистов Исполнителя со специалистами Заказчика; Доступность для команды проекта на уровне 100% (гарантированная доступность руководителя проекта критерий успеха проекта); Подведение итогов по отдельным этапам проекта и по проекту в целом; Принятие результатов итераций и этапов проекта (визирование актов сдачи-приемки услуг со стороны Заказчика); Разрешение конфликтов в ходе выполнения проектов, в случае их возникновения; Мотивирование бизнес-аналитиков рабочих групп Исполнителя; Менеджер проекта Москалев М.В. Информирование Инициатора и Куратора проекта о ходе выполнения работ. Обеспечивает коммуникации между Заказчиком и Исполнителем; Контроль и администрирование договорных отношений (формирование актов по работам, счетов и контроль оплаты). 14
15 Роль Ф.И.О. Функции и ответственность Бизнесаналитики со стороны Исполнителя Эксперты по системе. Основные функции: Участие в обследовании бизнес-процессов; Настройка системы; Тестирование функционала; Обучение пользователей, подготовка инструкций. Таблица 6. Эксперты рабочих групп Рабочая группа, эксперт Рабочая группа этапа Рабочая группа этапа 15
16 Рабочая группа, эксперт Рабочая группа этапа
17 Управление проектом Коммуникации между участниками проекта. Коммуникации между участниками проекта будут осуществляться: на регулярных встречах рабочих групп для формирования и анализа требований и планированию этапов; на еженедельных встречах по планированию итераций; на еженедельных встречах по демонстрации результатов итераций (Демонстрация). На еженедельных встречах Исполнителем предоставляется отчетность по выполненным Историям. на еженедельных встречах по выявлению проблем и отклонений по проекту (формируется протокол по проблемам и отклонениям). В конце каждого месяца Руководитель проекта со стороны исполнителя представляет Отчет о работе за месяц и согласовывает с Руководителем проекта со стороны Заказчика График реализации проекта. дополнительные каналы для обмена информацией: электронная почта, телефон, бумажные носители информации, Skype. Внесение изменений в Устав проекта. Внесение изменений в Устав проекта может инициировать любой член проектной команды. Руководитель проекта рассматривает данное предложение в течение 3-х дней, затем принимает решение об отклонении либо вынесении предложения на согласование с руководителем проекта с другой стороны. Внесение изменений в проект осуществляется по согласованию сторон с оформлением рабочего протокола и заполнения листа изменений. В случае успешного согласования предложения между руководителями проекта обеих сторон предложение вносится в Устав проекта в согласованной редакции. После внесения изменений в Устав ему присваивается следующий по порядку номер версии и дата новой редакции, после чего изменения считаются вступившими в силу. Новая версия Устава подписывается заинтересованными сторонами проекта. 17
18 Изменения функциональных требований Внесение изменений в Список требований проекта осуществляется по согласованию сторон в любой момент во время этапа, без дополнительной оплаты, при следующих условиях: Заказчик не вносит изменения в Истории текущей Итерации, следуя согласованному плану Итерации; Новая История (Новые Истории) и/или вариации существующей Истории (Историй) могут быть введены, если существующая История (Истории) с эквивалентным числом Баллов удаляется или существующие Истории уменьшаются на эквивалентное число Баллов, так что общее число Баллов по Этапу остается постоянным в течение проекта. Процедура разрешения противоречий Все замечания фиксируются в письменном виде и высылаются руководителю проекта со стороны Исполнителя. Риски проекта В ходе выполнения проекта могут возникнуть следующие потенциальные проблемы, которые проектная команда планирует минимизировать либо исключить. Риски Метод минимизации/устранения 18
19 История изменений Версия Дата Автор(ы) Краткое описание изменений 19
Дата: 4 марта 2015 г. Номер страницы: 1 ООО «ЗАКАЗЧИК» 14 УСТАВ ПРОЕКТА Проект Замена летней резины на автомобиле (наименование проекта) Подготовлен: «20.03.2015» Дата: Вид документации: Проектная документация
Методика внедрения системы КУБ Москва 2016 г. Оглавление Введение... 5 Цели документа... 5 Задачи документа... 5 Глоссарий... 6 Термины и определения... 6 Роли в документе... 7 Цели и задачи проекта внедрения...
ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ П О С Т А Н О В Л Е Н И Е от 15 октября 2016 г. 1050 МОСКВА Об организации проектной деятельности в Правительстве Российской Федерации В соответствии с пунктом 5 Указа
Открытое акционерное общество «Татнефть» имени В.Д. Шашина Во исполнении п. 4 протокола еженедельной планерки генерального директора от 08.12.2014г. 42/56-ПтПл Инструкция по управлению проектами Альметьевск
Андрей Петров «Богданов и партнеры» Корпоративный стандарт системы управления Создание КСУП НАЗНАЧЕНИЕ КСУП КСУП - свод информации о процессах, процедурах, методах и инструментах управления предприятия,
Эффективное взаимодействие с Заказчиком в проекте внедрения комплексной системы управления. Ирина Абрамова, старший менеджер, МАГ КОНСАЛТИНГ План презентации О проекте (цели, задачи,) Команды проекта
ПОРЯДОК выполнения процедур технического сопровождения, планирования и учета исполнения задач по развитию Программы для ЭВМ «Госзакупки» (АИС «Госзакупки») Применяемые понятия и определения: Плановая доработка:
ДЕПАРТАМЕНТ ПРОЕКТНОГО УПРАВЛЕНИЯ ХАНТЫ-МАНСИЙСКОГО АВТОНОМНОГО ОКРУГА - ЮГРЫ ПРИКАЗ О порядке инициации проектов г. Ханты-Мансийск 20 г. -нп В соответствии с пунктами 5.2, 5.4 Положения о системе управления
Утверждены Проектным офисом Правительства Российской Федерации 7 ноября 2016 г. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ по реализации первоочередных мероприятий в части организации проектной деятельности в федеральных
ОТКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО «РОССИЙСКИЙ СЕЛЬСКОХОЗЯЙСТВЕННЫЙ БАНК» (ОАО «РОССЕЛЬХОЗБАНК») В редакции решений Наблюдательного совета ОАО «Россельхозбанк» (протокол от 10.02.2012 4, протокол от 25.10.2012
1 РЕЗЮМЕ ПРАКТИКИ 1.1 Область специализации Информационные системы в управлении проектами в государственном секторе. Отрасли: Строительство, Транспорт, Электроэнергетика, Промышленность, Потребительский
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И ГОСТ Р 54871 2011 Проектный менеджмент ТРЕБОВАНИЯ К УПРАВЛЕНИЮ
Подробнее об услуге «Коробочное внедрение ИСУП» на базе MS Project Server 2007 Общая архитектура решения Ядром ИСУП, реализующим основную функциональность по управлению проектами, служат следующие модули:
Планирование Исполнение Контроль и анализ Принятие решения Управление проектами Информационные технологии ТЕХНОЛОГИЯ КОРПОРАТИВНОГО ВНЕДРЕНИЯ: РОЛИ, ФАЗЫ ЖИЗНЕННОГО ЦИКЛА, РИСКИ И ПЕРИОДИЧЕСКИЕ МЕРОПРИЯТИЯ
МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ (МИНКОМСВЯЗЬ РОССИИ) ПРИКАЗ Москва Об утверждении методических рекомендаций по организации системы проектного управления мероприятиями по
Дата текущей редакции: Стр. 1 из 14 УТВЕРЖДАЮ Генеральный директор 200_ г. Москва 200_ г. Дата текущей редакции: Стр. 2 из 14 Лист согласования Должность Подпись Дата ФИО Согласовано: Разработчики: Дата
Устав проекта Название проекта Информация о документе Дата документа Версия документа Статус документа Ответственный История изменений Дата Автор Примечание Содержание Содержание...
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И ГОСТ Р 54869 2011 Проектный менеджмент ТРЕБОВАНИЯ К УПРАВЛЕНИЮ
Опыт внедрения SAP GRC Process Control в ОАО «МегаФон» и тиражирование в ОАО «МегаФон Ритейл» Илья Губарев Руководитель по развитию корпоративных систем ОАО «МегаФон» МегаФон сегодня лидер в области передачи
О Порядке разработки и реализации муниципальных программ городского округа Новокуйбышевск Самарской области В целях обеспечения эффективной организации процесса разработки и реализации муниципальных программ
Применение Business Studio в проектах автоматизации Виктор Волонтей Управляющий партнер, руководитель компании «Правила бизнеса» (Беларусь, Минск) [email protected] [email protected] www.prabiz.by План мастер-класса
Номер страницы: 1 14 УСТАВ ПРОЕКТА ГАЗИФИКАЦИЯ Проект Газификация загородной квартиры (наименование проекта) Подготовлен: «Машутин В.С.» Дата: 22 марта 2015 г. Газификация квартиры Вид документации: Проектная
МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ» УТВЕРЖДАЮ Ректор
ПМ ФОРСАЙТ Расширенное календарное планирование ГК «Проектная ПРАКТИКА» www.pmforesight.ru Программно-методический комплекс ФОРСАЙТ КСУП Корпоративная система управления проектами, включающая информационную
Приложение к Решению Комиссии Таможенного союза от 15 июля 2011 г. 715 Проект ПОЛОЖЕНИЕ о порядке взаимодействия Сторон при разработке проектной документации, сдаче-приемке и модернизации программно-аппаратных
З Приложение 1 к Регламенту «Порядок планирования» Форма УП-8План 5 О выполнении контрольной точки 6 Отчет о выполнении блока работ 7 Инициативная заявка на внесение изменений 8 Мониторинг
Содержание Предисловие 13 Благодарности 14 Введение 15 Часть I. Приступаем к работе 19 Глава 1. Общий обзор 21 Что такое пользовательская история 22 Где описывать детали 23 На скольких страницах я должен
1 Основы управления ИТ проектами. Лекция 1. Термин "ИТ-проект" обычно используется для обозначения деятельности, связанной с использованием или созданием некоторой информационной технологии. Это приводит
1 РЕЗЮМЕ ПРАКТИКИ 1.1 Область специализации Информационные системы в управлении проектной деятельностью в государственном секторе. Отрасли: Строительство, Транспорт, Электроэнергетика, Промышленность,
СТО 003-2016 Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования ИРКУТСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТЕХНИЧЕСКИЙ
Приложение 1 Требования к ИСУП «Аэроэкспресс» Состав требований: 1. Требования к автоматизации основных сценариев управления проектом 1 2. Требования к автоматизации основных сценариев управления Портфелем
Администрация Ненецкого автономного округа ПОСТАНОВЛЕНИЕ от 12 мая 2015 г. 145-п г. Нарьян-Мар О региональной информационной системе в сфере закупок товаров, работ, услуг для обеспечения нужд Ненецкого
Проектами с применением MS Project в решениях ГК «Проектная ПРАКТИКА» ГК «Проектная ПРАКТИКА» О чем будем говорить? Комплексная задача внедрения системы управления проектами Решения и практики по автоматизации
«УТВЕРЖДАЮ» «УТВЕРЖДАЮ» Старший вице-президент Флорентьева М.В 20 г. 20 г. БИЗНЕС-ТРЕБОВАНИЯ (BRD) НА РАСЧЕТ ПОКАЗАТЕЛЕЙ ПРЕДМЕТНОЙ ОБЛАСТИ «NNN» ДЛЯ ЕДИНОГО КОРПОРАТИВНОГО ХРАНИЛИЩА ДАННЫХ (ЕКХД) ПАО
ПОЛОЖЕНИЕ О КОМИССИИ ПО ОЦЕНКЕ ЭФФЕКТИВНОСТИ ДЕЯТЕЛЬНОСТИ РАБОТНИКОВ ФГБОУ ВО «НИЖНЕВАРТОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Принято решением Учёного совета от 27 апреля 2015 г., протокол 14 Нижневартовск
Проектный офис Аутсорсинг. Запуск. Аудит. 2014 СОДЕРЖАНИЕ 1. Клиент: кому нужна помощь в развертывании проектых офисов и аутсорсинге специалистов 2. История: где это применялось 3. Продукт: что внутри
Бизнес-требования к проекту построения службы Data Helpdesk стр. 1 из 14 Содержание 1. Цели и задачи проекта... 3 1.1 Описание предпосылок и целей проекта... 3 1.2 Связь целей проекта с ИТ-стратегией Компании...
МУНИЦИПАЛЬНОЕ ОБРАЗОВАНИЕ ГОРОДСКОЙ ОКРУГ ГОРОД СУРГУТ ДУМА ГОРОДА СУРГУТА РЕШЕНИЕ Принято на заседании Думы 23 марта 2017 года 77-VI ДГ Об утверждении Порядка организации и проведения публичных слушаний
Техническое задание по автоматизации проектной деятельности Структура документа 1. Термины и определения. 2. Документы, использованные при создании технического задания 3. Общие сведения 4. Функциональные
СЭД 3 в минимальной поставке подразумевает поставку 50 х лицензий и 1 лицензии на систему потокового сканирования. Указанные цены могут быть изменены в 2016 году в зависимости от складывающейся экономической
Ппиложение 2 Технические решения на выполнение работ по внедрению Информационной системы управления проектами для нужд ООО «Аэроэкспресс» 1. Технологический подход 1.1. Программное обеспечение ИСУП. 1.2.
Заключительные этапы осуществления реформы электронных закупок в Армении www.ppi-ebrd-uncitral.com Запуск системы электронных закупок (eprocurement) ARMEPS армянская система электронных закупок www.armeps.am
Развернуть закупочное решение SAP за несколько недель - невероятно, но это факт! Дмитрий Иванов, руководитель направления ARIBA НОРБИТ И SAP НАДЕЖНЫЕ ПАРТНЕРЫ В РОССИИ И СНГ Компания НОРБИТ официальный
Гибкий подход к разработке OSS для крупного заказчика Уживутся ли Agile и крупный традиционный телекоммуникационный бизнес Александр Атцик, руководитель отдела развития Как мы предлагаем заказчику наше
ТВЕРСКАЯ ОБЛАСТЬ Правильная фокусировка проекта информатизации здравоохранения Тверской области Алексей Важнов Начальник Главного управления информационных технологий и связи Тверской области Выбор концепции
Управление человеческими ресурсами проекта Эффективное использование трудовых ресурсов одна из ключевых задач для компаний, которые занимаются проектированием, разработкой ПО, оказанием профессиональных
УТВЕРЖДАЮ Директор ГОБУ СПО «ЛОККиИ» 2014г. Н. А. Вартанян Комитет по культуре Ленинградской области Государственное образовательное бюджетное учреждение среднего профессионального учреждения «Ленинградский
Ключевые требования к информационной системе управления бизнесом для проектной компании Данный документ определяет состав ключевых бизнес-процессов для проектной компании с целью формирования требований
Инновация в образовании нововведение, влияющее на образование как социокультурную ценность, область деятельности, процесс и результат; инновационная деятельность это деятельность, ориентированная на качественное
Управление содержанием проекта ОПРЕДЕЛЕНИЕ Процессы, обеспечивающие включение в проект тех и только тех работ, которые необходимы для успешного завершения проекта. Качество Содержание 1. Сбор требований
УТВЕРЖДЕНО решением Совета директоров акционерного общества «Национальная компания «Қазақстан темір жолы» от «12» декабря 2011 г. протокол 7 Положение «О Корпоративном секретаре акционерного общества «Национальная
Обеспечение защиты информации на стадиях жизненного цикла при разработке информационных систем. Горбачев Евгений Васильевич Заместитель начальника управления ИБ начальник отдела защиты ИС апрель 2015 г.
Система организационно-распорядительного документооборота предприятия Описание функциональности Санкт-Петербург 2013 Содержание Общее описание «ОРД для SharePoint»... 3 ОРД... 4 Входящий документ... 4
СТРАТЕГИЯ. МЕТОДОЛОГИЯ И ПРОЦЕСС ПРОЕКТНЫЙ ОФИС КАК ЦЕНТР УПРАВЛЕНИЯ КОММУНИКАЦИЯМИ В статье рассматривается новая организационная структура проектного офиса как центра управления коммуникациями инвестиционного.
ПОРЯДОК ВНЕДРЕНИЯ ПРОЕКТНОГО УПРАВЛЕНИЯ В ОРГАНАХ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ ДОРОЖНАЯ КАРТА СТАРТ И ОРГАНИЗАЦИЯ РАБОТ Методические рекомендации по внедрению проектного управления в органах исполнительной власти
Постановление Правительства РФ от 02.08.2010 N 588 "Об утверждении Порядка разработки, реализации и оценки эффективности государственных программ Российской Федерации" ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Дата текущей редакции: Стр. 1 из 8 УТВЕРЖДАЮ Генеральный директор Компании 200_ г. Москва 200_ г. Дата текущей редакции: Стр. 2 из 8 Лист согласования Должность Подпись Дата ФИО Согласовано: Разработчики:
Новые порядки в порядочном банке или история внедрения одной КСУП Докладчик: Елена Копылова Начальник Офиса управления проектами ОАО «АИКБ «Татфондбанк», PMP Декабрь, 2014 г. слайд 1 Татфондбанк Татфондбанк
УЧРЕЖДЕНИЕ ВЫСШЕГО О ОБРАЗОВАНИЯ Лист 1 из 10 УТВЕРЖДАЮ Декан художественнотехнологического факультета Васильев А.А. «16» ноября 2015 г. ОЦЕНОЧНЫЕ СРЕДСТВА ПО ДИСЦИПЛИНЕ Б2.В.ДВ.1.1 Организация проектной
Муниципальное предприятие «Ханты-Мансийскгаз» Муниципального образования город Ханты-Мансийск Директор А.В. Лоцманов 2011г. ПОЛОЖЕНИЕ о Единой комиссии по размещению заказов г. Ханты-Мансийск 2011 СОДЕРЖАНИЕ
Игорь АШМЕТКОВ, заместитель начальника Управления разработки информационных систем ОАО Банк ВТБ, кандидат физико-математических наук Сергей ПАЗИЗИН, руководитель группы защиты автоматизированных банковских
Утверждаю Заместитель Директора по информационным технологиям В.А. Коротков ИЗВЕЩЕНИЕ О ПРОВЕДЕНИИ ЗАПРОСА КОТИРОВОК К157-09-13/Структура баз данных (НИУ) г. Москва «19» сентября 2013 г. 1. Заказчик: федеральное
Октябрь Октябрь 2014 г Сценарий работы с модулем Заявка на открытие счета РКО (SugarCRM версия 6) HARDSOFT321.ORG Оглавление 1. Предварительные установки.... 3 2. Создание Заявки на открытие счета в системе....
Страница стр. 2 из 9 1 НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ Настоящее положение устанавливает порядок и правила организации и осуществления образовательной деятельности по дополнительным профессиональным программам
«УТВЕРЖДАЮ» Директор ГАОУ ЦО 548 «Царицыно» /Е.Л. Рачевский/ «18» сентября 2012 г. ВРЕМЕННОЕ ПОЛОЖЕНИЕ об электронном классном журнале ГАОУ ЦО 548 «Царицыно» 1. Общие положения 1.1. Электронный классный
Содержание 1. Термины и определения 2. Общие положения 3. Инициирование процедуры закупки 4. Подготовка, утверждение, размещение извещения и документации о закупке 5. Внесение изменений в извещение и документацию
Положение о взаимодействии комитета Ставропольского края по государственному заказу и заказчиков Ставропольского края ГУБЕРНАТОР СТАВРОПОЛЬСКОГО КРАЯ ПОСТАНОВЛЕНИЕ от 8 июня 2006 г. N 342 О НЕКОТОРЫХ МЕРАХ
Устав проекта является наиболее важным и первичным документом. Проект можно считать открытым с момента составления и утверждения его устава. В связи с чем разработка этого документа является очень важным элементом проектирования с целью получения выгоды уже в обозримом будущем.
Таким образом, под уставом понимают первичный документ, характеризующий основные базовые требования и будущие ожидания всех заинтересованных сторон.
Его назначение можно кратко выразить в следующих тезисах:
Рассмотрим процесс разработки устава проекта (пример может дополняться и изменяться) поэтапно более подробно.
1 этап: Описание работы . Данный этап включает в себя создание характеристик всех планируемых товаров, услуг, установленных бизнес-проектом.
На данном этапе в уставе должны быть отражены следующие показатели:
2 этап: Составление бизнес-кейса. Предполагается формирование всей необходимой информации, которая позволяет оценить стоит ли в целом данный проект реализовывать.
В бизнес-кейсе устава следует описать следующие моменты:
3 этап: Формирование соглашений по проекту. Подразумевает характеристику первоначальных намерений в отношении проекта в виде договоров и аналогичных письменных документов.
4 этап: Исследование факторов среды предприятия. Подразумевает определение списка возможных факторов, которые могут оказать влияние на проект. Среди таких факторов установлены:
5 этап: Исследование активов процессов организации. Имеется в виду анализ следующих явлений:
Основные методы разработки устава можно классифицировать следующим образом:
Таким образом, на основании представленных выше этапов и при использовании указанных методов, в конечном счете формируется устав. Он представляет собой разработанный документ, который выпускается инициатором проекта и позволяет исполнителю использовать аккумулированные ресурсы.
В нем задокументированы бизнес-потребности, допущения, ограничения, исходная информация, требования и результаты проекта.
Пример разработки устава проекта представлен ниже в виде списка разделов:
Пример заполнения устава проекта представлен ниже.
Введение.
Раздел 1. Обоснование проекта.
Раздел 2. Сущность проекта.
Прочие допущения и ограничения.
Раздел 3. Орг. структура проекта.
Раздел 4. Права и обязанности.
Пример устава проекта по строительству представлен ниже.
Проект «Строительство детского сада».
Введение.
Раздел 1. Назначение документа.
Раздел 2. Профиль компании.
Раздел 3. Основные цели.
Раздел 4. Проектные документы.
Раздел 5. Организационная структура.
Раздел 6. Допущения.
Раздел 7. Ограничения.
Раздел 8. Риски.
Заключение.
Пример устава проекта по салону красоты представлен ниже.
Проект «Создание салона красоты «Василинка».
Введение.
Заключение.
Пример устава проекта по ремонту квартиры представлен ниже.
Проект «Ремонт новой квартиры ЖК «Зенит».
Введение.
Раздел 1. Разработка дизайнерского проекта.
Раздел 2. Смета расходов.
Раздел 3. Наем работников.
Раздел 4. Закупка стройматериалов.
Раздел 5. Организация работ.
Раздел 6. Итоговые работы.
Заключение.
Таким образом, можно сделать вывод о том, что устав является основополагающим документом при разработке бизнес-плана компании. В нем указываются все основные его характеристики, допущения и ограничения. От того, насколько логично и правильно выстроен устав, зависит продвижение среди спонсоров, кредиторов и исполнителей. Это в конечном счете оказывает влияние на финансовый результат и способствует достижению целей проекта.
