- 。对于某个裁剪对象，其范围、频度、正式度等都是裁剪要素。如，对于已有类似开发经验的项目，可以适当减少过程培训、业务培训等活动；对于开发周期较短的项目，可以适当合并一些评审活动，如概要设计和详细设计评审合并进行。
项目在进行裁剪时，由于裁剪指南很难枚举所有的裁剪情况，因此有时还是需要项目经理和QA依据经验进行判断和决定，这时，最根本的依据就是项目的质量要求和对风险的考虑。首先要分析如果一旦裁剪掉某些活动，是否会给项目带来风险，带来多大的风险，以及是否影响项目质量目标的达成。然后综合考虑后才能决定是否裁剪，如何裁剪。
另一方面，企业建立标准过程的目的不是为了“为了规范而规范”，而是为了提高过程和技术的重用。因此，如果项目在裁剪时有很大的灵活度，每个项目定义的过程都很随意或者项目过程之间相似的内容很少，那么重用的目的就很难实现了。所以，规范度和灵活度是项目裁剪时需要平衡的另外两个要素。
概括之，过程裁剪的原则是：质量与风险并重，规范与灵活的平衡。
（二）裁剪的过程
- 根据组织标准过程和裁剪指南，进行过程裁剪，以符合项目特征。项目经理在QA的协助下完成该项工作。
- 记录裁剪的理由，将裁剪的结果整理成项目定义过程文档。
- EPG（工程过程组）审核裁剪理由和项目定义过程，并批准。审核的检查点主要包括：是否与组织标准过程一致，是否符合本项目的特点，是否记录了充分的裁剪理由。如果审核不通过，则重新进行过程裁剪，或进行修改。
- 使用项目定义过程就是要基于项目定义过程制定项目计划，根据计划监控项目的实施。
（三）应避免的误区
常常见到企业的过程体系中赫然存在一份《裁减指南》，员工也往往认为裁剪就是大刀阔斧地“减少”完整的过程要求。如果项目时间紧、缺乏资源，就可以这么做。这是一个认识的误区。
所谓“裁剪”就是量体裁衣，根据项目特点量身定做最适合项目的过程，以期项目用最经济的过程实现质量目标。对于一个开发周期超过1年的系统级产品的开发，公司定义的四大决策评审点：概念决策、计划决策、可获得性决策和生命周期决策，以及六大技术评审点，技术评审1至6，可能“一个都不能少”。而对于一个快速定制开发的项目而言，很可能只需要将概念和计划决策合并为一个决策评审点，某些技术评审点也可以合并。
有些项目经理认为裁剪得到了项目定义过程，然后就可以开始项目的具体工作了。但项目定义过程并非项目计划，更不能替代项目计划。项目经理应基于项目定义过程制定项目的WBS（工作分解结构），以WBS为基础进行工作量、规模和进度估算，制定项目进度表和完整的项目计划。后续工作要以项目计划为基础监控项目的实施。
在过程中，项目还要记录、收集和分析实施中的度量数据，用于监控项目。一些常见的问题、风险和经验教训总结更应该提升到组织层面进行统一管理和协调。从而不断改进组织标准过程，形成闭环。
有些企业在刚刚建立过程体系时，由于很难立即制定一份完善的裁剪指南，所以干脆一刀切，不允许裁剪过程。但这样硬性规定的结果是一些维护型、功能增强型的项目要么就是在搞不清状况的情况下照着完整的过程执行，生成很多文档，也延误了开发周期，降低了效率；要么干脆拒绝执行过程，仍然按照过去的工作方式开发。显然，这就违背了建立过程体系的初衷。
另一个极端是企业允许过程裁剪有很大的灵活度，却没有设定一些原则。这样的结果往往是项目随心所欲地裁剪过程，最终项目形成的过程资产的可重用性非常低。
针对规范性和灵活度的平衡，很多企业倡导“先僵化，后优化”的原则，在过程建立的初期尽量削足适履，等到积累了一些经验后再优化过程，形成更易操作的裁剪指南。