项目是作为公司用来提供答案和建立解决方案的基本工具而诞生的，这些解决方案可以满足业务需求和目标的实现。这就是为什么必须将项目与定义为满足需求的业务案例相关联，为实现业务目标做出贡献，消除威胁，利用机会，将弱点变为优势，提高技能，扩展产品和服务的市场，并获得客户的青睐，最终转化为更高的销售和利润。
但是，我们有多少次听到和读到那些组织投入了巨大的财务资源来执行被遗弃的项目，或者不得不花费大量资源进行产品，可交付成果的重新设计，改编和重新工作的组织的挫败感这些项目是因为它们不能满足业务需求和制定用户的期望。
这些项目中的许多项目从一开始就注定要失败，因为它们没有花费足够的时间来定义和验证需求，选择利益相关者以及实现SME的承诺和参与（主题专家（其英文缩写）），构成需求调查，定义和确认过程中的基本要素。
让我们记住，中小企业是对组织的工作，流程和产品具有高度专业知识，知识和精通的工人。同样，利益相关者被定义为对项目开发感兴趣的人员，用户或组织。
一旦项目执行阶段开始，纠正需求的缺陷和歧义是非常昂贵的，因为它涉及返工，解决方案，产品和可交付成果的重新设计；计划和所有项目文件的更新导致预算，预算或计划之外的财务，人力和时间资源的消耗。
在以瀑布方法为导向的项目中，影响更大，因为该方法论假设从一开始就对需求进行了明确定义，并且在项目竞争之前一直保持稳定，并且一旦项目开始，就应尽可能地控制，减少和避免更改。可能。
出于多种原因，需求可能模棱两可或定义不清：
- 利益相关者的标识不正确，即列表不完整，他们不是他们本人，也不是全部。利益相关者的能力水平，知识，对组织业务流程的掌握程度不是适当。利益相关者与项目缺乏一致性和承诺性，因为他们认为对自己的流程或组织的收益很少或几乎没有。对组织的影响程度很小，无法实现他们所属组织成员的承诺。业务分析师和需求分析师的经验不足。后期任命项目经理，在启动过程中必须在项目章程中进行命名和授权，以便可以与业务分析师（如果存在）和需求分析师共同审查业务案例的文件，在项目的论证阶段进行了可行性分析和解决方案的定义，并将在规划期间用作输入。
但是，在已经提到的所有情况下，责任都由项目经理负责，项目经理必须特别注意以确保需求准确，项目团队对需求有统一的解释，并已通过验证。中小企业，用户和利益相关者已经越过以找出它们之间的任何冲突，如果是的话，请与其他利益相关者和中小企业进行澄清以解决冲突。
此外，项目经理必须确保可以在项目要生产的解决方案，产品和可交付成果中标识每个需求。也就是说，有一种机制可以“跟踪”或监视每个需求以及包含该需求的产品或可交付成果。
在敏捷或Scrum方法中，更改或重新定义需求（用户的故事）更为容易，因为它假设需求可以更改，它们不是静态的，不需要从一开始就对其进行明确定义，因此Sprint周期更多简短（2-4周），每个Sprint待办事项的需求很少（所有故事都可以在Sprint结束之前完全实现），并且对Sprint计划会议（Sprint）中的后续Sprint可以提出含糊的要求计划会议）。
但是，在这两种方法中，利益相关者和中小型企业所扮演的角色仍然是根本的，无论使用哪种方法，对它们的不正确识别以及他们的低承诺都可能影响项目的绩效，因为即使看起来更简单，解决需求歧义的敏捷或Scrum方法将取决于利益相关者和中小型企业提供定义和澄清需求或故事所需的时间，信息和业务知识的承诺水平；产品所有者（项目经理）对组织和利益相关者的影响程度。
