接下來會開始進行概念設計(concept design)，但是很多人以為是把概念圖畫出來，當然這時候用很多的不管是圖像、文字、甚至音樂，就是給人一種代入感。
基本上會根據幾點進行，這時候會出現一個叫single-line的圖，它基本會跟之前的方案差不多，但是方案中主要是為了釐清範圍，真正開發時，可能會在我方的系統single-line 加上接頭，這樣是方便釐清子系統範圍。
那既然有single-line，那應該會有double-line吧？猜錯了，它叫multi-line，不過這差不多要等到選料完成，進到細節設計(detail design)才會有的(參考下示意圖)。在這張圖上面你會看到控制器上有幾個檔位，每個接頭以及端子，順著圖可以知道，某個接頭的哪個pin，會接到另一個接頭的pin，或是對應的燈號的
multi-line 其中一角
如果需要用到高電壓，線束是相當重要的一環。因為線束較粗，要考慮到應力(甚至為了抗腐蝕，有鐵氟龍塗層)，這樣的線束無法有太大的彎折，憑經驗如何走線，才能既方便又省空間，有時增加一個接頭，雖然多點成本，但是維修上較方便，建議長度至少x3，再以實配方式剪取適合的長度。
很多人會忽略的，就是測試用的治具，這個有時價值也不低，而且沒有在初期排入時程，所以強調在開規格的時候，就同時決定了如何測試，並且與客戶商議允收標準，有些人可能認為允收標準越詳細越好，以我過去經驗，這個觀念有一個前提，東西成熟相對較高，詳細一點對雙方都有保障。但是如果是偏概念性質的原型機，太過詳細可能會把自己逼死，只要其中一條沒辦法達成，就可能拖著遲遲無法結案，並被要求各種配置進行測試。
建議訂立允收標準時，保險起見以must have / nice to have 切分層級，或是切割成不同合作階段，降低雙方風險。若碰到瓶頸，無法按預期結案的情形，可以在雙方同意下，即使第一階段還未結案，把下一階段打包進來，增加專案預算，同時修訂專案範疇；或是與客戶交涉，退還部分款項，避免公司在沒有前景的專案中無法抽身。
專案會議怎麼開
既然專案已經開始跑了，那就應該定期召開專案會議，有分成只有專案內部成員參加的，作為進度確認用；也有全部專案一起向高層報告的，也是一週一次，除了確認進度，索取資源，與其他專案協調，資訊量很大，要在一個小時開完有時候蠻趕的，基本上會檢討以下幾件事：
- 目前所有專案狀態，以及預算使用情形
- 距離上一次開會之後，又完成了哪些事
- 是否跟上預期進度，如果落後的話，那是什麼原因造成延遲，目前有對策嗎
- 接下來準備完成的任務，是否需要與行銷部討論進行拍攝，或是設計部提供偽裝
- 是否即將有大筆採購，以便財務部調度現金
- 其他需要高層或其他部門提供的資源或授權
現在還有公司在用Polycom嗎?
排斥開會的原因
很多人很排斥開會，會議趕場似乎是每天發生的事，但如果真的能激發出想法，擬定出方案，或爭取到資源，做到「言必信，行必果」，那至少參加會議還有一點用處。多年下總結了會議的問題，不外乎以下幾點
- 討論又不做出結論，毫無意義
- 其他部門兩手空空，該準備的資料都沒有
- 會議早已有定論，只是走形式找人背書
- 除了開會還有會前會，時間都在開會上
- 與會人員不守時，等待浪費很多時間
- 臨時召開的會議太多，無法安排自己時間
其實這些問題，幾乎都可歸因於人員配置錯位、組織流程不清、知識管理分散，追根究柢都不是單一個人或部門有辦法解決的。
你們開會的時候最常發生哪些問題? 你有果很好會議的經驗嗎?會議如果順利，那當然皆大歡喜，但是很多時候都是帶著問題進會議室，我們就來看看如果專案執行過程中，時間、成本、品質出問題，那會議上該怎麼辦。
1.時間爆炸
專案多少具有不確定性，時間爆炸的原因很多，我列在下方看看你是不是熟悉。而且大部分都在專案的後期才會浮現，因為前期都會想說拼看看，可能有機會趕上，隨著交付日逼近，及時交付的可能性越來越低，這時候不得不說。
- 規格特殊，中游庫存不足，上游每隔一段時間才會批量生產一次。
→ 之前沒有想到先下單嗎，目前已經試過哪些管道? - 供給不足，全世界都在搶料，量少的就會被插隊 。
→ 我們一定要用這顆料嗎? 如果量產怎麼辦? - 工程師或採購忘記訂料，或數量算錯，加量影響交期
→ 那如何避免再次發生，PM沒有核對訂單嗎 - 韌體需要客製，需要驗證完才能出貨
→ 訂單上同意交期多久? 延遲造成的損失，由誰承擔?
在箭頭中，都是你可能被問到的，但是回答它其實都有更深一層，值得探討。
像是規格特殊，可能因為應用特殊，所以能符合要求的選擇不多，團隊是否考慮增設供應商尋源，或是跟一家電子零件採購能力很強的公司結盟。至於漏下訂單這件事，一般會被認為低級錯誤，但是系統跟流程上怎麼避免，難道都要靠人力維持? 大部分公司還真的是，靠的是老員工用自己的excel在管理，人趕跑了檔案就銷毀，很多珍貴資料就此石沉大海。
2.預算爆炸
即便在立項初期就已經預估風險，但是還是有可能，最貴的零件偏偏就是不能用。所謂的不能用包括，莫名的壞掉(進料沒有檢到)，或是實際輸出與原廠宣稱的規格不符，對方又消極回應，不可能因為如此上升到國際訴訟，只能鼻子摸摸認了，此時如果已經特製了測試用治具，可能有部分還要廢棄重做。另外要考慮的是污染問題，就是有些損壞，會導致系統內部使用的液體汙染，某些工業液體價格非常高，一旦污染全部換掉，會吃掉一大部份預算。
3.品質爆炸
這裡講的是專案在驗證過程中發生的品質問題，不是產品的品質問題。有些人喜歡把根本原因分析(root cause analysis)掛在嘴邊，但是那些真的事根本原因嗎，可能工程角度上，還算能讓人接受，但是從比較高的經營角度，很多問題很難再追溯下去，較真起來只會覺得很挫折。
專案驗證有兩件事很重要：
第一、紀錄很重要。很多時候品質出現問題，團隊擔心被責罰，容易陷入一種心理，就是私下想辦法搞定，這樣就不用往上報，免去一些寫報告的文書作業。但是不按照規矩，容易使情況失控。正確的描述事件經過，永遠是解決問題的關鍵第一步，然後日本公司非常重視「失效模式與影響分析(FMEA)」，失效可能是哪些元件造成的，逐一進行排查，調整前後的結果。
有時候，開發案歷經多年，團隊成員也換了好幾批人，有些問題在先前已經發生過了，紀錄不是只為單一次的事件紀錄，也是讓之後接手的人了解到，之前的產品結構如何，發生過哪些問題，已經做過哪些測試，在什麼環境，用什麼設備紀錄，數據結果如何，以及負責工程師的結論報告。這些保存下來的檔案，包括文檔、影片、會議紀錄等等，必須儲存在雲端，並且讓接手的人都知道有哪些資料，放在哪個位址，大家都能自由閱覽，所以知識管理是相當重要。開發就是站著前人的肩膀往前看。
第二、第六感也很重要。研究開發是件很科學的事，凡事講求事實及數據，但是在你只有一台原型樣機，沒有實驗組及對照組，又不適合太多次的拆裝，問題時有時無，有時候就是突然靈光一閃。一些玄妙之事，真不由得你不信。我們每個專案都有自己的乖乖，有一次我想東西送出去了，肚子有點餓就開了一包，結果電話沒多久就響，客戶那頭喊道：「東西掛了。」
總之，在風險評估時，就要讓自己很悲觀主義，所有事情都要往壞方面想，你會發現只有你想不到，沒有發生不了。例如：正負極接反，導致短路；騎腳踏車被野狗撞到，鎖骨骨折住院；焊接的高溫，導致地毯黏著劑起火。
硬體不像軟體，受傷都是家常便飯，不過我還是想說，錢能解決的都是小事，最重要大家平安。
資源篇
專案一般會放上甘特圖，PPT做甘特圖的軟體，推薦office timeline，價格平實，或是考慮think-cell，這個軟體不只可以做甘特圖，還有柱狀圖，功能強大但稍貴 (我提供的連結，是知名YouTuber Leila Gharani 合作，提供60天全功能免費試用)。如果經常要做PPT，建議花點錢節省很大時間。如果沒有預算，就是用Excel畫再截圖下來，豐儉由人。
