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

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

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

Вы думаете о деньгах?

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

Мы можем только выполнить оценку. Оценка – это больше, чем просто взятие случайного числа с потолка, добавление 20% для ровного счета, и затем утверждение того, что все правильно. Реальная оценка изменяется, как только становятся доступны подробности (детали) проекта. Это постепенное развитие. Оценки проекта начинаются с приблизительных величин, и когда предоставляемые результаты проекта оказываются в центре внимания, мы можем уточнить наши оценки.

Каждая оценка должна представлять допустимый диапазон изменений, условия оценки и любые предположения, сделанные тем, кто выполнял оценку. Например, оценка стоимости постройки нового склада, утверждающая, что строительство склада обойдется в $350,000, +/- 10%, верна в течение 30 дней, и предполагает, что склад будет построен в течение июня.

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

Есть три основных типа оценок, на которые должны полагаться руководители проектов:

• Грубая оценка -- также известна как приблизительный порядок величины (ROM). Оценка ROM основана на обобщенных показателях, представляющих глобальную картину предоставляемых результатов проекта, и имеет большое пространство для маневра (гибкость в интерпретации). Многие оценки ROM, в зависимости от отрасли промышленности, имеют диапазон отклонений от -25% до +75%. Как и было сказано, большое пространство для маневра (вариаций).
• Руководитель проекта не должен вкладывать слишком много времени в создание этих начальных оценок, так же как и клиент не должен слишком доверять точности оценки ROM. К несчастью для обеих сторон, ожидания, возлагаемые на оценки ROM, постоянно не оправдываются. Обычно руководитель проекта слепо указывает оценку ROM, и клиент продолжает доверять этой оценке. Оценки ROM, независимо от вашей роли в проекте, нужны просто для визуального контроля расходов на начальном этапе проекта.
• Оценка бюджета (или нисходящая оценка) немного более точная. Четко формулируемая в начале стадии планирования проекта, оценка бюджета чаще всего основывается на аналогичной оценке, учитывающей опыт работы с бюджетом сходного проекта и применяющей этот опыт к текущему проекту.
• В оценке бюджета мы должны начинать с верхнего уровня и постепенно спускаться вниз к деталям проекта. Как и ROM, эта оценка должна включать в себя условия, диапазон отклонений и любых допущений, которые имеют отношение к вашим вычислениям. Оценка бюджета быстрая, но не очень точная. Диапазон вариаций оценки бюджета составляет от -10 процентов до +25 процентов.
• Определенная оценка (или восходящая оценка) является наиболее точная, но требует больше всего времени на свое создание. Для определенной оценки требуется структура декомпозиции работы (WBS). A структура декомпозиции – это не список действий. Структура декомпозиции работ – это ориентированная на предоставляемые результаты декомпозиция масштаба проекта. Это декомпозиция предоставляемых результатов, которые ваш проект создаст для клиента, существительные, не глаголы.

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

Ваша структура должна использовать код счета для нумерации каждого предоставляемого результата в ней. Например, предположим, что HQ Network является номером проекта 427. Секция глобальной сети этого проекта может быть 427.1, и элементы под предоставляемыми результатами глобальной сети могут быть 427.1.1, 427.1.2, и так далее. Эти коды счетов поясняют всем участникам, на какой предоставляемый результат указывает ссылка, представляя точную запись для любого элемента, которую руководитель проекта обещает как часть завершения проекта. Вы не обязаны использовать код счета, но это довольно легко реализовать, и это может сберечь ваше время впоследствии.

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

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

Создание определенной оценки отнимает много времени, но эта наиболее точная оценка из всех, которые вы можете представить. Вы можете знать ее как восходящую оценку, потому что вы начинаете с нуля (низа) и учитываете каждую вещь, которую нужно будет купить, создать или доставить в рамках проекта. Диапазон отклонения определенной оценки относительно низкий: -5% - +10%. Это имеет смысл, потому что намного легче предсказать, сколько что-либо будет стоить, когда вы можете видеть все, что будет создано в рамках проекта. Для скольких проектов из тех, в которые вы были вовлечены, вы могли с самого начала видеть все то, что будет создано в рамках проекта? Вероятно для немногих, или только для проектов, которые вы реализовывали неоднократно и поэтому точно знали, чего ожидать. Например, интегратор IT может иметь шаблон проекта, определяющий всю работу, необходимую для реализации заранее скомпонованного решения в любой среде.

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

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

Вы начали думать о деньгах?

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

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

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

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

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

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

Информационные технологии и контроль затрат на проект

Вам когда-либо казалось, что вы играете с бюджетом, как с мишенью для игры в дротики? Цена производителя увеличилась. Статистическая информация оказалась неверной. Временные оценки ошибочны. Проектная группа слишком слабая. Прибыль была ниже, чем ожидалось.

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

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

Затраты и руководитель проекта

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