理想情况下，添加控制使得团队的进程报告更可视，更精确，这也从三方面加快了开发周期。第一，它使瓶颈突显而出，这样不久后他们就会得到关注；第二，鼓励了团队的每一个人，使之在日常工作中更具生产力；第三，它鼓励了高管人员领导合适的参与会，这些高管是开发团队中唯一可以给出答案的人。

“30%的PMO(项目管理办公室)调用曾经是请求状态，”有一个客户说，“即使有一个在线项目仪表板和已发送的电子表格。” 跟踪项目进展一直都很神秘，而且报告经常不准确。

为什么会这样？那些乐观主义者的软件工程师举行的状态会议是这样的：“明天就会准备好了。只需一个测试”。悲观主义的质量工程师会这样：“我们需要更多的测试。”因此，所有交付的状态都要经过经验丰富的以及睿智的项目经理的调整。我们知道哪个项目团队已经交付完成，以及哪个项目团队拥有更灵活的方法。项目经理会做出相应的调整。

我们信任项目团队去做他们自己的事情，以及他们自己的方式，在他们的自己的时间内。我们不想进行微观管理。我们想要一个有机的创造性的过程。这给业务延迟一、两天记录留出了空间。不完整的失误将会导致额外的工作。

没有记录错误将会给错误补救增加额外负担。等待一个迟到的行政审批是在浪费时间。围绕着基础设施后期更改而重新计划将会给所有人带来麻烦。

有些团队很有生产力，而且得到了高品质的质量结果。有些的时间计划很紧凑，而另外一些却需要一些灵活的空间。项目经理的挑战是要准确地解释所有这些变量。

给繁重的软件交付业务添加更多的流程控制、阶段门槛和数据收集会使团队不断抱怨，它造成了过多的延迟。然而，软件的快速开发也是它的原因。当我们开始衡量并发布及时性、不完全性和错误率时，他们同时也都得到了改善。没有人希望在这一报告的最前面出现。

控制甚至不需要人工干预。对于许多已经自动化的任务来说，我们可以添加一些额外的自动化，直接更新项目计划。当把代码移到测试区域时，添加一步来报告这一行为。如果批准逾期，那么就自动化升级电子邮件给副总裁和首席信息官。如果一个发布调整是不完整的，那么就会自动地检查材料列表清单，报告遗漏；如果有必要的话，复原调整。这一检查应该包含培训文档、构建脚本和测试结果，以及代码。

当自动化系统跟踪人们的行为时，结果也一样，“它按照计划进行”或“它失败了。”系统不会因为一个迷人的微笑或宽恕的请求而受到影响。当自动化系统提醒了反应迟缓的高管时，他们会查看所有他们想要的技术，而且不会受到主管头衔或政治影响力的威胁。

看起来项目经理好像是工匠的孩子。我们是组织中最后一个业务单元，来扩大化项目管理自动化的能力，这将会给我们带来与其它部门同等的效率、质量和预测能力。我们能否参加状态会议给项目团队定位其状态。