| 1 | Проект принимает или находится под влиянием методологии реализации, диктуемой провайдером. | Методология оговаривается с провайдером и клиент вводится в курс дела. |
| 2 | Руководитель проекта по реализации пакета программ должен быть осведомлен о стратегической и тактической инициативе со стороны высших уровней, поскольку это может повлиять на проект.
Руководитель проекта должен планировать способ приспособления промежуточных выпусков продукта и улучшений в жизненном цикле проекта.
Руководитель проекта должен спланировать управление элементами репозитория конфигурации (Configuration Repository), которые являются результатами специализации продукта для конкретного клиента. | Руководитель проекта должен фокусироваться только на проекте. |
| 3 | Изменения могут произойти вследствие необходимости исправить ошибки или улучшить продукт. | Изменения зачастую происходят из-за возникновения или смены требований со стороны пользователей. |
| 4 | Реализуемый продукт должен быть создан наряду со списком функций, который должен быть оговорен с командами техников и менеджерами по продажам. Любые изменения продукта или его специализации, которая является уникальной для данной реализации, должны быть четко отделены от функций продукта. Требования должны быть классифицированы в группу тех, которые уже существуют в продукте, и тех, которые должны быть специализированы и внедрены для воплощения нужд конкретного клиента. | Полный набор требований составлен для конкретного клиента и никакой другой классификации не требуется. |
| 5 | Документация по продукту дает клиенту представление о том, как требования будут исполнены в разрабатываемом продукте. | Зачастую используются прототипы или демонстрация системы, в зависимости от размера проекта. Ведь клиент хотел бы увидеть систему и проверить, насколько успешно продвижение вперед. |
| 6 | Прогноз реализации зачастую выполняется путем оценки каждого действия, и результат оценивается по количеству затраченных усилий/дней. Такой метод оценки, как балльная функциональная оценка, используется редко. | Руководитель проекта может создать прогноз, основываясь на своем опыте в применении определенного метода прогноза (балльная функциональная оценка, сценарии использования и т.д.) |
| 7 | Клиенты предпочитают решение, воплощенное в пакете программ для того, чтобы сократить период от начала разработки изделия до выхода его на рынок. Это объясняет, почему ожидаемые сроки разработки часто бывают агрессивными. | Поскольку решение создано с нуля, клиенты обычно осознают все препятствия, и, следовательно, сроки не слишком агрессивны, по сравнению с реализацией упакованного решения, собранного из купленных комплектующих. |
| 8 | Прибыль проекта классифицируется как лицензионный платеж, плата за специализацию, платеж за профессионалов и годовое обслуживание контракта (AMC). Контракты обычно являются смесью фиксированного контракта и временных и материальных услуг. | Прибыль проекта должна быть классифицирована в различные категории. Контракты обычно фиксированные, но бывают случаи и отдельных временных и материальных услуг. |
| 9 | Плата за лицензию обычно известна заранее. Платы за специализацию или профессионалов привязаны к контрольным точкам. | Затраты привязаны к контрольным точкам. |
| 10 | Стандарты организации провайдера используются для предоставления результатов. К примеру, шаблоны документов будут такими, какие привыкла использовать организация провайдера. | Клиент может запросить организацию провайдера принять его стандарты для всех предоставляемых результатов. |
| 11 | Ожидания клиентов всегда различны и отличаются друг от друга в отношении качества. Следовательно, команды разработчиков и исполнителей должны работать вместе для того, чтобы предоставить продукт, который будет удовлетворять всем стандартам качества, установленным клиентом. | Решение создается для того, чтобы удовлетворить все требования конкретного клиента, следовательно, его ожидания относительно качества должны быть удовлетворены. |
| 12 | Вовлеченность клиента минимальна, поскольку он полагается на проектную команду, а также из-за отсутствия знаний о товаре. Задачей команды разработчиков является реализация всех требований. | Клиент будет вовлечен как можно большим образом потому, что его очень интересует развитие продукта. |
| 13 | Команда обычно состоит из экспертов в области, относящейся к продукту. В общем, принимается структура команды в виде матрицы. Руководитель проекта работает с ограниченной властью. | Структура команды согласуется с проектом, а руководитель проекта обладает высоким уровнем власти и контроля. |
| 14 | Влиятельный руководитель проекта будет во благо, поскольку иерархическая или экспертная власть будет во вред - слишком большая концентрация и использование экспертов в команде. | Власть экспертов и иерархическая власть будет во благо. |
| 15 | Продуктивность индивидуумов и команды во многом зависит от знания товара. | Продуктивность индивидуумов и команды зависит от технического опыта и опыта в предметной области. |
| 16 | Выпуски и обновления продукта или пакета могут влиять на реализацию контрольных точек проекта. | Выпуски полностью контролируются проектной командой. |
| 17 | Права на интеллектуальную собственность принадлежат провайдеру. Права на специализированную часть продукта могут принадлежать клиенту или провайдеру - в зависимости от контракта. | Права на интеллектуальную собственность принадлежат клиенту. |
| 18 | Продукт и связанные с ним предоставляемые результаты контрольных точек должны быть отданы на хранение агенту по эскроу (лицо, принимающее на временное хранение документы и другие ценности до урегулирования взаимоотношений между сторонами сделки или спора) для предотвращения банкротства клиента или других непредвиденных обстоятельств. | Клиент имеет полный доступ к артефактам проекта и экскроу-договор не требуется. |
Бизнес-требования выполняются либо путем создания новой системы, либо путем покупки уже готового продукта, либо комбинацией обоих этих вариантов. Выбор любого из этих вариантов осуществляет участниками после взвешивания различных параметров. Решение о разработке заключается в создании специализированных проектов (сделанных на заказ), в то время как решение о покупке заключается в проекте по реализации пакета готовых программ. Технические, функциональные и управленческие трудности различаются среди данных двух категорий, поэтому и опыт, полученный во время реализации каждого, различен.