Управление Проектами, Moscow (2024)

07/02/2024

ВЫШЕЛ НОВЫЙ НОМЕР ЖУРНАЛА УПРАВЛЕНИЕ ПРОЕКТАМИ 4-2023
https://pmmagazine.ru/editions/4-67-2023/
С удовольствием представляю вам новый номер журнала «Управление Проектами», посвященный организационному развитию. В этом выпуске мы собрали для вас передовые практики, современные методологии и главное — информацию от практиков в области организационных изменений в российских компаниях, направленные на улучшение управления проектами и содействие эффективному развитию вашего бизнеса.
Мы убеждены, что представленные материалы не только расширят ваш кругозор, но и вдохновят на новые идеи для успешного внедрения проектных подходов в вашей организации. Благодарим всех авторов за ценный вклад и надеемся, что этот номер станет для вас полезным источником знаний.
Также в этом номере мы представим взгляд на роль руководителя проекта в совершенно новой сфере – инфобизнесе, мы расскажем, как организован типичный проект в этом бизнесе и какие задачи решает руководитель такого проекта.

Желаем вам увлекательного чтения!
С уважением
Олег Тумасов
PMP, Prince2 Practitioner, MSP Practitioner, Certified Scrum Master
Главный редактор

10/11/2023

Вышел новый номер журнала Управление Проектами.
https://pmmagazine.ru/editions/3-66-2023/

Читайте в этом номере:
1. Виды компьютерных моделей проектов.
2. Применение искусственного интеллекта в системах управления проектами.
3. Бюджет проекта в процессно-ориентированном бизнесе: ключевая специфика.
4. Как проектному офису помочь своей компании выйти на более прогрессивный уровень развития?
5. Применение пакетно-узлового метода (ПУМ) управления строительством сложных объектов.

Интересного вам чтения!
С уважением к профессии,
Олег Тумасов, PMP, PRINCE2, MSP, CSM, главный редактор

18/08/2023

Вышел новый номер журнала Управление Проектами №2-2023.
https://pmmagazine.ru/editions/2-65-2023/
Управление современными крупными проектами и программами невозможно без целого набора информационных систем, входящих в состав корпоративной системы управления проектами предприятия. В этом номере мы поговорим о совершенно новом типе таких систем – это системы, использующие алгоритмы прикладного искусственного интеллекта для нескольких типов задач, возникающих при управлении проектами, программами и портфелями. Также мы поговорим о трудном пути, который приходится преодолевать BIM системам для того, чтобы стать полноценным инструментом управления строительными проектами.

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

Также мы обсудим проверенные методы контроля и оценки производительности реализации проектов.

Интересного вам чтения!
С уважением к профессии,
Олег Тумасов, PMP, PRINCE2, MSP, главный редактор.

24/05/2023

Вышел новый номер журнала Управление Проектами
https://pmmagazine.ru/editions/1-64-2023/
Успех проекта зависит не только от руководителя проекта. В ходе защиты и реализации проекта возникает множество трудностей, для преодоления которых требуется участие не только команды проекта, но и топ-менеджмента компании. На крупных проектах для этого формируется специальный орган – Управляющий комитет проекта, в который помимо Заказчика, Куратора и Руководителя проекта могут входить представители топ-менеджмента крупных подрядчиков и конечных пользователей результатов проекта. В этом номере мы подробно обсудим роль топ-менеджмента и механизмы его контроля над проектом.

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

Интересного вам чтения!

С уважением к профессии,

Олег Тумасов, PMP, PRINCE2, MSP, главный редактор.

13/03/2023

Кинопроект. Содержание как основа

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

В-первую очередь, их объединяет системный подход.

Есть такая известная фраза «Кино – это движущиеся картинки». История кино показывает, насколько эти картинки с каждым годом становятся сложнее. В последнее десятилетие особенно быстро в процесс создания кино стали интегрироваться цифровые технологии. Вот уже любой блокбастер на 70 % состоит из графики. А ведь когда-то кино было немым и черно-белым…

Продукты экранного искусства становятся год от года сложнее, объёмнее, дороже. Раньше я думал, что цифровые технологии значительно облегчат и ускорят создание кино. Но на деле всё не так оказалось однозначно. Цифровой формат стал менять многие процессы кинопроизводства, плодить избыточную массу материалов. Значительно повысилось время их сортировки и обработки. К тому же возникла значительная проблема хранения материалов таких гигантских проектов. И главное, на выходе продукт стал становиться более вариативным, и зачастую с менее предсказуемым результатом.
Процессы создания кино сами по себе являются сложными - их много, часто они зависят от личной компетенции. Поэтому в них много субъективных оценок. Кино, как искусство, - товар штучный, и практически ручной работы.

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

Массовое, зрелищное кино создать не потрудившись невозможно.

Для создателей сам фильм, не является конечным результатом. Важным результатом является выручка от проката, в тех случаях, если кино коммерческое. В случае же фестивального направления фильмов – признание у экспертов и публики, ради которой делается кино.

Но как спроектировать успех в такой, казалось бы, не системной сфере?

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

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

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

Итак, реально приходим к выводам, что кинофильм – это всего лишь часть одного большого дела. И в этом случае кино является творческим продуктом – результатом, которым необходимо умело воспользоваться. И вот как раз здесь мы видим ещё одну составляющую – технология разработки творческого продукта, сплав двух, казалось бы, очень похожих и в то же время различающихся техник.

Можно ли программировать успех?

Да, программировать успех нужно. Успех необходимо сделать осязаемым для себя и четким в определении. Совершенно точно надо знать, чего необходимо достичь программой проектов при создании любого визуального материала. Да-да, именно, любого. Неважно, что вы запланировали: музыкальный клип, короткометражный фильм или полнометражный блокбастер с огромным объёмом графики.

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

Полную версию этой статьи, а также другие интересные статьи читайте в журнале Управление Проектами https://pmmagazine.ru/editions/1-2-2021/

Автор статьи:
Бехтерев Евгений Игоревич
Проектный менеджер с 1998 года. PME. Продюсер /кинематограф/анимация/реклама. Разработчик проектов в области медиа и IT. Разработчик специализированных автоматизированных и производственных систем

04/03/2023

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

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

История написания претензий и рекомендаций восходит к тем временам, когда возникли современные правовые системы. Тем не менее, в индустрии EPCM написание претензий до сих пор вызывает проблемы. Процент принятых и одобренных с первого раза претензий остается крайне малым. Одна из причин этого – некорректная подача претензий и неправильная методология при их написании.

Что такое претензия?

Начнем с того, что такое претензия. Простейшее определение может быть таким: «Претензия – имеет целью утвердить; побудить; настоять на своем, в том числе на своем праве в соответствии с условиями контракта или по закону".

Однако в индустрии ECPM термин «претензия» часто используется либо для обозначения права на дополнительное время для завершения работ, либо на дополнительную оплату, и очень часто – на то и другое одновременно.

Типы претензий

Запрос на изменение (Claims for Variation)

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

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

Запрос на изменение – это заявление Подрядчика о компенсации, на которую он считает, что имеет право с учетом изменения состава или объема работ.

Запрос на увеличение длительности выполнения работ (EOT – Extension of Time)

Претензия типа EOT является вторым по распространенности типом претензий после запроса на изменение. Претензии типа EOT – это запрос Подрядчика на...

Полную версию этой статьи, а также другие интересные статьи читайте в журнале Управление Проектами https://pmmagazine.ru/editions/1-2-2021/

Автор статьи:

Сагар А. Раут (Sagar A. Raut)

B.Eng., PGP-ACM, LL.M (UK), FCIOB, FAPM, MCIArb, M.ASCE, ARICS | PMI-PMP,SP,RMP | AACE-CCP,PSP | PRINCE2, Program Manager – Planning / Risk / Claims

22/02/2023

Опыт трансформации подходов управления низкобюджетными инвестиционными проектами

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

Общеизвестно, что такие проблемы затрагивают необходимость:

- рационального, стратегически ориентированного управления бизнесом;

- устойчивого функционирования и конкурентоспособного развития компании;

- эффективного использования ограниченных ресурсов;

- получение максимально возможной выгоды от реализации проектов компании.

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

- Применение процессных методов позволяет выстроить бизнес по унифицированным правилам (даже для территориально распределенных команд), корректно разграничить зоны ответственности согласно ролям процесса (кто и что должен делать и на каком шаге процесса. Например, применяя IDEF0, EPC или BPMN нотации для описания процессов, а также RACI матрицы для описания ролевой модели взаимодействия);

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

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

Принимая во внимание, что инвестиционные проекты, реализуемые на предприятиях ПАО «СИБУР» (далее - Компания) направлены на повышение производственной эффективности и позволяют осознанно двигать Компанию к целевым показателям, перед нами встала крайне амбициозная задача – изменить подход к управлению и контролю большого количества (может исчисляться сотнями) территориально распределенных так называемых низкобюджетных инвестиционных проектов (средний CAPEX – до 5 млн $).

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

По результатам проведенного анализа было выявлено, что средний срок реализации низкобюджетных инвестиционных проектов, завершенных за последние три года, составляет 2 года и 3 месяца (стоит отметить, что 99% из них – это проекты технического перевооружения, не требующие разработки проектной документации, прохождения государственных экспертиз и получения разрешения на строительство).

Много это или мало, давайте посмотрим для сравнения:

- Одна станция метро неглубокого заложения с проходкой строится с учетом ПИР в среднем три-четыре года при объеме CAPEX 3,5 млрд.руб. и выше;

- Типовой ЖК строится с учетом ПИР в среднем два-три года при объеме CAPEX 2,5 млрд. руб. и выше.

Кроме этого, лучшие мировые практики по реализации проектов с аналогичным CAPEX не превышают 1,5 года. Вывод был очевиден, с текущей скоростью реализации Компания недополучает значительный экономический эффект и тормозит своё перемещение в целевые квартили.

Таким образом, Компания поставила перед собой задачу...

Полную версию этой статьи, а также другие интересные статьи читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2021/

Авторы статьи:

Ганзиков А.С., к.т.н., МВА, Менеджер, Капитальные вложения и инвестиционные проекты, ООО «СИБУР»

Будаев Я.В., Руководитель вертикали, проект Новая операционная модель, ООО «СИБУР»

Горбунов Н.В., Главный эксперт, Новая операционная модель, ООО «СИБУР»

Сумерин Е.В., Менеджер, ООО «Сибур Диджитал»

01/02/2023

Как работать с перфекционистом?

Рустэм Валеев, Генеральный директор, ООО "Софт-портал проект", г. Уфа

- Альберт, ты сделал справочник для расчета накладных расходов?

- Я даже не начинал.

- Слушай, нам эта доработка уже неделю, как нужна. В чем проблема?

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

- А что ты предлагаешь?

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

- И сколько времени займет эта разработка?

- Думаю, дня за три сделаю.

- Да, Альберт, это классное решение. Проблема только в том, что заказчик согласовал нам всего 40 часов на новый документ «Плановая себестоимости изделия». Из них на справочник «Формулы для расчета расходов» выделено 4 часа. Давай попробуем обойтись без конструктора формул.

- Это невозможно! Ваше решение с редактируемыми формулами в строке — не рабочее!

- Ну, слабое место ты увидел правильно. Вот что мы сделаем. Над строкой для ввода формулы мы напишем текстом, какие переменные и выражения с ними можно использовать. А еще ты запрограммируешь простую проверку введенной формулы. До того, как программа начнет вычислять реальные накладные расходы по ней. Пользователь сможет поправить ее вручную после сообщения об ошибке. Сколько времени займет такая разработка?

- Пару часов. Но я не уверен, что это хорошее решение.

- Я уверен. Я отвечаю за этот проект. Сделаем так, как я говорю.

- Смотрите сами. Я сделаю, конечно, то, что вы просите. Но я вас предупредил.

К вечеру справочник был готов. Без конструктора. С подсказкой и проверкой введенной формулы. Не очень удобный, не очень красивый. Но вполне работоспособный.

Вот такой у меня был сотрудник. Перфекционист. Он предъявлял очень высокие требования к результатам своей работы. Стремился к совершенству. У него получался прекрасный код. Возможно, самый лучший в компании. Заказчики его тоже очень любили. Он видел все слабые стороны обсуждаемых решений. И предлагал лучшие варианты. Но в стремлении к совершенству Альберт не учитывал реальные требования и возможности заказчиков. И часто откладывал начало работы. Не только потому, что долго продумывал совершенное решение. Но и потому, что у него рука не поднималась делать то, за что заказчики готовы были заплатить. Денег на совершенство никогда не хватало.
..

- Рустэм, снимите меня с проекта.

- Альберт, да ты что? Как я тебя сниму, ты руководитель этого проекта!

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

- Ты говорил с ней?

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

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

- Техподдержка будет сходить с ума. Они перегрузят ее звонками. Но это еще ладно. Хуже то, что многие в техподдержку просто не позвонят. Плохо обученные, они введут неверные данные! В итоге мы не закроем опытную эксплуатацию в срок! Я очень не хочу во все это вляпаться.

- Но у меня нет ни одного свободного руководителя проекта. Я просто не могу тебя заменить!

- Вам придется. Если вы не хотите катастрофы.

- Ладно. Я не могу заменить тебя. Но я могу заменить твоего консультанта. Евгения как раз освободилась. А Гузель переведем на проект попроще.

Мы заменили консультанта, и после пары других истерик, проект был все же завершен. Но каких нервов мне это стоило!
..

- Альберт, поздравляю.

- С чем?

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

- Премия? За что? Да заказчик просто не понимает, как там все плохо.

- В смысле — плохо?

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

- Погоди. Постановка налогового учета не входила в рамки проекта. Как-то же она его ведет? Нам не жалуется. Пользователей мы обучили. Я лично подписал сертификаты на допуск к программе двум десяткам специалистов. Конечно, они будут косячить, это неизбежно. Но техподдержка в отделе ИТ организована. Они точно справятся.

- Нет, все плохо. Я не могу получить премию за такую работу.

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

Попробуем понять, что же не так с перфекционистом, и как с ним работать.

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

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

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

Эту и другие интересные статьи читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2021/

20/01/2023

Как использовать иерархию метрик для увеличения эффективности продуктовых команд?

Илья Григорьян, Директор по продукту и сообществам, Deep Mind Consulting

В структуре крупных компаний отделы, занимающиеся IT-проектами, продуктами и их сопровождением, представляют из себя целые подразделения (дивизионы, департаменты) со множеством команд внутри, сгруппированных по направлениям. Между командами разработки, которые находятся в такой структуре, ответственность четко ограничена и сильно распределена: команда может отвечать за часть бизнес-процесса, продуктовый сценарий в конкретном канале (например, приложении или контактном центре) или нести ответственность за инфраструктуру.

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

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

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

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

Описываемая проблема снижения результативности продуктовых команд в крупных компаниях с распределенной структурой и «далекими» показателями измерения успеха, стоит и перед участниками команд, и перед руководством компании.

Одним из вариантов решения проблемы является процесс годового планирования.

Данный подход определенно имеет ряд преимуществ: вовлекает в целеполагание заинтересованных лиц и развивает культуру исполнительности в компании. С другой стороны, низкая частота процесса целеполагания приводит к слабой вовлеченности команд и поверхностному пониманию направления, которое выбирает бизнес.

Альтернативным решением по отношению к участию в годовом планировании является использование инструмента «иерархия метрик».

Иерархия метрик — инструмент декомпозиции ключевых (высокоуровневых) измерителей успеха организации (KPI) до низкоуровневых, которые их определяют.

Например, высокоуровневыми метриками являются...

Полную версию статьи Ильи Григорьяна читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2022/

17/01/2023

Взаимодействие заказчика и исполнителя: от достижения частной выгоды к максимизации совместной заинтересованности

Козлов Александр Сергеевич — к.э.н., доцент, независимый эксперт

Хорошая сделка должна нести в себе потенциал повторения. Чтобы это происходило, участники сделки должны быть довольны: покупатель (заказчик) — не только в момент покупки, но и после, когда использует или эксплуатирует полученные результаты; продавец (исполнитель) — не только фактом, условиями и реализацией продажи, но и пост‑продажей с минимальным отвлечением ресурсов на старую сделку и перспективами для новых, в том числе, и с другими покупателями (заказчиками).

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

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

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

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

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

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

Полную версию статьи Александра Козлова читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2022/

06/01/2023

Проектное управление в проектной организации: единство и борьба!

Владимир Малахов
Вице президент НПИ – Национальной палаты инженеров России, Президент БИСКИД – Бизнес-школы Инвестиционно-строительного консалтинга, инжиниринга и девелопмента

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

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

Наиболее распространённой ошибкой проектных организаций является так называемое "линейное" проектное управление, когда и ГИПами (Главными Инженерами Проектов) и Начальниками проектных отделов руководит один производственный менеджер, чаще всего - Главный Инженер проектной организации. С одной стороны, под одним техническим менеджером замыкаются две противоборствующие задачи - лучшие и дорогие проектные решения (Центр финансовой ответственности по прибыли) с одной стороны, и выполнение проектных работ в срок с нужным качеством в нужном объёме (Центр финансовой ответственности по выручке). Объединение этих контрфункций под единственным техническим руководителем (даже если у него есть много заместителей по проектам и направлениям проектирования) приводит к трагическому внутреннему когнитивному расстройству, что очень заметно у возрастных главных инженеров проектных институтов - они мастерски умеют говорить долго ни о чем! С другой стороны, генеральному директору остается заниматься вопросами общего управления с 20% персонала, так как основной производственный коллектив уже находится в подчинении главного инженера. У него тоже происходит управленческий перекос. В лучшем случае, генеральным директором может стать бывший главный инженер и тогда он никому не даст работать вообще. Говорить в такой ситуации о качественном проектном управлении нет смысла в принципе.

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

Полную версию статьи Владимира Малахова читайте в журнале Управление Проектами https://pmmagazine.ru/editions/3-4-2022/

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

07/02/2024

10/11/2023

18/08/2023

24/05/2023

13/03/2023

04/03/2023

22/02/2023

01/02/2023

20/01/2023

17/01/2023

06/01/2023

Address

Website

Alerts

Contact The Business

Shortcuts

Share

Category

Other Magazines in Moscow

You may also like