Pull to refresh

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

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

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




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

Метафоры


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

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

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

Горизонты мышления


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


Операционный уровень

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

Проектный уровень

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

Контроль выполнения


Для чего нужен контроль и какие результаты контроля мы должны получить?

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


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

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

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

Как часто проводить контроль?

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

Вывод


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

Оба эти подхода должны использоваться в проектной деятельности.
Tags:
Hubs:
+23
Comments60

Articles

Change theme settings