Устав проекта разрабатывается. Устав проекта: введение

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

Понятие и назначение

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

Его назначение можно кратко выразить в следующих тезисах:

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

Разработка устава поэтапно

Рассмотрим процесс разработки устава проекта (пример может дополняться и изменяться) поэтапно более подробно.

1 этап: Описание работы . Данный этап включает в себя создание характеристик всех планируемых товаров, услуг, установленных бизнес-проектом.

На данном этапе в уставе должны быть отражены следующие показатели:

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

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

В бизнес-кейсе устава следует описать следующие моменты:

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

3 этап: Формирование соглашений по проекту. Подразумевает характеристику первоначальных намерений в отношении проекта в виде договоров и аналогичных письменных документов.

4 этап: Исследование факторов среды предприятия. Подразумевает определение списка возможных факторов, которые могут оказать влияние на проект. Среди таких факторов установлены:

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

5 этап: Исследование активов процессов организации. Имеется в виду анализ следующих явлений:

• бизнес-процессы компании;
• установленные шаблоны документов компании;
• база накопленных данных.

Методы разработки устава

Основные методы разработки устава можно классифицировать следующим образом:

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

Состав устава проекта

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

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

Пример разработки устава проекта представлен ниже в виде списка разделов:

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

Как составить устав проекта на конкретном примере

Пример заполнения устава проекта представлен ниже.

Введение.

Раздел 1. Обоснование проекта.

• Краткая характеристика.
• Основные цели и задачи.
• Критерии успеха.
• Связи и зависимости.

Раздел 2. Сущность проекта.

• Результаты.
• Критерии приемки результатов.
• Исключения.
• Время и стоимость.

Прочие допущения и ограничения.

Раздел 3. Орг. структура проекта.

• Управление.
• Руководство.
• Команда.

Раздел 4. Права и обязанности.

• Права и обязанности со стороны руководителя.
• Права и обязанности соуправляющего комитета.
• Права и обязанности членов команды.

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

Как заполняются уставы строительных проектов

Пример устава проекта по строительству представлен ниже.

Проект «Строительство детского сада».

Введение.

Раздел 1. Назначение документа.

Раздел 2. Профиль компании.

• Контактные лица.
• Сфера деятельности.
• Основные сотрудники.

Раздел 3. Основные цели.

• Миссия компании заказчика.
• Бизнес-цели заказчика.
• Цели и критерии достижения.
• Границы.

Раздел 4. Проектные документы.

• Документы по управлению проектом.
• Техническая документация.
• Даты проекта и контрольные точки.
• Матрица гибкости заказчика.

Раздел 5. Организационная структура.

• Команда.
• Оргструктура.
• Процедуры.

Раздел 6. Допущения.

• Внешние факторы макросреды.
• Активы заказчика.
• Сроки.

Раздел 7. Ограничения.

• Бюджет.

Раздел 8. Риски.

• Структура рисков.
• Методы борьбы с рисками.

Заключение.

Как заполняются уставы проектов по услугам

Пример устава проекта по салону красоты представлен ниже.

Проект «Создание салона красоты «Василинка».

Введение.

1. Концепция.
2. Общая стоимость.
3. Основные финансовые показатели.
4. Юридические аспекты.
5. Маркетинговые мероприятия.
6. Производственный план.
7. Организационный план.
8. Риски.

Заключение.

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

Пример устава проекта по ремонту квартиры представлен ниже.

Проект «Ремонт новой квартиры ЖК «Зенит».

Введение.

Раздел 1. Разработка дизайнерского проекта.

Раздел 2. Смета расходов.

Раздел 3. Наем работников.

Раздел 4. Закупка стройматериалов.

Раздел 5. Организация работ.

Раздел 6. Итоговые работы.

Заключение.

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

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

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

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

Таблица 1.4. Матрица структурирования выгод ИТ-проекта (адаптировано из )

		ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС
		Создание новых возможностей	Повышение эффективности операций	Отказ от операций
СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ	Финансовые
	Количественные
	Измеримые
	Качественные

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

1. Качественные : выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.
2. Измеримые :выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
3. Количественные :аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
4. Финансовые :это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR , периода окупаемости.

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

Формирование бизнес-цели проекта

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

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

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

Разработка устава проекта

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

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

• стратегические и тактические цели организации-заказчика;
• формулировка требований организации-заказчика;
• ТЭО ;
• контракт;
• внутрикорпоративная методология управления проектами и соответствующие политики.

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

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

Таблица 1.5. Требования к уставу проекта

№	Раздел	Пояснения
1 .	Название проекта	Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
2 .	Бизнес-причина возникновения проекта	Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
3 .	Бизнес-цель	Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта "
4 .	Требования , удовлетворяющие потребности , пожелания и ожидания заказчика , спонсора и других участников проекта	Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
5 .	Расписание основных контрольных событий	На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта , принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств
6 .	Участники проекта	Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта"
7 .	Окружение проекта	Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта ; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения)
8 .	Допущения относительно организации и окружения, а также внешние допущения	Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений: o компетенции команды проекта достаточно для выполнения предпроектного обследования; o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта . Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе
9 .	Ограничения относительно организации и окружения, а также внешние ограничения	Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ . Пример ограничений проекта: увеличение стоимости проекта не более чем на 10%; не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте . Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
10 .	Объем денежных средств, выделенных на достижение бизнес-цели	На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта . Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100%
11 .	Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП , спонсор , координатор	Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [ , ]. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта - по одному от заказчика и исполнителя. . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: утверждать бизнес-цели проекта , включая расписания и бюджет, и вносимые в них изменения; назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; принимать решения о внесении изменений в базовую линию проекта . Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [ , ]. Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта

Транскрипт

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

С развитием информационных технологий и телекоммуникаций наша жизнь становится все более мобильной и информативной, новые технологии прочно входят в различные отрасли хозяйствования, сферы жизни и несут новые нормы в них. В связи с реформированием экономики РФ, с взятием курса на инновационное развитие экономики, всё чаще и чаще в повседневной работе в большинстве предприятий и организаций используют различные средства информационно вычислительной техники и соответственно программного обеспечения. Но необходимо заметить, что спонтанное, не спланированное развитие в любой деятельности малоэффективно. Поэтому очень важно знать и владеть таким программным обеспечением, как MS Project. Специалисты смогут разработать план-график проекта, прописать лист ресурсов, использование задач, использование ресурсов, рассчитать Pert анализ, сформировать отчетность. И самое главное – эффективно отслеживать ход выполнения проекта. В данной статье кратко рассмотрены примеры разработки устава проекта для дальнейшего применения материала при подготовке ИТ-специалистов в процессе работы с ПО MS Project.

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

1. Большакова О.Н., Чусавитина Г.Н. Применение методики pмi для управления рисками проекта по продвижению интернет-магазина: В сборнике: КЛАСТЕРНЫЕ ИНИЦИАТИВЫ В ФОРМИРОВАНИИ ПРОГРЕССИВНОЙ СТРУКТУРЫ НАЦИОНАЛЬНОЙ ЭКОНОМИКИ сборник научных трудов Международной научно-практической конференции, в 2-х томах. Ответственный редактор Горохов А.А.. 2015. С. 64-68.

3. Chusavitina G.N., Zerkina N.N. Cyber extremism preventive measures in training of future teachers: в сборнике: sgem 2015 international multidisciplinary scientific conference on social sciences and arts 2-nd international multidisciplinary scientific conference on social sciences and arts. 2015. С. 275-280.

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

Современный бизнес невозможен без знаний и навыков управления проектом. Ежедневно в любой компании реализуется какой-либо проект (разработка и внедрение новых продуктов (услуг) и технологий; реструктуризация деятельности компании и т.д.). Но когда дело доходит до распределения ресурсов и нагрузок, оказывается, что изначально разработанный проектный план нереален либо по затратам, либо по срокам, а чаще всего - и по затратам, и по срокам. А как бы здорово было просчитать все сроки и ресурсы заранее! Делать такой проектный план - одно удовольствие! Вот, где приходит на ум пословица «Конечно, обдумывай «что», но еще больше обдумывай «как»!». - Прежде, чем что-то сделать, необходимо эффективно продумать - как это сделать. Как создать оптимальный проектный план, который затем можно эффективно реализовать? Как добиться управляемости проектов? Как оценить реальную стоимость проекта? Как оценить реальный риск проекта?

На все эти вопросы дает ответ такой курс, как «Управление проектами», в основе которого лежит Microsoft Project - приложение семейства Microsoft Office, позволяющее организовать эффективное планирование и управление проектами. Управление проектами пытается организовать и систематизировать процедуры в проекте, минимизировать риски, с которыми Вы сталкиваетесь. Роль компаний, специализирующихся на разработке и реализации проектов, существенно возросла, а должность и профессия менеджера проекта (Project Manager) стала одной из престижных.

Цель: обеспечить базовую подготовку студентов в области управления проектами. Дать представление о существующих методологиях управления проектами в сфере ИТ и выработать у студентов практические навыки по их применению, чтобы по окончании одного семестра обучения они были в состоянии подготовить и выполнить на качественном уровне свой первый проект. А также, разработать устав проекта и рассмотреть примеры для дальнейшего применения материала при подготовке ИТ-специалистов в процессе работы с ПО MS Project. В данной статье рассмотрим краткие примеры разработки устава проекта с использование Microsoft Project. Устав проекта является документом официального запуска проекта, который готовит будущих руководителем проекта. Как правило, документ согласовывается с управляющим комитетом проекта: спонсором, куратором, клиентом и другими менеджерами . Задачи: зафиксировать причину проекта, определить ключевые параметры проекта - срок, стоимость, качество; назначить роли участников проекта - руководителя проекта и команду проекта; задать порядок управления проектом - общие правила (политики), на основании которых будет вестись управление проектом, права и обязанности всех участников проекта.

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

Перейдем к рассмотрению первого примера.

Наименование проекта: разработка сайта «Фабрика сайтов». Дата создания устава проекта: 05.10.2016 г. Основное назначение устава проекта: настоящий устав проекта охватывает работы по разработке и продвижению сайтов «Фабрика сайтов». Миссия компании: компания «Фабрика сайтов» работает над тем, чтобы раскрыть заказчикам новые возможности Интернет-технологий; превратить трудоёмкий и затратный процесс создания сайтов, рекламы в Интернете в доступное и прибыльное для клиента дело. Компания соединяет интересы покупателей и владельцев сайтов, помогая им, найти друг друга в Интернете .

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

Описание проекта. Так как сайт -это визитная карточка любой компании, то в него будут включаться: вкладка «О компании» (включает в себя разделы, в которых будет содержаться информация о самой компании), вкладка «Поддержка» (включает в себя форум с технической информацией о программе, которую продаёт компания и информацию по часто задаваемым вопросам). Так же поддержка может включать в себя срочные новости, связанные с конкретным ПО (например, если эта программа нуждается в сети интернет, то может быть информация о затруднённом соединении или ошибках которые требуют вмешательство специалистов компании); вкладка «Вакансии» (включает в себя информацию о вакансиях, в которых не хватает технического персонала, а так же контакты с отделами, в которые требуется специалисты; вкладка «Магазин» (если эта компания поставляет программное обеспечение, она включает в себя информацию, а так же цены на ПО которую поставляет компания); окно «Регистрации» и вкладка «Личный кабинет» (окно регистрации нужно для того, чтобы дать доступ к ПО, которого нет в свободном доступе) . Личный кабинет нужен для того чтобы предоставить доступ к полной версии сайта компании. «Связь» (нужна для того, чтобы пользователь мог связаться с руководством компании или конкретного отдела).

Основные функции сайта. Сайт - это визитная карточка любой компании. Он должен быть информативным, наглядным, знакомить посетителей с аспектами деятельности вашей компании. Существуют четыре основные функции сайта: имиджевая, информационная, рекламная и маркетингова. Имиджевая функция отвечает за формирование образа владельца сайта среди интернет - пользователей. Главную роль при этом играет оформление ресурса. Зачастую, это фирменный стиль компании, который обусловлен многими факторами, начиная от профессионализма персонала и заканчивая прочими мелочами. Информационная функция сайта заключается в том, чтобы предоставить пользователю, как можно более полную информацию о товарах или услугах, которые предлагает компания. Рекламная функция сайта. Реклама, размещенная в интернете, изрядно отличается от других способов ее опубликования. Удобный и современный рекламный носитель (большая потенциальная аудитория, возможность позиционирования предложений). Маркетинговая функция помогает продавать товар или же услуги, представленные на сайте. Это одна из главных функций, которая позволяет его владельцем получать постоянную прибыль. Она призвана убедить посетителя купить у Вас и сделать так, чтобы процесс покупки прошел легко и комфортно. Сегодня будущее за активно растущим рынком интернет-маркетинга.

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

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

Таблица 1

Название задачи	Длительность
Разработка сайта
Предроектное обследование
Определение целей сайта
Создание технического задания
Разработка и создание макета
Создание дизайна сайта
Верстка сайта
Выбор средства разработки
Принятие управленческого решения
Программирование
Наполнение информацией
Расположение сайта в сети Интернет
Тестирование сайта
Создание отчётности
Собрание
Разработка сайта
Пред проектное обследование
Определение целей сайта
Создание технического задания

Организационная структура проекта. Команда проекта: руководство компании «Фабрика сайтов»; отдел продаж компании «Фабрика сайтов»; работники компании «Фабрика сайтов»; существующие клиенты компании; новые клиенты компании.

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

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

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

Далее рассмотрим пример №2. Обоснование проекта. В данном разделе дается краткая информация из принятого бизнес кейса (концепции) проекта для сведения проектной команды. Эта информация важна для определения проекта. Краткое описание проекта: кто заказчик проекта, кто клиент проекта, что является результатом проекта, в одну строку ключевые параметры проекта? Результаты проекта. Для оптимальной реализации перечня представленных услуг и эффективности работы организации было принято решение создать Web-сайт.

Исключено из проекта. Web-сайт не будет предоставлять пользователям личный кабинет на сайте. Начало проекта - 25.03.16. Сумма затрат проекта - 16 400 р. Другие требования. В данный раздел могут быть включены ключевые бизнес-требования к свойствам продукта или специальные требования к организации работ по управлению проектом.

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

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

Таблица 3

Даты проекта и контрольные точки

Название задачи	Длительность		Окончание
Создание сайта
Проектирование
Составление договора
Составление ТЗ
Разработка макета
Презентация заказчику
Формирование листа замечаний
Реализация замечаний
Утверждение макета и их подпись
Открытие тестовой площадки
Верстка страниц
Демонстрация заказчику
Формирование листа замечаний
Утверждение верстки
Программирование
Программирование продукта
тестирование заказчиком
Закрытие проекта

Данный материал может быть использован при подготовке ИТ-специалистов направлений подготовки «Прикладная информатика», «Бизнес-информатика» и в работе «айтишников» при применении с MS Project.

Библиографическая ссылка

Новикова Т.Б. РАЗРАБОТКА УСТАВА ПРОЕКТА ПО СОЗДАНИЮ САЙТА С ИСПОЛЬЗОВАНИЕМ MS PROJECT // Международный журнал прикладных и фундаментальных исследований. – 2016. – № 12-3. – С. 435-439;
URL: https://applied-research.ru/ru/article/view?id=10856 (дата обращения: 06.04.2019). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

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

Устав проекта определяет каркас проекта в 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.. - Загл. с экрана

Литература

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