论客户和供应商都应能够以自己的方式清楚描述项目的价值。要随着项目的进展及时更新呈现给客户的销售策略，必须反复确认其有效性以避免在项目完成前过时。
服务交付模式定义了客户和所有运营支持团队之间的接口形式。本质上，这个模式代表了客户与项目团队合作的经验，这包括沟通方式、状态报告、原型和单个功能的演示及批准、合同和工作意向。总之，服务交付模式表达了项目中的客户关系如何发展，这种关系通常会留下持久的印象。
为了避免误解和不实际的期望，你需要对客户进行有关项目流程、方法和实践等方面的培训。单页的流程图是一种很好的工具，它能展示每个流程的关键元素。变更管理记录可以避免项目范围蔓延并重排新需求的优先级。项目团队必须与客户交流备选方案，然后解释最好的解决方案。总之，将客户转变为合作伙伴。
以下是美国加州弗里蒙特市Accrue软件公司的案例。在2001年7月，总部位于美国纽约州罗彻斯特市的伊士曼柯达公司需要一套系统来迅速分析大量数据并识别客户的购买模式。原始信息来源于柯达公司分布在全球29个地点的互联网渠道。仔细评估之后，伊士曼柯达公司选择了Accrue公司的软件。
Accrue遵循了“培养客户”的原则，他们向柯达团队展示了如何使用软件将顾客行为分析提升到一个新的层次。Accrue团队启动项目的第一件事情是面向客户团队所有成员的产品培训，其目的是确保需求分析使用的是共同的术语。
第三步，建立一套评价成功的标准。
为了评价项目是否成功，你必须创建一套双方均认可的评价尺度。如果项目团队达到了期望值，客户就会满意。如果没有目标测量标准，也就无法严格地把握进度。
另一个案例，1999年，佐治亚州税务局需要一套处理商业税务票据和支票的新系统。旧系统的能力已经不足并且需要许多人轮班操作。从收到一张支票到存款进银行的平均时间在当时是两个星期左右。这份合同被授予了诺斯罗普·格鲁曼公司。
一个由佐治亚州税务局和诺斯罗普·格鲁曼公司组成的联合IT团队撰写了需求和系统定义文档。由于当时正处于税收旺季，时间压力迫使联合IT团队没有建立正式的验收标准。不幸的是，计划使用并接收这套系统的团队并没有被邀请参与最初的需求分析。结果不出意料，IT团队创建的最初需求与使用团队的期望之间存在较大差距。
用户感觉到被排除在需求讨论的范围之外，而且没有项目成功的验收标准，所以，他们很不情愿接收这套系统。双方的管理团队通过谈判、变更和培训等手段尽力促成一致意见，并完成了系统部署。
在系统投入运营之后，从收取支票到存款的时间缩短到几天甚至几小时。佐治亚州税务局用了短短三个月的时间即利用额外利息收入收回了系统开发的投资。虽然投资回报是衡量一个项目成功的有力佐证，但如果使项目干系人参与到绩效评价决策中的话，项目的交付可能会更加顺畅。
第四步，召开项目进展会议。
误会和误解会在项目进展会议上暴露出来。在会上有诸多事项需要完成：创建并维护项目状态文档；与客户和团队成员交流关键的交付物，包括进度、项目计划更新、未完成任务条目和对上级的状态报告；此外，还要将这些信息汇报给管理层。
这种会议不应该成为唯一的沟通方式，但它们会是与客户交流的合适方式。1990年代中期，位于华盛顿特区的美国第三大电信公司MCI曾致力于寻找将部分销售流程自动化的方法。MCI成立了两支团队分别代表客户（MCI商务市场部门）和供应商（MCI内部IT团队）。项目团队收集了需求后开始了开发工作。尽管两支团队经常沟通，但没有设立沟通事务和关注的正式会议。
常规的进展会议促进了团队沟通并提高效率。他们开发的新软件赋予了MCI销售团队在销售效率方面的明显优势。
风险会随着项目生命周期发展而变化。在项目早期阶段，如果你展示了识别并减轻风险的能力，随着项目进展，高层管理团队会重视你的判断和建议，并且会做出一些“艰难的选择”以控制风险。
每个项目都有风险。顾客认为，没有什么风险比与一支反应迟钝的团队合作更加危险的了。所有技术、组织和市场风险都会被轻易地忽略。与客户共享风险管理计划会使他们确信你掌控局势并对潜在问题有所准备。