Управление проектами для руководителей

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

Мое знакомство с управлением проектами складывалось по-разному. Я выступал экспертом при внедрении систем управления проектами на базе Microsoft Project, окончил профильные курсы, читал PMBOK и некоторое время активно изучал это направление, размышляя, не сделать ли его своей профессией.

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

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

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

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

В мире написаны тысячи книг по управлению проектами. Существуют развитые стандарты, профессиональные сертификации и методологии - PMBOK, PRINCE2, PMP. Но в повседневной работе большинство руководителей сталкиваются с проектами, даже не называя их проектами. Запуск продукта, внедрение информационной системы, переезд офиса, ремонт помещения, создание нового подразделения или выполнение крупного заказа для клиента - все это проекты.

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

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

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

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

В проектной деятельности организация обычно выступает в одной из трех ролей:

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

2. Исполнитель реализует проект для себя или для внешнего заказчика.

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

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

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

Поэтому до планирования работ руководитель должен ответить на три вопроса:

- какой результат мы хотим получить;

- к какой дате он нужен;

- какие ограничения нельзя нарушить (бюджет).

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

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

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

Веб-система устраняет проблему версий: каркас проекта всегда доступен в одном месте. Например, в АСК Легарус реализовано также удобно как в MS Project - задачи можно быстро накидать, выстроить иерархию, связать между собой, задать начало и окончание и распланировать ресурсы в табличном виде или прямо на диаграмме Ганта. После декомпозиции часто выясняется, что первоначальная дата нереалистична. Тогда руководитель может либо пересмотреть срок проекта, либо упростить состав работ, либо добавить ресурсы.

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

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

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

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

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

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

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

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

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

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

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

Допустим, задачу планировали выполнить в марте за 40 часов. Позже стало понятно, что она завершится в апреле и потребует 80 часов. Текущий план показывает новый прогноз, а сравнение с базовым - масштаб отклонения. Для проекта с десятками или сотнями связанных задач это особенно важно: перенос одной работы способен сдвинуть весь график.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Точно сформулировать цель, ожидаемый результат и дату, после которой результат теряет актуальность.

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

3. Декомпозировать проект на связанные задачи, этапы и контрольные точки.

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

5. Согласовать и сохранить базовый план.

6. Регулярно фиксировать прогресс, трудозатраты и финансовые операции.

7. Контролировать прогноз завершения, риски и состояние всего портфеля, а не только красивый отчет за прошлый период.

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

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

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