Что такое оценка проекта

Уровни и моменты оценки проекта

Это первая (1) статья цикла, посвященного разработке и использованию системы сбалансированных показателей (ССП/BSC) для мониторинга состояния проекта и оптимизации управления проектом с целью получения запланированных результатов.

Различные моменты оценки проекта

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

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

В ходе жизненного цикла проекта и его используются следующие оценки:

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

Оценка ожиданий от проекта до старта проекта

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

Оцениваются и планируются показатели, которые позволяют объединить стратегические цели компании и бизнеса с результатами проекта – такие как чистый дисконтированный доход (NPV), внутренняя норма рентабельности (IRR), период окупаемости (PP). Кроме количественных показателей, могут применяться качественные, например, повышение безопасности производства.

Зафиксированные плановые показатели используются после завершения проекта для оценки его результатов. Так же, они могут использоваться в ходе проекта, для определения того, соответствует ли проект основным целям, ради которых он инициирован.

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

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

Оценка исполнения процессов в ходе проекта

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

Оценка корректности исполняемых процессов, в первую очередь, производится руководителем проекта и командой управления проектом. Могут привлекаться методологи из офиса управления проектами или сторонние аудиторы.

Оценка может производится в рамках следующих доменов:

Показатели исполнения процессов в ходе реализации проекта позволяют:

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

Ключевыми заинтересованными сторонами оценки процессов выступают руководитель проекта и команда проекта.

Оценка исполнения планов в ходе проекта

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

Одним из основных методов контроля производительности является метод освоенного объема (EVM) или различные его альтернативы. Наиболее простой вариант – сравнение плана с фактом, анализ отклонений, выявление возможных причин и разработка корректирующих мероприятий. Чем чаще и точнее осуществляется сравнение плана с фактом в ходе исполнения проекта, тем раньше могут быть выявлены возможные отклонения и события риска и минимизирован ущерб от них. В основном используются количественные и удельные показатели исполнения плана и отклонения от плана по содержанию, срокам, стоимости.

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

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

Оценка исполнения планов в момент закрытия проекта

Оценка исполнения планов в ходе закрытия проекта показывает на сколько проект выполнил цели, поставленные в уставе, бизнес – кейсе. Производится оценка выгод, зафиксированных в плане управления выгодами, которые можно оценить на данный момент.

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

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

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

Оценка исполнения ожиданий от проекта после завершения проекта

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

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

Основными заинтересованными сторонами оценки проекта после завершения являются спонсор проекта и Заказчики. Руководитель проекта, как правило, уже не привлекается.

Выводы

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

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

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

Источник

Этапы оценки проекта: понятия, методы и полезные инструменты

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

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

Статья будет полезна участникам проектных команд и начинающим предпринимателям.

Продюсер направления «Высшее образование» в Нетологии

Проект — это временное предприятие, которое направлено на создание уникального продукта или услуги. Проекты могут иметь различные формы и реализовываться в любой сфере и отрасли. Например, проектами можно считать:

Также к проектам относят стартапы — молодые компании без опыта операционной или проектной деятельности, работающие над идеей с высокой долей риска и неопределённости.

Любой проект начинается с идеи, а заканчивается, когда:

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

Расскажу, зачем командам проводить оценку проекта и какие методы при этом используют.

Что такое оценка проекта и зачем её проводят

Оценка проекта — это способ выяснить, насколько вероятно выполнить задачу в нужные сроки, качественно и в пределах бюджета.

Оценка позволяет понять реальный статус проекта.

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

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

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

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

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

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

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

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

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

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

К основным бизнес-документам относят:

Прежде чем сформулировать бизнес-кейс, нужно провести оценку потребностей рынка. В неё будет входить первичная оценка бизнес-идеи, оценка бизнес-задач, потенциальных проблем и возможностей проекта.

Источник

И всё-таки про оценку проектов

Елена Тупикова (Котина), 13 лет в управлении проектами и продуктами, автор канала «Games of Projects and Products».

Лет 10 назад менеджера от остальных сотрудников можно было отличить по вопросу в конце встречи: «Всё понятно, и когда вы это сделаете?»

Но уже давно хорошим тоном стало не просто рассуждать о задачах и брать их в работу, а проводить оценку.

И честно говоря, что-то планировать и приоритезировать, когда разработчики постоянно говорят: «Ну… сроки можно понять только когда начну разбираться», совершенно невозможно. [Стоп-стоп, я не говорю про точную оценку в 103 дня! ]

К счастью, в разработке ПО уже давно накоплен большой опыт проведениия оценок, которые дают достаточную точность.

Вот некоторые методы:

Дальше расскажу подробнее про часть способов.

Параметрическая оценка применяется на ранних этапах проекта (на стадии определения проекта и на начальных стадиях проектирования), когда еще нет достаточного количества информации.

Сначала выбираются параметры оцениваемого проекта, которые изменяются пропорционально стоимости проекта.

А потом строится математическая модель.

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

При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов.

Преимущество метода: для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов.

Недостаток: низкая точность (-30%-+50%).

Стоимость подготовки параметрической оценки: 0,04%-0,45% от общей стоимости проекта.

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

Как-то я работала над проектом по масштабному обновлению интерфейса системы. Это была гигантская задача.

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

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

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

Методы получения экспертной оценки:

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

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

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

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

Важно подбирать экспертов в соответствии с их компетентностью!

Если вы хотите подробнее почитать про эту тему, есть целое учебное пособие «экспертные оценки» (автор А.И.Орлов), но это будет полезно для масштабных глобальных прогнозов, а не для IT проекта на 2 месяца.

В этом варианте оценки нужно сравнить текущий проект с фактически потраченными человеко-часами на подобном проекте в прошлом, но не с изначально предполагаемым объемом!

В рамках данного подхода мы можем опираться на прошлый опыт решения подобных задач или проектов.

Основными шагами тут будут:

— найти возможные аналогии, выделить подобные задачи,

— учесть фактор сложности, который должен быть определен и умножен на человеко-часы.

Ну, например, вы хотите построить трехэтажный дом, и один такой вы уже построили 10 лет назад, тогда вы уже знаете, сколько это может занять времени, и с какими сложностями вы можете столкнуться.

Но сейчас на вашем участке нет водопровода, и его нужно провести, а в прошлый раз, такой задачи не было.

Тогда вы понимаете, что сложность при строительстве этого дома будет несколько выше.

Да ещё может быть ваш новый участок земли на склоне?!

Оценка на основе оптимистичного, пессимистичного и наиболее вероятного времени.

или более пессимистичный вариант:

О = оптимистично: минимально возможная длительность выполнения задачи, если все идет отлично и нет неожиданных сюрпризов.

Р = реалистично: как долго вы думаете, это займет, по всей вероятности?

П = пессимистично: всё окажется сложнее, чем ожидалось, и складывается наименее удачным образом (исключая крупные катастрофы).

Этот метод подходит для высокоуровневой оценки проектов в несколько тысяч человеко-часов, но при более детальной декомпозиции задач будет слишком трудоёмкий.

Оценка идёт по вариантам использования системы.

Этот метод разработал Gustav Karner в 1993 году.

Количество UCP в проекте зависит от:

— количества и сложности вариантов использования системы,

— количества действующих лиц в системе,

— различных нефункциональных требований (аля производительность), которые не описаны в пользовательских сценариях,

— среды, в которой будет развиваться проект (например, язык, мотивация команд,… ).

Процесс подсчета состоит из следующих этапов:

— Рассчитать нескорректированные UCPs

— Учесть техническую сложность

— Скорректировать на «окружение»

— Рассчитать скорректированные UCPs

И формула в итоге будет такая:

UCP = UUCP × TCF × EF

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Источник

Оценка проекта

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

Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.

Перед тем как рассказать о своем опыте, хотелось бы ответить на несколько принципиальных вопросов: чего хочет заказчик и чего хочет исполнитель при выполнении проектов? Будем исходить из того, что заказчик действительно хочет сделать проект. У него есть определенный бюджет, и он не собирается «кидать», а готов заплатить оговоренные деньги за получаемый результат. Понятно, что он хочет сделать за свои деньги как можно больше. А вы, когда делаете дома ремонт, разве этого не хотите? И как каждый хозяин, нанимающий бригаду строителей, заказчик, возможно, подозревает, что исполнитель будет его надувать раздувать бюджет. Что поделать, такова наша действительность.

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

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

Рамки проекта

Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика.

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

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

Проработка архитектуры

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

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

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

Архитектурные ограничения системы, вытекающие из решения, также фиксируются в документе «Рамки проекта». Помимо этого, в документе фиксируются события, значимые для проекта – необходимые ресурсы, которые должен предоставить заказчик, сроки подготовки оборудования, классов обучения и т.п.

Планирование работ

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

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

Под «оптимальным сочетанием привлекаемых ресурсом» имеется в виду простая мысль – сроки проекта должны быть минимальны, людей надо привлечь как можно меньше, но задействовать их максимально. Так появляются оценки длительности пребывания людей на проекте, которые являются основой для составления бюджета проекта.

Планирование работ мы делаем в MS Project. В плане работ мы проставляем трудоемкость выполнения той или иной задачи. Оценки, выданные архитектором, можно использовать только в сочетании с пониманием того, кто будет реализовывать эти требования. У нас должны появиться конкретные фамилии людей. И от того, кого конкретно мы привлекаем на данную задачу, будет зависеть корректировка оценки данной задачи.

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

Оценка бюджета

В результате планирования работ появляются роли и люди, участвующие в проекте и длительность их пребывания на проекте.

Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:

В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.

Четвертый ключевой момент при составлении бюджета заключается в том, что мы переходим от трудоемкости задач, выставленной в плане, к длительности привлечения ресурсов. Логика простая. Основной статьей расходов исполнителя является оплата труда персонала. Если люди находятся на проекте дольше оплаченного времени, то компания исполнителя несет прямые убытки.

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

Уточнение рамок, срока, бюджета

В результате проделанной работы мы получили документы:

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

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

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

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

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

Управление сроком и бюджетом

Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.

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

Суть их заключается в следующем:

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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:

В дальнейшем, в ходе проекта, остается только четко следить за соблюдением рамок проекта и за соблюдением взаимных обязательств.

Олег Пашинин
Генеральный директор, Информационные и высокие технологии, Москва

Источник