Управление стоимостью проекта

400% запас на Черных лебедей

0

Отличная статья про IT проекты “Черные лебеди” вышла у Александра Черникова

Простая метрика на основе статистики черных лебедей для оценки прочности организации перед лицом IT проектов:

«Любая компания, рассматривающая большие технологические проекты, должна спросить себя, достаточно ли она сильна, чтобы в случае необходимости увеличить бюджет проекта на 400%».

Обязательства, задачи и факт

0

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

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

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

6 углов проектного менеджера – уже не так железно

0

Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.

В состав шестиугольника входят следующие дополнительные компоненты:

  • Удовлетворенность клиента (Customer Satisfaction)
  • Риск (Risk)
  • Качество (Quality)

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

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

Аналогично риск. Сама природа риска такова что мы скорее не может полностью покрыть перечень рисков которым подвержен проект. В свою очередь точность измерения рисков также условна. Таким образом трудно утверждать насколько реально повлияло изменение одной из компонент на риск.

Пример EVA анализа

0

Давайте на примере абстрактного проекта проведем EVA анализ.

Исходные данные проекта: 4 месяца длительность, бюджет 100`000 грн. Менеджер проекта отчитывается на конец 3-го месяца проекта. Потрачено 85`000 грн., сделано 50% объема работ. Для упрощения считаем что объем работ был запланирован равномерно – на конец третьего месяца должно было быть выполнено 75% объема работ.

PV (Planned Value, сколько мы планировали выполнить объема работ) = Запланированный процент выполнения x Бюджет проекта = 75% х 100`000 = 75`000 грн.

EV (Earned Value, что фактически сделали, по исходному плану проекта) = Актуальный процент выполнения x Бюджет проекта = 50% х 100`000 = 50`000 грн.

AC (Actual Cost, сколько фактически потратили) = 85`000 грн.

CV (Cost Variance, отклонение по стоимости) = EV- AC = 50`000 – 85`000 = -35`000 грн.

SV (Shedule Variance, отклонение по графику) = EV – PV = 50`000 – 75`000 = -25`000 грн.

После того как мыс посчитали абсолютные отклонения рассчитаем индексы для стоимости (CPI) и графика (SPI) соответственно.

CPI (Cost Performance Index) = EV/AC = 50`000 / 85`000 = 0,59

SPI (Schedule Performance Index) = EV/PV = 50`000 / 75`000 = 0,66

А теперь давайте оценим что нам “светит” в конце проекта

EAC (Estimate at Completion) =  BAC (Budget at Completion, исходный бюджет проект) / CPI = 100`000 / 0,59 = 169,5

А вот и весь EVA анализ в простом виде!

Критичность закрытия фаз/итераций. Пример из практики

0

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

 

Сам факт закрытия фазы позволяет:

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

Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что

  • аналитический документ и зменился более чем на половину
  • объем работ вырос в полтора раза
  • было потеряно около трети времени на разработку в следствии кардинального изменения
  • существенно изменились сроки проекта
  • поставщик понес убытки на потерянном объеме работ
  • клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
  • клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта

У каждого свое понимание конца

0

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

Чтобы избежать этого – надо в самом начале проекта зафиксировать как можно четче что является результатом проекта, как и кто определяет на основании чего качество результатов (продуктов) проекта.

По ходу проекта надо управлять изменениями и при необходимости обновлять не только структуру работ, сроки и стоимость – но и условия приема проекта.

Снижение качества продукта в проекте

0

Хотите снизить качество продукта в проекте?

  • Безбожно давите на сроки, поставьте их нереальными и прессуйте
  • Снижайте стоимость, давите поставщиков до истощения
  • Вовлекайте ваших сотрудников в 5 проектов одновременно
  • Не в коему случае не доверяйте людям в проекте
  • Увеличьте бюрократию в проекте
  • Людей их проекта рассадите в разных комнатах в пяти корпусах.
  • Писать требования? Зачем! Это бумагомарательство. И завтра все равно мы что-то переделаем. А принимать будем когда более-менее будет готово.
  • Ни в коем случае не тратьтесь на тестировщиков. Разве и так не понятно что это должно работать?

Кросс-пост.

Осторожно – fixed price

0

Стоит обратить внимамние на статью в блоге Дениса Журавлева “Fixed-price со скрытым конфликтом” – http://pm.by/toc/fixed-price-so-skrytym-konfliktom/. В статье озвучена проблема в проектах где зафиксирована цена. Решение не предложено. Какие ваши соображения?

Области знаний PMBoK

0
  • Управление интеграцией проекта
  • Управление содержанием проекта
  • Управление сроками проекта
  • Управление стоимостью проекта
  • Управление качеством проекта
  • Управление человеческими ресурсами проекта
  • Управление коммуникациями проекта
  • Управление рисками проекта
  • Управление поставками проекта
Go to Top