第一步，也是至關重要的一步：Who
專案起始初期，作為專案負責人需要釐清，這個專案的需求是誰提出的？是客戶的需求、高階主管的需求、或只是其他單位工程師的murmur？
許多人做跨部門的大型專案時，只有邀請working level的人員參與，當大家忙活了幾個月終於做出成果，在高階會議上打算呈現出來邀功，結果只獲得高階主管悻悻然說一句：做的不錯，但做這個幹嘛？
會有這種情況即是因為未先知會高階主管將投入資源在這個專案，高階主管有其策略考量，若此專案與公司發展方向不符、或同時有其他更重要的專案占用資源，則可能直接否決；若與公司發展策略相符，高階主管也能在會議上指派各單位予以配合，讓專案進行更為順利。
此時可搭配利害關係人分析矩陣，來確定相關人士對於這個專案影響力為何，許多專案做到一半以失敗告終，常常是因為沒有釐清利害關係人；例如高階主管對專案是否繼續執行有決定權，在專案啟動初期最好能在高階會議上宣布專案啟動，先取得高階主管的支持，對於後續推展也較有力道。而對影響力較低的單位，則可信件通知請其知悉即可。
另一個常用的工具為ARCI，定義清楚此專案的全權當責PM是誰(Accountable)、各部門需要提供協助的負責人是誰(Responsible)、若專案遇到問題可諮詢誰(Consulted)、哪些人員需要被知會(Informed)等。
定義清楚利害關係人、ARCI，是專案啟動初期非常重要的環節
在對的時間做對的事：Why、What、When
做每個專案你都清楚知道目標是什麼嗎？你知道這個產品完成之後，使用者會是誰？產品將被賣到亞洲市場或歐洲市場？
組成一個新的專案團隊時，團隊成員可能不清楚此專案目的為何，為什麼要花時間來支援這個專案，這時候當責的PM就需要解釋清楚為什麼要做這件事。
常用的如緊急/重要性分析，告訴團隊成員為什麼這個專案很重要，如果成功能帶來什麼成果，如果不做會有什麼後果，為什麼這件事非現在做不可，凝聚團隊成員對專案的動力。
同時也需要宣達時程規劃，此產品預計什麼時間點要上市或量產，從現在起每隔多久會有什麼階段性產出需要完成，讓團隊成員知道大致時程及各自負責的任務，這些check point將可作為後續追蹤(Highlight)專案進度的基礎。
把格局放大：Where
前述的Why、What、When較類似於專案的基本規格，幫助我們了解這個專案在做什麼，但是優秀的PM不只滿足於眼前的專案，而要思考流程面的水平展開。
例如眼前的專案是做某產品生產線的改善，則可再看看公司內部有沒有其他類似的產品生產流程，待此專案結束後可一併導入，不只讓改善事半功倍，也讓此專案的效益大幅提升。
在做任何專案時，建議都要能以流程的方式思考，避免落入見樹不見林的情況，一般企業內的流程不外乎產銷人發財資，亦及生產、行銷、人事、研發、財務、資訊。
例如做人事招募系統的e化，則應了解整個招募流程為何，進而瞭解本專案將在招募流程中扮演什麼角色；做研發流程的優化，也應了解整個研發流程為何、本專案會影響到多少種產品的研發流程。
掌握流程不只能幫助PM理解專案的全貌及流程前後關係，也能思考此專案的延伸方向。
延伸閱讀：新產品開發導入流程介紹：APQP、EVT/DVT/PVT、C-flow
做對的事，也要把事情做對：How、How much
對工程師而言，有時候專案的目標、時程都已確定，當自己接到任務需求時How、How much則是能顯現自身價值的好地方。
要達成一個目標往往不只有一個路徑，解決一個問題也會有多個方案可以選擇，例如新的專案需要建立一個儲存資料的database，工程師可以選用Oracle、Microsoft等SQL語法，也可用免費資源MySQL建立。
不同的方案選擇代表了工程師的能力範圍，而怎麼衡量選擇哪個方案又是另一個學問，方案之間通常存在品質、速度、成本、風險之間的取捨，比較理性的衡量方式可計算不同方案的成功率或期望值，並選擇最優的方案執行；或是回到Who的階段，請教諮詢對象及取得高階主管的同意(特別是需要昂貴投資的時候)。
此時也可概略估算此專案的效益與支出，若資本支出(CapEx)大於預期收益，或許此專案在規劃階段即需喊停。
上述的Why、What、When，在接到任務需求時有時已被主管定義好工作範圍、Due date，而其餘部分則是做為專案管理者可多著墨的重點，如果能與相關團隊定義清楚ARCI、確認利害關係人、掌握流程、提出多個解決方案評估，相信此專案已經成功了一半。
下次接到任務前，也可以花點時間思考一下這個任務相關的5W2H為何，這幾個構面提供不同角度的思考，能問出正確的問題，問題就幾乎已經被解決了！
“If you do not know how to ask the right question, you discover nothing.” ~W. Edwards Deming
