Best Practices

对于Rapid 实施项目，需要制作一份详细的范围文档以确认最适合客户的建议解决方案。

因为对于Rapid 实施来说，它跳过了许多详细设计活动，这样就便得客户缺少足够多的机会去学习解决方案和其有关的其它功能。因此对Rapid项目来说制作一份详细且清晰的范围报告就显得非常重要。

这份范围报告在某种程度上可以让客户了解到产品和解决方案，这份报告的另一个功能是尽量减少由于误解和不清晰的预期目标所带来问题的可能。做出一份功能需求文档（Functional Requirements Document (FRD)）来对应范围报告。然后在项目的整个生命周期都使用这份范围报告来管理客户的预期。

针对Rapid项目，设定明确的预期目标。

虽然在某些情况下Rapid项目都有现成的解决方案，但还是要确认客户是否清楚的知道他们的真实期望到底是什么。同时要让客户清楚在此项目中是否有或有多少客制化。

虽然在Rapid 项目中客户的总承诺时间会少于其它项目类型，但参与程度会更加集中和激烈。

对于分阶段实施或多站点方案，要确保有一个项目中期升级或新版本发布计划。

因为分阶段或多站点实施相比其它方案会持续很长时间，在整个项目周期很可能遇到一些关键版本发布或升级。

确保有一个计划用于实施中的升级。例如是现在升级还是等整个项目结束再升级。

在对阶段型项目进行评估时，确保包括了临时集成所发生的成本。

在阶段实施中会经常需要对遗留系统或业务系统进行临时性的集成。这些集成的设计和开发成本可能会超过分阶段实施所带来的收益。在分析中要包括这些成本以决定实施方案。

针对Pilot rollout 制作一张时间表避免项目不会成为“僵尸项目”。

Pilot rollout 实施很容易因为客户不停的“微调”解决方案（Analysis paralysis），造成项目停止不前，最后变成僵尸项目。因此制定一个清晰明确的时间表（Timeline）可以帮助项目持续向前推动。