Формализация (устав) программы проектов

Антон Куценко пишет:

Анатолий Курочкин пишет:
Антон, поясните, пожалуста, что Вы имеете в виду под словом "формализовать", обозначить? 

Евгений Равич пишет:
Для начала у нескольких проектов должно быть много общего - цели, ресурсы, технологии ... . Но я бы не сравнивал проекты в строительстве и, скажем, в IT.

Возникает вопрос, в каком виде должны быть утверждена=формализована Программа проектов? Нужно ли утверждать каждый проект еще отдельно?

Ну я тоже не берусь давать советы в строительстве. На первый взгляд,это слишком практический вопрос, верно пишет Евгений Равич - всё зависит от заказчиков, исполнителей, согласования с ними.
А непосредственным строителям, на мой взгляд, важнее строительные ГОСТЫ, чем некие проекты. Например ГОСТ Р 21.101-2020 "Система проектной документации для строительства. Основные требования к проектной и рабочей документации".

На свежую голову отвечу, а то вчера у меня юбилей был. Сами понимаете.

Антон Куценко пишет:
Есть проект под названием "Строительство коттеджного дома", параметры проекта отражены (формализованы) в уставе (предпосылки, цели, эффект, сроки, бюджет и т.д.). Устав подписан, утвержден приказ о запуске проекта.

Во первых, это план проекта. "Уставом" называют свод правил и принципов, по которым функционирует вся организация. 

Антон Куценко пишет:
А потом появляется программа проектов "Строительство коттеджного поселка", в котором есть проекты "Строительство домов", "Строительство пожарной части", "Строительство школы" и т.д. То есть это группа проектов, которые взаимосвязаны между собой и друг без друга не целесообразны. Более того, у программы есть Рук. программы проектов, которому подчиняются и отчитываются Рук. проектов по каждому из них.

Антон Куценко пишет:
Возникает вопрос, в каком виде должны быть утверждена=формализована Программа проектов? Нужно ли утверждать каждый проект еще отдельно?

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

Отличается от архитектурных планов домов, школы, дороги, водонапорной вышки, котельной или пожарной части тем, что имеет более обобщенный вид. По сути это тот же макет или разметки на карте и данные об предпологаемых бюджете, начале работы и сроках сдачи, последнее обычно в виде "1 квартал 2020 года".

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

Анатолий Курочкин пишет:
Ну я тоже не берусь давать советы в строительстве. 

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

Через года три жутких мытарств со строителями (ему узбекский пришлось выучить, чтоб переводить порядок монтажа демонтажа электронного оборудования) плюнул, махнул рукой и увлекся нашим E-xe клубом.

Теперь далее... Недавно к нему приехали братки, на чьи деньги ведется реновация парка и попросили, что бы он отказался от требований в проекте и перешел на старый добрый ГОСТ. После того как Алексей вышел из больницы, он счистил с потолка всю лепнину и ударными темпами осортирил подмосковный парк. Выводы делайте сами.

Добрый день

По вопросам.

1.  "Как должен выглядеть Устав программы и нужно ли его формализовывать? (Думаю, что да и будет схоже с Уставом проекта)."

Структурно - это документ верхнего уровня. 

Конкретные разделы документа - от потребностей Заказчика/Инвестора/Заинтересованных сторон

Примерный перечень - Привел С.Средний ранее.

Формализовывать Устав программы - очевидно, да. Если возникла потребность в  разработке документа.

Состав согласующих Устава Программы - опционален. От бизнес-потребностей.

2. Нужно ли отдельно "формально" утверждать запуск проектов входящих в программу?

Скорее всего, да. Как обозначение перехода проекта отдельного на стадию оценки/выбора/реализации.

Как это документально оформлять - тоже опционально.

Например Документ - Протокол о принятии финального инвест решения о реализации, или иное.

3. Как закрывать программу и проекты? Отдельно проект, потом опять проект и потом только программу?

* На практике вам придется это делать пообъектно.

Маловероятно, что работы по проектам будут завершены одновременно. 

Т.о. отдельно подписываются закрывающие документы - например в строительстве Акт приемки завершенного строительством объекта по ф. КС-11, КС-14. - на каждый элемент/отдельный объект в программе.

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

Михаил Кузнецов пишет:

Анатолий Курочкин пишет:
Ну я тоже не берусь давать советы в строительстве. 

Был у нас если помните А.Уланов строитель (кстати, горячий привет вам от него). Так вот он как то мне жаловался, что уже семь лет они не могут сдать объект в одном подмосковном парке

...Выводы делайте сами.

Спасибо! Алексей - умнейший человек! Мы на связи с ним.
Я лет 30 назад связался со стороны заказчика с огромной стройкой. С тех пор, получив все возможные пинки, шишки и подзатыльники, стал относиться к строительным нормам с огромным почтением. Это вам не программульки на компьютере ваять [Шутка. Типа].

0.Насколько понимаю, заданный автором вопрос  – каковы принципиальные отличия Устава Программы  проектов (УПГ) от Устава Проекта (УПР), входящего в программу.

Специфика – реализация проектов в гражданском строительстве.

1.Короткий ответ  

УПГ – это уровень Стратегического планирования,

УПР – Тактическое планирование.

1. Длинный ответ.

2.1 При разработке УПГ  Фокус на - примерный перечень разделов:

• Обоснование Целесообразности реализации пула инвестиционной программы. Достигаемые Бизнес цели.
• Описание продукта, создаваемого в рамках реализации программы. проектов.Увязка целей с продуктовой верхнеуровневой стратегией компании.
• Обоснование коммерческой эффективности реализации программы.
• Обоснование реализации проектов в рамках программы - стадийности строительства, разбиения проекта на этапы, пусковые комплексы, очереди.
• Обоснование синергии при создании продукта – полезного бизнес результата – при реализации программы.

а) Например, завершение строительства комплекса коттеджного поселка – зданий и инфраструктуры – создаст Заказчику актив для потенциальной продажи.

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

б) Реализация проекта кап. строительства объектов Обогатительного комбината с учетом создания транспортно логистических путей - подъездных дорог, ж.д. инфраструктуры - путей и тяговых станций, морских терминалов.

Создание производственного актива "полного цикла". - от добычи руды до транспортировки готового продукта конечным потребителям.

• Описание объема работ в рамках реализации инвестиционной программы

Также можно дополнить – чего НЕ будет реализовано в рамках реализации инвест. программы. На практике это наиболее важный параметр, четко устанавливающий границы реализации.

• Обоснование макропараметров среды реализации проекта.
• Сценарная проработка - при каких условиях изменения макропараметров - возможен пересмотр бизнес-целей и отказ от реализации инвест программы.
• Стратегия Работа с гос. органами - надзорными - для строительства ИГСН и Ростехнадзор - и администрацией - при реализации. 
• Фин.модель проекта и основные инвест. показатели – например NPV, IRR, DPP, ROI - в рамках ПРограммы.
• Условия финансирования – описание инвест. контрактов. Источники привлечения финансирования. Верхнеуровнево про вопросы бюджетирования – высокоуровневое планирование – на этапе строительства.

Механизмы перераспределения средств в рамках одного проекта на другой, лимиты финансиования, и критерии возможности исполнения.

• Критерии достижения успешного результата реализации проекта

* в деньгах с привязкой к себестоимости . - возможны пороговые значения факт. NPV при которых проект будет считаться успешным.

* в материальных измерителях. Например завершение строительства комплекса жилых зданий согласно первичной экспликации.

* сроки исполнения план и прогноз

• Риск-менеджмент. При анализе рисков - Фокус на макро-параметры – т.е. сочетание каких факторов на высоком уровне в принципе может помешать реализации проекта.

Например

+ противодействие реализации проеков в рамках программы - жильцов прилегающих областей,

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

Свежий пример - Проблемы при получении разрешения на ввод построенног здания БЦ - ЧВК Вагнер центр

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

* Кто является Менеджером Программы

2.2 При разработке УПР  Фокус на:

• Критерии достижения успешного результата

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

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

При этом вопросы эксплуатации сетей – в рамках УПР уже не затрагиваются. Т.к. не входят в состав проекта.

• Описание продукта, создаваемого в рамках реализации Проекта. 
• Риск-менеджмент. Вопросы локального характера. На уровне реализации конкретной задачи.
• Бюджетирование – на уровне отдельного проекта.
• Стратегии функциональные – закупка товаров и услуг, реализация работ, логистика
• Работа с гос. органами - более детально на уровне реализации отдельного проекта.
• Стратегия формирования Проектного офиса
• Кто является Менеджером Проекта

1. Нужно ли отдельно "формально" утверждать запуск проектов входящих в программу?

Да. Например, Протоколом о принятии финального инвест. решения о реализации.

На практике срок реализации инвест программы - до 5- 10 лет в т.ч. в зависимости от возможности привлечения финансирования.

Также в ходе реализации допустим расширение объема работ - внесение дополнительных объектов в рамках программы - требующих отдельного запуска.

1. Как закрывать программу и проекты? Отдельно проект, потом опять проект и потом только программу?

4.1На практике при завершении работ по объектам Вам придется это делать  по мере готовности отдельных Проектов. Маловероятно, что работы по проектам будут завершены одновременно. 

Т.о. при завершении комплекса работ по объекту -  отдельно подписываются закрывающие документы - например в строительстве Акт приемки завершенного строительством объекта по ф. КС-11, КС-14. - на каждый отдельный объект в программе. Делается отчет о завершении, выученных уроках.

Принимаются решения по роспуску / перенаправлении команды ПО на иной проект.

4.2 После завершения реализации всех проектов - входящих в программу- в строительстве набор проектов м.б. выделен в отдельный этап / пусковой комплекс - В зависимости от того, как было получено исходное разрешение на строительство, как этапы сдачи работ указаны в исходной Проектной документации.

Отдельно м.б. получено разрешение на ввод в эксплуатацию  объектов пускового комплекса.

4.3 После реализации всех объектов в рамках программы - выпускается также общий закрывающий отчет. 

Алексей Старков пишет:
1.  "Как должен выглядеть Устав программы и нужно ли его формализовывать? (Думаю, что да и будет схоже с Уставом проекта)." Структурно - это документ верхнего уровня. 

Александр, спасибо за ответ. Вы как никто другой поняли о чем я спросил на форуме и подтвердили мои мысли ))

Алексей Старков пишет:
УПГ – это уровень Стратегического планирования,

Можно попросить пояснить, из чего это следует?

Евгений Равич пишет:

Алексей Старков пишет:
УПГ – это уровень Стратегического планирования,

Можно попросить пояснить, из чего это следует?

В понимании Программа проектов - есть производное от общей/функциональной стратегии предприятия.

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

Отдельный проект - по сути Локален.
И менеджер проекта зачастую в продуктовые характеристики не лезет. Он
Не занимается увязкой верхнеуровневых кпэ. Управление изменениями  в Проекте осуществляется, но по другим причинам.

Алексей Старков пишет:
Программа проектов - есть производное от общей/функциональной стратегии предприятия.

У этих формулировок есть автор? Производное от стратегии - это как?

Сравните с 

What Is a Program in Project Management?

A program is a cluster of related projects that are managed in a coordinated manner, so they can be executed simultaneously and share resources, activities and stakeholders.

What Is Program Management?

Program management is a strategic management approach to executing and controlling multiple related projects. The goal of program management is to drive benefits to the entire program by sharing project resources, costs and activities.

https://www.projectmanager.com/guides/program-management

В чем вопрос. Одно другого не исключает. Приведенные отрывки тоже верны по сути в том. Ч. Про распределение ресурсов. 

2. Вместо слова "производное" можно использовать " инструмент реализации ". Если так понятнее. 

Алексей Старков пишет:

В чем вопрос. Одно другого не исключает. Приведенные отрывки тоже верны по сути в том. Ч. Про распределение ресурсов. 

2. Вместо слова "производное" можно использовать " инструмент реализации ". Если так понятнее. 

Проекты, как и программы, могут иметь или не иметь отношение к стратегии компании. Это отдельная тема.

Заказчики, ресурсы, методы реализации, стандарты управления, технологии и бюджетирование могут быть внутренними и внешними - в любом сочетании.  Как и содержание конкретных проектных документов, начиная с Устава.

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

Говоря о строительстве посёлка и отдельного дома - это примеры двух разных проектов, если мы посмотрим на требования к таким объектам.

Евгений Равич пишет:
Проекты, как и программы, могут иметь или не иметь отношение к стратегии компании. Это отдельная тема.

Несогласен с утверждением. Как правило реализация идет хотя бы по формальному признаку с привязкой к стратегии. 

Есть разные ситуации - например функциональная стратегия или стратегия Бизнес-Единицы еще не сформирована, а проект запускать уже надо.

Но общее правило такое  - привязка к стратегии - в противном смысле разработка стратегий бессмысленна по сути.

Евгений Равич пишет:
Говоря о строительстве посёлка и отдельного дома - это примеры двух разных проектов, если мы посмотрим на требования к таким объектам.

1. Кажется на практике любой проект, состоящий из нескольких подзадач можно определить на выбор как:

* Проект с рядом подпроектов или

* Программу проектов.

Это вопрос того, как воспринимает решение этих задач Инициатор и заинтересованные стороны.

Остальное - как конкретно определить что собой конкретно представляет этот набор взаимосвязанных работ - проект или программу - это вопросы теоретиков. Оставим это им. 

2. В исходном запросе в дискуссии речь шла о Принципиальных различиях Устава - Программы и Проекта.

И наверное на этом надо сосредоточиться.

В моем понимании, простыми словами,

Чем выше менеджер Проекта/Программы/Портфеля по уровню управления - тем больше он должен сверять свой итоговый проектный результат - с требуемым продуктом - требования к которому определяются Менеджером продукта / Коммерческой функцией и пр. 

Это ключевое различие и д.б. отражено в итоговых создаваемых документах - Уставах и пр.

2.1 Например в ресторанном бизнесе - сравнения конечно условные -

Есть Шеф- повар - грубо менеджер гастрономического проекта.

Его задача - обеспечить приготовление набора блюд по меню согласно тех. карты. Ему наплевать на коммерческий эффект - ROI - по большому счету.

Его задача - сделать по меню с требуемым качеством точно в срок в рамках бюджета.

И Есть бренд-шеф - одна из его задач - Создать это меню / адаптировать имеющееся под нужды бизнеса.

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

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

Вот это типа Менеджера Программы.

3. Мнение дискуссионно. Вы сможете изложить свою т.з. более развернуто. 

Алексей Старков пишет:
Это ключевое различие и д.б. отражено в итоговых создаваемых документах - Уставах и пр.

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

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

Алексей Старков пишет:

Евгений Равич пишет:
Проекты, как и программы, могут иметь или не иметь отношение к стратегии компании. Это отдельная тема.

Несогласен с утверждением. Как правило реализация идет хотя бы по формальному признаку с привязкой к стратегии.

Что имеется в виду под проектом - примерно понятно, если Вы не даёте собственное определение.

Что для Вас стратегия? 

Есть разные ситуации - например функциональная стратегия или стратегия Бизнес-Единицы еще не сформирована, а проект запускать уже надо.

Но общее правило такое  - привязка к стратегии - в противном смысле разработка стратегий бессмысленна по сути.

На кого Вы ссылаетесь? Кто автор этого общего (?) правила? Что такое "стратегия Бизнес-Единицы" и при чем здесь проекты и программы? 

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

Евгений Равич пишет:
Говоря о строительстве посёлка и отдельного дома - это примеры двух разных проектов, если мы посмотрим на требования к таким объектам.

1. Кажется на практике любой проект, состоящий из нескольких подзадач можно определить на выбор как:

* Проект с рядом подпроектов или

* Программу проектов.

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

2. В исходном запросе в дискуссии речь шла о Принципиальных различиях Устава - Программы и Проекта.

И наверное на этом надо сосредоточиться.

В моем понимании, простыми словами,

Чем выше менеджер Проекта/Программы/Портфеля по уровню управления - тем больше он должен сверять свой итоговый проектный результат - с требуемым продуктом - требования к которому определяются Менеджером продукта / Коммерческой функцией и пр. 

Это ключевое различие и д.б. отражено в итоговых создаваемых документах - Уставах и пр.

Различия могут быть (или не быть) в зависимости от источников требований к этим документам и существующих на момент их подготовки корпоративных стандартов. Вариантов проектов слишком много.

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

2.1 Например в ресторанном бизнесе - сравнения конечно условные -

Есть Шеф- повар - грубо менеджер гастрономического проекта.

Оставим что-то одно - допустим, есть шеф-повар.

Его задача - сделать по меню с требуемым качеством точно в срок в рамках бюджета.

Пока это не проект - если Вы не считаете проектом каждый отдельно взятый день с его меню. Просто регулярный бизнес.

И Есть бренд-шеф - одна из его задач - Создать это меню / адаптировать имеющееся под нужды бизнеса.

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

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

Вот это типа Менеджера Программы.

Это не программа.

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