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