在項目的啟動階段，我們拿到一份很不專業(yè)的產(chǎn)品規(guī)格說明書，其中列出了大概的產(chǎn)品的一些需求，只是一些參數(shù)還沒有定義。基于這份規(guī)格書，我們進行了產(chǎn)品的市場需求收集和設計需求，并進一步進行細化。當中，我們忽略了很重要的一點，那就是這份規(guī)格說明書出自于一個非電子工程師之手，只是著重于目前的產(chǎn)品的設計規(guī)格，而沒有從整個項目去出發(fā)。由于對機電類產(chǎn)品缺乏經(jīng)驗，而項目內(nèi)部以及和內(nèi)部客戶之間的溝通都只是看到了接口的定義以及對方需要什么。
項目在啟動和執(zhí)行的前期的過程中出現(xiàn)了很多的問題，走了很多的彎路。具體表現(xiàn)在項目在啟動的頭一兩個月仍然對項目的需求不是很明確，在和內(nèi)部客戶溝通的過程中發(fā)現(xiàn)太過于拘泥于對方給出的一個規(guī)格說明書的要求，而忽略了對方真正的需求是什么。
在項目的可行性分析階段做了很多的可行性分析，做出了一個貌似是最優(yōu)的一個方案，但是卻存在一個很大的風險，即有一顆主要零件不是主要供應商提供的而是其他供應商提供的定制件。雖然這一器件的選擇并不是本項目的范圍，但是仍然會使得項目后期的零件認證出現(xiàn)很大的問題從而可能會導致這一子項目而是整體項目的失敗。
需求是指發(fā)起人、客戶和其他干系人的已量化且記錄下來的需要與期望。收集需求旨在定義和管理客戶期望。項目一旦開始，就應該足夠詳細地探明、分析和記錄這些需求，以便日后進行測量。收集需求旨在定義和管理客戶期望。需求是工作分解結構的基礎。在項目的初期，項目的需求只是一些概括的模糊的文件，通過不斷的溝通和各個功能模塊的介入、項目的可行性分析逐漸細化、清晰，需要在整個項目周期中分析、記錄和管理。在規(guī)劃過程中，由于對項目有了更多的了解，所以應該更具體地定義與描述項目范圍。應該分析現(xiàn)有風險、假設條件和制約因素的完整性，并在必要時補充其他的風險、假設條件和制約因素。同時，監(jiān)督項目和產(chǎn)品的范圍狀態(tài)、管理范圍基準變更的過程。對項目范圍進行控制，就必須確保所有請求的變更、推薦的糾正措施或預防措施都經(jīng)過實施整體變更控制過程的處理，也就是在項目的執(zhí)行過程中對項目的需求管理。而本項目由于溝通出現(xiàn)了問題，對于需求管理不明確和收集需求不完整，而導致項目的一個重大需求變化，項目的設計方案完全變化。
在項目的可行性分析階段，大家都放在基于國產(chǎn)定制件的設計而忽略了其他的方案。項目進入到執(zhí)行階段，在一次項目的設計討論中一位專家的一句話一眼點醒了大家，為什么我們要選擇這一顆定制零件而不選擇公司現(xiàn)有的零件呢。頓時發(fā)現(xiàn)了一個問題的問題，設計部門的leader在最早收到這一信息時直接忽略了這一信息，而其他人都不知道這件事。對方提及這一問題時，檢查已收到的郵件，終于找到了這一信息。頓時，項目進入到了很尷尬的一步。如此重要的信息竟然被忽略掉，而導致項目多花費了兩個月以及一些投資和原材料的花費。在這種狀況下，如何將項目在這種情況下讓項目順利的進行下去就變得非常重要。
可想而知，沿著這一思路走下去，項目出現(xiàn)了很多問題。比如項目的延期，預算超支，與內(nèi)部客戶第一次合作使對方懷疑我們的工作能力而導致后續(xù)項目的遺失等等一系列的問題。
基于這一問題，項目組內(nèi)部進行了一個頭腦風暴，利用原因—結果圖(關聯(lián)圖)的分析方法對于存在的問題進行分析。
基于以上的分析結果，總結出以下的主要原因和行動方案：
>>內(nèi)、外部溝通不足
方案：參加每周例會，學會互相挑戰(zhàn)
>> 市場需求不清晰，標準不明確
方案：多問為什么，有機會的話