Есть два пути оценки — либо с командой, либо самостоятельно. Преимуществ оценки сроков с командой несколько: это и снижение рисков относительно срыва сроков, и предпроектное «сплочение» — люди работают лучше, когда участвуют в планировании. Недостатки также велики — сотрудники будут завышать сроки, спорить между собой и т.д.
Оценка без команды делается просто и быстро, но точность ее оставляет желать лучшего, да и командой она будет воспринята хуже.
Лично я рекомендую некий компромисс — оценивайте сроки только с теми, без чьего мнения не обойтись. До остальных доносите предварительный результат в форме вопроса, если замечания будут — обсудите, если нет — подписывайте и распространяйте (по возможности от имени Куратора).
Учтите еще и тот момент, что после точной оценки одного этапа (или суммарной задачи) остальные этапы могут (а иногда даже должны) переоцениваться.
Для оценки времени (продолжительности) можно использовать «оценку по аналогу», если работы не носят уникальный характер. Параметрические и эвристические методы оценки времени (тестирование = 1/4 времени внедрения) очень неоднозначны, и применять их я бы не рекомендовал.
Метод PERT (оценка по трем точкам) является одним из наиболее действенных методов, он использует три сценария: “оптимистичный” (O), “пессимистичный” (P) и “наиболее вероятный” (M).
Формула расчета предполагаемой длительности:
EAD=(P+4M+O)/6
Формула расчета диапазона допуска:
SD=(P-O)/6
Исходя из этих данных, можно рассчитать самый оптимистичный (EAD-SD) и самый пессимистичный (EAD+SD) прогнозы.
Для оценки стоимости также можно использовать метод PERT, а исходные данные для него можно получить как сумму себестоимости всех работ.
После выполнения шагов, описанных выше, нужно переходить к созданию расписания.
После того, как Вы внесли данные в Microsoft Project, можете задать стартовую дату проекта, и получить предполагаемую дату окончания. Если срок окажется выше ожидаемого (что вполне вероятно), необходимо переходить к оптимизации расписания (этот процесс часто называют сетевым анализом).
Как бы Вы не трудились на этапе планирования, в ходе работ, сроки придется сжимать по самым разным причинам. Есть несколько классических методов, которые так или иначе Вы будете применять:
Crashing: больше ресурсов = быстрее работа. Это гарантированно дорого, а насчет эффективности гарантий нет. Тем не менее, метод дубовый и работает.
Fast track: приступать к следующему, не до конца завершив предыдущее. Очень популярен в управлении ИТ проектами. С одной стороны риски таковы, что по их метрикам можно закрывать проект. С другой стороны, многие так работают, и ничего, живы.
Если Вы столкнулись с задачей, которую не знаете, как выполнить, полезно провести декомпозицию, т.е. разбить большую и сложную задачу на более и более мелкие части.
Если ситуация складывается так, что в указанный срок никак не влезть, эту проблему нужно обсудить с Куратором и/или Клиентом сейчас. Возможно, допустимо будет увеличить срок, или отменить некоторые работы.
В любом случае, финальное расписание должно быть реалистичным, иначе проект будет провален.
Стоит отметить, что бюджетом проекта является не себестоимость работ, которая была получена Вами ранее, а ее сумма в так называемыми управленческими резервами. Формирование бюджета проекта, как правило, выполняет Куратор проекта.
Оглавление цикла статей об управлении проектами
Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.