Хочу рассказать, как наша команда в действительности работает с проектами. Используем ли знаменитые методологии? Следуем им полностью или берем из них понравившиеся приемы? Предлагаю собственную схему работы над проектом, которая является компиляцией приемов из известных методологий, составленных и дополненных с учетом собственного опыта и опыта коллег.
Целью данной публикации является обмен опытом, поэтому буду рада получить в комментариях мнение, оценку и советы от членов Сообщества.
1. Определить цель – что хотим получить от реализации проекта?
Проект должен быть оценен с точки зрения его влияния на реализацию целей компании. Определение этой цели находится в компетенции руководства.
Почему важно иметь четкое определение и фиксацию этой цели? Это поможет всем участникам процесса внутри компании (руководству проекта и членам проектной группы) правильно понять место проекта в жизни компании и свой статус. Что проектная группа – это не просто центр затрат, на содержание которой придется вычесть из суммы контракта. Проектная группа приносит профит – достигает цели за счет того, что управляет проектом, который непосредственно связан со стратегией компании.
2. Определить общие задачи
Для этого руководителю проекта нужно ответить на вопрос: «Что нужно сделать, чтобы достичь цели?». Задачи могут быть такими:
- Качественное и прозрачное управление проектом.
- Недопущение того, чтобы контроль реализации проекта превратился в излишнюю бюрократию.
- Развитие проектной методологии.
- Сокращение сроков реализации проекта.
- Оптимизация ресурсов при реализации проекта.
- Обучение сотрудников в процессе деятельности.
Это те задачи, которые отвечают за получение профита, но не прописаны в техническом задании проекта. Это нужно для того, чтобы иметь ориентир и возможность отчитаться, как проектная группа смогла повлиять на достижение стратегических целей компании.
3. Определиться – на чем зарабатываем, а на чем экономим
Проектная группа должна зарабатывать для компании или экономить при реализации проектов? Если рассчитывать именно на профит, то – зарабатывать. Но обстоятельства заключения контрактов могут быть разными, поэтому иногда может стоять только задача сэкономить.
На чем можно заработать:
- Краткосрочное – дополнительные работы.
- Долгосрочное – новые контракты с более выгодными условиями, дополнительные сферы (ответвления) деятельности, которые удалось освоить в процессе работы над проектом.
На чем можно сэкономить:
- За счет централизованной работы с рисками. Если анализ покажет, что на всех проектах компании повторяются примерно одни и те же риски, то можно заложить под них общий бюджет, это выйдет меньше, чем учитывать каждый отдельно.
- За счет ускорения реализации проектов.
На чем нельзя экономить: на качестве.
Заработанные и сэкономленные деньги необходимо показывать отдельно в бюджетах и отчетах – для наглядности результата работы проектной группы, а также для мониторинга, оценки и коррекции выбранного пути.
4. Сформировать бюджет проекта
В этом вопросе у каждой отрасли и направления свои нюансы, но для примера следующая возможная схема:
- Для простых объектов с небольшой ценой и коротким сроком исполнения из суммы контракта сразу выделяется процент, планируемый как прибыль.
- Для сложных длительных проектов каждый этап рассчитывается отдельно и прикидываем, на чем сможем заработать больше, на чем меньше.
- Далее идет детальная оценка основных видов работ, которая опирается на данные из справочников базовых цен и опыт. Утверждается общая сумма расходов.
- Получив примерную разбивку по стоимости, делаются запросы коммерческих предложений и устраиваются тендеры, по результатам бюджет может быть откорректирован в деталях.
- Утверждается детальная разбивка бюджета для дальнейшего исполнения. Одновременно разрабатывается и утверждается регулятор расхода денежных ресурсов (подробнее в шаге 9).
5. Составить методологию управления проектом
Существует множество методологий по управлению проектами: классическая каскадная модель, Agile, Метод критического пути, PMBOK и другие. Некоторые возведены их авторами в статус философии, например Six Sigma, а некоторые в большей степени относятся к инструментам, например Kanban, Scrum.
Насколько вообще эти методологии соотносятся с реальностью? Ведь управление проектом происходит не в вакууме, компания-исполнитель может выбрать определенную методологию, но к ней окажется не готов заказчик, кредитующий банк, смежные структуры и пр. Также выбор может быть ограничен условиями контракта. Мало шансов, что какая-то одна из существующих известных методологий подойдет на 100%.
В идеале, выбранная методология должна устроить всех участников, удовлетворив запросы каждого, значит, придется компилировать. Поэтому сначала определяем, какой подход предпочтителен для каждой стороны, и выделяем блоки основных участников, например:
- Внешние участники: заказчик, банк, госструктуры.
- Внутренние участники: руководитель проекта, сотрудники (проектная группа), субподрядчики, руководство компании.
Для заказчика, банка, госструктур
В условиях повышенной неопределенности и постоянно меняющихся рисков традиционный линейный подход и каскадный метод стали неэффективны для управления сложными проектами и их жизненными циклами. Основной их недостаток – негибкость. Однако, они привычны для большинства структур, с которыми придется работать, особенно удобны для заказчика благодаря следующим качествам:
- Четкая фиксация сроков и финансирования.
- Удобство контроля исполнения и ведения отчетности.
- Заказчик активно работает только на старте и на финише, а в остальное время только контролирует процесс.
Теоретически можно убедить заказчика, что линейный метод не эффективен для конкретного проекта, но и сам заказчик может быть ограничен в своих решениях по поводу выбора методологии и отчетностей. В этом случае принимаем его выбор как неизбежность.
Для руководителя проекта
Метод критического пути – методология, подходящая для проектов с большим количеством параллельных взаимосвязанных задач. Здесь для работы важна роль и квалификация руководителя проекта, ведь его силами разрабатывается иерархия задач:
- Определяются начальная, конечная и критические точки проекта.
- Рабочий цикл разбивается на отдельные конкретные задачи и назначается оптимальная последовательность их выполнения.
- Выбирается, какие задачи могут идти параллельно, а какие только последовательно.
- Определяется, какие задачи первостепенные, а какие могут быть выполнены позже.
- Каждому виду работ присваивается срок.
Такой подход позволяет быстрее адаптировать исполнение проекта к меняющимся обстоятельствам, иметь запас по срокам, при необходимости можно быстро делать «срезы».
Для проектной группы внутри компании
Самая человечная из систем – это Agile. Гибкая методология, подразумевающая цикличную работу, в которую легко вносить изменения. Разработана в противовес жесткой каскадной системе. По сути, это свод принципов работы, где во главе находится деятельность в команде, а важность личности ставится выше процесса.
Такая система хороша для внутренних проектов, но не подойдет проектам с множеством внешних участников. Поэтому из нее берем принципы только для внутренней работы над отдельными задачами. Так получаем методику адаптивного управления, которая позволяет изменять параметры регулятора в зависимости от изменения параметров объекта управления или внешних обстоятельств. Это позволит исполнителям чувствовать себя защищенными в условиях факторов, на которые они влиять не могут, и гарантирует, что их интересы учитываются наравне с интересами заказчика, что мотивирует участников.
Для достижения стратегических целей компании
В списке стратегических целей, наверное, любой компании есть улучшение процессов и устранение недостатков. Здесь удобнее использовать подход «Шесть сигм». Six Sigma создан для управления качеством, суть которого сводится к необходимости улучшения качества выходов каждого из процессов, а также минимизации дефектов и статистических отклонений. Достигается это за счет постоянного внесения улучшений.
6. Определить экстремальные точки проекта
Согласно методу критического пути, руководителем проекта сначала определяется наиболее длительная последовательность задач от начала проекта до его завершения, с учетом их взаимосвязи. Другими словами: выделяются задачи, лежащие на критическом пути (критические задачи), они имеют нулевой резерв времени выполнения, и, в случае изменения их длительности, изменяются сроки всего проекта. Поэтому критические задачи требуют предварительного выявления рисков и тщательного контроля.
7. Сформировать техническое задание
- Подготовить подробное техническое задание на все задачи. За основу берется ТЗ из контракта и тщательно прорабатывается, добавляются подробности, уточняются детали.
- Подготовить подробное анти-ТЗ – список того, что не приемлемо. Этот пункт необязателен, но может послужить дополнительным ориентиром и будет полезен в спорных ситуациях.
8. Определить риски
Общий опыт показал, что малоэффективно управлять рисками отдельно от управления проектом. Самый продуктивный подход – это интеграция управления рисками в процесс принятия решений.
Есть два основных типа рисков:
- Полноценные риски – те, что приходят извне: изменения в законодательстве, действия участников рынка, военные конфликты, природные катаклизмы... Риски этой группы действительно трудно прогнозируемы, поэтому здесь определяющую роль играет не точность прогнозов, а скорость и адекватность реакции.
- Риски, пришедшие изнутри компании. В большинстве случаев, эти обстоятельства не создают значимой неопределенности, т.к. являются частью повседневной работы по управлению отклонениями, изменениями и обеспечению требуемого функционирования процессов. Для контроля необходимо сформировать набор регуляторов.
9. Сформировать набор регуляторов
В нашем случае, регулятор – это элемент системы управления, вырабатывающий сигналы и позволяющий следить за состоянием проекта, основываясь на заранее заданном уровне качества управления. Основные регуляторы – это контроль сроков, качества, расхода ресурсов.
Подготовка регуляторов требует времени, поэтому не всегда возможно запустить их в начале проекта, но важно иметь их как можно раньше и ознакомить заинтересованных участников.
Первым из набора регуляторов является контроль сроков, поэтому на старте проекта разрабатывается график, который регулирует сроки всего жизненного цикла проекта, где отдельно фиксируем:
- Контроль срока входа (получение задания, исходных данных, дополнительной информации, способной повлиять на ход проекта).
- Контроль срока выхода (выдача промежуточных и итоговых результатов).
Важность контроля входа в том, что вход – это результат чужого процесса, содержащий много неизвестных. Контроль выхода важен, если в компании нестабильны процессы: текучка кадров, новые технологии, а также если реализуемый проект является уникальным.
Следующим разрабатывается регулятор для контроля полноты и качества входящих материалов (удобно, когда он в виде чек-листа, по нему принимается вся исходная документация). Далее разрабатывается регулятор для контроля качества исходящих материалов (стандарт качества и список приемлемых и не приемлемых отклонений).
И наконец, регулятор для контроля расхода ресурсов:
- Контроль расхода денежных ресурсов, основывается на утвержденном детальном бюджете и дополняется инструкцией, регламентирующей порядок перераспределения сумм и использования средств из графы «непредвиденные расходы».
- Контроль расхода человеко-часов – основывается на графике жизненного цикла проекта.
Работа с регуляторами – это сравнение/сопоставление итогового/фактического результата с плановым/ожидаемым. В случае выявления отклонения не искать виноватых, а искать способ улучшить ситуацию, контролировать не людей, а процесс, поэтому, если недостатки выявлены, алгоритм такой:
- Откорректировать процесс.
- Если первый пункт не сработал, следует заменить участников процесса.
10. Выстроить работу со сторонами взаимодействия
Тезисы, которые помогут выстроить взаимодействие и послужат принципиальными выводами к данной методологии:
- Стороны взаимодействия: заказчик, его подрядчики, надзорные органы, госструктуры, ресурсоснабжающие организации, субподрядчики, собственные сотрудники. Все находятся в равных партнерских отношениях. У всех сторон в цепочке зависимость круговая, а не линейная.
- Руководитель проекта в этой цепочке – тот, кто запускает, контролирует и завершает процесс. Он – руководитель процесса, но не людей, а рациональный баланс между контролем и взаимодействием помогут выстроить описанные выше регуляторы.
- Работа подрядчика себе в убыток ослабляет позицию подрядчика в глазах заказчика, независимо от статуса заказа.
- Как ни настраивай процессы, человеческий фактор все равно будет иметь место. В основном работу усложняют два элемента: некомпетентность и отсутствие желания что-то делать. Прежде чем менять людей, необходимо выяснить причины их нежелания работать.
- Проекты – это всегда о новом, о том, чтобы при необходимости выходить за рамки регламентов и типовых схем, создавая новые.
Также читайте:
И что? О чем собственно статья? Точнее по другому - что в ней уникального, чего бы не было написано 100500 раз? Уникальная экспертиза? Личные особенные фишки? Так то понятно: "чтобы получить товар - надо сделать заказ...".
Если читать медленно и внимательно, то новое и неожиданное можно найти практически в каждом абзаце.
Например,
Или
Впечатляюще, но голова кружится.
Интересно, какими проектами руководил автор.
Евгений, спасибо
Последние на данный момент: управление проектированием (генпроектировщик) и авторское техническое сопровождение строительства зданий Сбера на Кутузовском
Понял. Какие методологии PM Вы используете?
Станислав, спасибо за обратную связь, она имеет огромное значение. Целью публикации методологии было в т.ч. узнать, как она выглядит в глазах коллег, т.к. знакомлю с ней руководителей, заказчиков, инвесторов. Поэтому на большой аудитории заранее хочу обкатать возможные вопросы и внести в методологию соответствующие корректировки.
Про методологию: идея была в том, чтобы отказаться от гонки уникальностей, фишек и пр. Абстрагироваться от Вау-эффекта и оставить только очищенный от всего лишнего, абсолютно оптимизированный процесс
Вопрос про PM - в смысле Project Management? Если правильно поняла, то вот:
Методология объемнее, чем статья, чтобы уместить ее в разрешенные 14 тыс. символов, пришлось сильно порезать, пожертвовала в т.ч. подробностями описания что для чего
Впечатляет!
И статья убедительна. Однако не оставляют некоторые сомнения первые три пункта. Вроде и спорить не о чём, всё верно. Прикидывал и так, и сяк.
Ну так как Вы решили "обкатать вопросы", то поделюсь. Мне кажется это важным.
Понятно, что без цели планировать проект невозможно. И вы верно пишете, что это компетенция руководства. Тогда зачем вы это выносите первым пунктом? Ведь и Вас пригласили на строительство объектов не для определения целей проекта. Разве не так? Ваша задача не определить цели, а достигнуть с некоторыми параметрами - цена, срок, качество.
Если Ваши рекомендации для руководства, то зачем пункт следующий:
Я не думаю, что перечисленные примеры задач/подзадач важны и нужны. У проекта не может быть задачи "качественнгое и прозрачное управление". Если нет, конечно, желания "концы в воду" - так тоже бывает, увы. )))
Мне показалось, что в статье постянное перемещение от советов руководству/владельцу к советам руководителю проекта. Может что-то лишнее?
Если вы руководитель проекта, то вы расчитываете на выделенные ресурсы, а не планируете на чём-то экономить. Ну разве не так?
Статья очень интерсная. И у меня есть всегда особое пристрастие. Не люблю, когда Agile всовывают в любую щель: "Кабы не клин, да мох, так бы и плотник сдох". Даже у нас тут есть один специалист во всём, кандидат в науку. Но Вы очень аккуратно описали применение этой методики. Мне понравилось.
И создать абсолютно безликий, ничем не выделяющийся на общем фоне контент? ;)
Доброго дня.
Как-то непочтительно к Ганту... Календарный график необходим не только для "отчитаться перед Заказчиком", -- он необходим для планирования последующих после проектных работ и понимания, в какой момент какой раздел будет получен Заказчиком (для РД) или текущий прогресс в разработке ПД (вовремя выводить из бесконечного цикла итераций, чтобы к сроку получить проект, а не MVP).
Agile с подрядчиками -- просматривается возможность для эскизного проектирования, и то необходим График, чтобы ограничивать "полет фантазии", а остальные стадии проектирования -- Задание и Сроки, иначе есть большой риск не получить даже MVP...
Никогда нельзя понять, Евгений, когда Вы шутите, а когда серьезно...