Один из вариантов оценок по трем точкам – техника оценки и анализа проектов (Program Evaluation and Review Technique, PERT). Она была разработана в 1957 году для проекта по конструированию ракет Polaris для подводных лодок специальной командой, в которую входили представители Департамента исследований военно-промышленных корпораций Booz Allen Hamilton, департамента ракетостроения Lockheed и отделения оценки программ ВМФ США.
Многие проекты являются предприятиями по решению уникальных задач, которые до них не решались. Соответственно, нет никаких предшествующих или архивных данных. Программа PERT оказалась очень эффективной в оценке такого рода проектной среды. Она особенно хорошо работает там, где присутствует высокий уровень неопределенности и очень высоки пессимистичные оценки. PERT позволяет управляющему проектом использовать специальный индекс по отношению к оценке наибольшей вероятности в том случае, если она базируется на опыте и всестороннем анализе фактической ситуации. Различие между ней и средним стандартом методики трех точек заключается в том, что в программе PERT эта оценка содержит
где О – оптимистичная оценка, НВ = оценка наибольшей вероятности, П = пессимистичная оценка.
Многие руководители проектов полагают, что финальные оценки по программе PERT окажутся наиболее вероятными из-за «утяжеляющего» фактора. Хотя часто так и бывает, неопределенность среды проекта нередко повышает его пессимистичную оценку, что в конечном счете делает окончательную оценку более точной.
Помните, что оценки проекта – это предсказания. Это проекции в будущее, неопределенные по своей природе. Привлекайте к оценкам экспертов в предметной области! Никто не знает работу лучше и не может выдать более точных оценок, чем они. Вы можете корректировать и актуализировать свои оценки по мере того, как ваш проект развивается, а вы набираетесь в нем опыта.
Люди не могут учиться, если не получают встречной информации или критической оценки своих достижений. Если вы каждый день бегаете по сто метров, пытаясь повысить результаты, но никогда не фиксировали их, то не узнаете, лучше бегаете или хуже. Вы не узнаете, что мешает вам и замедляет бег. Точно так же, если вы будете оценивать срок выполнения той или иной задачи, не замеряя реальное время, потребное для ее решения, вы никогда не достигнете прогресса в оценочной деятельности. Более того, время выполнения задачи вы должны фиксировать ежедневно. Делая это раз в неделю, в своих оценках вы будете всего лишь строить догадки, а это не принесет пользы проектам.
Управление закупками проекта
Иерархическая структура работ показывает не просто содержание проекта – она также обеспечивает понимание задач и необходимых действий. Многие руководители проектов при этом обнаруживают, что осуществление намеченных по проекту работ требует приобретения или закупок товаров и/или услуг у внешних поставщиков. Это не причина для паники, но если раньше вам не приходилось сталкиваться с закупочными контрактами и соответствующей документацией и если вы входите в эту сферу деятельности, то должны иметь о ней хотя бы базовое представление.
Вспомните, как вы приобретали что-либо с доставкой на дом. Это было сделано вовремя? Как человек, работавший в области закупок по проектам авиакорпорации Northrop Grumman, уверяю вас, что не всякий произведенный товар доставляется покупателям и заказчикам вовремя и в надлежащем качестве. Все руководители проектов должны уметь управлять закупками проекта, чтобы обеспечить правильность и гладкость этого процесса.
Закупая продукт, управляющий проектом должен поставить три вопроса:
Что должно быть закуплено?
Когда именно этот продукт необходим?
Как это будет приобретено?
Далее руководитель проекта (или член команды) предпримет следующее действие и запросит данные о ценах. В зависимости от отрасли, в которой работает ваша организация, это может быть очень просто: вы направляете по соответствующему адресу имейл. А может быть и значительно сложнее. Этот запрос уже может включать в себя различные требования, условия и параметры.