文件2《IT項目管理辦法》文件2《IT項目管理辦法》文件2《IT項目管理辦法》xxx公司文件2《IT項目管理辦法》文件編號：文件日期：修訂次數：第1.0次更改批準審核制定方案設計，管理制度IT項目管理辦法信息管理部目錄前言 4一、術語定義 5二、IT項目生存期 7應用開發項目生存期 7應用部署項目生存期 8生存期模型裁減 10內部項目 10外包項目 11合作項目 12采購項目 12混合型項目 13三、IT項目過程 14啟動 14項目分解與計劃 14項目實施 15項目結束 16項目過程總結 16四、IT項目計劃 17項目規模估算過程 18項目規劃過程 19項目責任分配過程 19項目采購計劃 20五、IT項目監控 22項目定期評審過程 23項目事件評審過程 24偏離糾正過程 24計劃修訂過程 25項目采購監控 26六、IT項目審核 28審核計劃過程 29審核執行過程 29七、IT項目需求開發與管理 31需求開發的步驟 31需求管理的步驟 34八、IT項目工作產品及驗收 36交付件 36質量記錄 37工作產品模板 37任務書模板 38計劃書模板 38評審報告模板 39需求歸納表模板 39項目驗收 40可交付物驗收 40技術驗收 40功能驗收 41驗收計劃 41九、項目經理的職責和素質 42項目經理的職責 42項目經理的素質 45項目經理的技能 47前言中外運對IT的投資是通過各種類型的IT項目來實現的，通過實施IT項目體現對IT投資的效果，因此有必要對IT項目制定相關的流程和規范。IT項目分為兩個階段：立項階段和項目執行階段。本文只涉及項目執行階段的管理辦法，項目立項階段的流程按照《IT項目立項流程》執行。本管理辦法的適用范圍為股份公司總部。中外運股份有限公司信息化組織（以下簡稱ITO）是中外運股份有限公司專門致力于信息化建設的組織，負責企業信息系統應用的支持、業務信息化的幫助以及基于信息技術的業務開拓。這些責任將使得ITO逐漸成為企業核心競爭力的一個組成部分，與此同時，也要求ITO持續地改善其IT項目管理和運行能力。為了將這些項目管理過程得到有效的落實，特制訂以下IT項目管理辦法。ITO組織內所有人員需嚴格執行，保證ITO內的項目管理和系統運行逐漸提高到業界較高水準，滿足企業業務高速發展的需要。一、術語定義項目：在規定的時間和預算內完成的某種具有特定質量性能要求的一次性、多任務的工作。項目的特征：目標確定性時限性一次性獨特性項目生存期：一個項目從立項到項目執行結束的過程。項目生存期模型：是對項目生存期的抽象，其中包括項目階段的劃分、各個階段的進入條件、輸入和輸出等生存期公共屬性。關鍵過程域：是項目管理和項目執行所要關注的重要過程域，包括項目管理、項目實施、項目支持等多方面的過程。這些過程域是根據業務需要和資源情況逐步開發定義的。驗證：是對系統的評價過程，以確定一個項目執行階段的產品是否滿足在此階段開始時所給定的條件。確認：是在項目執行過程中或項目結束時評價系統，以確定它是否滿足特定的需求。審核：是用于驗證或確認的手段。審核是一種正式的評審活動，即需要計劃并按計劃執行。客戶需求（Customer’sneeds）：是客戶的需要與期待，這些要求和期待直接相關于用戶的業務過程和業務任務需求。系統需求（RequirementsforSystem）：通過對客戶需求的分析，確定系統應實現的規格。這些規格描述了系統的行為、特性和屬性。系統需求也稱為系統規格。功能性需求（FunctionalRequirements）：支持業務功能的系統需求，如數據檢索、交易執行、報告打印等。非功能性需求（Non-functionalRequirements）：系統執行的行為特征，如可靠性、安全性、性能指標等。IT（InformationTechnology）：信息技術。ITO（InformationTechnologyOrganization）：信息技術組織。SOW（StatementOfWork）：任務書。PP（ProjectPlanning）：項目計劃。PR（PeerReview）：同行評審或對等評審。二、IT項目生存期應用開發項目生存期應用開發項目生存期是中外運ITO管轄的所有IT開發項目的生存期模型，該模型可通過剪裁應用到不同類型的開發中。應用開發項目生存期模型定義圖示如下：項目立項（略）項目執行：用戶需求獲取用戶需求獲取SOW系統概念確定系統定義設計實現驗證定義過程實施過程項目立項結束，進入項目執行階段。SOW是項目執行階段啟動的文件。用戶需求獲取階段是析取用戶對IT系統的需要（Needs），其中包括系統目的、范圍、目標、業務需求、限制條件等方面。系統概念確定階段的目的是提出如何滿足用戶需要的總體策略，即確定滿足需求的系統基本實現模式，如體系、架構、獲取（Acquisition）方式等內容。系統定義階段是對用戶的需求進一步進行開發以得到系統實現的規格定義（Specification）。設計階段包括了系統層面的設計（高層設計）和實現層面的設計（詳細設計）。實現階段包括了具體開發、集成、工程測試。驗證階段是基于用戶的角度對系統的功能進行接收/驗證測試。項目結束。應用部署項目生存期應用部署項目生存期的執行階段是將經過驗證的應用系統部署到相關業務部門中并投入使用的過程。由于中外運規模較大，且地域分布很廣，一個大型IT應用的部署會涉及到多個部門、多個場所和不同的內部和外包資源，因此應用部署往往會作為一個獨立的項目進行。應用部署項目生存期模型就是用于此目的而建立的，該模型圖示如下：項目立項（略）項目執行：應用部署規劃應用部署規劃SOW試點發布實施計劃制定特殊需求處理切換準備切換項目立項結束，進入項目執行階段。SOW是項目執行階段啟動的文件。應用部署階段是一個準備階段，主要目的是進行實施策略、實施方法、相關人員、時間以及試點等方面的總體規劃和所需資源的準備。試點發布階段是實施策略和實施方法的測試階段，主要目的是確認實施策略和實施方法的可行性并獲取用于全面部署的經驗。在應用部署規劃時，如果確認試點發布無必要（例如，曾有過類似產品的發布），則可忽略此階段。實施計劃制定階段是應用部署的詳細計劃階段，目的是確定具體的應用部署活動步驟。如果應用部署涉及到多個部門，該階段也包括每個部門的行動計劃。特殊需求處理階段包括識別和解決一些部署點的特殊的要求，目的是保證部署活動不會因為這些特殊要求而受到阻礙。切換準備階段是資源落實和最后測試的階段，目的是確認切換所有的條件已就緒。切換階段將應用投入實際運行的階段，其中也包括切換結束的總結（無論成功或失?。ｍ椖拷Y束。生存期模型裁減生存期模型并不意味著中外運公司的所有IT項目執行周期一成不變地覆蓋整個生存期。不同類型的項目在生存期模型上的啟動點和終止點不完全一樣，需要根據項目的特征選擇項目生存期并根據具體情況對項目生存期進行剪裁。內部項目內部項目的特征是項目的管理和資源的控制均在ITO內部，因此可由ITO的一個項目經理負責整個項目生存期的過程和工作產品。實際上，這就是基本項目生存期的應用，具體如下：項目立項（略）項目執行：SOWSOW用戶需求獲取系統概念確定系統定義設計實現驗證應用交付項目執行階段由一個SOW啟動，項目經理根據該SOW制訂項目初步計劃，計劃可在各個階段里程碑結束后進行調整。外包項目外包項目的特征是項目的管理和資源的控制均在ITO外部，ITO代表中外運公司向外包公司發出需求并定義完成條件。ITO項目經理的責任是負責提供合理的公司業務對IT系統的要求并負責確認項目輸出的有效性，具體如下：驗證項目立項（略）項目執行：SOWSOW用戶需求獲取系統概念確定ITO-標書-標書-合同企業采購部門系統定義設計實現應用交付外包部門項目執行階段由一個SOW啟動，待完成了初步需求分析并形成了系統概念后，將用戶初步需求和系統概念設計反應到標書中來選擇外包商，反應到合同中來啟動外包項目。此外，項目生存期中驗證階段回到ITO來執行。一般的應用交付涉及到用戶的參與，但該階段的管理仍以外包商負責，或雙方協調后共同負責。如果外包的范圍與上述不同，可對上述剪裁模式進行調整，關鍵是合同和驗證兩個控制點。例如僅將設計部分外包時，標書和合同涉及的也將僅僅是設計階段，驗收也是對設計的驗收。需要注意的是驗證部分參與的內部人員和企業內部用戶與實現部分參與的人員不同。合作項目合作項目是ITO與合作方資源統一管理的工作模式。若是以ITO為主，可參照節描述的剪裁模型；如果是以外方為主，則可參照節描述的剪裁模型。采購項目外包項目和合作項目本質上也是采購項目，是IT服務的采購。因此IT服務采購項目的生存期參照上面2.3.2節和節。本節描述的是IT設備（包括軟件）的采購項目，具體如下：項目立項（略）項目執行：驗證應用交付SOWSOW用戶需求獲取系統概念確定ITO供貨程序-采購標書-采購標書-采購合同企業采購部門供應商同樣，內部以SOW啟動來確定設備采購的需求以及采購原則與策略（系統概念確定）。這些內容確定后形成采購標書，進而形成采購合同。供應商按其自己的供貨程序工作。如果必要，可在他們的供貨程序中插入質量檢驗的審核點。混合型項目當一個IT項目較復雜時可能包括了自行開發、合作部分、外包部分以及采購部分。在這種情況下可將項目分解成若干子項目，每個項目參照上面適用的生存期分別進行管理。三、IT項目過程下述模型是個簡化的IT項目執行過程模型，該模型包括了最基本的控制環節、分解原則和實施過程等要素。項目執行過程模型圖示如下：項目立項（略）項目執行：項目分解與計劃啟動結束項目執行項目分解與計劃啟動結束項目執行啟動IT項目在執行階段必須有一個正式的啟動文件SOW。正式的含義包括：來自于可下達任務的授權機構具有明確的主管人（發起人）指定了項目經理清晰的任務陳述（SOW）SOW定義了項目執行階段的開始。項目分解與計劃當項目經理接到任務書后，假設對任務書沒有任何疑義，那么項目經理需要執行的第一個過程是進行項目計劃，這樣才能保證項目有序的執行。由于直接面向任務書中SOW進行計劃會很難，特別是其中描述的任務規模很大時更是如此。一個有效的方法是將項目執行分為若干階段，然后按階段進行規劃。例如將項目執行分為如下的三個階段：項目執行：SOW實現設計需求定義SOW實現設計需求定義當然，如果上述階段劃分太粗，還可以進一步細化，例如將“設計”分為“系統設計”和“單元設計”，將實現分為“編碼”、“測試”和“集成”。如果有必要，還可以增加一些階段，如在“需求定義”和“設計”之間增加一個“技術選擇”的階段來專門分析采用什么技術對系統開發最有效。項目實施項目實施是項目計劃的執行。為了能夠知道項目進展是否符合項目計劃，需要對實施過程進行監控。監控的方法是每隔一個固定的時間對項目狀態進行一次檢查，然后與計劃進行比較。如發生了偏離，則進行糾正。僅僅按固定的時間間隔檢查項目狀態有時也不能及時處理項目的問題，例如在間隔之間發生了重大影響項目計劃的事件，如一項關鍵技術無法應用。因此要增加基于事件的檢查。偏離糾正包括兩個方面，一個方面是對項目工程活動和工作產品發生的偏離進行糾正，另一方面是對計劃進行修訂。這些工作必須加以控制，按嚴格的規范執行，否則不僅僅偏離未能解決，還會引起新的問題。在項目實施過程中，雖然是按項目計劃進行的，但項目計劃僅僅是定義了在什么時間由誰完成什么任務，沒有規定如何完成這些任務。如何完成有兩種方式，一種是憑執行者的經驗決策，另一種是定義好完成任務的過程和模板，然后按照過程和模板進行工作。當然，這兩種方式會結合起來。項目結束項目計劃的所有任務完成了，項目就可以結束。項目計劃確定的生存期中定義了項目的結束階段和結束應該進行的工作。項目結束不僅僅將項目交付件交給客戶就算完成了，還有一些其它總結性的工作，如項目數據匯集等。項目數據可為其它項目執行提供依據和參照。項目過程總結一個基本的項目管理體系應管理項目的啟動、項目劃分和計劃、項目的執行管理以及項目的結束。一個更完善的項目管理體系還應包括如何完成工程任務以及其它任務的過程。此外，還應包括需求開發和需求管理。四、IT項目計劃項目計劃的目的是為項目的執行和管理提供一個合理計劃。項目計劃過程域中的過程包括估計項目規模、定義項目生存期、確定項目目標、制訂人員、時間和投入計劃。項目計劃過程域與IT項目生存期的一個示例關系如下：用戶需求獲取系統概念確定系統定義設計實現驗證應用交付計劃修訂點計劃計劃修訂點計劃修訂點計劃修訂點計劃修訂點計劃修訂點計劃點計劃點箭頭所指示的是項目計劃在生存期的一個應用場景。前兩個階段是由ITO和業務部門共同進行初步需求分析和系統概念確定，ITO在項目初始制訂了計劃，并在第一個階段完成后對計劃進行調整，然后實施第二個階段。第二個階段完成后，交給一個ITO內的項目開發組織，開發組織在他們承接項目的第一個階段（生存期模型第三個階段）制訂項目計劃，并在每個階段完成后，調整或修改計劃。計劃的調整或修訂并不是必需的，只有當發現計劃與實際不符時才進行。項目計劃過程的目的是為執行軟件工程活動和管理軟件項目建立一個合理的項目計劃。項目計劃過程涉及的主要方面包括軟件項目規模評估、計劃責任的協商與確立以及軟件項目計劃的制定。項目計劃的目標為：項目規模估算并文檔化，以保證在項目規劃和跟蹤中可用。規劃項目活動和責任并文檔化。項目相關組和人員同意所分配的責任。 根據這些目標，在ITO項目計劃過程域中定義了三個過程：項目規模估算過程項目規劃過程項目責任分配過程項目規模估算過程過程名項目規模估算過程標識PP-01目標軟件規模估算并文檔化，以保證在項目規劃和跟蹤中可用。進入條件SOW（任務書）下達，并詳細描述了任務范圍。參與角色項目經理(由SOW確定)項目人員(由SOW或項目經理確定，包括項目經理)相關評審人員(由項目經理確定)項目主管(高層項目主管經理，由SOW確定)輸入SOW過程步驟輸出序號描述項目經理根據SOW確定項目工作分解(WBS:WorkBreakdownStructure)的策略和估算準則，其中包括估算單位、估算方法、估算爭議處理等。WBS策略估算準則項目經理向項目人員分配項目分解任務。(如果項目規模不大，可由項目經理本人獨立進行項目分解和任務規模估算工作。)項目人員根據WBS策略和估算準則對項目進行分解估算，分別建立各自管轄任務的WBS和相應的任務規模估算。項目經理負責進行匯總。項目任務分解(WBS)項目經理組織有關人員對WBS進行評審并根據評審結果對WBS以及估算進行修訂。評審的目地是保證分解沒有遺漏、重疊等問題；規模估算有依據。修訂的項目WBS和任務規模估算項目主管對WBS和估算結果進行審核。審核的目的是保證項目范圍理解正確、分解策略正確、估算結果合理。審核通過的項目WBS和任務規模估算項目經理負責整理上述步驟的輸出，形成項目規模估算文件。項目規模估算文件完成標志項目WBS和任務規模估算通過項目主管審核。形成項目規模估算文件(過程提交產品)。項目規劃過程過程名項目規劃過程過程標識PP-02目標規劃項目活動和責任并文檔化。進入條件項目規模估算完成。參與角色項目經理(由SOW確定)相關評審人員(由項目經理確定)項目主管(高層項目主管經理，由SOW確定)輸入SOW項目規模估算文件過程步驟輸出序號描述項目經理根據SOW確定項目具體目標和項目交付件。項目目標描述項目交付件清單確定項目策略，其中包括項目組織結構。項目組織圖等項目經理根據SOW確定項目生存期模型。選擇的生存期模型項目經理根據SOW、項目生存期模型和規模估算文件確定投入的資源，包括人力資源。項目資源投入表項目經理根據SOW、項目生存期模型和規模估算文件確定項目時間安排。項目時間計劃表項目經理根據SOW、項目生存期模型和規模估算文件確定投入的資金。項目資金計劃表項目經理對項目可能的風險進行分析并對高風險給出控制策略。風險分析是基于項目目標和項目計劃的，即影響項目目標和計劃可能發生的事件。項目風險控制表項目經理基于上面的輸出，產生項目計劃草案。項目計劃草案項目主管召集有關人員對項目計劃進行評審。項目經理根據評審意見對項目計劃進行修訂，形成正式項目計劃文檔，并由項目主管根據項目確認。項目計劃評審報告項目正式計劃文檔完成標志項目計劃經過評審。正式項目計劃文檔產生。項目責任分配過程過程名項目責任分配過程過程標識PP-03目標項目相關組和人員同意所分配的責任。進入條件項目正式計劃形成。參與角色項目經理(由SOW確定)項目組成員(由項目計劃確定)項目主管(高層項目主管經理，由SOW確定)輸入項目計劃過程步驟輸出序號描述項目經理根據項目成員和時間計劃生成每個人的任務時間計劃并發放給各個項目成員。個人項目任務時間計劃各個相關人員確認所分配的責任，其中包括：分配的任務和時間是合理的。可滿足完成任務所需要的業務要求?？蓾M足完成任務所需要的時間要求。若不能確認上述一項或若干項條件，則將情況反饋給項目經理。個人項目任務時間計劃確認結果項目經理根據反饋情況對計劃進行調整，并對變化的人員責任重復上一步驟。若有影響較大的調整，如關鍵人員的調整需得到項目主管的批準。若無調整，則跳過此步驟。調整的項目計劃項目經理發布項目計劃，發布對象包括：項目主管項目組成員其他項目相關組織或人員(如文檔管理部門)完成標志計劃經過所有項目相關責任人員的確認。對無法承擔項目責任進行調整并反映到計劃中。調整的計劃向所有有關人員發布。項目采購計劃采購規劃是確定哪些項目需求可以通過從項目組織之外采購產品、服務或成果，從而最好地滿足某些項目需求，是項目團隊在項目實施過程中可以自行滿足的過程。它涉及是否需要采購、如何采購、采購什么、采購多少，以及何時采購等。當項目從實施組織之外取得項目履行所需的產品、服務和成果時，每項產品或者服務都必須經歷從采購規劃到合同收尾的各個過程。采購規劃過程包括對每項外購決策涉及的風險，及就風險緩解或風險轉移進行審核。中國外運信息化建設中的IT采購工作分成項目采購和日常采購，日常采購包括但不限于個人電腦及配件的采購。日常采購在每年年底制訂采購計劃，并通過項目采購方式選定合格經銷商和購買產品種類，有效期1年。日常采購均從選定的合格經銷商中選擇。日常采購由具體采購人在合格經銷商中采取兩人（含）以上詢價的方式進行，部門負責人負責監控是否按流程進行，并抽查報價。主管（副）總經理可以確認部門負責人的簽字，也可以再次抽查。項目采購需成立采購項目組，項目組應根據情況，在符合法律相關規定的前提下，以公開招標、邀請招標或者內部議標的方式選擇設備供應商。五、IT項目監控項目執行監控的目的是關注項目進展情況并對發生的偏差及時進行糾正。項目執行監控的依據是項目計劃，凡是計劃了的內容，都需要進行監控，例如投入和時間安排。項目計劃過程域與IT項目生存期的關系如下圖所示：用戶需求獲取系統概念確定系統定義設計實現驗證應用交付監控點監控點監控點監控點監控點監控點監控點監控點監控點監控點監控點監控點監控點項目計劃項目計劃箭頭所示是項目執行監控的一個應用場景。一般項目監控采用定期評審，例如按周的定期評審。在每次定期評審中，檢查項目是否偏離了計劃。若發生了偏離，則立即采取糾正措施。此外，項目執行監控也可能是事件驅動的，一旦在定期評審之間發生了重要的項目管理事件，如發生了某種風險，則進行基于事件的評審，并根據評審結果采取相應措施。每次評審的內容和結果要向所有相關人員通報，相關人員包括項目人員、用戶和企業相關主管。通報通常采用定期項目簡報的形式。項目監控過程的目標為：按照計劃跟蹤項目的實際結果和執行性能。當實際結果和執行性能偏離計劃時，要采取糾正措施并對其進行管理。保證相關人員和組織同意所改變的責任。根據上述目標，項目監控過程域包括四個過程：項目定期評審過程基于事件的評審過程偏離糾正過程計劃修訂過程項目評審過程分為定期評審和基于事件評審。定期評審是正常的周期性評審，基于事件的評審是當發生了嚴重影響項目進展事件時進行的評審?；谑录脑u審由項目經理根據具體情況決定。偏離糾正過程用于控制管理項目進程中發現的問題和問題的處理。計劃修改過程用于控制和實施計劃的變更，保證變更后的計劃仍然具有合理性。項目定期評審過程過程名項目定期評審過程過程標識OM-01目標按照計劃跟蹤項目的實際結果和執行性能。進入條件到達項目評審時間參與角色項目經理(由SOW確定)項目組成員(由項目計劃確定)輸入項目計劃過程步驟輸出序號描述項目經理根據項目計劃本階段要求完成的內容，收集各個項目成員的任務完成狀態。項目進展狀態項目經理將各個項目成員任務完成的狀態與計劃進行比較。若項目經理認為出現與計劃的重要偏離，則與相關項目人員分析偏離原因，提出糾正措施，糾正措施包括對偏離的糾正或對計劃的修改。對不是重要的偏離，則不提出糾正措施，而是列入到下次評審關注對象。偏離程度的判斷由項目經理負責。偏離糾正措施項目經理審查以前定期評審確定關注的偏離問題(如存在的話)，并確定是否采取偏離糾正措施。偏離糾正措施(若存在需糾正的偏離)項目經理審查目前階段正在執行的偏離糾正措施，若發現問題則給出問題解決建議。偏離糾正措施執行建議項目經理將上述評審結果形成項目定期評審報告，并發布給相關人員，發放范圍依據項目計劃。項目定期評審報告完成標志項目計劃本階段內所有要求的完成內容與實際完成狀態進行了比較。對需要糾正的偏離，向相關項目人員發出了糾正措施或糾正措施執行建議。項目定期評審報告完成并向相關人員發布。項目事件評審過程過程名項目事件評審過程過程標識OM-02目標按照計劃跟蹤項目的實際結果和執行性能。進入條件項目經理得到項目成員的事件報告并決定進行評審。參與角色項目經理(由SOW確定)項目組相關成員(事件報告者和其他相關人員)輸入事件報告項目計劃過程步驟輸出序號描述項目經理與相關人員分析事件對計劃的影響，其中包括：計劃進度的影響計劃成本的影響計劃資源的影響質量的影響等事件影響分析項目經理與相關人員確定事件處理措施，處理措施包括事件的解決、計劃的調整等方面。事件處理措施項目經理落實事件處理的資源保證，如人力的保證。項目經理將上述評審結果形成項目事件評審報告，并發布給相關人員，發放范圍包括評審會人員、主管人員以及其他相關人員。項目事件評審報告完成標志確定了項目事件處理措施并落實了相關事件處理的資源。項目事件評審報告完成并向相關人員發布。偏離糾正過程過程名計劃偏離糾正過程過程標識OM-03目標當實際結果和執行性能偏離計劃時，要采取糾正措施并對其進行管理。進入條件項目定期評審會發出偏離糾正措施，或項目事件評審會發出事件處理措施參與角色偏離糾正人員，或事件處理人員、項目經理輸入偏離糾正措施，或事件處理措施過程步驟輸出序號描述偏離糾正人員/事件處理人員根據偏離糾正措施/事件處理措施制訂糾正/處理步驟。偏離糾正/事件處理步驟偏離糾正人員/事件處理人員執行制訂的偏離糾正/事件處理步驟，直至結束。偏離糾正/事件處理結果項目經理審核偏離糾正/事件處理結果，若存在問題，則確定相應措施，再重復1-2兩個步驟。偏離糾正人員/事件處理人員將偏離糾正/事件處理結果形成報告。偏離糾正/事件處理結果報告項目經理審核偏離糾正/事件處理結果報告，并發布給有關人員。完成標志項目經理審核通過偏離糾正/事件處理結果。偏離糾正/事件處理結果報告完成并向相關人員發布。計劃修訂過程過程名計劃修訂過程過程標識OM-04目標當實際結果和執行性能偏離計劃時，要采取糾正措施并對其進行管理。保證相關人員和組織同意所改變的責任。進入條件項目定期評審會發出偏離糾正措施，該措施包括計劃的修訂，或項目事件評審會發出事件處理措施，該措施包括計劃的修訂。參與角色項目經理項目主管輸入偏離糾正措施，或事件處理措施過程步驟輸出序號描述項目經理根據偏離糾正措施/事件處理措施確定計劃修訂的范圍和內容。計劃修訂范圍和內容項目經理根據確定的修訂范圍和內容修訂計劃。修訂的計劃若修訂的計劃涉及到人員責任的變化，則項目經理與相關人員確認變化的責任是否可接受。若不可接受，則需進一步調整。修訂的計劃項目主管審核修訂的計劃，若存在問題確定重新修訂的范圍和內容，再次執行步驟2-3。重新修訂的范圍和內容，或審核通過的計劃項目經理發布經項目主管的審核計劃，發布范圍同原計劃發布的范圍。完成標志項目主管審核通過修訂的計劃。審核通過的修訂計劃向相關人員發布。項目采購監控在進行項目采購的決策過程中，應考慮項目預算等制約因素。實施組織的長遠戰略也是在采購監控中應考慮的內容。如果決定外購，則反映了實施組織的長遠規劃和項目的當前需要。例如，決定購置某種開發平臺或數據庫，不是臨時使用，而是希望獲得長期支持。從項目經濟效益上看可能合算，也可能不合算。但是如果實施組織需要長期使用該開發平臺或數據庫，則分攤到項目上的那部分購置費用就有可能低于臨時使用的費用。在進行項目采購時，應成立采購項目組，并對項目采購的過程進行監控。采購項目組包括業務部門和信息管理部的主管領導及相關負責人員和經辦人員，必要時請企劃部、財務部等部門參加。根據《中國外運股份有限公司投資管理規定》，超過三百萬的項目采購，還要上報股份公司，經批準后方可執行。項目采購流程如下：起草立項報告項目組根據項目需求描述決定何時采購何物，制定相應的采購計劃并起草立項報告，通過內請流程上報公司審批。審批通過后，成立IT采購項目組，并確定項目組成員。確定采購方式經IT采購項目組討論通過后，決定采購方式，主要包括三種方式：公開招標、邀請招標、詢價采購。供應商的選擇和詢報價IT采購項目組應根據備選供方的報價單進行評定，即進行供應商的選擇。確定供應商和價格IT采購項目組經過討論，最終確定供應商和采購產品的價格。簽訂合同IT采購項目組和產品供應商談判后簽署采購合同。合同執行產品供應商按合同規定履約，IT采購項目組成員負責產品驗收。價款結算IT采購項目組負責辦理和產品供應商的價款結算。填寫IT采購申請/處理單IT采購項目組負責填寫IT采購申請/處理單。六、IT項目審核IT項目審核過程是一種正式的評審，需要較高的資源投入，因此并不意味著所有IT項目交付件都要進行正式的審核。審核對象的確定由項目經理在項目計劃時根據質量風險來確定。IT項目審核包括三個部分：審核計劃、審核執行、審核問題糾正，這三個部分描述如下：審核計劃審核計劃是基于項目計劃確定的審核對象和標準的審核過程來定義審核目標、資源計劃和時間計劃。在項目計劃中，需要確定審核對象和相應的審核主持人，與此同時在計劃中分配審核主持人審核計劃和審核執行任務。在一個項目中不同階段會對不同的交付件進行審核，這些審核的主持人可以是不同的。一個主要的原則是審核主持人不能是交付件的責任人。審核執行審核執行包括審核準備、召開審核會和建立審核記錄。審核準備包括審核對象資料準備、審核人員熟悉所負責的審核內容。審核會一般不超過兩個小時，否則效率會大大降低。審核會的目的是審核交付件是否滿足相應的準則，而不是審核人的能力和具體采用的開發方法、技術的正確與否。審核記錄要記錄審核過程發現的缺陷，缺陷屬性，例如嚴重程度、來源（本階段產生的，還是前面階段遺留下來的）等。審核問題糾正審核問題糾正是解決審核中發現的缺陷。審核問題的糾正要加以跟蹤，直到全面完成。審核計劃過程過程名審核計劃過程過程標識PR-01目標對審核活動進行計劃。進入條件到達項目計劃的審核計劃時間。參與角色審核主持人(由項目經理在計劃中指定)審核人交付件開發責任人輸入審核對象定義(根據項目計劃)審核過程過程步驟輸出序號描述1審核主持人根據審核對象定義確定審核目標。審核目標2審核人與交付件開發責任人討論確認審核目標。交付件開發責任人確認的審核目標3審核主持人根據審核對象和審核目標確定主審人和審核人以及它們的責任，并得到這些人員參加審核的確認和對審核目標的確認。審核人名單確認的審核目標4審核主持人與交付件開發責任人確認審核材料提交的時間和發放的對象。審核材料提交時間、清單和發放對象5審核主持人確定審核時間和地點并得到審核人員和交付件開發責任人的確認。審核時間6審核主持人形成書面審核計劃并送達交付件開發責任人、所有審核人員和項目經理。審核計劃完成標志審核計劃送達所有相關人員。審核執行過程過程名審核過程執行過程過程標識PR-02目標按照計劃執行審核。進入條件到達審核計劃確定的審核任務時間審核對象材料發放參與角色審核主持人(由項目計劃確定)審核人員(由審核計劃確定，包括主審人)交付件開發責任人輸入審核計劃審核對象材料過程步驟輸出序號描述1所有審核人通過審核對象材料了解與其責任相關的審核內容。審核主持人對此進行確認。無2審核主持人按計劃召集審核會。無3主審人報告全面審核的結果。主審人審核結果4各個審核人報告各自責任范圍內的審核的結果。審核人審核結果5審核人討論交付件可能的缺陷。候選缺陷6交付件開發責任人對審核人提出的問題應答。無7審核人確認交付件的缺陷和缺陷屬性，其中包括嚴重程度(高、中、低)和來源(本階段產生，前面階段遺留)。缺陷清單8審核主持人形成審核報告，并得到與會人員的認可。審核報告確認的缺陷清單作為該報告的附件。10審核主持人向項目經理、質量保證經理、配置管理經理和與會人員提交審核報告。無完成標志審核報告完成并向相關人員發布。七、IT項目需求開發與管理需求開發的步驟系統需求是通過一系列步驟逐步轉化得到的。這些步驟可能執行一次，就可得到開發人員所要的系統規格定義，但更多的是重復地執行多次來確定系統規格定義。需求開發的基本步驟如下：確定項目范圍獲取客戶需求分析客戶需求制訂系統規格驗證系統規格系統規格受控確定項目范圍項目范圍本身往往在項目開始時也不是很容易確定?？蛻羰且粋€群體，不同層面的人員因處于不同的地位會對項目含義有不同的認識。有時在同一范圍概念下，也會有不同內容的理解。這個階段的目的是建立一個統一的項目視圖并在這個視圖的基礎上對項目范圍取得共同的認識。項目視圖需要采用客戶容易理解的圖示來表達，例如系統環境關聯圖，系統功能層次圖、系統在業務價值鏈中的位置等。利用這些圖示來進一步刻畫和描述系統范圍要素，如支持的用戶類別、系統特征、基于的環境和支持目標等。項目范圍實質上是客戶需求的一個部分并且是一個重要的部分。項目范圍為項目任務圈定了一個問題考慮范圍。隨著需求分析的進展，項目范圍會發生變化，這些變化應及時反映到相關的文檔中，并及時知會相關的人員。獲取客戶需求項目范圍定義是項目宏觀的需求析取，為了能夠真正開發一個應用系統，必須全面了解客戶對系統的要求。由于客戶不是系統分析人員，因此這個階段的目的是確定有效的方法，然后利用所確定的方法從相對分散的需求源，系統化地獲取客戶需求。獲取客戶需求方法的基本原則是系統地定義需求類別、建立統一的需求表達、識別和規劃需求獲取的渠道。系統地建立需求類別可以將一個大的問題分解為若干小的問題，同時可幫助客戶需求獲取人員完備地收集客戶需求。建立統一的客戶需求表達可一致化和規范化得到的需求，為后面的工作提供一個良好的基礎。識別和規劃需求渠道可有效地配備資源。需求獲取渠道不僅僅是按確定用戶類別的訪談，也包括業務資料的分析等其它方面。分析客戶需求獲取的客戶需求難以直接轉化為系統規格定義，因為這些需求往往是概要性的、一般情況下不會完備、相互之間可能存在不一致。因此這個階段的目的是對獲取的需求系統地加以分析，建立一個相對完整的系統概念模型，如系統交互模型。通過系統概念模型的建立來細化、補充需求、消除需求中的不一致性。這個階段會繼續執行上個階段的工作，以解決已經獲取需求中的問題并補充分析客戶需求所需要的進一步信息。這個繼續工作不是簡單的重復需求獲取的工作，而是針對客戶需求分析中發現的問題?？蛻粜枨蠓治黾夹g包括許多類型，如非常形式化的建模計劃和簡單的業務場景分析技術。具體技術的采用取決于客戶需求的復雜程度、客戶的背景以及分析人員對技術的掌握等諸多因素。此外，分析技術的采用也取決于是否有有效的工具支持，特別是基于圖形的分析技術。制訂系統規格系統分析人員必須給系統設計人員提供完整、清晰、明確的系統設計要求。因此這個階段的目的是基于客戶需求和對客戶需求的分析結果建立書面的系統規格定義。這個規格定義不僅僅作為設計人員的設計依據，也將作為系統驗證的依據。同客戶需求分析一樣，系統規格定義也包括許多類型的方法和技術，如形式化的定義方法和自然語言的描述。一個理想的情況是分析模型和定義模型采用相同的技術。這樣不僅僅可以平滑地聯結分析客戶需求和制訂系統規格這兩個階段，同時也可大大提高工作效率，因為分析模型的結果可被重用到規格定義中。同樣，具體技術的采用也與客戶需求階段相同。驗證系統規格系統規格定義一旦確定，將作為開發依據貫穿在整個項目開發活動中。因此如果規格定義存在缺陷，將會產生很高代價的質量成本。此外，系統規格是通過客戶需求的分析和轉換產生的，因此這個分析和轉換可能會存在偏差。這個階段的目的就是來驗證是否定義的系統能夠真正滿足客戶的需求。系統規格驗證包括用戶評審、內部評審、走察（Walk-through）或更為嚴格的同行審核（PeerReview,Inspection）。如果需要讓客戶對系統實現后的式樣有充分地了解，還可以建立系統原型（Prototype）供客戶評審。系統驗證技術和方法的采用是風險和成本的平衡。例如原型技術會很大程度降低實現的系統背離用戶需求的風險，但需要較高的投入。不過由于系統規格是保證系統成功的關鍵，因此采用多種驗證形式其中包括較嚴格的驗證形式是十分必要的。系統規格受控正如上面多次指出的，系統規格將在整個項目生存期中作為系統實現的依據，其中包括設計的依據、系統測試的依據、驗收的依據等。因此如果系統規格隨意變更，則會引起整個開發的混亂。這個階段的目的是將系統規格納入到一種受控的狀態下。系統規格的受控包括兩個環節，一個環節是批準，另一個環節是“凍結”。當系統規格經過完整的開發過程產生出來后并由各方審計無誤后，則由項目權威機構正式批準。第二個環節是將批準的系統規格“凍結”，即不能隨意地對其更改。這之后的任何更改要通過嚴格變更控制程序。這兩個環節是將系統規格“基線化”?；€化是配置管理的任務。實際上，系統規格受控通常都是配置管理中的一個環節。需求管理的步驟需求管理的目的是保證系統需求作為基線加以管理，即系統需求定義的建立、使用和修改均加以控制，以保證系統需求可用性和其它項目活動與系統需求的一致性。需求管理與配置管理密切相關。實際上，需求是作為配置項納入到配置管理中的。需求管理的基本步驟如下：建立系統需求基線發布系統需求基線系統需求基線跟蹤報告處理系統需求基線修改請求建立系統需求基線建立系統需求基線是將開發的系統需求置為基線狀態。如果實施了正式的需求管理和配置管理，可將系統規格納入到需求管理和配置管理中。例如，一個具體的做法可以是將開發完成的系統規格提交給配置管理，由配置管理員對規格進行配置標識，然后入配置管理庫。發布系統需求基線由于系統需求基線是整個項目生存期項目活動的依據，因此應將正式建立的基線及時加以發布，以確保所有相關的人員了解基線的狀態。特別當基線修改后基線的及時發布對正在進行的項目活動至關重要。系統需求基線跟蹤報告為了保證系統需求基線被有效的實現，需要對需求基線的實施進行跟蹤，并將跟蹤的結果進行報告。例如跟蹤系統設計是否覆蓋了所有的需求基線。處理系統需求基線修改請求這是需求基線管理的最核心也是最復雜的一個步驟。這個步驟包括了一系列子步驟如下：對需要更新的基線部分提出更改請求。分析、審核更改請求，其中包括確認更改理由的充要性、分析更改的波及范圍、估算更改的投入等方面。如果同意更改，則制訂更改計劃。實施更改計劃。審核更改結果。批準更改。更新需求基線。由于需求基線修改涉及到多方面人員，因此對需求基線的修改（也包括對其它基線的修改）的批準要征得相關人員的同意。一般在配置管理體系下，由相關人員代表成立一個配置管理委員會來處理基線管理事項。八、IT項目工作產品及驗收IT項目工作產品是IT項目過程的輸出。這些輸出包括兩類，一類是通過開發產生的交付件，這些交付件是軟件產品的一部分，有些會最終提供給客戶使用，有些僅僅是中間產品（如系統設計）或管理文件（如項目計劃）。另一類是記錄性質的文件，這些文件往往作為質量證據使用，應此稱之為質量記錄，如評審記錄報告、測試記錄報告等。無論是交付件還是質量記錄，一旦產生可能被多個人多次使用，特別是工作產品。如果這些產品能按類別分別以統一的形式與內容要素產生，那么可有效的提高工作產品的質量，降低工作產品的交流成本。交付件項目交付件一般由四部分組成，封面、目錄、正文、附件。項目文件屬性信息需包括項目交付件的封面中文件標題的下方。項目交付件屬性信息包括：項目交付件編號交付件類別版本號完成時間開發責任人批準人密級所有的交付件都應包含上述屬性信息，這些屬性定義可用于交付件文檔的管理并有利于交付件的使用。質量記錄項目質量記錄是各種過程活動的記錄，也包括活動的報告。質量記錄的重要特征是客觀。質量記錄一般為表格形式的文件，這些表格形式的文件在形式上并不一致。原則上標識信息應涉及在表格的開始部分，其它信息在表格結尾部分。項目質量記錄屬性信息包括：記錄編號記錄類別記錄時間記錄人審核批準人所有的質量記錄都應包含上述屬性信息，這些屬性定義可用于質量記錄的管理并有利于質量記錄的引用。一類質量記錄往往在項目中有多個實例，因此質量記錄可以通告定義模板來減輕質量記錄格式的創建工作。工作產品模板工作產品模板包括交付件模板和質量記錄模板。模板的定義和應用將可規范工作產品的格式和內容要素，也可減少在項目過程中創建文檔格式的工作量。工作產品模板的應用本質也是質量控制的手段。任務書模板 項目名稱項目標識項目主管項目下達時間年月 日項目經理計劃提交時限年月 日項目定義類型用戶目標內容描述輸入項目限制時間資金資源實現計劃書模板1.引言目的 范圍參考資料版本歷史2.項目概述3.項目目標和交付件4.實施策略5.項目生存期6.任務分解與估算7.資源規劃人力資源 設施工具關鍵資源8.時間計劃9.預算10.風險識別與控制11.項目監控評審報告模板項目名稱項目編號評審時間評審地點評審類別評審人員姓名項目職責評審職責簽字No.評審項評審意見/結論0102030405060708091011…評審報告起草人/時間評審報告審核人/時間需求歸納表模板ID摘要類別描述優先級來源狀態項目驗收可交付物驗收可交付物是指項目驗收時向客戶提交的系統、源程序和文檔，通常的項目可交付物如下：《需求分析報告》《功能規格說明書》《體系架構設計說明書》風格設計的效果樣片（圖片）、頁面原型以及圖素（經切割的圖片原素）詳細設計文檔為項目實施所編制的特定的程序代碼可能涉及到的網頁框架模板《系統維護手冊》《用戶使用手冊》各階段的項目進度報告技術驗收通過驗收會的形式向客戶陳述系統體系架構的合理性，并從下面幾個方面對技術架構進行驗收：系統的可靠性系統的安全性系統的延展性系統的操作性系統性能可能存在的技術問題和技術風險功能驗收功能驗收主要針對功能性需求的滿足程度進行驗收，通常包括以下幾個方面：信息展示需求的滿足程度業務功能需求的滿足程度用戶管理需求的滿足程度數據初始化需求的滿足程度應用集成需求的滿足程度未完全滿足的需求在下一期項目中的安排驗收計劃編號任務開始時間完成時間參與部門1可交付物驗收2技術驗收3功能驗收4驗收會5最終驗收簽字

九、項目經理的職責和素質項目經理的職責項目經理是負責管理項目日常工作的個人。項目經理通常需要明確地給予授權，以便能取得其他部門的支持與合作，帶領項目小組按時、按質并在批準的預算范圍內完成任務。信息管理部IT項目經理的職責包括：挑選項目組成員；制定項目計劃并得到相關領導的認可；對項目進行界定并得到相關領導的認可；負責信息溝通；識別并處理風險；有效分配并使用資源；監控并跟蹤項目的進展；解決項目執行過程中出現的阻礙進展的問題；控制范圍、成本、進度、質量等；領導項目小組；提交項目可交付使用的成果及收益；負責評價項目組成員的表現。簡單的講，項目經理就是要關注四方面的內容：T——時間C——成本Q——質量性能S——工作范圍即在規定的時間內，在批準的預算內，完成事先確定的工作范圍內的工作，并且達到預期的質量性能要求，這就是項目經理的崗位職責。中外運公司的IT項目經理應該面臨更激烈的競爭，需要承受更大的壓力，需要介入更廣闊的業務，具體的崗位職責體現在計劃、組織、指導、控制四個方面。計劃計劃決不是可有可無的，而是必不可少的。如果沒有計劃，項目后期的控制便沒有基礎。項目經理的計劃職責具體包括：確定項目目標，并取得管理層與客戶的一致意見；制定項目計劃，并取得管理層的批準；確定項目所需要的資源；制定項目管理所用的技術、方法、程序和規章。組織項目經理是項目責、權、利的主體，是項目的組織者。項目經理應該把組織職責放在首位，在項目內部建立一個領導核心，實現項目班子的最佳組合和有效領導。項目經理組織工作的核心就是配備人員、制定規章制度、明確崗位責任、建立項目內部和外部的溝通渠道等。對于項目組的工作，項目經理要獲得項目組成員的承諾；對于項目組外部的工作，項目經理需要與客戶界定各自的職責范圍并達成協議，還要注意與項目組成員和客戶的溝通協調。另外，項目經理還應該營造一種團結緊張、嚴肅活潑的工作環境，使各方面的人員都能高效地工作。組織工作成功的標準是項目組織能夠高效率運轉和能夠實現有效的領導。項目經理組織工作的具體內容包括：開發項目所需要的人力資源，即組建項目小組；建立適當的項目管理組織機構圖；對項目各職位進行描述，制定項目管理責任矩陣；確保項目組成員理解和接受他們的職責；組織項目組成員制定項目計劃；促進項目團隊內外部的有效溝通；根據批準的項目計劃，配置各種資源