Что лучше цена или условия контракта
В процессе разработки ОТР мы оценивали не только стоимость оборудования, объемы СМР, которые потребуются для монтажа данного оборудования, но и вели обсуждение с поставщиком оборудования об условиях контракта, которые, на наш взгляд, могут оказать существенное влияние на окончательный выбор поставщика. На рисунке 4 приведен пример нескольких из подобных условий.
Рис.4. Пример нескольких условий контракта с поставщиком оборудования
Проведенный в процессе работы с поставщиками анализ ТКП и условий договоров показал, что, несмотря на то, что Поставщик 2 предоставил более низкую стоимость оборудования, риски, связанные с условиями контракта на поставку, будут стоить больше, чем выгода от разницы в цене с Поставщиком 1.
Вырастание команды из проектных групп
Вернемся к модели взаимодействия в проектной деятельности и разберем ее локальную часть после описанных выше стартовых шагов. Проектная задача считается принятой PM тогда, когда основные разделы устава проработаны, и он подписан сторонами. Этим самым менеджер принимает на себя ответственность, после чего она начинает его беспокоить. Подписанную ответственность ему необходимо разбить и каким-то образом перенести, распределить. Должна появиться команда проекта.
Команда проекта состоит из исполнителей, а ее возглавляет PM. Эта проектная группа работает на протяжении всей проектной реализации. Исполнители должны понимать только свои задачи, общую картину им видеть необязательно. Исполнители делятся на внешних и на внутренних. Внешние производители работ привлекаются по договору подряда, и с ними работать проще в силу большей формальности отношений. В любом случае, каждому исполнителю нужно правильно поставить задачу. А такое сделать невозможно, пока не будет детально разработанного плана.
В данный момент PM попадает в неудобную ситуацию с силу того, что у него не хватает компетентности в некоторых работах, которые нужно будет выполнять. Знать буквально все характеристики, все технические, технологические аспекты, процедурные моменты достижения требуемых решений не входит в его функции. Другими словами, менеджер не готов взять на себя ответственность за оценку отдельных работ (например, в сфере программирования).
Получается, что PM нужно найти экспертов в узких областях, которые способны оказать содействие на этапе планирования, а потом будут помогать на этапе реализации. Сначала руководитель проекта собирает так называемую «рабочую группу». Эта проектная группа помимо него состоит из группы экспертов, специалистов, на которых PM может положиться, и без которых он не способен грамотно спланировать проект.
Потенциально в роли экспертов могут выступить и непосредственно исполнители. В данном случае менеджеру следует быть осторожным, потому что они могут предоставить не совсем корректную и достоверную информацию. На уровне ТЗ коллеги или подрядчики способны предложить не то, что нужно, а то, что выгодней продать исполнителям (внешним или внутренним). Важен вопрос доверия, существенны характеристики исполнителей.
Затем рабочая группа трансформируется в команду управления проектом. К наступившему моменту уже несколько иная проектная группа по существу представляет собой ядро команды, которому PM доверяет и на них полагается. Она состоит из специалистов в конкретных отраслевых, управленческих областях. Поэтому такая группа называется командой управления проектом (КУП), состоящей из непосредственных помощников менеджера. С ними он советуется, на них он возлагает какую-то ответственность и передает определенные полномочия.
Названные выше группы являются основанием для формирования команды проекта. Получается, что команда включает более широкое окружение, чем КУП. Кроме доверенного ядра в эту группу входят еще и исполнители. С исполнителями РМ, как правило, выстраивает более простые взаимоотношения. То есть с ними обычно менеджер не советуется, нужно эту работу делать или не нужно. Руководитель с ними обсуждает вопрос о принятии ответственности за локальные задачи. Его интересует, на каких условиях последние готовы «взяться». Алгоритм прост: обсудить, договориться, заключить соглашение (договор), выполнить, сдать, принять. Таковы основные аспекты взаимоотношений с ответственными ресурсами по локальным результатам.
Фрагмент схемы взаимодействий проектных групп
Учет характеристик и функций исполнителей
Проектная группа, ставшая командой, определяет силу реализации задачи развития компании. Данный коллективный элемент системы управления опирается на личностную силу и ответственность каждого участника-исполнителя. Когда проектная команда собрана воедино, прошло первое рабочее совещание, можно с уверенностью говорить, что состав участников проекта сформирован полностью.
Руководителю проекта нужно быть точным с выбором в члены команды в каждом из случаев рассмотрения кандидатов
Для этого в момент определения состава команды ему важно учесть основные характеристики подбираемых людей, исходя из диагностических установок. Вашему вниманию предлагается один из примеров таких вопросов-установок
- Однозначны ли формулировки задач, которые следует предложить потенциальным исполнителям?
- Какие роли потребуется установить в команде, чтобы все задачи и мероприятия получили по ответственному ресурсу?
- Какими навыками и опытом должен владеть участник-претендент?
- Какие функции и задачи допустимо предложить претенденту при включении в команду?
- Какие основные черты характера, психотип и ценностные ориентации исполнителей являются предпочтительными?
- Какую загруженность и бюджет времени можно предположить для участия исполнителя?
- Достаточно ли число кандидатов на исполнение задач для обеспечения минимального уровня конкурентной среды между потенциальными участниками группы?
Представленные характеристики отталкиваются от специальной методический позиции. В ней предполагается, что дефицит ответственных ресурсов под декомпозированные задачи проекта является заблуждением. Человеческие ресурсы, способные стать участниками команды, потенциально всегда есть как внутри компании, так и за ее пределами. Поэтому, соблюдая задачную и проектную методологию, PM всегда имеет возможность созвать оптимальные по составу группы участников для успешной работы.
Помимо задач, каждому из участников команды придаются функции, обязательные к исполнению в периоды коллективных действий. Например, проектные совещания, регулярно проводимые для отчетно-аналитической работы, выработки оперативных решений требуют исполнения ряда административных действий. Секретарские операции являются обязанностью любого члена команды, назначенного РМ. Планирование и отчетность по проекту также является функциональной обязанностью каждого участника. Учет действительных функциональных навыков кандидатов в команду является прерогативой менеджера в момент ее созыва.
В настоящей статье мы рассмотрели багаж результатов, наработанных куратором и PM при работе над уставом. Последовательно возникают: проектные группы в форме рабочей группы, команды управления проектом и команды проекта. Задачный контекст ответственности PM обременяет обязанностью передать ее на плечи исполнителей, что является мощным управленческим навыком
Менеджер проекта, осознавший важность и освоивший на практике такую способность, несомненно, становится успешным руководителем
Аудит подрядчика – не просто проверка мощностей, но и новые идеи
Параллельно выполнению ОТР мы начали работу по поиску потенциальных генеральных подрядчиков, способных и желающих поучаствовать в нашем проекте.
После составления списка потенциальных подрядчиков мы провели аудиты данных организаций с выездом в офисы управления строительством, посещением материально-технических баз и действующих строительных площадок.
При проведении аудита мы обращали внимание на следующее: качество управления (процессы планирования, программное обеспечение), персонал (количество ИТР, проектных менеджеров), материальная база (производственная база по металлоконструкциям, парк техники), опыт. Во время одного из аудитов, подрядчик продемонстрировал нам на одном из своих текущих объектов пример технического решения (трубчатый конвейер), который, по его мнению, мог существенно упростить техническое решение уже нашего проекта, а также существенно сократить его бюджет
Применение трубчатого конвейера по перевозке сырого угля позволяет за счет своей формы огибать различные здания и сооружения и, тем самым, сокращать количество сносов и переносов тех зданий, и сооружений, которые могут понадобится при внедрении новой технологии на существующем производстве
Во время одного из аудитов, подрядчик продемонстрировал нам на одном из своих текущих объектов пример технического решения (трубчатый конвейер), который, по его мнению, мог существенно упростить техническое решение уже нашего проекта, а также существенно сократить его бюджет. Применение трубчатого конвейера по перевозке сырого угля позволяет за счет своей формы огибать различные здания и сооружения и, тем самым, сокращать количество сносов и переносов тех зданий, и сооружений, которые могут понадобится при внедрении новой технологии на существующем производстве.
В результате аудита потенциальных подрядчиков из 17 организаций на этап предквалификации вышло 7.
Условия эффективной работы команды проекта
Какая бы ни была организационная структура проекта и состав команды, эффективность ее работы зависит от следующих факторов:
- закрепление иерархии в команде (каждый должен знать, кто старший);
- наличие четких регламентов работы и передачи информации внутри команды;
- использование инструкций и готовых шаблонов;
- использование современных методов и инструментов управления проектами, в т.ч. программное обеспечение и информационные системы;
- готовность участников к командной работе и нестандартным подходам.
Таким образом, основная задача руководителя на этапе формирования команды — не только найти хороших экспертов и объединить их, но и создать вышеперечисленные условия их работы, обеспечивающие эффективную реализацию проекта.
О проекте
Для того чтобы лучше понять, что представляет собой проект, о котором далее пойдет речь в статье, на рис.1 представлена основная технологическая линия по переработке сырого угля в пыль и ее вдувания в доменные печи. Данная технологическая цепочка и является основным объектом строительства и пуска в эксплуатацию в проекте по вдуванию пылеугольного топлива (ПУТ).
Рис.1. Основная технологическая схема проекта ПУТ.
На рис.1 представлены фото фрагментов данной технологической цепочки при реализации подобного проекта на другом предприятии Компании. На фото видно, что все объекты технологической цепочки представляют собой довольно габаритные здания и сооружения. Несмотря на то что, установка ПУТ в г. Днепропетровске является менее мощной, чем в Нижнем Тагиле, структура технологической цепочки и объем основных объектов являются сопоставимыми.
Разработка оптимального технического решения
На рис.2 приведена схема разработки ОТР, примененная на нашем проекте. Основная идея данной схемы заключается в том, чтобы создать конкурентную среду между проектными организациями и потенциальными поставщиками оборудования при разработке ими ОТР, на основе которых будут рассчитываться эффекты, бюджет и сроки проекта. Конкурентная среда между контрагентами создается за счет выбора не одного, а двух проектировщиков, каждый из которых должен разработать по два варианта ОТР для разных поставщиков оборудования. В итоге после выполнения данной фазы проекта мы имеем четыре варианта ОТР, из которых выбираем тот вариант, при котором достигается максимальный эффект от проекта.
Рис.2. Схема разработки и выбора основных технических решений проекта.
Таким образом, получается, что, с одной стороны, мы платим дважды (так как выбрали двух проектировщиков) за выполнение одной и той же работы, а, с другой стороны, мы компенсируем эти дополнительные затраты за счет того, что проектировщики и поставщики оборудования стремятся разработать более оптимальное техническое решение.
Генеральный подрядчик. Контракт «2 ключа» лучше, чем «3 ключа»
Следующим вопросом при реализации проекта стал вопрос о выборе схемы контрактации: 1, 2 или 3 ключа. Схема «1 ключ» подразумевает, что все работы (проектные работы, поставка оборудования и СМР) выполняются одним контрагентом. «2 ключа» — за проектные и строительные работы отвечает один подрядчик, а за поставку оборудования другой. «3 ключа» — это схема с тремя отдельными контрактами: с Генеральным проектировщиком, Генеральным подрядчиком и Поставщиком основного оборудования. На рисунке 7 представлена таблица сравнения данных схем контрактов. Следует сразу отметить, что процесс и критерии выбора схемы контракта не является универсальными и зависят от сложности проекта, рынка подрядчиков в регионе, в котором реализуется проект, а также компетенций рабочей группы проекта.
Рис.7. Сравнение видов контрактов с подрядчиком.
Исходя из вышеперечисленных условий для нашего проекта была выбрана контрактная схема в «2 ключа».
Какие проблемы взаимодействия ГП и Заказчика мы выделили.
Неопределенность ответственности. Что имеется в виду: известно, что часть работ по проектированию в виде базисного инжиниринга выполняется поставщиком оборудования, а более детальное проектирование в виде стадий П и РД выполняется проектным институтом. Поэтому часто возникает ситуация, когда граница ответственности между проектным институтом и поставщиком оборудованием за те или иные объекты проекта четко не прописана, что приводит в дальнейшем к возникновению дополнительных соглашений на дополнительные работы и, как следствие, к увеличению бюджета проекта. Или ситуация, когда не понятно кто когда и какие данные должен передать проектному институту, чтобы он смог начать выполнение того или иного этапа проектирования.
Плохие коммуникации. Проектный институт часто не имеет прямого контакта с поставщиком оборудования и поэтому все текущие вопросы, которые возникают в процессе работы либо решаются в течение длительного времени, либо «подвисают» на неопределенный срок и, впоследствии, приводят к сдвигу графика всего проекта. С другой стороны, Заказчик может быть не всегда хорошо информирован о тех проблемах, с которыми столкнулся в процессе работы проектировщик и о возможных путях решения этих проблем.
Недостаточная мотивация. Проектировщик не всегда заинтересован в оптимизации предлагаемых решений, поскольку, как правило, любая оптимизация приводит к упрощению технических решений и, как следствие, к сокращению объемов проектно-сметной документации и стоимости контракта с проектным институтом.
На нашей встрече с проектными институтами все проектировщики согласились, что, действительно, такие проблемы существуют и что обе стороны заинтересованы в их решении. После этого мы предложили проектным институтам прописать в нашем с ними договоре ряд процедур, требований и правил, которые бы регулировали наши отношения с ними в процессе работы.
Итак, какие условия мы договорились прописать в договоре.
- Разработка основных технических решений (ОТР) будет выполняться на основе технико-коммерческих предложений поставщиков оборудования, а не аналогов, которые часто используют проектные институты. Таким образом, мы можем повысить точность оценки бюджета проекта.
- Границы проектирования между поставщиком и проектировщиком, технологическая схема и объем поставки обсуждаются и утверждаются на трехсторонней встрече «Заказчик – Проектировщик – Поставщик оборудования».
- График обмена исходными данными между проектировщиком и поставщиком фиксируется отдельным документом.
- Главный инженер проекта (ГИП) со стороны проектировщика – не формальная фигура, а лицо, наделенное определенными полномочиями и ответственностью, которые позволят ему быстро и эффективно принимать оперативные решения в процессе реализации проекта.
- Генеральный проектировщик не просто передает Заказчику свои проектные решения, а проводит их защиту с обоснованием их целесообразности.
Данные условия были благоприятно приняты со стороны потенциальных проектировщиков, возможно, за исключением условия, в котором мы просили наделить ГИПа широкими полномочиями по принятию решений и согласовать с нами (Заказчиком) кандидатуру ГИПа перед его официальным назначением. На наш взгляд, это вызвано тем, что данное требование Заказчика не совсем вписывается в привычную для многих проектировщиков структуру управления проектом.
Выбор проектировщика: качество или коммуникации
В результате работы по разработке ОТР, после нескольких итераций оптимизации объемов СМР, мы получили от двух потенциальных Генеральных проектировщиков практически идентичные варианты бюджетов проекта. В такой ситуации перед нами встал вопрос кого из двух проектировщиков нам выбрать. На рисунке 5 показана таблица с теми критериями, на основе которых мы проводили сравнение работы с данными проектными организациями.
Рис.5. Таблица оценки качество работы проектировщиков.
Как видно из таблицы (рис.5) несмотря на то, что Проектировщик 1 выполнил все работы в срок и с минимальными корректировками, он тяжело реагировал на любые пожелания Заказчика и постоянно пытался пересмотреть «правила игры», о которых договорились ранее. В то же самое время Проектировщик 2 соблюдал все ранее достигнутые договоренности по подходам к взаимной работе, а также старался «услышать» все пожелания Заказчика в процессе разработки технических решений. Из этой истории мы сделали для себя вывод, что от ошибок никто не застрахован, и для нас лучше работать с контрагентами, которые ошибаются и «слышат» нас, чем, с теми, которые ошибаются меньше, но «слушать» отказываются.
Предквалификация проектировщика
Следующим нашим шагом по реализации проекта было проведение предквалификации среди потенциальных проектировщиков. Какие цели мы преследовали в этом процессе:
- Получить адекватную предварительную оценку стоимости проекта и, как следствие, оценку его эффективности для получения возможности двигаться дальше по проекту;
- Генеральный проектировщик должен подтвердить свою заинтересованность и возможность выполнить данный проект.
На этапе предквалификации нами были поставлены следующие задачи:
- Разработка принципиальных технологических решений (или вариантов решений);
- Привязка технологии к Генеральному плану предприятия;
- Оценка качества инфраструктуры;
- Оценка объемов строительно-монтажных работ (СМР);
- Обсуждение условий договора.
В результате проведения предквалификации из девяти проектных организаций были приглашены к тендерным процедурам только четыре.
Прогнозный бюджет проекта по результатам предквалификации был оценен в 77 млн. долл.
Роли в команде проекта
Обычно выделяются следующие члены проектной команды, активно участвующие на всех стадиях жизненного цикла проекта:
- Заказчик — будущий владелец и пользователь результатов проекта (физическое или юридическое лицо).
- Инвестор — сторона, выделяющая средства для реализации проекта (инвестором может выступать сам заказчик).
- Руководитель проекта — лицо, которому заказчик делегирует полномочия по руководству работами и распоряжению ресурсами. Это главный ответственный за результат. Подробнее о роли руководителя проекта и предъявляемых к нему требованиях можно прочитать в соответствующей статье.
- Администратор проекта — это член проектной команды, обеспечивающий коммуникации в проекте и документооборот. Он также отвечает за техническую поддержку разработки планов и мониторинга выполнения всех работ. О роли администратора, его правах и обязанностях вы можете узнать в отдельной статье.
- Исполнитель — организация или лицо, выполняющая работы, связанные с реализацией проекта.
- Подрядчик — юридическое лицо, выполняющее работы в соответствии с контрактом.
- Поставщик — организация, ответственная за материально-техническое обеспечение проекта.
- Проектировщик — организация или лицо, ответственное за разработку проектно-сметной документации.
- Консультант — фирма и/или специалисты-эксперты для оказания консультационных услуг.
Состав команды зависит от вида проекта и его организационной структуры. Например, IT проект предполагает обязательное наличие проектировщика и тестировщика, а культурный проект — дизайнера-консультанта.
Стадии управления коммуникациями
Система взаимоотношений участников проекта обеспечивает планирование, запуск в действие и регулирование связей между заинтересованными сторонами (ЗС). Также производится их информирование в контексте целей проекта и с учетом интересов лиц
Большое внимание уделяется контролю и мониторингу коммуникационных процедур. Система включает в свой состав три основных процесса построения надежного взаимодействия в проектных коммуникациях
План управления коммуникациями является основным выходом из первого процесса системы. План позволяет найти и формализовать лучшие подходы к началу эффективных и результативных коммуникаций с ЗС. Сами процедуры качественного обмена информацией между участниками проекта реализуются на основе процесса «Управление коммуникациями». Процедура «Контроль коммуникаций» отвечает за оценку и коррекцию информирования и взаимодействия на любом этапе процесса выполнения проекта.
Результативность коммуникаций предусматривает, что ЗС получают информацию своевременно в допустимых и обоснованных форматах. Сведения поступают именно той аудитории, которой они предназначены, являются объективными и оказывают спланированное воздействие без искажений. Виды процессов управления коммуникациями и показатели их эффективности отражает схема, представленная далее.
Процессы управления коммуникациями проекта и показатели их эффективности
Размещенная выше схема добавляет к традиционной модели несколько значимых акцентов.
- До начала планирования управления коммуникациями должны быть сформированы организационные предпосылки, которые дают возможность создать план коммуникаций. Данная работа происходит на самых ранних этапах разработки проекта, в момент создания плана управления проектом. План управления коммуникациями учитывает виды и состав информационных потребностей ЗС, внешние информационные запросы, физическую архитектуру позиционирования участников.
- В стадии управления коммуникациями включается этап создания инфраструктуры, в том числе программно-информационной платформы.
- Схема включает блок архивирования, без которого невозможно продуктивное развитие активов процессов организации в терминологии PMBOK.
- Схема дополнена шестью показателями эффективности, которые повышают возможности циклического регулирования управления коммуникациями на основе контроля и мониторинга.
Средства исполнения процесса управления коммуникациями уточняются в форме технологий, моделей, методов и элементов системы управления информацией. Сначала возникает план, затем он реализуются, по ходу событий подвергаясь контролю. Реализация дополняется аналитикой и отчетностью. По их итогам процессы могут войти в рецикл, если выявятся недочеты. Интерес может представлять схема поступательных преобразований входов в выходы управления коммуникациями в проекте.
Модель динамики входов и выходов процессов управления коммуникациями
Поставщик оборудования – оптимизация объемов СМР
В процессе разработки ОТР мы много раз обсуждали с поставщиками оборудования возможные варианты снижения объемов СМР. На рисунке 3 показан пример подобных решений. Как видно из рисунка в процессе оптимизации технологической цепочки поставщик оборудования уменьшил объем бункера хранения сырого угля (Δ1) (при сохранении гарантий бесперебойности поставок угля на следующий участок технологической цепочки), что позволило уменьшить, и как следствие облегчить, здание, в котором располагался бункер (Δ2). Уменьшение высоты здания бункера сырого угля позволило отказаться от дорогостоящего вертикального конвейера, заменив его на более дешевый – наклонный (Δ3). Затем поставщик предложил (впервые в своей практике) инновационное решение по интеграции главного рукавного фильтра с бункером готового ПУТ (Δ4), что привело к изменению высоты здания хранения готового ПУТ и соответствующему уменьшению объема металлоконструкций (Δ5).
Рис.3. Пример оптимизации объемов СМР поставщиком оборудования.
Что было важно для нас, как для Заказчика, в данной работе это то, что поставщик оборудования, изменив свою технологию, уменьшил объем поставки своего оборудования и, как следствие, уменьшил стоимость своего контракта. Таким образом, поставщик пренебрег своими интересами ради интересов Заказчика
Конструктивные функции конфликтов в команде
Управление конфликтами – весомая часть системы эффективных взаимоотношений между участниками проекта. Данная тема локализуется в зоне деятельности команды проекта, потому что там отношения особенно концентрированные. Межличностные соприкосновения наиболее часто могут входить в область противоречий, ценностных и целевых предпочтений. Конфликт – это всегда соперничество на ценностном уровне или столкновение ресурсных, статусных и властных интересов между членами группы.
Перед тем, как рассмотреть виды управления конфликтами, разберем вопрос полезности конфликтов, рассмотрим стадии их развития. В последнее время ученые-психологи утверждают, что далеко не всякий конфликт внутри проектной команды наносит вред. У конфликта есть внутренние функции, которые делятся на конструктивный тип и деструктивный. Конструктивные функции важны для проекта и различаются в зависимости от направленности конфликта.
- Информационная функция, дающая импульс к осознанию ценностей и интересов сторон команды в противоборстве.
- Конфликт как способ снятия стрессовой напряженности и разрядки обстановки в команде.
- Функция стабилизации команды как социальной системы и ликвидации источников неудовлетворенности.
- Конфликт как способ консолидации команды вокруг общей цели и формирования чувства причастности и активизации участников.
- Функция стимулирования командного творчества, мобилизации энергии для решения задач.
- Средство формирования новых форм общения внутри команды.
- Функция конструктивной инициации личностного развития члена команды.
Управлять конфликтами целесообразно с учетом стадий их жизненного цикла. Еще до момента инцидента противоречия формируются и начинают «вызревать», а противостояние носит скрытый характер. Постконфликтная фаза характеризуется либо относительно безоблачными деловыми отношениями между бывшими соперниками, либо производными столкновениями в иных сферах взаимодействия. Аналитики предлагают выделять следующие стадии конфликтов:
- предконфликтная фаза, которая никак не проявляется и остается на уровне внутренних процессов участников события;
- начало конфликта;
- эскалация (нагнетание) конфликта;
- завершение ситуации;
- постконфликтная фаза.