要求与项目管理方法之间的关系
上述讨论表明，项目管理方法应根据项目要求的相对清晰程度及实现方式的相对明确性进行选择，在过去十年中，这一理念已经在软件工程和产品开发领域获得主流认可，但这似乎还没有在语言服务行业站得住脚。接下来，我们将分析项目管理的主要方法，以及通过满足客户要求，促使项目团队达到质量标准的方式。
线性模式或“瀑布”模式
传统的项目管理实践在二十世纪上半叶兴起并得以发展，主要集中在工程和建筑领域。在该实践中，项目团队“希望获得（获得）客户对项目期望、交付时间以及期望价格的清晰说明”。因为项目团队清楚顾客需求以及产品提供方式，所以他们能制定出清晰、全面的项目计划。而且，这些计划一般不需要后续修改，从计划到目标实现的路径是线性的，即坚持最初的项目计划便能满足客户需求。
在项目工作开始前，项目团队得到清晰完整的客户要求，形成的传统项目管理方法，被称为线性或“瀑布”模式（见图 5）。顾名思义，线性模式即按照顺序进行。必须在完成一个阶段后，才能进行下一阶段。
图 5. 线性或“瀑布”型项目管理方法（改编自PMI 2008：40和Wysocki 2007：49）。
专家指出线性方法的问题具有两面性。首先，在范围定义阶段，线性方法要求全面确定客户需求。然而，正如我们所见，这并不是每次都能实现的，尤其是在翻译项目中。另外，线性方法要求在截至日期内完成项目，因此是不能改动的，即在项目完成之前，客户也看不到或无法使用项目交付成果。在没有上层反馈的情况下，无法将实施和监控阶段的经验教训应用于更新或改进项目计划。同样，在项目启动后客户要求变动不仅会破坏进度，而且还可能需要对上道流程进行返工，从而又推迟了项目的完成。最坏的情况是项目必须全部返工，这会导致时间和/或预算超出 1 倍。举个例子来说明线性项目模型中常见的问题。
20世纪90年代在一次贸易展会上，一家公司起草了一份罗马尼亚语和德语的双语合同，合同规定交付3000辆汽车，一半黑色，一半黄色。显然，该公司想要1500辆黄色汽车和1500辆黑色汽车。结果（由于误译），所有的汽车除了引擎盖是黄色（一半黄色），其余部分都是黑色（一半黑色）。买方不接受，因此必须重新生产一批符合正确规格的汽车。而那批初始产品则交付国内市场，成了出租车。
该案例中，生产之前未能确认生产要求的正确性和完整性，并且在交付前未进行任何客户检查，导致生产的3000辆汽车全部被客户拒收，从而不得不全部返工。尽管这可能是一个极端的例子，但是它表明在交付前如果缺少客户反馈，项目团队没有理解项目要求或某些必须执行的工作，线性项目管理模式的返工风险会很高。
综上所述，基于流程的质量管理方法其基本方面之一是从增值角度考虑整个流程。换句话说，质量管理旨在尽量减少非增值流程的数量。如果项目存在很大的不确定性，线性模型则会阻碍这一目标的实现。
增量模式或“分期交付”模式
处理不清楚、不完整或不断变化的项目要求可采用增量法，将项目工作进行划分，每项工作依据最初要求逐块进行。阶段性的和最终的可交付成果可在客户正式接受之前根据客户反馈进行多次迭代（见图 6）。因为它是可变动的，与线性方法相比，增量方法有助于降低返工的风险和范围。增量模型鼓励客在评估阶可交付成果，并提出改进建议。项目划分的模块越小，就能越早地对其进行评估，客户提供反馈的频率会越高，项目团队越能对其做出更好的修改。逐步更新项目规范以反映不断变化的需求，有助于项目团队确保可交付成果与客户的需求和期望相一致。相对于线性模型，增量模型还允许客户更早地确认交付项目是否达到其期望值。
许多项目经理在项目后期停止使用增量方法，并非有意而为之，而是不得不停止。因为在定义范围时，增量方法无法明确、完整地指出客户需求，或者在项目启动后无法获知不断变化的需求。2007 年，项目管理专家 Robert Wysocki 指出，他在过去几年内与许多项目经理讨论过不明确的、变动的要求带来的问题，多数项目经理都承认他们会“按照最初要求交付产品，然后在满足客户当前要求的情况下进行一次或多次迭代”。换句话说，这些项目经理为客户提供了一整套可交付成果，然后进行一轮或多轮返工，直到客户满意为止，这与之前讨论的“一半黑色、一半黄色”的汽车生产商很像。
从这个角度来看，线性模型可看作是是增量方法的一种，但它只包含一个增量因素。除了传统线性模型的一个增量因素外，为满足最新的或完整的客户需求而进行返工还包含第二个增量因素。虽然这种特别的方法包含两个增量因素，但它缺乏表示真正增量的分工、交错交稿和反馈，因此可以将其理解为瀑布模型的改良版本（见图 7）。
虽然 Wysocki 认为“我们会发现在项目执行/建设过程中提出要求会使得效率变低并会带来不利影响，因此我们假定，有能力的、明智的人不会犯这样的错误”，这表明事实上，很多项目团队都在使用这种模型。Wysocki 还指出，他问这些项目经理为什么他们明明知道交付结果会迭代，但却不采用合并迭代的方法。他说道，“项目经理对此表示沉默，但事实却是震耳发聩的”。
图 6. 增量式或“分期交付”式的项目管理方法（改编自 PMI 2008：40及 Wysocki 2007：50，59）。变量包括螺旋模型 (Boehm 1986，1988) 及快速应用开发 (Martin 1991)。
图 7. 改良的瀑布模型方法。虽然这种模型包含两个增量，但是其本质与真正的增量方法并不相同（见图 6）。
迭代模型
信息社会和知识经济的到来，以及从有形产品到无形产品的转变，加大了开展项目工作前收集客户清晰完整要求的难度。如今，被要求阐明其需求的客户通常都会这样答复，“我无法告诉你我需要什么，看到产品了我就会知道了”。这表明，收集要求时应侧重于快速创建模板，以便发现客户需求。然而，认识到客户需求并不是一成不变的也很重要。客户可能认为，他们在早期模板中已经了解到他们想要什么，但是随着与后续模板的相互比较，他们会更加了解自己的需要，从而改变要求。
当要求在项目执行过程中才出现时（未提前说明），规划阶段再制定综合规范起不到任何作用。这时需要一种灵活的处理方法，不仅仅是忍受变化，还应该预测和接受变化。正如 Laufer 和 Hoffman 所说，“在动态环境中，项目管理不只是保证计划执行并将其变化降到最小。而是满足客户需求，成功应对不可避免的变化”。这正是迭代方法的理论基础。
顾名思义，迭代模型由一系列迭代或较短的开发周期组成，每个迭代建立在不完整的解决方案上，并在此基础上制定更接近完整的解决方案（见图 8）。迭代完成后，客户评估当前已经完成的工作，并向项目团队提供反馈。此外，需要进行规划，即记录新确定的要求，并规划下一次迭代。在迭代方法中，所出现的要求会逐步整合进项目中；因此，变化也是开发周期的一个组成部分。在这方面，迭代方法与增量方法截然不同，增量方法要求在项目规划期间说明要求，并在监控阶段进行后续改进（如果需要）。此外，相对于增量方法，迭代项目模式对客户的参与度要求更高。
图 8. 项目管理的迭代方法（改编自PMI 2008：40和Wysocki 2007：52）。
敏捷方法
如今，上述的增量模型和迭代模型通常称为“敏捷”方法。事实上，“敏捷方法”是一系列方法的总称，其核心价值与传统方法截然不同。该术语源自敏捷软件开发宣言，其中阐述了这些核心价值观，并将其归入敏捷方法：
我们正通过敏捷方法，或帮助他人使用敏捷方法来探索更好的开发[产品]方式。这使我们开始重视：
流程下的独立工作与互动、使用工具进行客户合作的综合记录以及回复计划的改动。
也就是说，项目的一方面虽然有价值，但我们更加重视另一个方面。
虽然这些核心价值声明只是在表面上阐述了软件开发，但它们直接关系到项目管理，并能适用于项目管理 (Highsmith 2004)。敏捷项目管理方法建立在给定要求变化的基础上。因此，他们可以接受变化，并强调结果的可靠性，而不是过程的稳定性和可预测性。
总而言之，清晰全面的要求是客户满意和项目成功的基石。然而，在开展项目工作之前，明确要求和必须承担的工作这一过程并非总能实现。所以应选择合适的项目管理方法。当要求及满足要求的事项可清楚理解和说明时，可采用线性方法。当要求可清楚理解及说明，但尚不明确需要如何开展工作以满足要求时，可采用增量方法。最后，当要求及如何开展工作以满足要求都不明确时，可采用迭代方法（见图 9）。
图 9. 项目管理方式的分类要以相对清晰的要求和完成项目所必备的条件为基础（改编自Wysocki和McGary 2003：xxvii）。