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

5 классов AACE для оценки стоимости проектов       Вчера проводил тренинг и был задан такой вопрос: «Как оценить бюджет проекта, о котором на данный момент мало что известно».       Когда о проекте известно немного, главный вопрос не «сколько это стоит точно», а «какую цифру можно назвать, чтобы не выглядеть фантазёром». AACE International* предлагает систему из пяти классов оценок — от «идеи» до «полной определённости». Класс 5 — «Идея». Определённость проекта: 0–2%. Точность: от -20% до -50% по нижней границе и от +30% до +100% по верхней. Методы: аналоги, факторные модели. Когда использовать: «Прикидка» для первого разговора. Класс 4 — «Эскиз». Определённость: 1–15%. Точность: от -15% до -30% и от +20% до +50%. Метод: факторные или параметрические модели. Когда: оценка на этапе пресейла. Класс 3 — «Бюджет». Определённость: 10–40%. Точность: от -10% до -20% и от +10% до +30%. Метод: параметрические модели, удельные расценки. Когда: авторизация бюджета, контрольная оценка. Класс 2 — «Конкурс». Определённость: 30–75%. Точность: от -5% до -15% и от +5% до +20%. Метод: детальные расценки с проработанными объёмами. Класс 1 — «Полная определённость». Определённость: 65–100%. Точность: от -3% до -10% и от +3% до +15%. Метод: детальный подсчёт объёмов. Когда: контрактование. Нельзя получить класс 1 без полного определения СДР проекта. Нельзя требовать точности класс 3 от проекта на стадии идеи. Если неизвестных много — честно назовите класс 5. Но обязательно объясните про погрешность. Это профессиональный ответ на вопрос «сколько?», когда точных данных нет. Оценку класса 5 за базу принимать нельзя! * AACE International (Association for the Advancement of Cost Engineering  - Ассоциация развития стоимостного инжиниринга)— это профессиональная ассоциация, которая занимается развитием методологии управления стоимостью и сроками в проектах, программам и портфелях. #УправлениеПроектами #AACE #ОценкаСтоимости #PMO #УправлениеПроектами

Когда ставить точку в проекте Продолжаем. Проект — это временное предприятие. У него есть начало и конец. Вчера я написал почему важно понимать точку старта. Сегодня – почему важно вовремя поставить точку финиша. На практике многие проекты превращаются в бесконечную историю. Классический кейс — создание IT-системы. Систему создали. Она в промышленной эксплуатации. Пользователи работают. Вроде бы проект выполнен — цель достигнута, результат передан. Но проект не закрывают. Почему? - Первая причина: поддержка. Система требует сопровождения — обновления, исправления ошибок, консультации пользователей. Это операционная деятельность, а не проект. Но её продолжают тащить в рамках того же проекта. - Вторая причина: «хотелки» заказчика. После запуска начинается бесконечный поток новых требований: «добавьте вот эту функцию», «а можно вот так», «мы тут подумали — нужно переделать». Каждая новая хотелка оформляется как задача внутри проекта. Скоп растёт, но плановый горизонт теряется. Результат: проект не завершён, но и не управляется. Он превратился в операционную деятельность с элементами хаоса. Спланировать это невозможно, потому что когда поступят новые запросы от пользователей непонятно, объём будущих требований не определён, а сроки, соответственно, размыты. Постоянно приходится отвлекать специалистов с новых проектов на неожиданные задачи по незавершенному проекту. Проблема разрастается при увеличении количества проектов. Люди разрываются между новыми проектами и незавершенными. Производительность падает. Текучка растет. Прибыль проседает. Что делать? - Зафиксировать завершение проекта. Система создана, принята, введена в эксплуатацию. Проект закрыт. Цель достигнута. Акт подписан. - Поддержка — это операционная деятельность. Передать её в соответствующий отдел, с SLA, регламентами и отдельным бюджетом. Это не проект. - Новые требования — это новый проект. Собираем поступающие требования и инициируем новый проект. С новыми целями, бюджетом, сроками и ответственными. Не нужно пытаться запихнуть его в старый закрытый проект. Не бойтесь ставить точку. Незакрытый проект — это не гибкость. Это управленческий хаос. Проект, который «вроде бы продолжается», не даёт ни контроля, ни предсказуемости. Проект заканчивается тогда, когда достигнут результат, он передан заказчику и подписан акт выполненных работ. Всё, что после — либо поддержка, либо новый проект. Смешивать эти вещи — значит поддерживать хаос в системе. #УправлениеПроектами #PMO #ЗавершениеПроекта #IT #УправлениеПроектами

Что считать стартом проекта Проект — это временное предприятие. Но когда именно оно начинается? Казалось бы, простой вопрос. На практике бывает что один из самых спорных. Классический кейс — создание IT-системы для внешнего заказчика. До этого в компании создали систему управления проектами. Начали считать трудозатраты и соответственно себестоимость проектов. И тут выяснилось: значительная часть трудозатрат падает на мероприятия по продаже проекта — встречи с заказчиком, демонстрации, подготовка конкурсных документов, согласования. Всё это делается до того, как договор подписан. И вот дилемма: - Если считать эти затраты на проект — то многие проекты будут завершаться на этапе «продажа». То есть в системе будет масса убыточных «проектов». Формально — это провальные проекты. Фактически — нормальная ситуация: мы потратились на пресейл, но проект не получили, конкурс не выиграли. - Если не считать — что делать с этими затратами? Они же реальные. Сотрудники тратили время, компания платила зарплату. Мы решили так: - Мероприятия по продаже проекта — это операционная деятельность. Не проект. - Старт проекта — момент подписания договора. Всё, что до — операционка. Всё, что после подписания договора — проект. - Специалисты, занятые в пресейле, должны иметь соответствующий KPI и запланированное время на операционную деятельность. Иначе их работа не учитывается нигде. Почему это важно? Если не договориться о том, что считать стартом проекта, вы получите: Проекты, которые «завершаются» на этапе продажи с убытком. Искажённую статистику: одни проекты выглядят убыточными, хотя на самом деле это затраты на развитие бизнеса. Хаос в учёте и мотивации. Старт проекта — это не первая встреча с заказчиком. Не демонстрация. Не подготовка конкурсной документации. Это подпись под договором. Всё остальное — операционная деятельность, которая должна жить по своим правилам. Таким было наше решение. А как у вас? Договоритесь о точке старта. Иначе получите хаос при работающей системе. #УправлениеПроектами #PMO #СтартПроекта #IT #УправлениеПроектами