绩效信息流项目执行过程有三个重要的输出，即可交付成果、工作绩效信息、即变更请求。对绩效信息来说，从原理上来说是一个由粗到细、由原始数据到精确结论的分析过程。在第四版PMBOK里，这条线大致是：（43指导与管理项目执行过程）工作绩效信息、（55控制范围66控制进度73控制成本）工作绩效测量结果、（105报告绩效）绩效报告。
其中绩效报告是最结论性的概括，其输入也包括工作绩效信息等。实际上还有其它的分支，例如（83实施质量控制过程）的目的，就是利用工作绩效测量这一输入，帮助产生“质量控制测量结果”、“确认的可交付成果”等输出。
现在来看，第四版PMBOK里工作绩效方面的用词也不是很正确，例如很多学员把“工作绩效信息”和“工作绩效测量结果”搞混。第二点是工作绩效的信息流不是很清晰和准确，甚至还有遗漏，例如既然控制范围进度成本的过程会产生工作绩效测量结果，那实施质量控制为什么不会产生这一信息呢。
第五版PMBOK里，对这两点进行了非常明确的更新。首先，工作绩效方面的用词进行了更改，使之更符合一般管理习惯和知识管理的DIKWdatai
formatio
k
owledgewisdom模型，即：
工作绩效数据：取代第四版里的“工作绩效信息”，是指由执行过程组产生的未经处理的观察和测量。例如活动开始与结束的时间，缺陷的数量、实际的花费、实际的时长等。
工作绩效信息：取代第四版里的“工作绩效测量结果”，是指由监控过程组收集的性能数据，包括分析和集成的信息。例如可交付成果的状态，变更请求的完成状态、预测到完成时的估计。
工作绩效报告：不再由（报告绩效）过程产生，而是由44监控项目工作这一过程产生。其目的是产生决定、行动或意识。例如项目的状态报告、调整、信息笔记、建议、更新等。
f第二个改变就是对工作绩效信息流重新进行了整理，如下所示。
PMBOK第5版的新变化之四：瀑布？还是敏捷？很多管理软件开发或新产品设计的项目经理很熟悉这两个概念，但也有很多项目经理可能完全没有听说过它们。
另一方面，很多项目经理在学习PMBOK时，可能会陶醉于其中清晰的过程流程，但同时又困惑于它与自己的实际工作有很大差异。例如，在开发软件产品时，一开始并没有或不能完整地确定出需求和范围，而是首先实现一个可以运行的大概的软件，然后和客户进一步地不断沟通探讨，不断修改甚至重构，“边设计、边建设”，小步快跑，并最终实现客户需求。
所以说，实际工作中的项目可能有两类比较极端：一类就好比是建设r