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