Управление проектами: операционный vs. проектный подход

В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта. В этом посте проведу более детальное сравнение операционного подхода с проектным.

1. Операционный уровень — это уровень операций длительностью несколько часов (обычно называемых «тасками») и проблем, возникающих по мере выполнения этих задач. На этом уровне скапливается много «мелочовки», здесь некогда думать, нужно быстро выполнять. 2. Проектный уровень — это уровень работ длительностью несколько дней, блоков работ и контрольных точек. На этом уровне нужно больше анализировать, прогнозировать, нежели скорее запускать задачу в работу. Здесь также решаются проблемы, проводится дополнительная работа с рисками. 3. Программный уровень — это уровень куратора проекта или менеджера программы/портфеля, который в меньшей степени погружен в проект, и его как правило интересует прохождение контрольных точек, решение крупных проблем и рисков. 4. Ручное управление. Это самый простой, однако и самый влиятельный подход по сравнению с другими. Если «вождь» отдал поручение, то оно обязательно к исполнению, не важно что там в планах и программах. Вся работа строится на поручениях менеджера. Нет поручений — нет работы. Внимание! Все перечисленные подходы применяются при управлении проектом, а не какой-то один конкретный из них.

Ручное управление Образ — указать рукой на то, что нужно делать.

Операционное управление Образ — конвейер. Мы настраиваем работу конвейера. Формируем задачи, передаем их в конвейер, а он дальше самостоятельно распределяет их между освободившимися участниками команды. Главный принцип:«Нормально делай — нормально и будет».

Проектное управление Образ — профессиональная игра в бильярд, когда игрок делает партию с кия. Нужно просчитать всю серию и сложить ее с кия. Если вы неправильно вышли на следующий шар, то прежде чем забить следующий шар, вы должны по-новой просчитать серию и только после этого забивать шары. То есть в проектном управлении вы должны не только осуществлять операционное управление (забивать шары), но и просчитывать ситуацию на несколько ходов вперед, всегда ориентируясь на последний шар (конечный результат).

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

На этом уровне менеджер обычно имеет некий список тасков. Закрыв одну задачу, менеджер передает очередную задачу освободившемуся сотруднику. Для себя менеджер обычно выделяет первостепенные задачи и снова передает их в конвейер, на котором работают члены команды проекта. Итак, горизонт мышления — набор первоочередных операций («тасков»)

Проектный подход подразумевает под собой контроль всего проекта целиком. Однако на на практике для проектов длительностью около года и более не всегда целесообразно держать весь проект в поле зрения. Поэтому в таких ситуациях применяется метод «набегающий волны». Вначале берется в работу один этап, он детализируется на более мелкие работы(длительностью 2-3 месяца). Затем выполняется работа по управлению преимущественно только этим этапом. А затем при переходе на следующий этап «приходит следующая волна» и процесс повторяется снова. Однако проектный подход не ограничивается только управлением текущего этапа, периодически нужно смотреть в далекое будущее — на следующие этапы. Итак, горизонт мышления — этап проекта (проект целиком — для небольших проектов).

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

Результатами процесса контроля должна быть следующая информация: — Статус (что выполнено, какие проблемы возникли?) Содержание: что выполнено Сроки: сколько времени было затрачено Стоимость: сколько денег было затрачено Изменения: какие запросы на изменения появились (с оценкой влияния на содержание/сроки/стоимость) Проблемы: какие проблемы возникают и другое

— Отклонения (что не успели выполнить или перевыполнили?) Содержание: что не успели выполнить/перевыполнили относительно планируемого Сроки: на сколько времени отстали/опередили? сколько времени нужно, чтобы доделать запланированное Стоимость: сколько денег было перерасходавано/сэкономлено? сколько средств нужно, чтобы доделать запланированное и другое

— Прогноз (что будет в будущем, когда и как будут пройдены контрольные точки, какие проблемы могу возникнуть?) Содержание: какие результаты будут достигнуты в будущем Сроки: когда будут пройдены контрольные точки Стоимость: сколько денег будет потрачено на проект в контрольных точках Изменения: перечисленные выше прогнозы должны быть приведены с учетом включения изменений Проблемы: какие риски и как на них реагировать (риски — это и есть возможные проблемы и возможности в будущем) и другое

Контроль операций — проводить постоянно. Контроль проекта — регулярно (1 раз в неделю, 1 раз в 2 недели).

На операционном уровне менеджер управляет только незначительной частью проекта, так как операций очень много, оставляя вне поле зрения оставшуюся часть проекта. Он не может объективно измерить отклонения и сделать прогнозы для всего проекта (или этапа проекта). А тем, что невозможно измерить и нельзя предвидеть — нельзя и управлять. На проектном уровне менеджер измеряет отклонения, делает прогнозы проекта и соответственно может эффективно управлять этим.