Публикация Школы траблшутеров

Подробное руководство по внедрению проектного управления с нуля

Время чтения: 8 мин 30 сек
16 ноября 2023 г. Просмотров: 559

Проекты, Управление | Даниил Шмитт, Владислав Иванов

Зачастую в компаниях отсутствует понимание разницы между проектами и процессами. В результате деятельность неэффективна, а нововведения – буксуют. В нюансах разбираются управляющий партнёр «Школы траблшутеров» Даниил Шмитт и ученик Владислав Иванов.

Процессная эффективность – залог оптимального выполнения операций. Требует неоднократного повторения действий и времени для получения опыта и знаний для анализа и совершенствования типовой деятельности. А что делать с новыми видами активностей и внедрением изменений?

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

Фирма, попросившая внедрение, на рынке уже 25 лет. Занимается производством и поставкой продукции по территории России. Имеет несколько производственных комплексов в разных регионах. Офисные сотрудники в большинстве своём работают из дома. Штат – 350 человек.

К счастью, предшественники продали топ-менеджерам методику каскада в исполнении PMBoK и модный Scrum. Также компания тяготела к Адизесу и сотрудничала с его адептами. Каскадное управление проектами – поэтапное движение, когда всё идёт последовательно. Похоже на водопад.

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

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

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

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

Product Owner – владелец продукта, отвечает за взаимодействие команды разработки (Dev Team) и заказчика. Также в его зону ответственности входит поиск необходимых ресурсов и составление требований к конечному результату.

Scrum Master – лидер поддержки, помогает команде работать согласно идеологии Scrum. Служит барьером для интервентов: коммуникации со внешним штатом компании происходят через него.

Dev Team – команда разработчиков (исполнителей). Самодостаточные сотрудники, обладающие полным спектром компетенций и навыков для реализации проекта. По ряду вопросов могут обращаться к аутсорсингу. Подробнее описание:

Теперь рассмотрим инструменты:

Подробнее о Scrum

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

Backlog – список всех историй, возникающих в рамках проекта. Существует несколько методик для оценки и сортировки накопленного массива.

Ретроспектива – обычно происходит в последний день типового временного отрезка – спринта. Команда анализирует проделанную работу, отмечает нерешённые проблемы. Scrum-мастер готовит диаграмму сравнения намеченного плана и реального выполнения задач.

Burndown-диаграмма – график прогресса команды за спринт. По горизонтали указывается временной промежуток, по вертикали – оценка запланированных и реализованных задач в Story Points (SP).

Sprint – единица времени, цикл, в рамках которого команда занимается созданием результатов по отобранным на данный период пользовательским историям.

Story Point – условная единица, используемая для оценки задач и расчёта производительности команды в рамках спринта.

Подробнее об инструментах по Адизесу

Список PIP’ов – проблемные вопросы в операционной деятельности компании. Собирается из всех отделов, состоящих в POC. Ранжирование – на основе таблицы атрибутивного анализа.

Встречи POC – обычные совещания, их цель – выбор проблемы и определение состава команды-решателей.

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

График сессий – расписание совещаний, а документ POC – итоговый файл, в котором отображаются результаты SynerTeam по итогам проекта. Также в нём фиксируют участников команд и проблему, с которой следует справиться.

На основании сравнения сделали вывод, что методика Адизеса больше фокусируется на разрешении операционных задач, улучшении текущих постоянных процессов компании. Поэтому решили отказаться от неё и сфокусироваться на каскаде и Scrum.

Вспомнив китайских мудрецов, поработали с ключевыми терминами: составили глоссарий на основании определений учебников и пособий:

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

Следующим шагом приступили к формированию процесса управления проектами. Ввели критерии последнего с разделением на каскад и Scrum. Исходя из этих критериев руководитель проекта должен был выбрать методику.

После приступили к описанию процессов каждой стадии проекта. Общую схему поместили в IDEF0:

Остальные этапы сделали в BPMN. Инициирование:

Планирование:

Реализация:

Закрытие проекта:

Затем создали управляющий орган – Проектный комитет. Определили задачи и состав. Так как компания не крупная, то участниками заседаний стали топ-менеджеры в лице генерального, финансового и коммерческого директоров и учредители компании – ещё три человека.

Для комитета разработали правила работы:

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

И в самом конце сформировали пакет документов для проекта:

  • Матрица ответственности участников проекта
  • Акт приёмки результатов проекта
  • Паспорт проекта
  • Бюджет проекта
  • План проекта.

Для запуска собрали приказ «О внедрении и использовании инструментов проектного управления». Запустили на согласование с руководителями. После передали на подпись генеральному. Опубликовали. Регламент решили выпустить через год, чтобы компания поднабралась опыта.

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

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

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

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

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

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

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