在使用者及管理層認同上述的tor 後，這個專案的負責人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結果進行分析，多少時間建立專案需求，編寫需求說明書，需要多久進行系統設計，多少程式設計師及多少時間進行程式編寫，如何進行測試，編寫系統文件，編寫使用者手冊，什麼時候在倉庫安裝終端，如何連線主機，什麼時候進行使用者培訓，如何讓系統取代目前的人工作業等等有關工作計畫及時間表。
在系統分析員完成訪談後，便需要依據訪談結果進行分析，理解什麼時候知道有貨品進入倉庫，什麼時候更新有關資料，如何更新，採用哪些表單，倉庫人員如何決定貨品應該存放在**，如何記錄有關資訊，如何知道需要檢貨，什麼時候進行資料更新，如何分別哪些貨品要去生產部門或者直接送到客戶指定地點等等資訊。這些資訊便成為系統在不同過程中所需的功能需求。
從上述的開發過程說明中可以體現功能需求並不是客戶或使用者提供，是系統分析員在理解目前的人工作業後分析出來的結果。
在系統移交到倉庫中執行前，倉庫中的工作人員需要對系統的操作進行學習及測試。要知道當時倉庫的工作人員並不是針對系統的功能進行測試，是對系統能否滿足他們的工作過程進行測試。基於這批工作人員對人於工作業的過程十分理解，如果系統未能提供一些他們操作過程中的日常工作，他們會要求技術人員對系統進行修改。
這個過程讓我們誤會使用者是對功能需求進行測試，這個誤會一直到今天讓我們把系統開發的焦點錯誤地放在功能上，而不是系統的最終交付上。而系統的最終交付是否能夠滿足tor 的要求是當時專案成敗的主要指標。
系統整合的範圍及需求
20世紀70 年代的專案多以部門單獨運營為主，自動化的目的是提公升部門本身的運營效率進行系統建設。到80 年代，企業高層開始體會企業中的資料分散在不同的部門或子公司的部門中。哪些資料是最新的？
哪些是最準確的？應該採用哪個部門的資料做決定呢？如何整合這些資料，如何獲得即時的資料，如何利用當時的區際網路（areanetwork），客戶/服務端（client/server），遙程訪問（remote‐access）資料庫（data base）等科技來更有效提公升企業的運營效率呢？
這些問題提供軟體開發專案進行系統整合及資料分享的工作，最終的目的還是環繞原來自動化提公升企業（不單是70 年代提公升部門）的整體運營效率為主要目標。
這個時候，簡單的tor 已經不能夠說明專案的範圍，但可以採用多個tor 來加以說明。工作說明（statement of work）在這個時候誕生，開始取代tor 成為專案範圍的主要工具。乙個專案可能有多個statement of work（sow）才能夠有效說明專案包含的範圍。
例如要建立乙個 「訂單管理系統（order processing system）」的時候，這個系統可能包括銷售部門，庫存管理部門，會計部門，運輸部門，生產部門等，這些部門也可能分布在不同的地區。
專案負責人首要是建立這個「訂單管理系統」的範圍，保證能夠提供訂單管理的的全部工作，所以會首先進行初步調查，理解一張訂單從不同業務點如何把訂單傳送回銷售部門，銷售部門如何把訂單資訊轉進倉庫，如何結合現有庫存管理系統，如何通知會計部門有關銷售，如何通知運輸部門需要送貨，或者如何通知生產部門需要進行生產等內容。在與個別部門負責人完成初步訪談後會，理解訂單在各個部門的進入點和輸出點後才建立這個專案的工作說明（sows）如下：
sow‐1： 連線業務點各終端到銷售系統，建立當天的銷售記錄。
sow‐2： 連線銷售系統與庫存管理系統，容許銷售部門查詢倉庫管理系統中有關貨品庫存量。
sow‐3： 容許銷售部門在庫存系統中預訂貨品數量以便運送到客戶指定地點。
sow‐4： 容許銷售部門指示庫存工作人員進行檢貨，並通知運輸部門有關訂單的運送要求。
sow‐5： 在銷售部門計算有關訂單的總金額，運送費及保險費用，並生成發票送交客戶。
sow‐6： 自動更新倉庫貨品儲存量，如有關貨品低於最低數時，建立貨品生產通知單併發送到生產規劃部。
sow‐7： 自動通知業務點有關訂單發貨日期。
sow‐8： 有關發票內容自動**會計部門，建立有關應收賬款記錄。
sow 並不是我們所說的系統功能，是在專案完結後這個系統所應該提供的最終目的。以上的sow 說明了這個專案的範圍，包括的有關部門及現有系統的連線。在客戶確認後每乙個sow 將當作乙個tor處理，這個tor 便成為整個系統建設專案中的乙個子專案（也是子專案名稱的起源）。
如何才知道我們建立的sow 已經包含整個系統的各個部門，如何保證這個範圍能夠有效地提供一套「訂單管理」的系統，這需要專案負責人對行業有一定的理解，同時為保證開發過程中能夠控制範圍的變動，在有關文件中明確說明sow 所包含或不包含那些工作。利用「包含（inclusive）」和「不包含（exclusive）」的說明來牢牢地建立乙個固定專案範圍。
在專案規劃完成後，系統分析師便按照被分派的sow 採用tor 的調查方式進行深入調查，對有關工作進行訪談，理解有關sow 的工作流程後對有關流程進行分析，並找尋初步的解決方案。如何利用科技取代**諮詢庫存量，利用科技取代傳真把訂單從業務部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內部檔案傳送發票副本到會計部門等等工作，什麼時候需要進行資料收集，需要進行資料更新，需要列印發票或其它有關報告等工作便成為專案的功能需求。
如果在開發過程中，使用者認為需要貨品在運送完畢後，收貨單應該自動確認有關應收賬款的作業流程，或者需要增加萬一退貨後的訂單處理操作流程時，我們便可以依據原sow 來控制專案的範圍變動，因為這兩項操作流程並沒有在專案的sow 中說明。如果使用者認為一定需要增加這兩個操作流程，那麼專案的範圍會變動，帶出額外的工作量，額外的開發時間，額外的投資預算，修正系統的架構，增加軟體模組，追加人力資源等等因應的後果。有能力的專案負責人會盡量說服客戶把有關工作在目前的系統建設完成後才進行處理，避免延誤專案的進度和交付日期。
這個系統整合的專案再一次說明如何從專案範圍中建立有關功能需求。建立功能需求是軟體從業人員的責任，不是客戶或使用者能夠提供的內容。在完**工操作過程分析訂立系統的功能需求後，更要進一步考慮如何讓科技提公升企業的運營效率。
也許在設計過程中發現當時的貨品運送流程是從倉庫直接送到銷售部門，再由銷售部門安排貨品連同發票一起送到客戶的指定地點，設計師可能考慮是否可以直接從倉庫把貨品運送到客戶指定地點，銷售部門另外把有關發票直接送交客戶？這個改變會為企業帶來多大效率改善？有了確實的構思後便需要說服使用者這個系統如何能夠更有效地完成有關貨品運送的過程，要說服使用者這些功能可以提公升貨品運送的效率和客戶滿意度，讓銷售部門和運輸部門可以體會未來的工作流程將有所改變。
決定最終解決方案及使用者認可後依據分析師的建議建立有關系統的功能，交由系統設計師對有關功能進行模組組合及邏輯設計。到這裡，我們可以清楚知道系統建設不是依據客戶的需求而建設，是依據如何達到專案最終目的和專案的最終交付而建設。需求不是客戶或使用者提供，是我們作為乙個專業人員依據我們要開發的專案目標（如何達到）和專案的最終交付而制定出來的結果。
沒有專案範圍，我們便不能建立有關系統的功能。沒有專案範圍，我們便不能控制任務的工作量，不能預估完成日期並按時完成。
從上述兩個例子中可以看到，功能需求與業務流程直接相連的，理解了業務流程，便能夠建立有關的功能需求，利用科技完成有關工作，提公升運營效率，減低業務部門有關工作量和工作人員的需求。
軟體工匠和軟體工程師
如果我們需要客戶提供有關功能或需求才能夠完成軟體開發，那麼我們便淪為軟體工匠。乙個工匠，如木匠、泥水匠等都是依據客戶的需求去完成任務的技術人員，這個工匠可以把工藝做到很好，很精，很細膩，成為乙個很優秀的木工或泥水工，但永遠不會成為大師，因為他們沒有創思，沒有溝通能力去說服客戶如何能夠更有效地達到客戶的投資目的。
希賽顧問團首席顧問張友生博士認為，乙個專業的技術人員需要理解本身的專業能力，理解客戶投資的最終目的，理解如何更有效地達到客戶的最終目標而建議客戶應該如何進行建設或改良，才有可能成為這個行業的大師。目前我國充斥著很多軟體工匠，如果我們要把自己打造成為乙個軟體工程師，我們便需要放棄以前的思維，不用老是抱怨「客戶不明確本身的需求，所以我們不能夠完成專案的交付」。我們需要思考如何才能夠把握專案的最終目標，建立系統的功能需求。
從20世紀90 年代中期開始，計算機在企業中已經從自動化的時代進入資訊化的時代，從科技的應用提公升企業的運營效率，轉變成科技應用所能帶出來的價值，讓企業能夠減低運營成本，改善產品，提供增值服務，開拓市場，增加利潤等成為軟體開發的主要目標。
客戶在決定投資一套軟體系統建設的專案前，本身很明確知道希望這套系統能夠帶來什麼價值，但對於如何能夠利用科技來達到目標則一概不清楚。希望透過軟體工程師的專業知識來告訴他們如何才能夠滿足他們的願景，客戶希望透過人工智慧（ai）去理解顧客的採購習慣，背景，行為和對現有產品的反饋對產品進行改良；他們希望透過企業資源規劃（erp）來減低生產或運營成本，提公升資源對企業的價值；希望透過客戶關係管理（crm）軟體的應用來保留顧客對企業品牌的忠誠，增加顧客對企業的滿意度。這些都是透過科技應用所希望帶出來的普遍價值和投資願景。
但技術人員仍然停留在科技應用的層面上，希望客戶能夠告訴他們需要那些功能來達到這個願景，讓他們能夠利用技術完成客戶的系統建設。這些構思型或願景型的專案如何進行交付，是上世紀末期開始對軟體行業的一大挑戰。
在這種情況下，技術人員如何能夠滿足客戶的願景，客戶如何能夠告訴技術人員有關這個投資專案的功能需求，變成專案在實施過程中不斷進行修改，不斷延誤的主要原因。如何解決這個困境是當時急迫需要處理的難題。所以計算機行業新增加了乙個崗位，叫做業務分析師（business analyst 或簡稱ba），業務分析師應該有深厚的行業知識，透過ba對行業的理解，對願景專案進行流程分析及建設，然後讓技術人員對有關流程進行分析，建立功能需求，設計有關模組，為這些構思型或願景型專案提供所需的基本資訊。
但可惜行業知識與技術知識兩者還是有相當大的距離，ba 未能發揮應有的效益。美國pmi 也是在這個時候訂立專案贊助人（sponsor）及專案干係人（stakeholders）的角色，在專案開發過程中，專案贊助人需要確認ba 的流程建議，需要取人系統建設每乙個階段的交付。專案干係人需要確認流程及系統功能不會影響部門的正常操作，兩者要確保整個專案能夠達到預期的交付願景和目的。
應用系統。希賽顧問團需求工程首席專家徐鋒認為，這些工具和方法誤導了這個行業的技術人員，讓他們在專案啟動的時候便把重心放在把握功能需求，而不是建立專案範圍，直到今天，很多軟體工匠在專案起動時便盡量希望能夠把握專案的功能需求，一些學者更把如何把握需求當作教育重點來讓我們不斷培育軟體工匠。讓技術人員忘記了建立範圍的重要性，讓技術人員未能發揮本身的智慧型，為客戶建立所需的解決方案，讓這些工匠不能夠有效地考慮如何利用科技來提供客戶期盼的價值，發揮本身的創作力和創思。
智慧型讓技術人員不斷跟著客戶後追尋那些不存在的專案需求。
軟體工程在21 世紀的挑戰
在20世紀90 年代中期，網際網路與windows開始進入個人及企業的空間。當時，筆者被任命為澳大利亞墨爾本市的一家百貨公司建立一套網路銷售系統。當時我對網際網路的認識相當膚淺，如何完成這個任務對我及整個交付團隊是乙個考驗。
我花費大量精力及時間與客戶溝通，希望理解他們建立這套系統的背後目的，在過程中我們共同建立了一套假設的業務流程，因為雙方都不清楚顧客在網路的另一端在過程中會有些什麼反應，所以我們依據不同的反應建立相當數量的流程。在這套業務流程被客戶接受後，我們便能夠建立系統的功能需求，能夠對系統進行設計及最後完成系統的交付。
專案管理在新產品開發過程中的應用
摘要 隨著經濟的發展與社會的不斷進步，創新已經成為當前時代主旋律。對於企業來說，積極有效地促進新產品開發是企業保持活力的源泉，也是其能夠長遠生存與發展的中心支撐。本文在全面地分析與總結現代專案管理以及新產品開發的具體特點上，論述新產品開發在專案管理上的具體應用和相關組織模式。關鍵詞 專案管理 新產品...
油田開發過程中剩餘油的形成
0.前言 油藏在開發之前呈現動態平衡系統。投入開發後，由於鑽井 採油 注水以及注汽等開發措施，使得油藏變為動態的非平衡系統。在這一非平衡系統中，部分區塊或者層段驅替程度高 油汽採出程度高，而另外區塊或者層段驅替程度低 油汽採出程度低，從而形成剩餘油的分布。剩餘油分布的研究成為了油田開發中後期提高採收...
房地產開發過程中的成本管理
剛剛過去的十年可以說是中國房地產發展的 十年，由於城鎮化的不斷推進和國家土地制度的改革使得房地產行業從無到有 從弱到強經歷了乙個蛻變的過程。然而房地產行業不同於其他行業，它在專案的前期便需要大量的資金投入，並且開發周期較長，對於開發企業來說要求具備一定的資金實力或者融資能力，同時行業門檻也較高。如此...