Инициация проекта – Введение в программную инженерию

Что такое «консалтинг»?

Предлагаю для начала определиться с терминологией.

Мне кажется при внедрении ERP представители бизнеса несколько по-иному понимают понятие «услуги консалтинга», чем представители компании-исполнителя. Давайте попробуем внести ясность. Определение из Википедии:

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

Так вот, цель проекта – внедрение ERP-системы. Именно это прописывается в договоре с исполнителем. В рамках проекта внедрения консультанты НЕ будут выполнять аудит и реинжиниринг бизнес-процессов как таковых.

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

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

Действительно, при внедрении ERP происходит «оптимизация…, повышение…, минимизация…» бизнес-показателей, но это происходит только, если выполняется хотя бы один из пунктов ниже:

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

Что является основанием для начала проекта?

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

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

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

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

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

Выбор проектных инициатив

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

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

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

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

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

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

Что мы понимаем под объемом целевой группы? Состав и значимость заинтересованных в проекте сторон также очень важен и требует хотя бы субъективной экспертной оценки. Это могут быть непосредственно участники проекта: заказчик, инвестор, куратор, PM и т.д.

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

Наконец, третьим большим критерием оценки выступает достижимость или реализуемость инициативы. Она тоже делится на параметры:

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

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

Инициация проекта

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

Группа процессов инициации (рис. 3.5) состоит из процесса разработки устава проекта и процесса определения заинтересованных лиц.

Группа инициирования

‘ ‘

Разработка

Устава проекта

ч___

/-N

Определение

заинтересованных лиц

ч___/

Рис. 3.5. Процессы инициации

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

Процесс разработки устава проекта

Рис. 3.6. Процесс разработки устава проекта

Устав проекта. Это документ, выпущенный инициатором (спонсором) проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта. В отечественной практике данный документ чаще называется Концепция проекта. Концепция (от лат. сопсерйо — понимание, система) есть система взглядов на «понимание» или трактовку какого-либо предмета, явления или процесса, основная точка зрения или руководящая идея для их систематического освещения.

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

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

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

Высокая — ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1,5 раза превышают расходы. Все допущения при проведении этих оценок четко обоснованы.

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

Средняя — проект позволяет улучшить эффективность производства в компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

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

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

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

Шкала оценки стратегической ценности проекта может иметь следующие градации.

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

Выше среднего — создает временные конкурентные преимущества, способствует выполнению обязательств перед многими важными клиентами, конкурентное преимущество может быть удержано в течение 1 года.

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

Низкая — стратегическое воздействие отсутствует или незначительно, влияние на клиентов несущественно, конкуренты могут легко повторить результаты проекта.

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

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

Низкий — цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

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

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

Высокий — цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе, в отношении которой крайне мало ясности. Технологии имеют неподтвержденную стабильность.

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

У каждого проекта должна быть концепция проекта. Если проект небольшой, то для изложения концепции часто достаточно несколько абзацев. Однако давать старт проекту без концепции — это все равно, что отправлять корабль в плавание, не определив для него пункт назначения.

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

Концепция проекта содержит, как правило, следующие разделы.

1. Название проекта.
2. Цели проекта.
3. Результаты проекта.
4. Допущения и ограничения.
5. Ключевые участники и заинтересованные стороны.
6. Ресурсы проекта.
7. Сроки.
8. Риски.
9. Критерии приемки.
10. Обоснование полезности проекта.

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

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

Изменения в компании — например, автоматизация ряда бизнес-процессов для повышения эффективности основной производственной деятельности.

Реализация стратегических планов — например, завоевание значительной доли растущего рынка за счет вывода на него нового продукта.

Выполнение контрактов — например, разработка ПО по заказу.

Разрешение специфических проблем — например, доработка программного продукта в целях приведения его в соответствие с изменениями в законодательстве.

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

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

Также должны быть сформулированы высокоуровневые требования, содержащие краткое описание, и при необходимости, ключевые свойства и/или характеристики продукта (услуги).

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

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

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

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

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

К ключевым участникам программного проекта относятся:

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

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

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны по сравнению с этим расходами. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до 100%.

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

Распределение трудозатрат по основным производственным

Рис. 3.7. Распределение трудозатрат по основным производственным

процессам при разработке ПО

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

Ф. Брукс писал: «Чтобы родить ребенка, требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер». Брукс также приводит исключительно полезную, эмпирическую формулу оценки срока проекта по его трудоемкости, которая была выведена Б. Боэмом (Barry Boehm) на основе анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле для проекта, общая трудоемкость которого составляет TV чел,-мес., можно утверждать, что существует оптимальное с точки зрения затрат время выполнения графика для первой поставки:

Т= 2,5N^l/

т.е. оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в чел.-мес. Кривая, представляющая оптимальную численность проектной команды, представлена на рис. 3.8. Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время. Кривая стоимости резко возрастает, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за ³/₄ расчетного времени оптимального графика, вне зависимости от количества занятых в нем работников (рис. 3.9). Этот примечательный результат дает менеджеру программного проекта солидное подкрепление, когда высшее руководство требует принятия невозможного графика.

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

Зависимость длительности проекта и численности команды от суммарной трудоемкости

Инициация проекта - Введение в программную инженерию

Трудоемкость, чел.-мес.

-Опт. длит. —Мин. длит. — Опт. числ.

Рис. 3.8. Закон Б. Боэма

Инициация проекта - Введение в программную инженерию

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

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

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

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

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

Процессы инициации проекта.

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

Цели и задачи проектной инициации

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

Выше вашему вниманию предложена модель процессов инициации, заимствованная из курса МВА по управлению проектами А.В. ПолковниковаПолковников А.В. Управление проектами. Полный курс МВА/ А.В.Полковников, М.Ф.Дубовик – М.:

Издательство «Олимп-Бизнес», 2022 – 552 с. . Каждому процессу функциональных зон проектной интеграции и содержания на нашем сайте посвящен отдельный материал. Нас же здесь интересует в большей степени само начало инициации в вопросе, как принимается решение о проекте и о его месте в портфельном рейтинге?

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

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

Среди задач-результатов процессов инициации выделяются следующие.

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

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

Похожее: 11 лучших аутентификаторов для Android, iOS, Windows и macOS | Блог Касперского