從第四章開始,進入49個過程的學習。49個過程被劃分爲十大知識領域,分爲十個章節,本章節是項目整合管理知識領域,主要講述項目整合管理的7個過程。git
一、須要對什麼進行整合管理?
干係人需求、約束條件、項目管理各個過程、項目集、項目組合的政策、公司戰略等等。github
二、如何實現整合管理?
在整合管理的過程當中要常常尋找平衡點,考慮各類約束條件、風險和不肯定性來知足項目的目標。面試
三、本章節的七個過程組:算法
1)制定項目章程:編寫一份正式批准項目並受權項目經理在項目活動中使用組織資源的文件。屬於啓動過程組
2)制定項目管理計劃:定義、準備和協調全部子計劃,並把它們整合爲一份綜合項目管理計劃。屬於規劃過程組
3)指導與管理項目工做:爲實現項目目標而領導和執行項目管理計劃中所肯定的工做,並實施已批准的變動。屬於執行過程組
4)管理項目知識:使用現有知識並生成新知識,以實現項目目標,而且幫助組織學習的過程。屬於執行過程組。
5)監控項目工做:跟蹤、審查和報告項目進展,以實現項目管理計劃中肯定的績效目標。屬於監控過程組
6)實施總體變動控制:審覈全部變動請求、批准變動,管理對可交付成果、組織過程資產、項目文件和項目管理計劃的變動,並對變動處理結果進行溝通。屬於監控過程組
7)結束項目或階段:完結全部項目管理過程組的全部活動,正式結束項目或項目階段。屬於收尾過程組編程
編寫一份正式批准項目並受權 PM 在項目活動中使用組織資源的文件的過程。項目章程確立項目的正式地位,並展現組織對項目的承諾。微信
1)最適合編寫項目章程的是發起人或項目經理,由發起人、項目集、PMO 或項目組合治理委員會主席等等這些公司高層來批准。
2)項目章程的批准,標誌着項目的正式啓動,項目經理的正式受權。
3)儘早確認並任命項目經理,最好在制定章程時任命,最遲必須在規劃開始前任命。網絡
商業文件(包括商業論證和收益管理計劃)數據結構
1)商業論證:文檔化的項目經濟可行性研究報告,包含商業須要分析與成本效益分析。主要是從商業視角描述必要信息,論證項目的合理性,並據此決定項目的預期結果是否值得所需投資。高於項目級別的經理和高管們一般使用該文件做爲決策的依據。商業論證的緣由要符合組織戰略須要:框架
a) 市場需求(如爲應對汽油緊缺,某汽車公司批准一個低油耗車型的研發項目); b) 組織須要(如由於管理費用過高,公司決定合併一些職能並優化流程以下降成本); c) 客戶要求(如爲了給新工業園區供電,某電力公司批准一個新變電站建設項目); d) 技術進步(如基於技術進步,某航空公司批准了一個新項目,來開發電子機票以取代紙質機票); e) 法律要求(如某油漆製品廠批准一個項目,來編寫有毒物質處理指南); f) 生態影響(如某公司批准一個項目,來下降對環境的影響); g) 社會須要(如爲應對霍亂頻發,某發展中國家的非政府組織批准一個項目,爲社區建設飲用水系統和公共廁所,並開展衛生教育)。
2)收益管理計劃:對創造、提升和保持項目收益的過程進行定義的書面文件。——商業文件,不是PM作的,是商業分析師作的,PM能夠參與,能夠提出建議,可是不能夠對商業文件進行更新或修改。微服務
協議定義了啓動項目的初衷。一般,爲外部客戶作項目時,就用合同。
事業環境因素、組織過程資產,基本上是全部過程的輸入。
定義:具備專業知識或受過專業培訓的任何小組或者我的,均可以提供專家判斷。因此專家判斷,有時不只僅是一我的,有時能夠是一個小組、多人。好比主題專家 SME、PMO、行業協會、客戶、發起人等等均可以提供專家判斷。
項目經理的周邊處處都是專家。項目經理本身自己是項目管理專家,但並不表示他什麼都該知道。專業技術方面的問題能夠諮詢主題專家,財務問題能夠諮詢財務專家。專家判斷可用於第四章整合管理的所有過程組。通俗點來講專家判斷就是拍腦殼想問題。
數據收集(頭腦風暴、焦點小組、訪談)
1)頭腦風暴:一種用來產生和收集對項目需求與產品需求的多種創意的技術,又稱「集思廣益」。拍腦殼、天馬行空、集思廣益、沒有對錯,能在短期內得到大量創意。不涉及排序或投票。
2)焦點小組:召集預約的干係人和主題專家,瞭解他們對所討論的產品、服務或成果的指望和態度,由一位受過訓練的主持人引導你們進行互動式討論。
3)訪談:經過與干係人直接交談,來獲取信息的正式或非正式的方法。採起「提問—回答」的方式,一般一對一,有時也可多對多。
人際關係與團隊技能(衝突管理、引導、會議管理)
1)衝突管理:(詳見第9章資源管理)有助於干係人就目標、成功標準、高層級需求、項目描述、整體里程碑和其餘內容達成一致意見;
2)引導:引導者有效指導團隊活動成功以達到成功決策、解決方案或結論的能力。
3)會議管理:(詳見第10章溝通管理)包括準備議程、確保邀請每一個關鍵干係人羣體的表明,以及準備和發送後續的會議紀要和行動計劃。
項目章程又稱「項目批准書」,是由項目啓動者或發起人發佈的,正式批准項目成立,並受權項目經理動用組織資源開展項目活動的文件。章程至關於發起人與項目經理之間的契約。
項目章程確保干係人在整體上就主要可交付成果、里程碑以及每一個項目參與者的角色和職責達成共識
包括如下 12 個內容:
1)項目目的
2)可測量的項目目標和相關的成功標準
3)高層級(high-level)需求:(是指宏觀、大概、大致上、戰略上的需求)
4)高層級項目描述、邊界定義以及主要可交付成果(這是一個什麼項目?要造成什麼產品?)
5)總體項目風險;(主要的風險)
6)整體(Summary)里程碑進度計劃:(幾個關鍵的里程碑進度)
7)預先批准的財務資源(大概的項目預算)
8)關鍵干係人名單:(大概的干係人名單)
9)項目審批要求:(用什麼標準評價成功、由誰對成功下結論、由誰來簽署項目結束)
10)項目退出標準:(在何種條件下才能關閉或取消項目或階段)
11)委派的項目經理及其權責
12)發起人或其餘審批項目章程的人員的姓名和職權。
假設條件:不肯定因素、風險,須要漸進明細。
制約因素:限制性的因素,好比事先肯定的預算、強制性日期、進度里程碑、合同條件等,不是漸進明細的。
定義、準備和協調全部子計劃,並把它們整合爲一份綜合項目管理計劃。
過程做用:生成一份核心文件,用於肯定全部項目工做的基礎及其執行方式。項目管理計劃肯定項目執行、監控和收尾方式,應足夠強壯和敏捷,以應對不斷變化的項目環境。PMI要求在項目中所作的全部事情都必須是在計劃中所體現的,作計劃以外試圖「討好」干係人被稱爲「鍍金」,這是項目中明令禁止的。好比客戶要PM去買包煙,PM買了煙後又私自決定給客戶配了個打火機。這就是鍍金了,客戶並不須要打火機,也許客戶本身有更高級的「ZIPPO」,並不須要PM給他買的打火機。鍍金,是多此一舉、由於浪費了資源。
是指子計劃和基準,好比:範圍管理計劃、進度管理計劃、成本管理計劃等等,制定項目管理計劃要參考這些子計劃,把他們整合爲綜合的「項目管理計劃」。項目管理計劃並非一步到位,而是須要不斷更新來漸進明細。
覈對單:基於相似項目和歷史信息來編制覈對單,或採用所在行業的核對單。覈對單用來指導項目經理制定計劃或幫助檢查項目管理計劃是否包含所需的所有信息。
項目管理計劃,是說明項目將如何執行、監控和收尾的一份文件。它整合並綜合所了有子管理計劃和基準,以及管理項目所需的其餘信息(取決於具體項目的需求)。構成:子計劃、基準和其餘組件。
1)子計劃:範圍管理計劃、需求管理計劃、進度管理計劃、成本管理計劃、質量管理計劃、資源管理計劃、溝通管理計劃、干係人管理計劃、風險管理計劃、採購管理計劃。
2)3 個基準:範圍基準、進度基準、成本基準。
基準:工做產品、項目計劃,通過批准,即成爲基準。只有經過正式的變動控制程序才能對其進行變動。用於與實際績效比較,來肯定績效是否在可接受的誤差範圍內。
好比:某網銀天天限制轉帳額度5000,超過5000 就要使用大額轉帳技術,好比u 盾、密保卡等等。這個5000 就是一個基準。若是這個基準須要變化,須要通過正式的變動控制程序才能變動。
3)其餘組件(配置管理計劃、變動管理計劃、績效測量基準、項目生命週期、開發方法、管理審查):
績效測量基準 Performance Measurement Baseline ,簡稱 PMB。項目範圍-進度-成本三位一體基準。爲項目工做制定的,經批准的範圍-進度-成本綜合計劃,用來與項目執行狀況相比較,以測量和管理績效。
項目管理計劃的批准:《項目管理計劃》必定要獲得管理層、發起人、項目經理、項目團隊表明和相關項目干係人的贊成和正式批准。一個項目或項目階段,如沒有正式批准的《項目管理計劃》是難以有效開展的。正式批准意味着干係人的簽名,簽名意味着發起人與項目經理,項目經理與團隊成員之間創建的契約關係。
開工會議: Kickoff Meeting :又稱啓動大會、開工會議、開踢會議
1)每一個項目必須有啓動大會,是個動員大會。召開時間:項目規劃完成後、項目執行開始前召開;屬於規劃過程組;
2)參加方:項目各重要干係人(發起人、顧客、高層管理、職能管理部門、賣方表明、項目團隊等)。
3)是個宏觀、務虛會議。做用:傳達項目目標與項目管理計劃,得到干係人對項目的承諾與支持,闡明每一個干係人的角色和職責,並宣佈項目正式進入執行,至關於開工典禮。
爲實現項目目標而領導和執行項目管理計劃中所肯定的工做,並實施已批准的變動的過程。
過程做用:對項目工做和可交付成果開展綜合管理,以提升項目成功的可能性。
輸入有「批准的變動請求」,這個是已經遵循變動管理流程被幹系人批准的。
用來收集和發佈績效數據的系統,可自動收集和報告KPI是PMIS的重要功能。項目管理信息系統提供下列工具:進度計劃工具、工做受權系統、配置管理系統、信息收集與發佈系統,或進入其餘在線自動化系統的網絡界面。
可交付成果(Deliverables ):在某一過程、階段或者項目完成時,必須產出的任何獨特並可覈實的產品、成果或服務能力。可交付成果能夠是有形的產品,或無形的計劃、服務能力等。好比你們考PMP 是一個項目,最終得到PMP 證書是產品,它是有形的可交付成果。掌握的項目管理知識是無形的能力,這些都是此項目的可交付成果。
在執行項目工做的過程當中,從每一個正在執行的活動中收集到的原始觀察結果和測量值。數據是底層的細節,將交由其餘過程從中提煉出信息;執行過程當中收集數據,再交由控制過程作進一步分析。
好比:第一天計劃預習PMBOK 到50 頁,實際只預習到30 頁。30 是工做績效數據。
典型的工做績效數據包括:已完成的工做、KPI、技術績效測量結果、進度活動的實際開始日期和完成日期,已完成的故事點、可交付成果狀態、進度進展狀況、變動請求數量、缺陷數量、實際發生的成本、實際持續時間等
在整個項目生命週期中,項目經理常常會遇到問題、差距、不一致或意外衝突,須要採起某些行動來加以處理,以避免影響項目績效。問題日誌能夠幫助項目經理有效跟進和管理問題,確保他們獲得調查和解決。
在執行項目管理計劃中的工做的時候會引起新的變動請求,這是項目的漸進明細。變動請求:任何干系人均可以提交變動請求,變動請求必定是對項目的某一方面有變化,須要可交付成果、基準或者項目文件更新。包括糾正措施、預防措施、缺陷補救和更新。
1) 糾正措施:實際績效與計劃之間已存在誤差,須要糾偏;
2) 預防措施:防止實際績效與計劃之間出現誤差,須要防範;
3) 缺陷補救:產品組件有質量問題,須要修正;
4) 更新:針對受控文件或計劃的變動。
若是改變了計劃,必定是更新。前面三者:計劃不變。
使用現有知識並生成新知識,以實現項目目標,而且幫助組織學習的過程。管理顯性和隱性知識,重複使用現有知識並生成新知識。重點關注把現有知識條理化和系統化,以便更好的加以利用。
促進員工合做創造新知識,分享隱性知識。好比人際交往、工做跟隨和跟隨指導。
1)人際交往:在組織、行業或職業環境中與他人的正式或非正式互動。人際交往在項目初始時特別有用,目的是爲了創建關係,增長獲取資源的途徑,改進人力資源管理。人際交往的方式有不少種:寫信、午飯會、座談會等等。
2)工做跟隨:徒弟跟着師傅實習,徒弟無需承擔任何責任,所有責任由師傅承擔。
3)跟隨指導:師傅跟隨和觀察新手的工做狀況,並給予指導。
用於促進顯性知識分享的各類具體方法。好比:圖書館服務、文獻檢索、經驗教訓登記冊編制。
會獲得更新,最終存入組織過程資產中。
跟蹤、審查啓動、規劃、執行、收尾各個過程,來實現項目管理計劃中肯定的績效目標。就是把實際績效和項目管理計劃進行對比,發現誤差、分析緣由,提出變動。
從各控制過程當中收集並結合相關背景和跨領域關係,進行整合分析而獲得的績效數據。好比:第一天計劃預習PMBOK 到50 頁,實際只預習到30 頁。對比發現,比計劃少預習20頁,20 是工做績效信息。
爲制定決策、提出問題、採起行動或引發關注,而彙編工做績效信息,所造成的實物或電子項目文件。
好比:第一天計劃預習PMBOK 到50 頁,實際只預習到30 頁。對比發現,比計劃少預習20頁。次日少預習10 頁、第三天又少預習15 頁„„最終寫成一份報告,爲何老是不遵照計劃,怎麼老是少預習。是工做效率過低、仍是懶惰引發的,分析找到緣由等等。彙總寫成一份狀態報告。
是指監控項目工做時會引起變動請求。經過比較實際狀況與計劃要求,可能須要提出變動請求,來擴大、調整或縮小項目範圍與產品範圍,或者提升、調整或下降質量要求和進度或成本基準。
審查全部變動請求,批准或否決變動,並管理對可交付成果、項目文件和項目管理計劃的變動,並對變動處理結果進行溝通的過程。這個過程的做用,就是對這四種提出來的變動請求,批准或否決,而後更新相應的計劃或文件。提出的變動究竟是贊成,仍是拒絕?須要在這個過程作判斷。實施總體變動控制過程貫穿項目始終,項目經理對此負最終責任。這句話說明PM對變動負最終責任,萬一哪一個變動變得很差,責任都在PM沒有把控好。PM要對變動請求跟蹤負責到底。
包含在配置管理計劃中,由一系列正式的書面程序組成,用於對如下工做提供技術和管理方面的指導與監督:
1)識別並記錄產品、成果、服務或部件的功能特徵和物理特徵
2)控制對上述特徵的任何變動
3)記錄並報告每一項變動及其實施狀況
4)支持對產品、成果或部件的審查,以確保其符合要求
配置管理系統明確了爲覈准和控制變動所需的批准層次。
配置管理活動包括:
1)識別配置項:選擇與識別配置項,從而爲定義與覈實產品配置、 標記產品和文件、管理變動和明確責任提供基礎。
——至關於編號,version 1.0,version 2.0
2)記錄並報告配置項狀態:關於各個配置項的信息記錄和報告。
——至關於記錄版本的說明,1.0 版本拓展了場景文字„„;2.0 版本優化了bug,解決了閃退問題。
3)配置覈實與審計:保證項目的配置項組成的正確性,以及相應的變動都被登記、評估、批准、跟蹤和正確實施,從而確保配置文件所規定的功能要求都已實現。
——確保配置項組成的正確性,確保變動都被記錄、評估、批准、跟蹤和正確實施。如今2.0的版本要變動到2.1 了,要確保這個變動符合流程。
也能夠用五大過程組的關係來理解這三個活動:
識別配置項、記錄並報告配置項狀態屬於執行過程組的活動;
配置項覈實與審計屬於監控過程組的活動;
簡單理解配置管理包含了變動管理和版本管理。
1)CCB 是正式的團體,但不必定是固定的團體;
2)組成:項目發起人、客戶、項目經理、相關專家、其餘主要干係人;
3)任務:審查、評價、批准、推遲或否決項目變動,記錄和傳達變動處理請求;
4)設立緣由:項目經理權力有限,對於涉及計劃基準的變動不能自作主張;
一句話歸納CCB 設立的緣由:PM 一我的決定不了的大事須要經過CCB 來羣體決策。
包含在變動管理計劃中
1)是指包括變動管理的一系列正式的書面程序,包括文檔、跟蹤系統和變動的批准層次等;
2)該系統不只說明什麼樣的變動須要哪一個層次的批准,並且也說明在什麼狀況下能夠不經批准就實施變動;
3)該系統說明CCB 的組成、權力與責任;
4)緊急狀況下的變動能夠不經CCB 批准就實施,但過後需補辦相關變動手續;
每項記錄在案的變動請求都必須由一位責任人批准或否決。這個責任人一般是PM 或者發起人,在項目管理計劃或組織流程中會指定批准責任人。必要時由CCB 開展實施總體變動控制過程。
1)PM:通常批准不涉及基準的變動請求,緊急狀況可批准特殊的變動請求。好比有客戶老闆的連環奪命call,要求立刻、當即、馬上進行一個變動,不變就解約,很是緊急。那就PM 本身決定要不要變吧。由於若是走流程的話,時間來不及。注意:一些很簡單的變動,不涉及基準的,好比說干係人登記冊裏一位干係人的名字寫錯了,這種小問題,PM 也能夠自行決定,不用走流程
2)發起人:通常批准章程的變動;章程寫的不清楚,要進行變動,由發起人來決定要不要變;
3)變動控制委員會CCB:批准或否決基準的變動請求;
4)客戶:批准按合同實施的項目的某些變動請求雖然影響基準的變動必需要經過CCB 的批准,但並不意味着CCB 只能批准影響基準的變動,有一些在變動控制系統中指定須要CCB 批准的變動但並無影響基準。
0)PM 對可能引發變動的因素施加影響;
——注意!是「施加」影響,而不是第2 步的「評估」影響。看看是不是沒必要要的變動,
避免因我的的主觀臆斷隨意進行變動。
1)干係人正式向PM 提交變動請求,並記錄變動請求;
——書面記錄變動、建立變動請求。
2)PM 評估變動對項目的影響;
——記錄後,評估若是實施變動會對項目產生什麼影響。
3)PM 與干係人溝通並尋求處理變動的備選方案;
——尋找處理變動的解決方案
4.1)PM 自主決策;
——若是變動不影響基準,PM 自主決策,以後更新到變動日誌中。
4)PM 提交含解決方案的變動請求給CCB 審批;
——若是變動影響基準,PM 將變動請求提交給CCB。
——若是CCB 否決了變動請求,將結果更新到變動日誌中。
5)更新項目管理計劃與項目文件;
——若是CCB 批准了變動請求,就須要更新項目管理計劃/文件。
6)通知受變動影響的干係人;
——通知會受到變動影響的干係人。
7)項目團隊執行批准的變動;
——項目團隊執行、實施批准的變動請求。
8)跟蹤確認變動的實施狀況;
——被批准執行的變動,跟蹤、記錄實施狀況如何。
完結全部項目管理過程的全部活動,正式結束項目或階段。結束項目也叫項目收尾、行政收尾、階段收尾。項目有明確的起點和終點,起點是項目章程得到批准。終點是:
1)目標達成
2)不能達到目標項目終止
3)項目需求不復存在
4)客戶或發起人但願終止等等
若是項目在完工前就提早終止,本過程還需制定程序,來調查和記錄提早終止的緣由。
記錄了項目成功標準、審批要求,以及由誰來簽署項目結束
結束項目時,項目經理須要審查項目管理計劃中的範圍基準,確保全部的項目工做均已完成,才能夠進行收尾。
商業論證:用於肯定項目是否達到了經濟可行性研究的預期結果
收益管理計劃:用於測量項目是否達到了計劃的收益
正常收尾的驗收的可交付成果包括批准的產品規範、交貨收據和工做績效文件;
分階段或被取消的項目中,包括未所有完成的可交付成果或中間可交付成果。
用於確承認交付成果已經過驗收、肯定已達到退出標準、正式關閉合同,評估干係人滿意度,傳遞項目知識和信息,以及慶祝成功。
參與者:團隊成員、參加項目或受項目影響的干係人
會議類型:收尾報告會、客戶總結會、經驗教訓總結會,以及慶祝會等
項目收尾,移交項目所產出的最終產品、服務或成果;
階段收尾,移交該階段所產出的最終產品、服務或成果。
用最終報告總結項目績效,可包括如下信息:
a) 項目或階段的概述
b) 範圍目標、範圍的評估標準,以及證實達到完工標準的證據
c) 質量目標、項目產品和質量的評估標準,覈實信息以及誤差緣由
d) 成本目標,包括可接受的成本區間、實際成本,以及誤差緣由
e) 最終產品、服務或成果的確認信息的概述
f) 進度目標,包括成果是否實現項目所預期的收益,以及將來實現狀況
g) 最終產品、服務或成果如何知足商業計劃所述業務需求的概述
h) 項目過程當中發生的風險或問題及其解決狀況的概述
1)爲達到階段或項目的完工或退出標準所必需的行動和活動;(確認該作的已經作完,怎麼確認?經過什麼確認?審查項目管理計劃中的範圍基準)
2) 確認賣方的工做已經過正式驗收,並處置未決索賠;(確認供應商交付的產品已經過驗 收,並處理採購工做涉及的索賠);
3)爲向下一個階段或向生產和/或運營部門移交項目的產品、服務或成果所必需的行動和活 動;(最終成果作移交)
4)總結經驗教訓並存檔;
5)收集關於改進的建議;
6)測量干係人滿意程度;
接下來
7)慶功會;
8)釋放資源;
項目已準備部署。質量測試顯示存在一些嚴重問題,但項目經理有信心在部署日以前解決這些問題。下列哪個干係人應作出部署/不部署的決定?
A. 供應商
B. 發起人
C. 員工表明
D. 項目管理辦公室
答案:B。發起人可能還參與其餘重要事項,如範圍變動審批、階段末評審,以及當風險很大時對項目是否繼續進行作出決定。
高層經理告訴項目經理,若是項目變動,則會引發範圍變動,費用變動,他指的是?
A、要常常檢查溝通管理計劃
B、多重約束
C、儘可能防止變動發生
D、要向高層彙報
答案:B。有一個因素髮生變動,則會引發其餘因素中至少一個受到影響,這是項目的多重製約。
項目經理與贊助人針對一項新的多階段複雜項目,共同制定章程。項目經理從哪一過程組開始制定並審查經驗教訓文件?
A 規劃過程組
B 執行過程組
C 收尾過程組
D 啓動過程組
答案:D。制定章程屬於啓動過程組,而且在整個項目期間都應該對經驗教訓文件彙編、更新。
客戶啓動了一個新的戰略項目,該項目必須在年末完成。該項目對於客戶的戰略成功相當重要,關於項目範圍、預算和進度的意見已經討論過。項目章程中還應包括哪些內容?
A、批准的預算、指定的資源和固定的完工日期
B、定量的風險、限制的例外狀況、以及修訂的里程碑日期
C、整體需求、主要風險和識別的範圍
D、項目計劃、範圍計劃和資源計劃
答案:C。
章程中沒有指定的資源、固定的完工日期,只有一些關鍵的里程碑。排除 A;
章程中沒有定量的風險、修訂的里程碑日期。只有主要的風險。沒辦法「定量」。排除B;
章程中沒有項目計劃,排除 D。
項目經理正與一名認可未使用章程的同事討論項目章程。爲了向同事說明項目章程的重要性,項目經理代表項目章程是重要的,由於項目章程的批准即意味着下列哪一項?
A、 啓動階段正式開始
B、 執行階段正式開始
C、 詳細需求清單的正式批准
D、 項目的正式受權
答案:D。 A錯誤的緣由:並非啓動階段正式開始,而是意味着啓動階段結束。B錯誤的緣由:章程在啓動階段結束就完成了,等不到執行
下列哪一項描述了項目管理信息系統?
A、支持工做分解結構詞典開發的應用軟件
B、注重聯繫項目團隊成員的社交網絡平臺
C、用於日程安排、配置管理和鏈接其餘系統的一組工具
D、在項目溝通生命週期內支持項目經理工做的一套模版
答案:C,見PMBOK第六版95頁。項目管理信息系統(如自動化工具,包括進度計劃軟件、配置管理系統、信息收集與發佈系統或進入其餘在線自動系統的網絡界面)。
項目管理計劃制定完畢並由利害關係者批准。項目經理接下來應該怎麼作?
A. 開始執行項目管理計劃中規定的工做
B. 審查風險評估並更新風險登記簿
C. 爲承包商制定工做說明書
D. 針對項目設立變動控制委員會
答案:A。計劃被批准後,下一步是根據項目管理計劃去執行工做
某個項目可交付成果所需的設備是舊的且不可靠。工廠經理建議訂購一臺新機器。工廠經理向項目經理提交變動請求記錄下列哪一項?
A、 糾正措施
B、 缺陷補救
C、 預防措施
D、 更新
答案: C。工廠經理建議訂購一臺新機器,這是爲了防止出錯工廠經理而建議訂購新的。
項目經理向客戶提交可交付成果以供批准。客戶稱可交付成果沒有達到驗收標準,並要求項目經理對可交付成果進行返工。客戶還但願查看返工進度的相關信息。項目經理接下來應該執行哪一項活動?
A. 配置識別
B. 配置覈實與審計
C. 配置狀態記錄
D. 配置控制
答案:B。項目經理應進行配置覈實與審計,屬於監控,查看配置文件所規定的功能要求是否已經實現。
爲響應一項政府要求,A 公司啓動了一個項目。項目經理將根據項目發起人提供的信息編制項目章程。下列哪一項屬於項目章程中的高層次選擇?
A. 溝通計劃
B. 採購計劃
C. 預算彙總
D. 企業環境因素
答案:C。項目章程的內容包括了預算彙總。
下列哪一種基線綜合了範圍、進度和成本?
A.質量基線
B.綜合基線
C.整體項目基線
D.績效測量基線
答案:D。PMB 績效測量基準是範圍-進度-成本三位一體的基準,用來測量、管理績效。
整體項目計劃制定完畢並獲批准。項目經理將正式宣佈啓動項目,並向全部利害關係者提供項目預期里程碑概要。項目經理接下來將怎麼作?
A. 與團隊成員召開啓動會議
B. 向團隊成員發送項目計劃
C. 安排周進度審查會議
D. 開展團隊建設活動
答案:A。啓動大會在項目計劃制定完,執行前召開。
客戶提早終止了項目,下列哪一種說法是正確的?
A、 你必須中止全部的工做並解散團隊
B、 你必須與項目團隊一塊兒記錄經驗教訓
C、 你必須讓項目團隊繼續在項目中工做,以便讓管理層有足夠的時間與客戶洽談
D、 你必須更新項目管理計劃以及反映這種變動
答案:B。終止了項目,須要收尾,AB 都是收尾要作的,先作B、再作A。
項目經理正在準備項目收尾文件。這些文件應包括下列哪些內容?
A. 預算和財務信息、客戶驗收管理計劃以及項目收尾批准
B. 未決風險、關閉項目的緣由以及質量保證審計
C. 關閉項目的緣由以及完工和未完工可交付成果的移交程序
D. 可交付成果、預算和財務信息以緊急變動請求
答案:C。若是項目在完工前提早終止,則須要在正式的收尾文件中說明項目終止的緣由,並規定正式程序,把該項目的已完成和未完成的可交付成果移交他人。
因爲對於項目可交付成果有太多互相矛盾的討論,一個實施新系統的項目在發佈時發生問題。項目經理離開公司,一名新項目經理被分配到該項目中。新項目經理首先應該採起的行動是什麼?
A. 完成項目管理計劃,並與相關干係人溝通
B. 上報項目發起人,並尋求支持,來處理正在進行的討論
C. 正式肯定項目章程,並要求得到項目發起人和關鍵干係人的批准
D. 製做工做分解結構,並與全部相關干係人溝通
答案:C。換了新的PM,要從新肯定章程,要把PM的名字改爲本身的,新的PM才被正式受權。
項目章程和團隊任務分派已經完成,計劃在下週召開項目啓動大會。項目啓動大會的目標是什麼?
A. 審查風險登記冊,討論風險管理計劃,並確保全部風險均已記錄
B. 與全部干係人一塊兒審查項目計劃,並收集他們對於項目範圍和進度的反饋
C. 與全部干係人一塊兒審查項目的目的和目標,並得到他們的支持
D. 審查最終項目管理計劃,並肯定是否全部模板都已建立
答案:C。項目啓動大會,是務虛的會議,不會探討具體事情。不會查看風險登記冊,太具體。排除A;尚未開工,沒法收集範圍和進度的反饋,並且這個太具體了,排除B;模板,太具體,排除D。
開展實施後項目審查的目標是什麼?
A. 分析項目是否達到其目標
B. 發出變動請求
C. 審查項目風險
D. 進行團隊成員的績效評估
答案:A。項目審查的目標就是分析項目是否達到原計劃既定的目標,也就是在作監控。
在收尾階段,項目發起人認爲項目沒有達到原始預期。項目經理應使用什麼文件來驗證項目的最終可交付成果?
A. 狀態更新
B. 風險登記冊
C. 干係人登記冊
D. 項目章程
答案:D。項目章程中包含可測量的項目目標和相關的成功標準。
市場動態發生變化。因爲項目績效不肯定,項目發起人但願終止合同。項目經理和項目發起人應審查什麼?
A. 根本緣由分析和技術問題的行動計劃
B. 項目的技術和商務目標、可行性和可盈利性
C. 修訂項目需求的變動請求
D. 對致使技術問題進行解釋
答案:B。從商業論證的角度看項目是否可行
弱矩陣組織的項目經理正爲項目的人力資源計劃制定獎勵制定。項目經理應經過下列哪一種方法獎勵團隊成員?
A、向超出預期的團隊成員的領導發送推薦信
B、向人力資源部發送表現最好並應得到年終獎的團隊成員名單
C、向表現最佳的團隊成員額外提供工做機會
D、讓表現最佳的團隊成員參與下一項目
答案:A。弱矩陣 PM 只有推薦權。弱矩陣 PM 權力很是小,沒有績效評估的權力、不能提供工做機會或者決定其參與下一個項目,排除 B、C、D。
項目經理指示客戶總監變動某個項目的資源分配。項目經理在哪一種組織類型工做?
A.強矩陣型
B.項目型
C.弱矩陣型
D.職能型
答案:A。客戶總監能夠理解爲職能經理,pm 權力大於職能經理,這是強矩陣。
大廠筆試內容集合(內有詳細解析) 持續更新中....
歡迎關注我的微信公衆號: Coder編程
歡迎關注 Coder編程公衆號,主要分享數據結構與算法、Java相關知識體系、框架知識及原理、Spring全家桶、微服務項目實戰、DevOps實踐之路、每日一篇互聯網大廠面試或筆試題以及PMP項目管理知識等。更多精彩內容正在路上~
新建了一個qq羣:315211365,歡迎你們進羣交流一塊兒學習。謝謝了!也能夠介紹給身邊有須要的朋友。文章收錄至
Github: https://github.com/CoderMerli...
Gitee: https://gitee.com/573059382/c...
歡迎關注並star~