Как упоминалось ранее, обстоятельные обсуждения, которые проводились на тему целей, могут привести на этом этапе к довольно длинному списку целей. Приведенный ниже список описывает структуру для организации целей.
• Непрерывность бизнеса/аварийное восстановление (кластеризация, хранение, резервирование и восстановление).
• Производительность (усовершенствования в распределении памяти, общедоступные папки, электронная почта).
• Безопасность (сервер, электронная почта).
• Мобильная связь (Outlook Web Access, поддержка SmartPhone и карманных
ПК).
• Сотрудничество ( сотрудничество в режиме реального времени, замена системы обмена сообщениями Exchange, портал SharePoint).
• Удобство эксплуатации (администрирование, управление, разворачивание).
• Разработка (объекты данных сотрудничества, управляемые API-интерфейсы).
При использовании подобного каркаса все "пробелы" в целях и задачах проекта станут более явными. Некоторые менее эффектные цели (например, устойчивая сеть, возможность восстановления данных, защита от враждебного внешнего мира) могут и не определиться во время обсуждений. Именно сейчас наступает время для того, чтобы поднять все темы, которые, возможно, были пропущены. Только после этого можно переходить к более обстоятельной фазе планирования.
На данном этапе также будет полезно обозначить те моменты, которые будут исправлены посредством процесса модернизации (так называемые "болевые точки"), и новые возможности, которые будут добавлены.
Определение графика работ и контрольных точек
Все, что обычно требуется для определения временных рамок реализации процесса модернизации, - это пронумерованный список задач (в более сложных проектах можно воспользоваться высокоуровневым графиком Гантта, состоящим не более чем из 10-20 строк). Временные рамки должны быть разбиты по фазам для уточнения количества времени, которое отводится на фазы планирования и тестирования. Также должно быть оценено реальное время ввода в действие обновленной системы.
В зависимости от сложности проекта временные рамки в один-два месяца могут считаться "узкими" рамками. В то время как два-четыре месяца предоставят более удобное временное пространство для проектов, ориентированных на большее количество серверов, пользователей и приложений обмена сообщениями. Если часть проекта или весь проект будут ассистировать внешние консалтинговые фирмы, то необходимо добавить дополнительное время. 
Поскольку все проекты различаются между собой, очень важно предусмотреть правила для определения временного интервала для каждой фазы. Опыт показывает, что выделение дополнительного времени для реализации фаз планирования и тестирования способствует более гладкому прохождению процесса модернизации, в результате чего образуется более удачная пользовательская основа. Если планирование будет недостаточным или вообще отсутствовать, то наиболее вероятно, что во время прохождения фазы тестирования будут пропущены основные условия, необходимые для обеспечения успеха проекта. Нельзя также забывать о том, что в течение процесса нужно выделить время на профессиональную подготовку штата администраторов и конечных пользователей.
Основным фактором успешной реализации в узких временных рамках является понимание сопутствующих рисков и определение объема проекта с учетом контроля рисков. Это можно осуществить путем отбрасывания некоторых функциональных возможностей, которые не являются существенными. Второй способ - привлечение внешней помощи для ускорения процесса или использование опыта компаний, которые производили подобные обновления много раз. Поставка соответствующего оборудования и программного обеспечения также может вызывать задержки, поэтому для сокращения временных рамок все необходимое должно быть приобретено как можно быстрее сразу после мысленного определения конфигурации.
На самом деле в некоторых случаях процесс модернизации может занять всего одну неделю. Тогда в понедельник утром можно провести обучение пользователей и начать работу уже на основе новой системы обмена сообщениями.