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

Другая проблема для проектного офиса, а для компании вообще-то не проблема, когда компания начинает сама реализовывать программу изменений. Это и есть то, ради чего проектный офис создавали — чтобы повышение эффективности бизнеса стало частью задач всей организации. Это финальная точка, когда цели создания проектного офиса достигнуты и он расформировывается, либо переформатируется под новые задачи развития бизнеса с новой командой.

Создание проектного офиса — один из инструментов развития бизнеса и его также необходимо правильно использовать, как и любые другие.

#экспертговорит

#экспертговорит
#ЕвгенийБеспалов

Сроки и бюджет ОДИН раз!

Евгений Беспалов, руководитель проектного офиса энергогенерирующей компании «ГТ Энерго»

Это, казалось бы, элементарная истина, однако многие руководители проектов слишком часто наступают на эти грабли.

Обычная ситуация: в первые месяцы проекта вы замечаете, что объем работ увеличился, на рынке возникли проблемы, и как руководитель проекта осознаете, что в первоначальные сроки или бюджет вы уже точно не уложитесь. В этой ситуации вы, как рациональный ПМ, принимаете решение о том, чтобы вынести вопрос об изменении параметров проекта на Управляющий совет (Проектный комитет и т.п.). Вы тщательно рассчитываете и анализируете каждый рубль и/или каждый день, при этом стараясь сделать все возможное, чтобы сделать желаемые изменения как можно меньше. И вот, наконец-то, наступает момент, когда вы защищаете это на УК и (ура!) получаете «одобрям-с».

Продолжение 👇

Когда прошло еще полгода, вы обнаруживаете что-то еще (предположим, что это «что-то» – объективная причина для запроса на изменение) - и снова идете в УК, так как в прошлый раз вы сделали запрос на увеличение по минимуму.

Внимание, вопрос – как вы будете восприняты управляющим комитетом, если вы ранее уже вносили изменения в проект, а также получили одобрение на увеличение сроков и финансирования?

Очевидно, как не компетентного в вопросе планирования проекта и человека с недостаточным уровнем профессионализма, который приносит им одни проблемы (они только начали перепланировку бюджета с учетом предыдущего опыта, а тут на тебе!) Первое, что приходит на ум руководителю или члену управляющего комитета или спонсора в данном случае – «какого ****?».
Попытки получить увеличение бюджета или продлить сроки проекта приводят к тому, что он становится для него проблемой (даже если это не так).

По правде говоря, далеко не все из ПМов осознают тот факт, что на уровне Управляющего комитета или даже вашего непосредственного руководителя эти подробные расчеты по срокам и деньгам, которые вы подготовили, вряд ли будут иметь какой-либо эффект. И, даже если бы вы потребовали значительно больше средств – вряд ли что-то изменилось бы для УК. Скорее всего это было бы просто одним из изменений в вашем проекте, а не значимым событием для портфеля. Произвели внесение, а затем забыли о нем.
А вот если вы снова обратитесь к корректировке, то, скорее всего, это может привести к тому, что на ваш проект будет обращено гораздо больше внимания, чем вам бы того хотелось.

Мораль: если есть возможность, а также необходимость в увеличении средств или продлении сроков, то следует увеличивать их таким образом, чтобы 2й или даже 3й раз идти не пришлось.

#экспертговорит
#ЕвгенийБеспалов

#экспертговорит

Штабная логика как метод реализации сложных проектов

Пономарев Петр - директор департамента управления проектами АО "КОНСИСТ-ОС" организации Госкорпорации "Росатом"

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

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

Поскольку "штурм" проблем происходит в расширенном составе, то и решение их находятся и принимаются быстрее без дополнительных консультаций и согласований. Минусы во времени руководителей, которое всегда ограничено, но доля таких проектов не превышает 5% и это как правило импортозамещение АРМ, импортозамещение систем ЗОКИИ, т.е. весьма сложные технические, технологические и организационные проекты с максимумом неопределённостей и, чаще всего, с жёсткими директивными сроками.

При этом, никто не исключает классических методов управления проектами!