Определение границ проекта:

• Важно с самого начала определить, что входит в проект, а что останется за его рамками.

· Речь идет о согласовании желаний стейкхолдеров;

· Лучше формализовать и даже зафиксировать в письменной форме:

Проект предполагает:

1. Какие конечные поставки

2. Какие результаты поставки

3. Какие характеристики поставки

Проект не предполагает: чтобы не было разногласий и никто ничего не забывал;

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

Качество – комплексная характеристика, можно выделить 3 уровня качества:

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

- средний уровень – набор всех требуемых характеристик, которые нужны потребителю. (Насколько может дольше проработать телевизор и т.д.). Это и есть обсуждаемые характеристики.

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

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

На ранних стадиях необходимо:

Есть 2 техники работ:

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

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

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

1. Заказчик может предполагать, что какая-то характеристика должна быть присущая.

2. Часто по ходу проекта заказчик может пожелать добавить что-то в проект или убрать. Добавление требует кардинального изменения проекта или вовсе его переделывание.

3. У заказчика может возникать желание нас обхитрить.

Если такие проблемы возникают, то всегда есть несколько решений:

- Можно занять жесткую позицию и отказать ему, что приведет к потерям бизнеса

- Иногда нам придет идти к нему на компромисс

Три основных документа (PMI):

1. Устав проекта (Project Charter): Официально авторизует проект. Проект появляется как структурная единица в компании, т.е. это не просто идея, а что-то уже существующее. Над проектом назначается, утверждается менеджер, который наделяется полномочиями, ресурсами, ответств-ю.

2. Описание содержания проекта. Содержит описание работ, которые предстоит выполнить, и результатов поставок, которые надлежит произвести.

3. План управления проектом, который должен содержать детально, что мы собираемся делать в проекте и как;

§ позволяет детально проработать параметры проекта;

§ содержит описание того, как работа будет выполняться;

§ даёт возможность принять окончательное решение о выгодности проекта.

§ состоит из разделов по всем 9 предметным областям;

§ на основе плана осуществляется дальнейшее управление проектом.

Чтобы понять, что проект идет как-то не так, необходимо сравнить проект с плановыми показателями и прошлым опытом (схема мониторинга и контроля). Хорошо составленный план – необходимое условие, чтобы управлять проектом.

Инструменты планирования (каждый из них старается на передний план выделить какую-то характеристику проекта и максимально успросить проект):

· Work Breakdown Structure (WBS) – представляет собой декомпозицию всех работ…

· Иерархическая структура работ – из каких более простых работ состоят более сложные и объемные задания;

· Разбиение работ до уровня управляемости

· Не учитывается временную составляющую – в какоцй последовательности надо выполнять работы

Иерархическая структура работ ИСР (Work Breakdown Structure, WBS):

§ Представляет собой декомпозицию всех работ проекта, необходимых для достижения поставленных целей.

§ Учитывает иерархию работ –из каких более простых работ состоят более сложные, объемные задания;

§ Разбиение работ до уровня управляемости;

§ Не учитывает временную составляющую – в какой последовательности необходимо выполнять работы.

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

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