Управление проектами Multi manager/Project manager менеджер

2021-12-05 12:15:00 Советы, как эффективно занять минуты совещания

#meetings
#kickoff

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

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

Как занять минуты встречи: наши простые советы

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


Как настроить шаблон протокола собрания

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

Тема встречи, включая название проекта или этапа

Дата и время проведения совещания

Список участников, включая руководителя собрания

Статус всех пунктов и задач предыдущей встречи

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

Место проведения совещания

Продолжительность совещания

Список членов команды, которые не присутствовали

Любые утвержденные решения

Дата и время следующей встречи

Вопросы, которые будут обсуждены на следующем совещании

Ожидаемые действия от товарищей по команде к следующей встрече

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

2021-11-29 12:15:00 Советы по созданию полезных отчетов по проектам

#reports
Определите цель: Поймите цель отчета о проекте и то, что вас просят передать.
Знайте аудиторию: для кого вы создаете отчет и что они хотят знать о проекте?
Выберите формат отчета: выберите, будет ли это презентация, ссылка на файл или печатный документ.
Набросок отчета: Создайте приблизительный проект того, что вы готовите, и внимательно его просмотрите. Убедитесь, что вы включили все детали, которыми хотите поделиться с командой, и обратитесь к руководителям команд, чтобы заполнить любые пробелы до завершения.
Рассмотрите компоновку: Придайте отчету хорошую структуру и эффективную компоновку. Облегчите определение наиболее важной информации сначала при сканировании и перечислите другие детали как второстепенные.
Выделите ключевое содержание: Если объем отчета превышает несколько страниц, создайте оглавление и подзаголовки для удобства просмотра. Читатели должны иметь возможность быстро находить ключевую информацию.
Корректность: Используйте Советы по созданию полезных отчетов по проектам

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

2021-11-28 13:15:00 Как написать отчет по проекту?

#reports

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

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

Почему отчеты по проектам важны

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

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

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

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

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

2021-11-14 19:47:51 10 лучших качеств руководителя проекта

#pm_skills

Успешный проект, как правило, предполагает выполнение проекта в соответствии с объемом, временем и бюджетом.
Эффективный руководитель проекта должен иметь:

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

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

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

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

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

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

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

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

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

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

2021-11-03 11:10:00 Поворот не туда или как понять, что всё пропало? Часть

#Projects_Fail_part4

Мы продолжаем список распространенных причин неудач ИТ-проектов.

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

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

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

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

2021-10-31 13:15:00 Поворот не туда или как понять, что всё пропало? Часть

#Projects_Fail_part3


Мы продолжаем список распространенных причин неудач ИТ-проектов.

Чрезмерно оптимистичный График проекта

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

Переполнение проектов

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

Продолжение следует... Открыть/Комментировать

2021-10-30 11:15:00 Поворот не туда или как понять, что всё пропало? Часть

#Projects_Fail_part2


Мы продолжаем список распространенных причин неудач ИТ-проектов.

Выбор технологий

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


Размытие границ проекта

Что произойдет, если при разработке продукта вам будут представлены новые идеи? Ответ прост: вы теряете концентрацию. Да, хорошо продолжать совершенствоваться, но вам нужно где-то "остановиться", чтобы выпустить результаты.
Подходящее время для проведения мозгового штурма-это ранняя фаза проекта, когда собираются все требования, выбираются технологии и завершаются технические процессы. Ранние этапы проекта используются для определения того, что должно быть построено и как это должно быть построено. После завершения работы проектная группа переходит к разработке согласованного продукта.
Рост требований становится проблемой, когда вы продолжаете добавлять функциональные возможности, не выделяя больше времени или бюджета. Т.е. вы, заказчик или продак продолжаете генерировать идеи без изменения первоначальных планов. Аналогичным образом, для изменения существующих требований также может потребоваться больше повторной работы, времени и усилий, что повлияет на базовые показатели эффективности вашего проекта.
Имейте в виду, что не все требования должны быть реализованы в текущей версии приложения. Если вы близки к производству и к вам проникают новые требования, убедите заинтересованные стороны сохранить их для более поздней версии.
Такой подход может привести к катастрофическим последствиям для вашего проекта, если вы будете продолжать улучшать один и тот же результат снова и снова. Это приводит к огромному расширению возможностей, если вы продолжаете предлагать лучшие идеи для своего продукта, когда он находится на стадии разработки.
Но всегда есть место для совершенствования.
Эти идеи могут быть детищем клиента, руководителя проекта или даже членов проектной команды. Лучшие идеи могут принимать различные формы, такие как новые требования, модификация существующих функций и изменение модели данных, принятие лучшего подхода к кодированию и лучшей организации существующего кода.

Продолжение следует... Открыть/Комментировать

2021-10-26 13:15:00 Рубрика "What "

#What
#Glossary
#Terminology
#Stakeholder

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

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

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

2021-10-26 10:15:00 Поворот не туда или как понять, что всё пропало?

#Projects_Fail_part1

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

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

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

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

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

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

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

2021-10-23 11:10:00 Как управлять постоянно меняющимися требованиями?

#management
#requirements

Постоянно ли меняются требования к вашему проекту?  Умеете ли вы управлять ожиданиями заказчика?

Представляем наши рекомендации.

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

Инструменты управления изменениями

Четкий набор требований

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

Попросите всех ваших заинтересованных сторон просмотреть список и подтвердить, что в нем представлено текущее представление о том, что они хотят получить от проекта.

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

Определите ожидания

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

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

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

Создайте (или просмотрите) процесс управления изменениями

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

В любом случае, шаги, которые нужно пройти, одинаковы:
Получен запрос на внесение изменений в базовые требования.
Изменение оценивается в соответствии с установленными критериями, как правило, влияние на:
Расписание
Ресурсы
Другие требования
Бюджет
Риски проекта
Цели и проект в целом, если изменения не будут внесены.

Принимается решение о том, следует ли вносить изменения или нет.

Если да, задокументируйте изменения, обновите планы и расписание и сообщите всем об этом.
Если нет, сообщите лицу, запросившему изменение, что работа не будет выполнена, и объясните причины.

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

Вы на верном пути, когда:
У вас есть четкий набор требований, которые будут служить основой
Все понимают, что означает внесение изменений в них Открыть/Комментировать