После того, как получены ответы на первые четыре вопроса, мы имеем две важные категории информации. Первая – это лучшее понимание ценности для клиента, а вторая – это вызов, связанный с переходом от одного набора политик, норм и поведения к другому. Вторая категория является ключом для поиска ответов на следующий вопрос.
Вопрос 5: Исходя из вышеизложенного, какие изменения/добавления нужно сделать в новой технологии?
Другими словами, какие характеристики должны быть включены в разрабатываемую технологию, чтобы поддержать использование политик, норм и поведения, позволяющих получить наибольшую ценность от новой технологии?
Пятый вопрос возвращает нас к планированию проекта и фокусирует его на том, что действительно необходимо. Несомненно, негативные ветви новой технологии должны быть изучены и найдены пути их «отсечения».
Качество команды величина
субъективная, однако его можно выразить через скорость поставки качественного
продукта решающего задачу клиента. Если записать это в терминах 
В любой проектной деятельности самым
базовым элементом планирования работ является "Задача". И это в корне отличает
Проект от деятельности по сопровождению продукта, в которой основной элемент
вокруг которого все вертится, это "Инцидент".
Что такого плохого в гибком (Agile) подходе к управлению проектом по разработке программного обеспечения? Особо ничего, если не считать того что завершение проекта в срок не стоит целью этой методологии.
Иногда
может сложиться впечатление что ваша команда работает медленнее чем обычно. Это
может быть субъективное впечатление, а может быть и на самом деле так. Обычно
рекомендуют в таких случаях, для исправления ситуации, менеджеру проекта
поговорить с каждым участником команды..