对项目、工作项、所有者、依赖关系、批准、视图和报告进行建模，而不强迫团队采用通用任务模板。
工作流程不适合标准看板或电子表格的交付团队、机构、运营团队和专业公司。
- 反映项目实际情况的工作模型移动
- 具有明确下一步行动的特定角色视图
- 基于记录而不是会议的可靠状态
确定层次结构是项目组合、项目、阶段、可交付成果、任务或其他特定于领域的模型。避免将所有事情都称为任务。每个级别都应该有一个目的、所有者、日期和存在的理由。
使用描述有意义的更改的状态，例如就绪、进行中、阻止、审核中、批准和完成。定义谁可以转移工作、需要哪些信息以及哪些转移是不可能的。太多的状态会产生报告噪音。
表示在另一项完成之前无法开始的工作。让拦截器带有所有者、原因和下一次审核日期。没有责任的红色标签只会装饰延迟。
贡献者需要他们的下一份工作。项目负责人需要风险、未分配的项目和即将到来的里程碑。客户可能需要批准和简化的状态。从相同的记录构建视图，这样团队就不必维护并行的跟踪器。
跟踪工作何时进入和离开状态，而不仅仅是当前状态。这支持周期时间、等待时间、吞吐量和错过的承诺。活动历史记录还解释了为什么项目在不依赖内存的情况下移动。
与真实项目一起运行该工具，并记录人们返回电子邮件或电子表格的每一刻。首先修复工作模型和缺失的操作。仅在手动工作流程可靠后才添加自动化。
从项目、工作项、所有者、状态、日期、注释、文件、依赖项和活动事件开始。
使用最少的更改责任、权限或报告的状态。对于第一个工作流程来说，五到七个通常就足够了。
通常不需要。他们可以通过更简单的状态、请求的信息和批准的视图来使用相同的记录。
周期时间、等待时间、吞吐量、阻塞时间、准时里程碑以及审核后重新打开的工作比原始任务计数更具可操作性。