需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。需求是工作分解结构的基础。在项目的初期，项目的需求只是一些概括的模糊的文件，通过不断的沟通和各个功能模块的介入、项目的可行性分析逐渐细化、清晰，需要在整个项目周期中分析、记录和管理。收集需求旨在定义和管理客户期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求，以便日后进行测量。收集需求旨在定义和管理客户期望。
项目在启动和执行的前期的过程中出现了很多的问题，走了很多的弯路。在项目的可行性分析阶段做了很多的可行性分析，做出了一个貌似是最优的一个方案，但是却存在一个很大的风险，即有一颗主要零件不是主要供应商提供的而是其他供应商提供的定制件。具体表现在项目在启动的头一两个月仍然对项目的需求不是很明确，在和内部客户沟通的过程中发现太过于拘泥于对方给出的一个规格说明书的要求，而忽略了对方真正的需求是什么。虽然这一器件的选择并不是本项目的范围，但是仍然会使得项目后期的零件认证出现很大的问题从而可能会导致这一子项目而是整体项目的失败。
在项目的启动阶段，我们拿到一份很不专业的产品规格说明书，其中列出了大概的产品的一些需求，只是一些参数还没有定义。基于这份规格书，我们进行了产品的市场需求收集和设计需求，并进一步进行细化。当中，我们忽略了很重要的一点，由于对机电类产品缺乏经验，而项目内部以及和内部客户之间的沟通都只是看到了接口的定义以及对方需要什么。这份规格说明书出自于一个非电子工程师之手，只是着重于目前的产品的设计规格，而没有从整个项目去出发。
在规划过程中，由于对项目有了更多的了解，所以应该更具体地定义与描述项目范围。应该分析现有风险、假设条件和制约因素的完整性，并在必要时补充其他的风险、假设条件和制约因素。同时，监督项目和产品的范围状态、管理范围基准变更的过程。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理，也就是在项目的执行过程中对项目的需求管理。而本项目由于沟通出现了问题，对于需求管理不明确和收集需求不完整，而导致项目的一个重大需求变化，项目的设计方案完全变化。
在项目的可行性分析阶段，大家都放在基于国产定制件的设计而忽略了其他的方案。项目进入到执行阶段，在一次项目的设计讨论中一位专家的一句话一眼点醒了大家，为什么我们要选择这一颗定制零件而不选择公司现有的零件呢。顿时发现了一个问题的问题，设计部门的leader在最早收到这一信息时直接忽略了这一信息，而其他人都不知道这件事。对方提及这一问题时，检查已收到的邮件，终于找到了这一信息。顿时，项目进入到了很尴尬的一步。如此重要的信息竟然被忽略掉，而导致项目多花费了两个月以及一些投资和原材料的花费。在这种状况下，如何将项目在这种情况下让项目顺利的进行下去就变得非常重要。
可想而知，沿着这一思路走下去，项目出现了很多问题。比如项目的延期，预算超支，与内部客户第一次合作使对方怀疑我们的工作能力而导致后续项目的遗失等等一系列的问题。
基于这一问题，项目组内部进行了一个头脑风暴，利用原因—结果图(关联图)的分析方法对于存在的问题进行分析。基于以上的分析结果，总结出以下的主要原因和行动方案：
>>内、外部沟通不足项
方案：参加每周例会，学会互相挑战
>> 市场需求不清晰，标准不明确
方案：多问为什么，有机会的话进行现场参观