какая информация не используется при определении содержания проекта
Этапы оценки проекта: понятия, методы и полезные инструменты
Оценка помогает команде определить вектор развития проекта и вовремя его скорректировать. Однако для многих менеджеров оценка — сложный и пугающий процесс, из-за чего она часто упрощается или игнорируется вовсе.
Вместе с Андреем Кокшаровым, продюсером направления «Высшее образование» в Нетологии, разобрались, зачем проводить оценку проекта, из каких этапов она состоит и какие инструменты помогут в этом.
Статья будет полезна участникам проектных команд и начинающим предпринимателям.
Продюсер направления «Высшее образование» в Нетологии
Проект — это временное предприятие, которое направлено на создание уникального продукта или услуги. Проекты могут иметь различные формы и реализовываться в любой сфере и отрасли. Например, проектами можно считать:
Также к проектам относят стартапы — молодые компании без опыта операционной или проектной деятельности, работающие над идеей с высокой долей риска и неопределённости.
Любой проект начинается с идеи, а заканчивается, когда:
Оценка проекта как раз помогает избежать рисков не уложиться в бюджет или сроки проекта, потерять в качестве продукта или разработать фичи, которые никому не нужны.
Расскажу, зачем командам проводить оценку проекта и какие методы при этом используют.
Что такое оценка проекта и зачем её проводят
Оценка проекта — это способ выяснить, насколько вероятно выполнить задачу в нужные сроки, качественно и в пределах бюджета.
Оценка позволяет понять реальный статус проекта.
Она не призвана наказать отстающих, иначе участники будут приукрашать результаты или прятать неудобные данные и оценка станет необъективной и бесполезной.
Получить реальные данные для принятия решений возможно только, если оценка будет достоверной и актуальной. Чтобы в процессе оценки не возникало искажений, руководителю важно позволить участникам проектных команд высказывать опасения и предположения по ходу проекта.
Например, в некоторых компаниях используют анонимные ящики, которые устанавливают в общедоступных местах, чтобы любой участник команды мог положить туда записанные на листке бумаги сомнения и опасения. С определённой периодичностью менеджер проекта проверяет ящик и узнаёт о проблеме, о которой по какой-то причине подчинённые не говорят лично.
Оценку проекта можно разделить на оценку идеи проекта и оценку самого проекта. Данные блоки в свою очередь состоят из процессов, связанных с оценкой бюджета, сроков, качества и прочих компонентов в зависимости от уровня сложности проекта.
Оценка идеи проекта происходит на этапе, когда формируется бизнес-план и создаётся концепт продукта. Она позволяет руководителю обосновать решение о запуске проекта и его необходимости для бизнеса. В оценке идеи обычно участвуют аналитик, команда маркетинга, менеджер будущего проекта. По её результатам принимают решение об инициации проекта, подписывают устав проекта и набирают команду.
Оценка же самого проекта может происходить на всех этапах, начиная от планирования до этапа завершения. Её задача — скорректировать ход проекта. После проведения оценки проекта обычно вносят изменения в документацию, может измениться состав команды или перечень фичей продукта, либо вовсе решают закрыть проект. Если команда решила продолжать, то после этого оценивают потребности в дополнительных ресурсах.
Менеджер определяет, что важно рассмотреть в ходе оценки проекта. Он же решает, какие процессы нужно оценить и формирует список критериев для оценки каждого из них. В крупных компаниях — особенно тех, которые работают на зарубежном рынке, — инициирует оценку обычно отдельный специалист или команда специалистов отдела контроллинга, которые следят за ходом проекта. В перечень могут входить, например, такие процессы, как:
Состав оцениваемых процессов определяет менеджер на этапе инициации проекта. Чаще всего это называется процессом адаптации системы управления проектом к новому проекту — важно настроить его под среду и процессы внутри компании. Во время адаптации менеджер проекта тесно взаимодействует с командой проекта, с владельцем продукта и ключевыми стейкхолдерами. Адаптация помогает определить контролируемые точки в проекте, грамотно распределить ресурсы и разработать базовый план проекта.
Процесс адаптации — важный этап в работе над любым проектом, так как из-за уникальности разрабатываемого продукта каждый новый проект требует свой набор инструментов, компонентов и контрольных точек.
Менеджер проекта разрабатывает план управления выгодами проекта. И в процессе адаптации ему необходимо синхронизировать между собой основные бизнес-документы проекта — понять, нет ли расхождения между ними и бизнес-кейсом, который изначально представлялся руководству.
К основным бизнес-документам относят:
Прежде чем сформулировать бизнес-кейс, нужно провести оценку потребностей рынка. В неё будет входить первичная оценка бизнес-идеи, оценка бизнес-задач, потенциальных проблем и возможностей проекта.
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос ” Зачем выполняется данный проект?”.
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос “Какую конкретную работу нужно выполнить для достижения поставленных целей?” или “Какие задачи необходимо решить для достижения поставленных целей?”. Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать:
Управление интеграцией проекта. Управление содержанием проекта
6. Основные предположения и ограничения.
Для составления списка предположений рекомендуется использовать так называемый “мозговой штурм”. Неправильные или незадокументированные предположения могут вызвать проблемы во время реализации проекта.
8. Контрольные события и ключевые даты.
| Наименование вехи проекта | Ключевые даты |
|---|---|
| Конфигурирование программного обеспечения завершено | 1 сентября 2008 г. |
| Материалы для обучения разработаны | 2 ноября 2008 г. |
| Прототип разработан | 12 декабря 2008 г. |
| Тестирование завершено | 1 марта 2008 г. |
| Программное обеспечение выпущено | 20 января 2009 г. |
9. Основные результаты и критерии успеха.
Приведем пример описания результатов и критериев успеха проекта по внедрению ИС.
Разработанная ИС должна решить нижеследующие задачи.
В части Управления Основными Средствами:
В части Управления Персоналом:
В части Учета затрат:
10. Планируемая стоимость проекта.
Стоимость проекта определяется контрактом между Заказчиком и Исполнителем. Исходя из стоимости проекта в дальнейшем составляется бюджет расходов проекта с указанием статей расходов на внедрение ИС в разрезе месяца, квартала, полугодия, года.
Устав проекта официально закрепляет назначение руководителя проекта, определяет ролевой состав команды управления проектом, содержит имена Спонсора и Руководителя проекта, а также определяет их полномочия.
Предварительное описание содержания проекта
Какая информация не используется при определении содержания проекта
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОМ
Project management. Requirements for project management
Дата введения 2012-09-01
Предисловие
1 РАЗРАБОТАН Автономной некоммерческой организацией “Центр стандартизации управления проектами” (АНО “Центр стандартизации управления проектами”)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 “Стратегический и инновационный менеджмент”
6 ПЕРЕИЗДАНИЕ. Октябрь 2019 г.
Введение
Настоящий стандарт устанавливает требования к управлению проектом от его старта до завершения, при этом предметом стандартизации являются обязательные выходы процессов управления проектом.
Стандарт не содержит требований, которые могут считаться обязательными лишь для определенного вида проектов, требований к методам реализации процессов управления проектами, а также требований к предпроектной и послепроектной деятельности.
1 Область применения
Настоящий стандарт устанавливает требования к управлению проектом для обеспечения эффективного достижения целей проекта.
Требования настоящего стандарта распространяются на управление любыми проектами и могут быть применены для проектов, реализуемых юридическими или физическими лицами. Проекты могут осуществляться на договорной основе или быть реализованы внутри организации.
Настоящий стандарт может использоваться с целью оценки соответствия управления проектом установленным в стандарте требованиям.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт:
ГОСТ Р ИСО 9000 Системы менеджмента качества. Основные положения и словарь
3 Термины и определения
В настоящем стандарте применены термины в соответствии с ГОСТ Р ИСО 9000, а также следующие термины с соответствующими определениями:
3.1 архив проекта: Структурированный комплект документации проекта, представленный в бумажном и/или электронном виде.
3.2 базовый план проекта: Принятый к исполнению план проекта, содержащий сведения об основных временных и стоимостных параметрах проекта.
3.3 бюджет проекта: Документ, содержащий общую сумму финансовых средств, распределенных по статьям и временным периодам.
3.4 допущение: Фактор, который считается верным для проекта без привлечения доказательств.
3.5 заинтересованные стороны в проекте: Лица или организации, чьи интересы могут быть затронуты в ходе реализации проекта.
3.6 изменение в проекте: Модификация утвержденного ранее содержания, сроков, ресурсов в проекте, а также установленных процедур.
3.7 контрольное событие проекта: Существенное событие проекта, отражающее получение измеримых результатов проекта.
3.8 корректирующее действие: Действие, предпринятое для устранения обнаруженного несоответствия плану проекта.
3.9 ограничение: Сдерживающий фактор, влияющий на ход исполнения проекта.
3.10 предупреждающее действие: Действие, предпринятое для снижения вероятности или последствий отрицательных рисков проекта.
3.11 продукт проекта: Измеримый результат, который должен быть получен в ходе реализации проекта.
3.12 проект: Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
3.13 процесс: Совокупность взаимосвязанных действий, направленных на достижение определенных результатов.
3.14 работа проекта: Действие, выполняемое для достижения цели проекта.
3.15 расписание проекта (календарный план): Плановые даты исполнения работ и контрольных событий проекта.
3.16 риск: Вероятное для проекта событие, наступление которого может как отрицательно, так и положительно отразиться на результатах проекта.
3.17 управление проектом: Планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта.
4 Организация управления проектом
Ролевая (организационная) структура управления проектами может в значительной степени различаться в зависимости от их специфики, но в каждом проекте должны быть определены следующие роли:
Схема, иллюстрирующая основные понятия проектного менеджмента и их взаимосвязь, приведена в приложении А.
5 Управление проектом
5.1 Области управления и последовательность процессов управления проектами
Управление проектом включает совокупность процессов инициации, планирования, организации исполнения, контроля и завершения проекта.
В рамках процессов управления проектом выполняются действия, относящиеся к следующим функциональным областям управления проектом:
– управление содержанием проекта;
– управление сроками проекта;
– управление затратами в проекте;
– управление рисками проекта;
– управление персоналом проекта;
– управление заинтересованными сторонами проекта;
– управление поставками проекта;
– управление качеством в проекте;
– управление обменом информацией в проекте;
– управление интеграцией проекта.
Последовательность процессов управления проектом определяется условиями конкретного проекта, при этом:
– проект должен начинаться с процесса инициации проекта;
– проект должен оканчиваться процессом завершения проекта;
– выполнение процессов организации исполнения и контроля проекта начинается не раньше процессов планирования.
5.2 Процесс инициации проекта
Цель процесса: формальное открытие проекта.
Выходы процесса определяются и документируются следующими параметрами проекта:
– причины инициации проекта;
– цели и продукты проекта;
– дата инициации проекта;
5.3 Процессы планирования проекта
5.3.1 Процесс планирования содержания проекта
Цель процесса: определение требований проекта и состава работ проекта.
а) требования к проекту со стороны заказчика, других заинтересованных сторон проекта, а также законодательства и нормативных актов определены, проанализированы на предмет возможности их выполнения, согласованы с заказчиком проекта и документированы;
б) определены, согласованы с заказчиком и документированы ключевые данные по продукту проекта, а именно:
1) назначение, свойства и характеристики продукта;
2) критерии и методы приемки продукта проекта и его составных частей;
3) допущения и исключения, касающиеся продукта проекта;
4) определены, согласованы с заказчиком и документированы работы проекта, а также допущения и исключения, касающиеся работ проекта.
Управление содержанием проекта
Содержание проекта – это то, что проект включает в себя, и в чем он состоит. Управление содержанием проекта – достаточно большая область знаний, владея которыми Руководитель проекта определяет, что входит в проект и что остается за его рамками.
Содержание проекта – это наличие в проекте тех работ, которые необходимо выполнить, для того, чтобы получить желаемый результат.
Таким образом, содержанием нужно управлять и контролировать его на протяжении всего жизненного цикла проекта, следить за тем, чтобы в списке необходимых работ не появились лишние, не относящиеся к желаемому результату проекта. Или какие-то побочные, относящиеся уже к другому проекту.
Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.
В процессе определения содержания появляется детальный документ, в котором отражены цели и задачи проектных работ.
Не стоит так же забывать, что для достижения одного результата могут быть использованы различные альтернативные методы, таким образом, следует рассматривать вопрос шире, со всех сторон, чтобы не упустить более выгодные возможности.
После того, как разработан и утвержден устав проекта, собраны и задокументированы требования, может быть составлено описание содержания проекта. Оно уже содержит больше информации о проекте, и оно более детально.
Качественно составленное описание содержания проекта важно еще и потому, что впоследствии будет являться основой для планов и решений. В то время как при плохо определенных целях могут возникнуть значительные риски.
Чем детальнее и однозначнее звучат пункты содержания проекта, тем проще потом определить, что проект завершен, то есть выполнены все требования и достигнуты все поставленные цели.
Но мы все понимаем, что в процессе жизненного цикла проекта появляется все больше и больше уточняющей информации, что необходимо учитывать при дополнении и детализации содержания проекта, при необходимости согласовывая с заинтересованными лицами.
Содержание проекта включает в себя:
Об описании содержания проекта, критериях приемки результата и границах проекта поговорим ниже.
Описание содержания проекта
В описание проекта входит достаточно высокоуровневое описание того, какие результаты должны быть получены. По большому счету, это следующий уровень детализации того содержания, которые было приведено в уставе проекта. Важно включить сюда то, что требуется сделать или произвести для получения результата. Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:
Критерии приемки результата проекта
По каждому из элементов содержания проекта, приведенному выше, указывается, как заказчик и мы сами поймем, что результат действительно соответствует ожиданиям? Это обычно самая сложная часть описания содержания проекта, т.к. степень неопределенности еще слишком высока, а договариваться нужно уже тут, на берегу,пока работы не начались.
Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.
Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.
Границы проекта
Помимо того, что команда проекта будет делать в ходе его реализации, очень важно определить, чего она делать не будет.
На рисунке ниже схематично изображено определение границ проекта.
Определение границ проекта
В ходе описания границ проекта определяются и документируются все моменты, которые могут подразумеваться как часть проекта, но таковой не являются (опять же, в идеально случае вы просто детализируете то, что ранее написали в уставе проекта).
Продолжая приведенный выше пример, в содержание проекта входит обучение пользователей, но не входят командировки проектной команды для обучения бухгалтеров в регионах или организация командировок этих бухгалтеров для обучения в Москве (об этом заказчику придется позаботиться самостоятельно).
Управление содержанием целесообразно еще и потому, что позволяет контролировать объем усилий и средств, направленных на получение результата. Что, если на выполнение проекта потрачено огромное количество ресурсов, усилий, времени – а результат, мягко говоря, того не стоит?
Хорошо написанное содержание проекта – одна из основополагающих успеха проекта и отличный инструмент коммуникации, который руководитель проекта должен уметь использовать во благо этого проекта.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂