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

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

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

Таск-трекер отвечает на вопрос: «что нужно сделать и кто за это отвечает?»
ИСУП отвечает на более широкий вопрос: «как компания управляет проектами как системой: сроками, ресурсами, трудозатратами, бюджетом, изменениями, рисками и результатом?»

Задача – это элемент исполнения, а не модель проекта

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

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

Например, задача может быть закрыта вовремя, но при этом:

• на нее потратили в два раза больше часов, чем планировали;

• ее выполнил специалист, который должен был работать на другом критичном проекте;

• из-за нее сдвинулась зависимая задача;

• она увеличила себестоимость проекта;

• ее результат не приблизил проект к контрольной вехе;

• изменение не было отражено в плане и бюджете.

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

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

Что обычно хорошо делает таск-трекер

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

• постановка задач;

• назначение исполнителей;

• контроль статусов;

• обсуждения и комментарии;

• вложения и файлы;

• дедлайны;

• уведомления;

• доски и списки;

• базовая прозрачность для команды.

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

Руководителю проекта нужно понимать не только «что в работе», но и «где мы относительно плана». Руководителю проектного офиса – где системные отклонения и перегрузка ресурсов. Руководителю направления – какие проекты требуют вмешательства. Директору – что происходит с портфелем, сроками, затратами и рентабельностью. Эти вопросы уже не про список задач. Они про ИСУП.

Что такое полноценный контур управления проектами

Полноценная ИСУП – это не «таск-трекер с диаграммой Ганта». Это система, в которой проект рассматривается как управленческий объект. Такой контур обычно включает несколько связанных уровней.

1. Структура проекта

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

• проект;

• этапы;

• подэтапы;

• задачи;

• подзадачи;

• вехи;

• зависимости;

• контрольные точки;

• ответственные роли.

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

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

2. Планирование и перепланирование

Проектное управление начинается не с постановки задач, а с планирования. План проекта отвечает на вопросы:

• что должно быть сделано;

• в какой последовательности;

• к каким датам;

• какие работы зависят друг от друга;

• где находятся контрольные точки;

• какие ресурсы нужны;

• что будет считаться отклонением.

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

• сравнивать план и факт;

• видеть сдвиги сроков;

• обновлять связи между задачами;

• использовать шаблоны типовых проектов;

• анализировать последствия перепланирования;

• понимать, какие вехи находятся под угрозой.

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

3. Ресурсное планирование

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

• хватает ли людей на все проекты;

• кто перегружен;

• где будет дефицит через две недели;

• какие проекты претендуют на одних и тех же специалистов;

• какие роли нужны на следующих этапах;

• можно ли запускать новый проект без риска для текущих;

• как изменение сроков в одном проекте повлияет на другие.

Таск-трекер обычно показывает назначение исполнителя. ИСУП должна показывать ресурсную картину.

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

4. Учет трудозатрат

Статус задачи показывает, выполнена она или нет. Но он не показывает, сколько проекту стоило ее выполнение. Для проектного управления важны трудозатраты:

• сколько часов планировали;

• сколько часов потратили фактически;

• кто выполнял работу;

• на каком этапе возникло отклонение;

• какие задачи оказались дороже ожидаемого;

• как фактические трудозатраты влияют на себестоимость;

• где команда регулярно недооценивает объем работ.

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

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

5. Финансовый контур проекта

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

• бюджет проекта;

• плановые доходы и расходы;

• фактические расходы;

• ожидаемые и фактические оплаты;

• платежные события;

• трудозатраты;

• себестоимость;

• маржинальность;

• план-факт;

• рентабельность.

В таск-трекере можно увидеть, что команда работает. Но руководителю важно понимать, как эта работа влияет на экономику проекта. Например:

• проект идет по срокам, но трудозатраты выше плана;

• оплаты от заказчика задерживаются;

• внутренние работы не были учтены в бюджете;

• часть задач выполняется за счет более дорогих специалистов;

• проект требует дополнительных работ, которые не попали в договор;

• маржинальность снижается, хотя формально прогресс по задачам нормальный.

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

6. Роли и рабочие места

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

Исполнителю нужен понятный список задач: что делать сегодня, что в приоритете, какие вводные есть, куда внести результат.

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

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

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

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

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

7. Методология

Еще одно важное отличие ИСУП – наличие методологической основы. Если каждый руководитель проекта ведет проекты по-своему, компания быстро сталкивается с проблемами:

• разные структуры планов;

• разные правила постановки задач;

• разные статусы;

• разные подходы к вехам;

• разная детализация;

• разные отчеты;

• разные правила учета трудозатрат;

• разные критерии завершения этапов.

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

• жизненные циклы задач и этапов;

• типовые шаблоны проектов;

• роли и зоны ответственности;

• контрольные точки;

• правила учета трудозатрат;

• правила план-факт анализа;

• типовые отчеты;

• требования к заполнению данных;

• порядок согласования изменений.

Это не отменяет гибкости. Но гибкость должна существовать внутри понятной управленческой рамки.

8. Отчетность и управляемость

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

В полноценной ИСУП отчетность должна собираться из тех же данных, с которыми каждый день работают участники проекта:

• плановые и фактические сроки;

• статусы задач;

• вехи;

• трудозатраты;

• загрузка ресурсов;

• бюджет;

• оплаты;

• расходы;

• отклонения;

• риски;

• комментарии и решения.

Тогда отчетность становится не отдельным ритуалом, а результатом нормального ведения проекта.Это и есть управляемость: руководитель видит не просто активность команды, а состояние проекта и причины отклонений.

Когда таск-трекера становится недостаточно

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

Например:

• проекты ведутся в разных инструментах, а общая картина собирается вручную;

• задачи есть, но календарный план и вехи живут отдельно;

• руководители не видят реальную загрузку специалистов;

• одни и те же люди перегружены несколькими проектами;

• трудозатраты фиксируются нерегулярно или не связаны с экономикой проекта;

• бюджет проекта ведется отдельно от задач и этапов;

• себестоимость становится понятна только после завершения проекта;

• отчеты готовятся в Excel и быстро устаревают;

• каждый РП использует свою структуру проекта и свои правила;

• руководитель видит список задач, но не видит, какие проекты прибыльны, а какие нет;

• изменения в сроках не связаны с анализом последствий для ресурсов и бюджета.

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

Задачи не равны проектному управлению

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

• структуры проекта;

• планирования;

• управления зависимостями;

• ресурсного планирования;

• учета трудозатрат;

• финансового контура;

• методологии;

• отчетности;

• управленческих ролей;

• анализа отклонений;

• связи с учетными системами.

Таск-трекер помогает команде выполнять работу. ИСУП помогает компании управлять проектной деятельностью. Это разные уровни зрелости.

Вместо вывода

Таск-трекер не нужно воспринимать как «плохой» или «недостаточный» инструмент. Он решает свою задачу: помогает организовать исполнение.Но когда компании нужно управлять проектами как бизнес-процессом, одного операционного слоя становится мало. Появляется потребность в системе, которая связывает задачи с планами, ресурсами, сроками, трудозатратами, бюджетом, себестоимостью, отчетностью и методологией. Именно такую роль играет ИСУП.

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

Если хотите разобраться, как такой контур может выглядеть на практике, приходите на вебинар «Простая система управления проектами в 1С: от плана и задач до ресурсов, бюджета и себестоимости».

Разберем, как в системе управления проектами на 1С можно вести проект от структуры работ и задач до трудозатрат, ресурсов, бюджета, себестоимости и отчетности для руководителей.