Составляющие проекта

Составляющие проекта

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

Компонентами всякого проекта являются:

● проблема;

● цели (цель) проекта;

● план действий по достижению целей;

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

● ресурсное обеспечение проекта;

● действия, обеспечивающие реализацию проекта;

● результаты реализации проекта;

● субъект проекта (один человек или команда). Составляющие проекта разрабатываются, формируются и используются в ходе его выполнения.

Лекция 2 Этапы проекта, жизненный цикл проекта, устав проекта.

Этапы проекта и его жизненный цикл

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

Жизненный цикл практического проекта проходит стадии:

● постановки практической проблемы – проблематизации;

● поиска способа решения проблемы – проектирования решения;

● планирования достижения желаемого результата;

● практической реализации проекта;

● завершения проекта.

Жизненный цикл исследовательского проекта проходит стадии:

● постановки исследовательской проблемы;

● разработки гипотезы;

● проектирование способа проверки гипотезы;

● планирование проверки гипотезы;

● практической реализации проекта.

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

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

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

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

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

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

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

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

Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:

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

Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.

Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).

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

Содержание устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:

1. Начальные условия (Project Background) – что привело к инициации проекта, входные условия, «боль» Заказчика.

2. Цели и ожидания проекта (Project Objectives / Expectations) – чего мы хотим достичь на выходе. Это что-то должно быть измеримым (по SMART или как-то еще, неважно) и не допускать двойного толкования. Например, цель «сделать систему CRM, чтобы привлекать больше клиентов» – как-то не очень, правда? А вот «разработать и внедрить систему CRM для сотрудников отдела продаж Северо-Волжского филиала до 01.12.2015 для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года» – это уже немножко лучше.

3. Содержание и результаты (Scope and deliverables) – что именно мы включаем в состав проекта и какие конкретные результаты получим? Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку (а может, и саму организованную с нуля поддержку). В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включить подраздел со списком того, что в содержание проекта не входит в явном виде (чтобы все это согласовали и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили).

4. Ключевые требования и характеристики (Requirements and Characteristics) – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть «Срок обучения сотрудника системе не должен превышать 1 рабочего дня», «Поддержка системы не должна быть дороже 200 000 р. в год», «В системе одновременно должно работать не менее 300 человек» и подобное.

5. Бюджет и сроки (Cost and Timelines) – деньги, сроки и их взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию типа Бюджет-Содержание-Сроки. Т.е. потратить больше денег прямо никак нельзя, уменьшать получаемые результаты сильно нежелательно (но можно, в самом крайнем случае), и если надо ради первых двух пунктов увеличить срок – это ок. Часто тут многие зависают, мол, «да нам все важно!», но в правильно мире вы идете к Спонсору и спрашиваете его, если спонсор адекватен – у него это понимание приоритетов точно есть, и он поделится им с вами.

6. Ключевые участники (Key Stakeholders) – основные заинтересованные лица, как минимум – Спонсор, Заказчик, те, кому придется делиться с вами ресурсами (в матричной структуре), ваш руководитель, держатель бюджета и т.д. Включать сюда всю компанию не стоит, просто подумайте и напишите: а) кто должен знать о проекте на этой стадии б) к чьему авторитету вам будет полезно апеллировать в ходе проекта

7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – про эти вещи мы еще поговорим подробнее, но в целом цель включения их в устав проекта – донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. Ну и чтобы потом никто не говорил «а нам не сказали».

⇐ Предыдущая 1 23