Хорошо бы сделать ветку отличие Проектного управления от операционного.
В одной из компаний даже был курс «Проектный менеджмент для операционных менеджеров».
На мой экспертный взгляд многие менеджеры занимаются управлением операциями проекта в рамках проекта, но не занимаются проектным управлением. Увидев такие отличия, они бы выяснили основные пробелы в своей деятельности и направления для совершенствования.
waterfall — каскадная модель управления проектами (содержащая 1 итерацию), scrum — итеративная модель.
Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.
Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
Спасибо за замечание.
Поправил схему.
В идеале должно быть так.
1. Принято решение «Отложить»
2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
Процедура может повторится еще 2 раза.
3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)
На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
1. В идеале нужно применять средства автоматизации. (Мы используем MS Project + формулы + индикация)
2. Но если менеджер не мыслит проектно, то и средства автоматизации не помогут.
Например, если менеджер задает себе вопрос, что ждет мой проект в дальнейшем, когда он сможет завершится?
То он проанализирует ключевые задачи (в терминах УП — задачи на критическом пути), составит сценарий, заложит резервы на риски и получит прогноз завершения проекта.
Вот это будет проектное управление.
А если менеджер привык к тому, что у него нет времени подумать о будущем, а лишь бы поскорее выполнить то, что есть, то он так и останется «операционистом».
Доклад неплохой, посвящен он полномочиям менеджера, а не методологическому подходу.
Как сотрудник, работавший в компании, лидирующей в области управления проектами, выскажу свое мнение.
Основная причина, почему большинство менеджеров работают «через %опу», «или как получится» — это то, что они применяют приемы операционного управления вместо проектного подхода.
ОПЕРАЦИОННОЕ УПРАВЛЕНИЕ
Метафора — конвейер.
Поступила одна задача — выполнили,
Возникла проблема — решили.
Пока конвейер к нам не подошел, мы не думаем, о том что к нам придет дальше.
Нормально делай — нормально и будет.
ПРОЕКТНОЕ УПРАВЛЕНИЕ
Метафора — это профессиональная игра в бильярд, когда игрок делает партию с кия.
Нужно просчитать всю серию и сложить ее с кия.
Если вы неправильно вышли на следующий шар, то прежде чем забить следующий шар, вы должны по-новой просчитать серию и только после этого забивать шары.
То есть в проектном управлении вы должны не только осуществлять операционное управление (забивать шары), но и просчитывать ситуацию на несколько ходов вперед, всегда ориентируясь на последний шар (конечный результат).
Насчет того, что правильно применять знания PMBOK — это далеко не просто, тут полностью согласен.
Леонид, вы случайно не работали в 1 из 2 компаний, лидеров на рынке России по предоставлению услуг УП на базе PMBOK? (Не буду называть, какие. Думаю вы меня поймете)
Как сертифицированный специалист в области управления проектами и применяющий все эти подходы на практике, могу сказать, что основная причина провала: это отсутствие проектного управления, а наличие операционного.
Люди решают задачи и проблемы по мере их поступления, а проектное управление подразумевает системное мышление и системный подход, держа весь проект от начала и до конца и оценивая влияние каждого изменения на проект в целом. В этом кстати, помогают средства автоматизации.
В одной из компаний даже был курс «Проектный менеджмент для операционных менеджеров».
На мой экспертный взгляд многие менеджеры занимаются управлением операциями проекта в рамках проекта, но не занимаются проектным управлением. Увидев такие отличия, они бы выяснили основные пробелы в своей деятельности и направления для совершенствования.
Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.
Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
Поправил схему.
В идеале должно быть так.
1. Принято решение «Отложить»
2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
Процедура может повторится еще 2 раза.
3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)
На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
2. Но если менеджер не мыслит проектно, то и средства автоматизации не помогут.
Например, если менеджер задает себе вопрос, что ждет мой проект в дальнейшем, когда он сможет завершится?
То он проанализирует ключевые задачи (в терминах УП — задачи на критическом пути), составит сценарий, заложит резервы на риски и получит прогноз завершения проекта.
Вот это будет проектное управление.
А если менеджер привык к тому, что у него нет времени подумать о будущем, а лишь бы поскорее выполнить то, что есть, то он так и останется «операционистом».
Как сотрудник, работавший в компании, лидирующей в области управления проектами, выскажу свое мнение.
Основная причина, почему большинство менеджеров работают «через %опу», «или как получится» — это то, что они применяют приемы операционного управления вместо проектного подхода.
ОПЕРАЦИОННОЕ УПРАВЛЕНИЕ
Метафора — конвейер.
Поступила одна задача — выполнили,
Возникла проблема — решили.
Пока конвейер к нам не подошел, мы не думаем, о том что к нам придет дальше.
Нормально делай — нормально и будет.
ПРОЕКТНОЕ УПРАВЛЕНИЕ
Метафора — это профессиональная игра в бильярд, когда игрок делает партию с кия.
Нужно просчитать всю серию и сложить ее с кия.
Если вы неправильно вышли на следующий шар, то прежде чем забить следующий шар, вы должны по-новой просчитать серию и только после этого забивать шары.
То есть в проектном управлении вы должны не только осуществлять операционное управление (забивать шары), но и просчитывать ситуацию на несколько ходов вперед, всегда ориентируясь на последний шар (конечный результат).
Леонид, вы случайно не работали в 1 из 2 компаний, лидеров на рынке России по предоставлению услуг УП на базе PMBOK? (Не буду называть, какие. Думаю вы меня поймете)
Пришлось поставить другое.
Люди решают задачи и проблемы по мере их поступления, а проектное управление подразумевает системное мышление и системный подход, держа весь проект от начала и до конца и оценивая влияние каждого изменения на проект в целом. В этом кстати, помогают средства автоматизации.