10 основных компонентов проектного менеджмента для ГИПа

Для большинства русских людей, получивших «совковое» образование, оторванное от основных международных трендов, понятие «проектный менеджмент» несёт в себе какой-то непонятный смысл. Что это? По мнению одних, это новая область знаний; по мнению других, это всё те же старые знания, облачённые в новые слова. И чем больше вникаешь в суть вопроса, тем более становится понятно, что истина где-то посередине. Вроде бы попытка шаблонизации действий по исполнению текущих задач, ведущих к достижению цели, но рамки шаблонов размыты и не имеют каких-либо чётких ограничений. Что крайне не привычно для людей, воспитанных жестких рамках всевозможных ограничений. В проджекте всё неопределённо — надо делать так, но если что-то не так, то так делать не надо, а надо делать этак.  Инструкция по применению каких-то методик? Как-будто элементы инструкций налицо: существует строгая последовательность операций для любого проекта и внутри каждого действия существуют подзадачи с прописанными указаниями к действию. Но тем не менее самих методик нет и не даётся конкретных инструкций что делать, когда то-то и то-то получается не так, как нужно. Выбор таких действий остаётся за менеджером. Каждый заполняет шаблоны контентом, основанным на собственном опыте.  На мой взгляд в проектном менеджменте объединены обе эти функции, но главный смысл всех мероприятий по ведению проекта по правилам PMI (института проектного менеджмента) заключается в документальном сопровождении реализации комплекса действий по достижении определённой цели. Зачем нужно документальное сопровождение?

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

Во-вторых, для стандартизации отображения процессов по отслеживанию хода исполнения текущего проекта и использования этих стандартов во всех последующих проектах. То есть в каждом проекте мы создаём шаблон из списка последовательности действий (WBS) и подтверждения этих действий соответствующим документом. Получается своего рода инструкция по применению. На самом деле, этот подход ничем не отличается от классической деятельности по исполнению комплексной работы, например в строительстве, существовавшем с незапамятных времён, с той лишь разницей, что советское производство не признавало изменений и все процессы и последовательности, расписанные в каком-либо НИИ, притом людьми, зачастую плохо знакомыми с производством, были незыблемы и их изменение требовало титанических усилий. В противоположность такому жёстко структурированному подходу, в современном проектном менеджменте важнейшая роль выделяется изменениям и действиям по их исполнению или нейтрализации, так как самый неизменный процесс в современном мире, это процесс изменений «и мы все знаем, что изменения будут»(Дженнифер Уитт).

В-третьих, создав шаблон последовательности действий по подобию программы MS Power Point, мы в каждую ячейку загружаем конкретные шаги и инструкции, применимые к данному подразделу, исходя из собственного опыта и знаний, либо берём это описание у других, успешно выполняющих подобные задачи. Такое заимствование может иметь различные формы, например: франшиза для магазина; пройти курс обучения в специализированном учреждении; просто взять (подсмотреть, украсть) идею, что наиболее распространено во всех областях человеческой деятельности, например поработав в компании, «набраться опыта», прихватить технологий и уволившись, создать точно такую же компанию. Хотя, на самом деле мультиплицирование игроков на рынке и вытекающее отсюда усиление конкуренции, это и есть главная предпосылка прогресса.

Как и в любой комплексной теории, у теории проектного менеджмента существует множество вариантов объяснений её сущности.  Один из наиболее интересных и популистских, в смысле понятных для прикладного применения, на мой взгляд, приводит Дженнифер Уитт, директор веб-сайта projectmanagement.com, которая даёт живое описание 10 основных составных компонентов проекта, наиболее часто используемых специалистами проектного менеджмента. Повторюсь ещё раз, что эти термины описывают уже не теорию, но конкретные действия и важнейшие задачи по созданию и сопровождению проекта, то есть шаги по выработке шаблонов или термины, применяемые международным сообществом для процессов проектного менеджмента, поэтому я привожу первичные названия на английском языке.

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

1.WBS –work breakdown structure-детализация позиций.

Структура разбивки всего проекта на группы работ и подпозиции. Это подраздел группы SCOPE – цель проекта. Когда определен путь, ведущий к цели, то есть объем работы, которую необходимо выполнить, она должна быть разбита на меньшие работы, сопоставимые с возможностями единицы рабочей силы, например бригады рабочих или группы из нескольких чертёжников. Например, в строительстве всегда существовали сметы, которые автоматически разбивали возведение здания на отдельные виды работ. Взяв за единицу бригаду, к примеру каменщиков, разбиваем кладку всего дома на этажи или блоки, в зависимости от ситуации. В проектировании также регулятором установлены правила разбиения всего проекта на разделы, отображенные в 87 постановлении правительства РФ от 16.02.2008, которое так и называется «О составе разделов проектной документации и требования к их содержанию». В пределах одного раздела, в зависимости от квалификации исполнителей и опыта ГИПа предварительно создается список работ и назначаются исполнители. Во время контрольных сверок с планом и качеством исполнения обычно возникают подсписки, отображающие собственно информационный состав проекта. Это и будет низшим уровнем детализации. Как правило опытные проектировщики изначально могут создать почти полный список-содержание, исходя из опыта и ранее выполненных похожих проектов. В строительстве нет чёткой привязки по виду работ, всё зависит от объёма. Большой объём одинаковой работы иногда целесообразно разбить на меньшие для упрощения учёта сделанного или начисления зарплаты по факту выполнения. У меня, при строительстве частного дома, однажды сложилась такая ситуация, что пришлось разбивать один этаж на отдельные стены, которые делали 4 бригады, так как в виду внезапного потепления в ноябре-декабре 2008 года хозяин решил возвести коробку дома в этом же году, а не откладывать на следующий, как планировалось ранее. Так же и в проектировании, при большом объёме однотипной работы и достаточном количестве подготовленных исполнителей можно разбить эту работу, получив результативную работу в ограниченные сроки.

2.Milestones –вехи исполнения проекта.

       Значительное событие или окончание группы работ называются вехой. На графике Гантта в Майкрософт проджекте обозначается черным бриллиантом (ромбиком). По сути это не конкретная работа, хотя в принципе в конце каждой позиции можно установить веху. Вехи обычно служат для обозначения срока окончания группы работ, объединённых по какому-либо признаку: однотипность, объём, последовательность. Например, при создании общего графика для всего проекта, обратимся  опять к 87 постановлению правительства РФ «О составе разделов проектной документации …». Используя разделы из 87 постановления, как группы работ, определяем время окончания по созданию каждого раздела и помечаем вехой. Закономерен вопрос – зачем нам какие-то вехи, то есть дополнительная работа, если мы и так должны сделать каждый раздел. Этот вопрос подразумевает два вполне логичных ответа, в дополнение к сказанному в 1 части – разбивка проекта на группы:

  1. Когда проектная организация взялась за выполнение работы по созданию чертёжного проекта здания, то по условиям договора работа должна быть выполнена к определенному сроку. Руководствуясь взятыми обязательствами, ГИП с группой исполнителей, исходя из собственного опыта назначает каждой работе-позиции конкретное время исполнения. При нехватке исполнителей в группе, привлекаются специалисты из резерва организации или со стороны. При составлении отчёта о ходе проекта ГИП отмечает выполненные позиции в пределах между двух вех, по сути давая укрупнённые показатели. Веха, точнее процент её выполнения, как раз даёт понимание для руководителей о соблюдении принятого графика либо об отставании и необходимости принятия мер по выправлению ситуации.
  2. Для облегчения рутинизации составления расписания создания чертёжного проекта на основе анализа предыдущих работ. Например, создав один раз расписание по созданию проекта 12 этажного дома, площадью 500 м2 на этаж, определяем вехи и после исполнения проекта проставляем вехи по реальным срокам. Во всех последующих проектах, можно отталкиваясь от этого проекта, назначать количество исполнителей и время для разработки каждого раздела и даже каждого этажа, при возникновении такой необходимости, для всех похожих проектов с некритичной дифференциацией исходных данных. К примеру, не составит труда рассчитать по трудозатратам в процентном соотношении 16 этажный дом с площадью этажа 600 м2.
  3. Baselines – базовые параметры.

Утвержденный план проекта, например, расписание или график выполнения отдельных позиций или групп работ. Для успешного исполнения чертёжного проекта необходимо иметь в наличии достаточное количество исходных данных. Наиболее важные, это: ГПЗУ, техзадание заказчика, инженерно-разрешительная документация. На основании исходных данных ГИПом создаются: план работ, календарный график, бюджет проекта, назначаются всевозможные ресурсы. Далее, вся созданная документация обсуждается, корректируется и утверждается с участием CCB – change control board, руководителями и участниками, вносящими изменения, например инвестор, ведущий архитектор, застройщик. Все проекты подвергаются изменениям во время их исполнения, поэтому важно зафиксировать первичный вариант – baselines, чтобы в дальнейшем, когда ответственные за вариации участники (CCB) будут вносить изменения, влекущие увеличение продолжительности, они же и брали ответственность за увеличение сроков.

Следующий немаловажный аспект, часто не принимаемый в расчёт, в виду некоторой нетактичности поднятия финансовых вопросов с одной стороны и порой желания проектировщиков получить максимальный доход с клиента, это платёжеспособность клиента. Несомненно, это свойственно природе человека – желание получить максимальное количество всего, что бы это ни было, не всегда принимая в расчёт наличие денег на выполнение грандиозных планов, или просто «на авось, прорвёмся», главное начать, а потом денег найдём. В проектном сообществе таких ещё называют –«хотелкин». В такой ситуации, финансирование проектных работ может прерваться в любой момент с непредсказуемыми последствиями, когда окажется, что денег на такой проект нет и необходимо либо уменьшать площади, либо переделывать весь проект, но при этом бюджет на проектные работы уже утверждён и изменения не будут оплачены. Конечно, всё зависит от количества работы, которую необходимо будет сделать для соответствия новым требованиям. Если процесс проектирования в начальной стадии, то может иногда и можно пойти на некоторые уступки ради поддержания хороших отношений, но обычно всё происходит не по самому желательному сценарию. Поэтому, чтобы не попасть в такую ситуацию, ГИП должен не только хорошо разбираться в вопросах заключения договоров, но и владеть усреднёнными данными по стоимости создания чертёжного проекта и иметь представление о стоимости строительства и для некоторых объектов стоимости эксплуатации, чтобы при возникновении вариаций во время разработки техзадания, или тем более после начала работы по созданию чертёжного проекта, своевременно предупреждать заказчика о примерной конечной стоимости нового здания.

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

 

  1. Triple constraintтри ограничителя: время, стоимость, цель.

Такая структура существовала довольно-таки долго в проектном менеджменте, но впоследствии в группу ограничителей добавили качество, так что уже получился не треугольник, а квадрат; или скорей треугольник в круге, так как оказалось, что качество это наиболее важный из ограничителей, влияющий на все остальные самым непосредственным образом. Эти четыре параметра являются базовыми, по которым оценивается проект. Также регулярно сверяя реальные значения этих параметров с baselines проектный менеджер получает картину исполнения проекта в каждый необходимый определенный срок. И совершенно очевидно, что при возникновении отклонений по любому из параметров, его восстановление потребует манипуляций с другими ограничителями. Например изменили цель – проект увеличился на N количество квадратных метров – время и стоимость также вырастут. Закончились внезапно деньги у заказчика – меняется цель (довести до консервации) и время.  Качество по идее не должно изменяться, но тем не менее должны существовать достаточно чётко определённые критерии качества. Например чертёжный проект, созданный в автокаде, является пока что наиболее распространённым для чертёжной документации. Тем не менее соременный программный софт позволяет создавать чертежи, снабженные 3D видами отдельных узлов, визуализировать отдельные сложные участки, что несомненно облегчит труд строителей и снимет некоторые вопросы на стадии планирования последовательности проведения работ. Например, увидев в модели какие-либо объёмные агрегаты, заложенные инженерами, строители смогут предусмотреть и спланировать работы по установке этого оборудования с наименьшими издержками, не прибегая как обычно к демонтажу участков стен или перекрытий.  Таким образом 3D виды или то, что мы называем сейчас BIM – моделированием, дает проекту новый уровень качества, присутствие которого может быть оговорено в контрактных документах. Или более распространённая проблема качественного чертежа: чертёжник не сверил(а) на одном из листов размеры с эталоном (моделью) и начал(а) мультиплицировать чертёж с ошибкой в одном из подразделов. Попав на стройплощадку такие чертежи создадут некоторые проблемы, которые будет необходимо в зависимости от того на каком этапе это вскроется, тем или иным способом урегулировать.

Если проект не соответствует требуемому качеству или параметрам, определённым на стадии планирования, такая ситуация автоматически влечёт возникновение споров и последующей переделки. Любая переделка обходится дороже, чем создание изначально правильного продукта. И самое печальное в такой ситуации то, что заказчик будет относиться с подозрением ко всей последующей работе и выискивать в ней ошибки. Восстановление доброго имени потребует значительных усилий как в плане качества, так и на коммуникативно-убедительном уровне. Если же ошибка вскроется на конечной стадии сотрудничества, то скорей всего, времени на восстановление хороших отношений не будет, и у клиента останутся о вас только плохие воспоминания как о бракоделе, халтурщике вне зависимости от того, насколько прекрасно вы ладили до этого. И самое печальное в этой ситуации, это то, что он уже не вернётся к вам с новым заказом и никому вас не порекомендует. Такая особенность заказчиков замечена не только мной, но и другими (P. Netscher, “Tips and Tricks», 2017)

  1. Projectlifecycle – жизненный цикл проекта.

       Инициация, планирование, исполнение, закрытие. Эти циклы определяют путь, по которому должен развиваться проект. Но, планирование само по себе, без мониторинга, без сверки с плановыми параметрами: сроки, количество ресурсов…, не имеет смысла. Поэтому проектные менеджеры осуществляющие исполнение, должны сверяться с плановыми показателями и наоборот, плановики проверяют ход выполнения проекта на соответствие запланированному. В небольших организациях обычно обе функции выполняет один менеджер, поэтому составляется только один регулярный отчёт о ходе исполнения. Кстати сказать, отчёт обязательно должен проверяться во избежание возникновения в дальнейшем неразрешимых проблем, связанных с отсутствием контроля и безнаказанностью. Все эти термины в полной мере применимы к созданию чертёжного проекта с ГИПом в роли менеджера или несколькими ГИПами, разделяющими проект на зоны ответственности. Форма отчётов совершенно не важна, я пользуюсь простой таблицей Excel. Важно отмечать отклонения сроков и сроки устранения. Желательно разработать про запас решения по устранению отклонений в момент идентификации первых признаков их возможного наступления, в случае если не удастся выправить ситуацию обычным путём. Например, осведомиться у знакомых субподрядчиков и фрилансеров о наличии свободного времени.

 

  1. Ganttchart – график Гантта.

Графическое отображение расписания проекта или как ещё его называют календарный график. Наиболее распространенный на данный момент софт, позволяющий довольно-таки просто составить компьютерный график, это Microsoft Project. Конечно график может быть составлен и в Excel и от руки, но если необходимо будет отслеживать ход выполнения расписания работ и вносить изменения, возникающие по ходу выполнения проекта, то любые статичные графики будут отнимать слишком много времени на внесение этих изменений, так как большинство работ взаимозависимы, и задержка исполнения одной влечёт задержки других. В MS Project’е изменения одной позиции автоматически изменяют весь график, давая наглядную картину всего проекта и позволяя принимать решения, имея наглядное представление о возможных последствиях. Интерфейс приложения вполне понятен всем, знакомым с Excel и весение данных по продолжительности отдельных работ в график не составляет какого-либо труда. Правда существуют некоторые сложности с назначением ресурсов для каждой позиции , но так как при создании ГИПом первичной (плановой) документации по ведению и развитию проекта, в любом случае изначально ресурсы лучше отобразить в Excel в виде классической таблицы для наглядности, расписав позиции работ в один столбик и назначив людей в другой, то по большому счёту необходимость прикреплять людей и усложнять график Гантта совершенно отпадает. Ниже приведён пример такой элементарной таблицы, содержащей все базовые параметры проекта. Вносить изменения в такую таблицу при необходимости не составляет никакого труда.

N Наименование работы Назначение Кол-во начало окончание
1 стадия П Иванов (отдел) 10 1.1 1.3
1.1 фундамент Смирнов, Петров 2 1.1 1.2
1.2 стены Андреева, Киселёв, Ким 3 1.1 1.2
           

 

  1. CCBchange control board.

Буквально – контролирующий изменения совет. То есть представители различных групп, вовлечённых в проект, облечённые полномочиями утверждать изменения либо отвергать их, либо деятельность которых напрямую влияет на ход проекта. Как это относится к деятельности проектировщиков? Конечно, в проектировании превалирует каскадный подход к разработке проекта, по аналогии со строительством, но тем не менее возможен и итерационный ход развития событий, когда начинаем работать соответственно техзадания, но в процессе работы открываются некие обстоятельства, накладывающие ограничения на дальнейшее развитие проекта в заданном векторе или заказчик сам изменил задание на проектирование. Например, проект почти готов  а заказчик решил увеличить этажность дома. С его точки зрения всё просто – мультиплицируем этажи выше, но на практике вслед за таким решением, как правило следует достаточно большой объём работы от расчёта нагрузок на грунт и перерасчёта несущих конструкций до разработки нового Проекта Организации Строительства и испытаний в аэродинамической трубе. То есть потребуется создать почти что новый проект. Эти работы, включая создание ведомости новых работ, займут немало времени и стоят денег и соответственно должны получить одобрение на финансирование у директора проектной организации, затем у самого заказчика, который должен подтвердить их необходимость и наконец инвестора. И даже при класически каскадном развитии проекта, изменения, это неотьемлимая часть процесса и предвидение и разработка методик и решений по их нивелированию является одной из основных способностей успешного ГИПа и всего проекта в целом. Например столь обычная сезонная эпидемия гриппа может внести ощутимые поправки в график выполнения и для исправления ситуации потребуется применять срочные меры по привлечению людей, фрилансеров или аутсорсинга. Любые из этих проблем не могут решаться только ГИПом, в каждой из них потребуется одобрение руководителя группы участников проекта. И такую последовательность необходимо письменно закрепить в списке решений по Risk mitigation – смягчению рисков, где в каждой позиции возможного риска обозначить период, по истечению которого после возникновения ситуации необходимо доложить руководителю для выработки решения и собственно руководителей, которых касается эта конкретная ситуация и которые обладают полномочиями по утверждению изменений, требуемых для исправления ситуации.

  1. Stakeholders — участники

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

  1. Change management – изменение управления.

В первых абзацах я уже приводил слова директора «Projectmanagement.com» Деннифер Уитт «мы все знаем, что изменения произойдут, поэтому важно понимать, как мы будем управлять этими изменениями». Здесь всё ясно и понятно – произошло изменение и менеджер должен предпринять какие-то шаги по встраиванию этих изменений в процесс реализации. Вопросы управления изменениями составляют стандартную программу проектного управления.

Изменение управления, хотя и звучит похоже, но затрагивает другую, высшую область проектного управления, собственно само управление проектом. Что это значит? Это некий план по контролю действий по достижению цели. Иногда необходимо предпринимать некоторые шаги для того, чтобы цель была достигнута. Для этого может потребоваться передать часть полномочий другому человеку, так как он более компетентен в данной области или по контрактным и даже по психологическим  проблемам – так решил заказчик и спорить в текущей ситуации бесполезно. В моей практике часто случалось, что клиент забирал себе функции по текущему руководству, а так как его знаний, мягко говоря, не всегда хватало, то приходилось выстраивать сложную систему подстройки и отладки его решений для корректного исполнения. Если встать в позу и оспаривать все его неправильные решения, то проект просто не будет закончен, так как отношения с заказчиком будут испорчены, клиент рано или поздно найдет других исполнителей, они либо худо-бедно, либо превосходно закончат работу, но денег на этом конкретном проекте вы уже не заработаете. Конечно, если за проект не платят, или платят неадекватно мало, то может быть это наиболее правильное решение – поднять собственную самооценку, отказавшись от бестолковой работы. Но настоящее искусство опытного руководителя состоит в том, чтобы «и овцы были целы и волки сыты», то есть проведение постоянного мониторинга процессов происходящих вокруг проекта и создания таких условий, при которых  выиграют все: и он сам, и компания-работодатель, и клиент; то есть дать клиенту поруководить стратегически, не допуская пересмотра оговоренных в договоре цен и не позволяя испортить проект и взвалить в последующем вину за это на вас.

  1. Risk mitigation – смягчение риска.

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

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

РЕЗОЛЮЦИЯ

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

Комментарии к этой публикации закрыты.