План-факт по проектам часто выглядит как простой отчет: что запланировали, что получили, где есть отклонения. Но на практике именно с ним возникает много вопросов.
В таблице цифры могут быть аккуратно разложены по строкам, а на совещании выясняется, что часть работ не попрали в учет, трудозатраты собрали не полностью, оплаты не связаны с этапами, бюджет пересчитывался вручную, а перерасход стал виден только после закрытия проекта.
Проблема обычно не в самом отчете. План-факт не сходится, когда плановые и фактические данные собираются по разным правилам, в разных системах и без связи с одним объектом – проектом.
Чтобы план-факт был полезным, он должен показывать не просто разницу между двумя цифрами. Он должен помогать понять, почему возникло отклонение, где именно оно появилось и как оно влияет на сроки, бюджет, себестоимость и маржинальность проекта.
Что нужно сравнивать в план-факте по проекту
В проектном учете план-факт – это не только сравнение планового и фактического бюджета.
Полезно сравнивать несколько измерений.
Проект может идти по календарному графику, но уже перерасходовать трудозатраты. Или задачи могут быть закрыты, но оплата по этапу еще не поступила. Или бюджет может формально не превышаться, но часть внутренних работ не попала в себестоимость.
Поэтому план-факт должен собирать картину по нескольким связанным контурам: сроки, работы, часы, ресурсы, оплаты, бюджет и расходы.
Причина 1. План сделан крупными блоками, а факт собирается по задачам
Одна из частых причин расхождений – разная детализация плана и факта.
На старте проект планируют укрупненно:
- обследование;
- проектирование;
- разработка;
- тестирование;
- внедрение;
- сопровождение.
А фактические работы потом собираются по десяткам задач и активностей:
- встречи;
- переписки;
- уточнения требований;
- внутренние обсуждения;
- исправления;
- повторные согласования;
- доработки;
- тестовые прогоны;
- поддержка пользователей;
- подготовка инструкций.
В результате план и факт невозможно корректно сопоставить. План говорит: «на этап разработки заложено 200 часов». Факт показывает множество мелких задач, часть из которых относится к разработке, часть – к тестированию, часть – к дополнительным согласованиям, а часть вообще появилась после изменения требований.
Если нет понятной структуры проекта, факт начинает жить отдельно от плана.
Что происходит на практике
Руководитель проекта видит, что задачи выполняются. Финансист видит, что трудозатраты растут. Руководство видит отклонение, но не может быстро понять, где именно оно возникло: в исходной оценке, в дополнительных работах, в задержках согласований или в неучтенном изменении объема.
План-факт превращается в спор о том, «куда отнести часы», вместо инструмента управления.
Что проверить
- Есть ли у проекта структура этапов, задач и вех?
- Можно ли отнести каждую фактическую работу к этапу?
- Совпадает ли детализация плана и факта?
- Есть ли отдельный учет дополнительных работ?
- Понятно ли, какие задачи входят в исходный объем, а какие появились позже?
Практический вывод
План должен быть достаточно детальным, чтобы потом можно было сопоставить его с фактическими задачами и трудозатратами. Иначе план-факт будет показывать отклонение, но не объяснять его причину.
Причина 2. Трудозатраты фиксируются нерегулярно или задним числом
Для проектных компаний трудозатраты часто являются основной частью себестоимости. Поэтому любые ошибки в учете часов напрямую искажают план-факт.
Проблема возникает, когда сотрудники фиксируют часы:
- в конце недели;
- в конце месяца;
- перед подготовкой отчета;
- после напоминания руководителя;
- приблизительно, «по памяти»;
- без привязки к конкретной задаче или этапу.
Чем позже фиксируются трудозатраты, тем выше риск, что часть работ забудут, округлят, отнесут не туда или не отметят как отдельный перерасход.
Особенно это заметно, когда один специалист участвует сразу в нескольких проектах.
Что происходит на практике
Сотрудник за неделю участвовал в трех проектах, помогал коллегам, правил замечания заказчика, участвовал во встречах и отвечал на вопросы пользователей. В конце недели он пытается восстановить, сколько часов куда ушло.
Часть времени попадает в основной проект. Часть – в поддержку. Часть вообще не фиксируется, потому что кажется «мелочью». Но именно из таких «мелочей» часто складывается перерасход.
В отчете проект выглядит лучше, чем есть на самом деле: часть себестоимости просто не попала в учет.
Что проверить
- Как часто сотрудники фиксируют трудозатраты?
- Можно ли списать время прямо из задачи?
- Обязательна ли привязка часов к проекту и этапу?
- Разделяются ли оплачиваемые и внутренние работы?
- Фиксируются ли доработки после приемки?
- Кто контролирует полноту отметок?
- Есть ли плановые часы, с которыми можно сравнить факт?
Практический вывод
Фактические трудозатраты нужно фиксировать как можно ближе к моменту выполнения работы и в привязке к задаче, этапу и проекту. Иначе план-факт по часам и себестоимости будет приблизительным.
Причина 3. Бюджет проекта живет отдельно от задач и этапов
Еще одна типичная причина расхождений – бюджет ведется отдельно от проектного плана.
Например, финансист ведет бюджет в таблице, руководитель проекта – план работ в другой системе, исполнители – задачи в таск-трекере, а фактические расходы и оплаты отражаются в учетной системе.
Формально бюджет у проекта есть. Но он не связан с реальным исполнением.
Что происходит на практике
В бюджете заложен этап «доработки» на 100 часов. В ходе проекта появляется 40 дополнительных мелких задач: исправления после демонстрации, уточнения требований, новые варианты отчета, дополнительное тестирование, консультации пользователей.
Часть этих задач не была согласована как изменение объема. Часть ушла во внутренние работы. Часть не привязали к этапу. В итоге трудозатраты растут, но бюджет не пересматривается.
К моменту план-факта видно отклонение, но сложно понять, откуда оно взялось: из плохой оценки, изменения требований, неучтенных работ или слабого контроля объема.
Что проверить
- Есть ли бюджет в разрезе этапов?
- Связаны ли задачи с бюджетными статьями или этапами?
- Фиксируются ли дополнительные работы отдельно?
- Видно ли влияние новых задач на себестоимость?
- Пересматривается ли бюджет при изменении объема?
- Кто согласует перерасход?
- Есть ли связь между плановыми трудозатратами и бюджетом?
Практический вывод
Бюджет должен быть связан с этапами, задачами, трудозатратами и изменениями объема работ. Если бюджет живет отдельно, план-факт будет показывать цифры, но не давать управленческого объяснения.
Причина 4. Оплаты не связаны с вехами и фактическим выполнением
В проектной деятельности оплаты часто завязаны на этапы, акты, вехи или договорные события.
Например:
- аванс перед стартом работ;
- оплата после завершения этапа;
- платеж после подписания акта;
- оплата после передачи результата;
- платеж по календарному графику;
- отдельная оплата дополнительных работ.
Если оплаты ведутся отдельно от проектного плана, финансовая картина начинает расходиться с фактическим прогрессом.
Что происходит на практике
Руководитель проекта считает этап почти завершенным, но акт еще не подписан. Финансист видит плановую оплату в ближайшие дни, но не знает, что результат задерживается. Руководство смотрит на план поступлений, но не видит, какие проектные риски могут сдвинуть оплату.
Бывает и наоборот: работы фактически выполнены, но документы не подготовлены, акт не отправлен, оплата не ожидается в актуальном графике.
В итоге план-факт по оплатам не объясняет состояние проекта. Он показывает денежные отклонения, но не связывает их с работами, вехами и документами.
Что проверить
- Есть ли график плановых оплат?
- Связаны ли оплаты с этапами, актами или вехами?
- Видит ли руководитель проекта финансовый статус проекта?
- Видит ли финансист фактический прогресс по этапам?
- Учитываются ли дополнительные работы и изменения объема?
- Отражаются ли задержки актов и приемки в проектном контуре?
- Можно ли увидеть, какие оплаты находятся под риском?
Практический вывод
Оплаты нужно связывать не только с договором, но и с этапами, вехами, актами и фактическим выполнением проекта. Иначе план-факт по деньгам будет оторван от реального состояния работ.
Причина 5. Изменения проекта не фиксируются как управленческие события
Проекты редко идут строго по исходному плану. Меняются требования, состав работ, сроки, ресурсы, приоритеты, подрядчики, условия оплаты.
Проблема возникает, когда изменения просто «передаются в работу», но не фиксируются как события, влияющие на план-факт.
Типовые примеры
- заказчик попросил дополнительную доработку;
- этап перенесли из-за недоступности ключевого специалиста;
- часть работ передали более дорогому ресурсу;
- добавились внутренние согласования;
- сроки сдвинулись, но бюджет не пересмотрели;
- команда выполнила внеплановые работы, чтобы «не тормозить проект»;
- поменялся состав команды;
- появились новые требования после демонстрации.
Если эти изменения не отражены в плане, бюджете, трудозатратах и графике оплат, факт начинает расходиться с планом, а причины отклонений остаются неочевидными.
Что происходит на практике
На старте проект был прибыльным по расчетам. В середине появились дополнительные работы, несколько согласований затянулись, часть задач пришлось передать другому специалисту, а оплачиваемый объем не пересогласовали.
В конце план-факт показывает перерасход и снижение маржинальности. Но если изменения не фиксировались по ходу проекта, разбор превращается в восстановление истории: кто попросил, кто согласовал, почему не пересчитали, где потеряли часы.
Что проверить
- Есть ли история изменений по проекту?
- Фиксируются ли причины отклонений?
- Пересматриваются ли сроки и бюджет при изменении объема?
- Учитываются ли внеплановые работы?
- Видно ли влияние изменений на ресурсы?
- Видно ли влияние изменений на маржинальность?
- Есть ли правила согласования дополнительных работ?
Практический вывод
Изменения нужно фиксировать с последствиями: что изменилось, почему, кто согласовал, как это влияет на сроки, ресурсы, бюджет, оплаты и себестоимость.
Как сделать план-факт полезным: минимальный набор правил
Чтобы план-факт был не формальным отчетом, а инструментом управления, важно договориться о правилах сбора данных.
Минимальный набор:
- Планировать проект не только общей суммой, но и по этапам.
Так проще понять, где именно возникает отклонение. - Привязывать задачи к этапам и вехам.
Тогда фактические работы можно сопоставить с исходной структурой проекта. - Фиксировать плановые трудозатраты до старта работ.
Без плановых часов невозможно корректно анализировать перерасход. - Собирать фактические трудозатраты регулярно.
Желательно – в контексте задачи, этапа и проекта. - Разделять оплачиваемые и внутренние работы.
Это важно для расчета себестоимости и маржинальности. - Привязывать оплаты к этапам, актам или вехам.
Тогда денежный поток будет связан с фактическим выполнением. - Фиксировать изменения объема, сроков и бюджета.
Иначе причины отклонений будут теряться. - Сравнивать план и факт не только по деньгам.
В проектном учете важны сроки, часы, этапы, оплаты, себестоимость и ресурсы. - Использовать одну версию данных для РП, финансов и руководства.
Если каждый контур живет отдельно, план-факт быстро превращается в спор о цифрах.
Проверьте свой план-факт
Небольшой чек-лист для самодиагностики:
- План проекта разбит на этапы, к которым можно отнести фактические работы?
- У каждой задачи есть связь с проектом и этапом?
- Плановые трудозатраты заданы до начала работ?
- Исполнители фиксируют фактические часы регулярно?
- Есть разделение оплачиваемых и внутренних работ?
- Бюджет связан с этапами и задачами?
- Оплаты связаны с актами, вехами или результатами?
- Изменения объема работ фиксируются отдельно?
- Можно увидеть отклонения по срокам, часам, бюджету и себестоимости?
- Руководитель проекта и финансы используют одну и ту же версию данных?
Если на большую часть вопросов ответ «нет» или «только вручную», план-факт будет скорее формальным отчетом, чем инструментом управления.
Вместо вывода
План-факт по проектам не сходится не только из-за ошибок в расчетах. Чаще причина в том, что план и факт собираются из разных контуров.
План – в таблице.
Задачи – в таск-трекере.
Часы – по памяти.
Оплаты – в учетной системе.
Изменения – в переписке.
Решения – на совещаниях.
В такой схеме отчет может показать отклонение, но не всегда объяснит, откуда оно появилось и что с ним делать.
Чтобы план-факт помогал управлять проектом, проект должен быть единым объектом учета. К нему нужно привязывать структуру работ, задачи, трудозатраты, ресурсы, бюджет, оплаты, изменения и отчетность.
Тогда план-факт становится не итоговой таблицей для разбора ошибок, а рабочим инструментом: показывает отклонения вовремя, помогает управлять себестоимостью и дает руководителю возможность принимать решения до того, как проект ушел в минус.
Приглашаем на вебинар
Если вам актуальна тема проектного план-факта, приходите на вебинар «Простая система управления проектами в 1С: от плана и задач до ресурсов, бюджета и себестоимости».
Покажем, как в едином контуре на 1С можно связать план проекта, задачи, трудозатраты, ресурсы, бюджет, оплаты, себестоимость и управленческую отчетность.