性的用户在项目早期就直接参与到开发队伍中来，一同经历整个开发过程。
其次是业务需求无休无止。业务部门在开发中若不断补充需求，项目就可能越变越大以致于超过计划及预算范围。计划并不总是与项目需求规模与复杂性、风险及需求变更实际情况相一致，使得问题更难解决。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。另一方面，CIO要确定一个提需求分析的最后时间，不能放任业务人员无休止的提需求分析。
再次是用户需求模棱两可。模棱两可是需求规格说明中最可怕的问题。模棱两可的需求会使开发人员为错误问题而浪费时间，并使测试者无所适从。一位系统测试人员说，他所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。
最后是不必要的“画蛇添足”。“画蛇添足”是指开发人员力图增加一些用户“欣赏”，但需求分析说明中并未涉及的新功能。有时IT人员花了非常大的力气，但用户并不认为这些功能很有用;IT人员应努力使功能简单易用，但不要未经业务人员同意，就自作主张。
任何项目都不可能十全十美，也不可能满足用户的所有需求，毕竟项目的成本有限;CIO要弄清这些功能的“来龙去脉”，使得需求分析过程始终注重那些能使用户完成主要任务的核心功能。
同样，客户有时也会提一些看上去很“酷”，但缺乏实用价值的功能;若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。