許多不同的專業為項目管理的理論和實踐做出了貢獻。自史前時代以來，工程師和建築師就一直在管理重大項目。大約從 1960 年代開始，人們就開始努力將項目管理實踐專業化，作為其自身的專業化。圍繞這個問題有很多激烈的爭論：項目管理是否應該像工程、會計和醫學一樣成為一種職業？這些機構有專業協會，證明誰可以合法允許使用職稱，誰可以合法從事該行業。他們還為行為不當的質量和紀律成員提供一定程度的保證。另一個正在進行的辯論是：經驗豐富的項目經理需要多少行業知識？一個項目經理從一個行業（例如 IT）過渡到另一個行業（例如酒店業）有多容易？

有兩個對項目管理實踐具有世界影響的主要組織：總部位於美國的項目管理協會 (PMI) 和總部位於瑞士的國際項目管理協會 (IPMA)。本教科書採用更接近 PMI 方法的方法。本章包含更多詳細信息，以及有關項目管理辦公室的部分。

項目管理知識領域介紹

項目啟動與整合

項目的啟動類似於新組織的啟動。項目負責人開髮用於設計和執行項目的項目基礎設施。在項目的早期階段或定義階段，項目管理團隊必須在項目的主要利益相關者（那些對項目有共同利益或利益的人）之間建立一致性。項目經理將召開一次或多次啟動會議或調整會議，將項目的各方召集在一起，並開始項目團隊建設，為了在項目期間高效運作。

在項目啟動期間，項目管理團隊細化工作範圍並製定初步進度表和概念預算。項目團隊根據項目概況制定項目執行計劃。制定和跟踪詳細時間表的計劃、採購計劃以及建立預算和估算和跟踪成本的計劃是在啟動期間制定的。信息技術、溝通和跟踪客戶滿意度的計劃也都是在項目啟動階段製定的。

流程圖、圖表和責任矩陣是捕獲與執行項目計劃相關的工作流程的工具。項目程序手冊的初稿捕捉了團隊成員為項目帶來的歷史和直覺知識。這些程序和工作流程的開發和審查有助於項目組織結構的開發。

了解到一切皆有可能，這是項目啟動的一個激動人心時刻。項目管理團隊要花很多時間制定初始計劃、為項目配備人員並與客戶建立關係。項目經理設定項目的基調，並為每個項目團隊成員設定期望。複雜項目的項目啟動階段可能會很混亂，在製定計劃之前，項目經理成為信息和方向的來源。項目經理創造一個環境，鼓勵團隊成員充分參與項目，並鼓勵採用創新方法來製定項目計劃。

項目範圍 Project Scope

項目範圍是一個文檔，它定義了項目的參數——定義系統並確定其行為的因素，在項目邊界內完成了哪些工作，以及在項目邊界外完成了哪些工作。工作範圍（SOW）通常是一份書面文件，用於定義項目結束時將完成的工作——項目的可交付成果。項目範圍定義了將做什麼，項目執行計劃定義瞭如何完成工作。

沒有適用於所有項目的模板。有些項目有非常詳細的工作範圍，有些僅有簡短的摘要文檔。範圍的質量由項目經理和項目利益相關者發展和保持對項目將交付的產品或服務的共同理解的能力來衡量。項目範圍的大小和細節與項目的複雜性概況有關。更複雜的項目通常需要更詳細且全面的範圍文件。

根據PMI，範圍說明書應包括以下內容：

•   範圍的描述 Description of the scope
•   產品驗收標準 Product acceptance criteria
•   項目可交付成果 Project deliverables
•   排除項目 Project exclusions
•   項目約束 Project constraints
•   項目假設 Project assumptions

範圍文件是各方達成協議的依據、清晰的項目範圍文檔對於管理項目變更也至關重要。由於項目範圍反映了項目將完成的工作，因此未捕獲和記錄的任何預期變化都會造成混淆。項目最常見的趨勢之一是項目範圍的增量擴展。這種趨勢被稱為“範圍蔓延”。範圍蔓延會威脅到項目的成功，因為範圍的小幅增加需要計劃中沒有的額外資源。增加項目範圍是常有的事，因此需要對項目預算和進度進行調整以應對這些變化。當這些變更未被識別或未被管理時，就會發生範圍蔓延。項目經理識別潛在變更的能力通常與範圍文件的質量有關。

需要更改項目範圍的事件確實會發生。市場的變化可能需要改變產品設計或產品交付時間。客戶管理團隊或客戶財務狀況的變化也可能導致項目範圍發生變化。項目進度、預算或產品質量的變化將對項目計劃產生影響。通常來說，項目變更發生的越晚，項目成本的增加就越大。項目經理有責任為項目建立一個變更管理系統，以捕獲項目範圍的變更，並確保這些變更得到客戶組織中適當管理層的授權。項目經理還分析這些變更對成本和進度的影響，並調整項目計劃以反映客戶授權的變更。範圍的變化可能會導致成本的增加或減少。

 

項目進度和時間管理 Project Schedule and Time Management

項目成功的定義通常包括按時完成項目。制定和管理按時完成項目的項目進度表是項目經理的主要職責之一，按時完成項目需要製定切合實際的計劃並對計劃進行有效管理。在較簡單的項目中，項目經理可能會領導項目計劃的製定，並製定一個時間表來滿足該計劃。在較大或更為複雜的項目中，專注於成本和進度計劃和控制功能的項目控制團隊將協助項目管理團隊制定計劃並根據計劃跟踪進度。

 

為製定項目進度表，項目團隊對項目範圍、合同和其他有助於團隊定義項目可交付成果的信息進行分析。基於這些信息，項目團隊制定了一個里程碑時間表。里程碑時間表確定了項目生命週期中的關鍵日期，項目必須滿足這些日期才能按時完成。關鍵日期的確定通常是為了履行合同義務或確定的時間間隔，以反映項目的適當進展。對於不太複雜的項目，里程碑時間表可能足以跟踪項目的進度。對於更複雜的項目，需要更詳細的時間表。

 

為了製定更詳細的時間表，項目團隊首先制定了工作分解結構（WBS）——對按細節層次排列的任務的描述。儘管項目範圍是製定 WBS 的主要文件，但 WBS 合併了所有項目可交付成果並反映了闡明項目可交付成果的任何文件或信息。從 WBS 中，制定了項目計劃。項目計劃列出了完成 WBS 中確定的工作所需的活動。 WBS 越詳細，為完成工作確定的活動就越多。

 

項目團隊確定活動後，團隊將根據活動完成的順序對活動進行排序。工作流程的一個結果是項目邏輯圖。邏輯圖代表完成項目所需活動的邏輯順序。規劃流程的下一步是估算完成每項活動或活動持續時間所需的時間。有些活動必須按順序進行，有些活動可以同時進行。計劃流程通過以有效和高效地使用項目資源並在最短時間內完成項目的方式安排活動來創建項目進度表。

 

在較大的項目中，會創建多個路徑來表示從項目開始到結束的一系列活動。完成項目的最長路徑是關鍵路徑。如果關鍵路徑花費的時間少於客戶允許的完成項目的時間，則該項目的總浮動時間或項目鬆弛時間為正數。如果客戶的項目完成日期早於計算出的關鍵路徑結束日期，則該項目有一個負數的總浮動時間。理解和管理關鍵路徑上的活動是一項重要的項目管理技能。

 

要成功管理項目，項目經理還必須知道如何加快進度以補償延遲關鍵活動的意外事件。壓縮加速 (Compressing) ——緊急沖刺 (Crashing)——是用來描述縮短項目進度的技術的術語。在項目生命週期中，經常會發生進度衝突，項目經理有責任減少這些衝突，同時保持項目質量和滿足成本目標。

項目成本 Project Cost

項目成功的定義通常包括在預算範圍內完成項目，這是製定和控制項目預算以實現項目目標的關鍵項目管理技能。儘管客戶期望項目能夠高效執行，但不同項目所面臨的成本壓力各不相同。在某些項目中，項目的複雜性使項目完成或結束日期成為最大的挑戰。有許多關於項目成本的例子，例如開發解決重大健康問題的新藥、生產新產品以產生關鍵現金流，以及公司憑藉新技術取得市場競爭優勢。這些例子表明在某些情況下，項目進度的壓力超過了項目成本的壓力。

 

項目預算的準確性與項目團隊已知信息的多少有關。在項目的早期階段，制定詳細預算所需的大量信息常常缺失。為了解決信息缺乏的問題，項目團隊制定了不同級別的項目預算估算。概念估算（或“大概估算”）是使用最少的知識開發的。概念估算的主要輸入是專家知識或過去的經驗。過去執行過類似項目的項目經理可以使用這些成本來估算當前項目的成本。

 

當了解更多信息時，項目團隊可以製定粗略的數量級 (ROM) 估算。諸如建築物的近似平方英尺、工廠的生產能力以及開發軟件程序所需的近似小時數等其他信息可以為提供ROM估算提供基礎。在項目設計更加完整之後，可以完成項目詳細估算計劃。例如，當項目團隊了解房屋的房間數量、材料類型和建築位置時，他們可以提供詳細的估算。這個詳細估算並不是房屋的出價。

 

項目成本是根據工作進度和完成該工作的估計來跟踪的。根據成本估算，將已完成工作的成本與該工作的預算成本進行比較。如果成本明顯偏高或偏低，項目團隊會探究預期成本與實際成本之間存在差異的原因。

 

項目成本可能會偏離預算，因為市場價格與預期不同。例如，住房項目的木材估計成本可能高於預算，或者勞動力的小時成本可能低於預算。項目成本也可能因項目績效而有所不同。例如，一個項目組估計河上橋樑的鋼結構設計需要 800 個工時，但實際花費了 846 個工時。項目團隊捕獲工作預算成本與實際工作成本之間的偏差，根據需要修改估算並在偏差反映趨勢時採取糾正措施。

 

項目經理負責確保項目團隊根據可用的最佳信息制定成本估算，並在獲得新的或更精確的信息時修改這些估算。項目經理還負責根據預算跟踪成本，並在項目成本顯著偏離項目估算時進行分析。然後項目經理採取適當的糾正措施，確保項目績效與修訂後的項目計劃相匹配。

項目質量 Project Quality

 

項目質量側重於反映項目目的的最終產品或服務可交付成果。項目經理負責制定項目執行方法，明確了解預期的項目可交付成果和質量規範。房屋建築項目的項目經理不僅需要了解房屋中的哪些房間將鋪設地毯，還需要了解需要何種等級的地毯。人流量大的房間就通常需要高檔的地毯。

 

項目經理負責制定項目質量計劃，該計劃定義質量期望並確保滿足規範和期望。通過記錄規範和期望來深入了解項目可交付成果對於製定良好的質量計劃至關重要。確保滿足規範和期望的流程被整合到項目執行計劃中。正如項目預算和完成日期可能會在項目生命週期中發生變化一樣，項目規範也可能發生變化。質量規格的變更通常與成本或進度變更在同一流程中進行管理。分析變更對成本和進度的影響，並在適當的批准下，對項目執行計劃進行變更。

 

PMI 的《項目管理知識體係指南》（PMBOK 指南）中有一章是關於項目質量管理的。本章中的材料類似於優秀的運營管理文本中的材料。

 

雖說旨任何漸進式的質量管理改進技術都可以應用於項目工作流程，但小型項目的特徵（獨特且持續時間相對較短）使管理改進的吸引力較小。與製造業務一樣，項目重工（Project Rework）流程會增加產品或服務的成本，並且通常會增加完成重做活動所需的時間。由於受到項目的持續時間限制，在項目早期開發適當的技能、材料和工作流程對於項目成功至關重要。在更為複雜的項目中，儘早分配時間來製定計劃了解和發展適當水平的技能和工作流程。

 

如果你在執行多個相似類型的項目管理工作，你可能會發現流程改進工具對於識別和改進其他項目的基本流程非常有用。流程改進工具還可以幫助確定成本和進度改進的機會。快速找到改進機會可以對項目績效產生影響。在項目的早期階段，即規劃階段，投入時間和資源以尋求改進是最為重要的。然而，在項目的後期階段，隨著滿足項目進度目標的壓力增加，項目文化往往不利於對工作流程進行更改。

 

另一個另一個應用流程改進工具的機會是在具有重複流程的項目中。例如，一個建造多棟相似房屋的房屋承包商可以通過評估前幾棟房屋的工作流程來尋找改進機會。如果承包商建造的房屋數量超過五個，那麼每個工作流程投資1,000美元就可以為每棟房屋節省200美元，這將是一項很不錯的投資。

項目團隊：人力資源 Project Team

在合適的地點和合適的時間為項目配備合適的人員是項目管理團隊的一項重要職責。項目通常有兩類團隊成員：職能經理和流程經理。職能經理和團隊專注於項目的技術。在建築項目中，職能經理將包括工程經理和施工主管。在培訓項目中，職能經理將包括專業培訓師； 在信息技術項目中，軟件開發經理將是職能經理。項目管理團隊還包括項目過程經理。項目控制團隊將包括在估算成本、成本跟踪、計劃成本和調度成本方面具有專業知識的流程經理。項目經理需要職能和流程專業知識來計劃和執行成功的項目。

 

因為項目是臨時的，所以項目的人員配置計劃通常既反映項目所需的熟練團隊成員的長期目標，也反映反映項目性質的短期承諾。團隊成員通常會協商確切開始日期和結束日期來滿足個人和項目的需求。項目的不同階段也有不同的人員配置計劃和決定。在項目的早期或概念階段的團隊成員通常不需要配置在後期或項目收尾階段。在概念或收尾階段通常不需要配置實施階段的團隊成員。每個項目階段都有人員配備要求，複雜項目的人員配備需要詳細規劃，以便在正確的時間及區域擁有正確的團隊技能。

 

通常來說，核心項目團隊致力於管理從啟動到收尾的項目。核心項目管理團隊的成員包括：項目經理、項目控制、項目採購，以及功能管理的主要成員或項目技術專家。雖然較長期的項目可能比短期的項目經歷更多的團隊更替，但對於任何項目來說，擁有能夠在項目階段保持連續性的團隊成員是很重要的。

 

例如，在一個大型商業建築項目中，負責建築施工場地設計的土木工程團隊將在設計的早期階段作出最大的貢獻。土木工程負責人將根據需要帶來不同的土木工程專業。隨著土木工程工作的完成和結構工程的順利進行，大部分土木工程師將從該項目團隊從任務中解脫出來。職能經理、工程經理和土木工程負責人等將在整個項目期間提供專業知識來解決可能出現的技術問題並處理變更請求。

 

項目團隊成員可以從多個不同來源分配到項目。特許項目的組織可以是—組織內的職能部門指派有才能的經理和員工﹑與個人或機構簽訂合同擔任項目的員工職位﹑為項目臨時僱用員工，或是這些人員配置選項的組合。這種人員配備方法允許項目經理創建項目組織文化。一些項目文化更加結構化和注重細節，而另一些則結構化程度較低，角色和溝通要求不那麼正式。項目經理創造的文化類型在很大程度上取決於項目的類型。

溝通 Communications

成功完成複雜項目需要團隊合作，而團隊合作需要團隊成員之間的良好溝通。如果這些團隊成員在同一棟大樓里工作，他們可以安排定期會議，互相走進對方的辦公室得到快速答案，甚至在其他辦公場合非正式地討論項目。在現今的全球經濟中，許多複雜項目涉及來自分散地點的團隊成員，而在同一建築內有效的會議類型並不適用。使用電子通信方式而無需面對面會議的團隊被稱為虛擬團隊。
溝通可以分為兩類：同步和異步。如果所有參與溝通的人同時參與交流，則該溝通是同步的，電話會議是同步通信的一個例子。當參與者在不同的時間交互時，則該溝通是異步的。 （單詞開頭的字母“a”表示“非”）。通信技術需要各種兼容的設備、軟件和服務提供商，與全球虛擬團隊的通信可能涉及許多不同的時區。建立有效的溝通需要一個溝通計劃。

項目風險 Project Risk

風險存在於所有的項目中。項目管理團隊的角色是了解項目中存在的各種類型和程度的風險，然後製定和實施計劃來減輕這些風險。風險代表了項目生命週期中可能發生的事件，這些事件將對項目目標的實現產生負面影響。風險的類型和數量因行業類型、複雜度和項目階段而異。項目風險計劃還將反映項目經理和關鍵利益相關者的風險偏好。人們對風險的舒適度不同，項目團隊的一些成員會比其他人更不願承擔風險。

 

制定風險管理計劃的第一步是識別潛在的項目風險。有些風險很容易被識別，例如加勒比地區出現破壞性暴風雨的可能性，而有些風險則不太明顯。許多行業或公司都有根據過去經驗制定的風險清單。建築業研究所發布了一份包含100個項目風險的清單，提供項目風險的例子和領域。沒有任何一個風險清單能包含所有潛在的風險。清單的價值在於激發對項目潛在風險的討論和思考。

 

項目團隊分析已識別的風險，並估計風險發生的可能性。然後，團隊估計事件發生時對項目目標的潛在影響。這個過程的結果是一個按照發生可能性和對項目的潛在影響程度進行排序的預估項目風險清單。

 

項目團隊隨後製定風險緩解計劃，以降低事件發生的可能性或在事件發生時降低對項目的影響。風險管理計劃被整合到項目執行計劃中，並將緩解活動分配給適當的項目團隊成員。在風險分析中識別到的所有潛在事件發生的可能性極小。而至少一個事件發生的可能性是很高的。

 

項目風險計劃反映了項目的風險偏好，並在投資緩解措施與項目效益之間取得平衡。較為常見的風險緩解方法之一是使用應急預算（或稱“備用金”）。應急預算是項目團隊為應對未預見事件而設立的資金。高風險項目通常會有較大的應急預算。如果團隊知道哪些活動具有最高的風險，應急預算可以分配給具有最高風險的活動。當風險不易與特定活動相關時，應急預算會在單獨的行項目中標識。該計劃包括項目生命週期內定期的風險計劃審查。風險審查評估當前計劃的有效性，並探索之前未識別的可能風險。

項目採購 Project Procurement

項目採購工作因項目類型而異。通常情況下，在較為簡單的項目中，客戶組織會提供採購服務。在這種情況下，項目團隊確定項目所需的材料、設備和用品，並提供產品規格和詳細的交貨時間表。當母公司的採購部門提供採購服務時，項目的聯絡人可以幫助採購團隊更好地了解項目的獨特要求以及項目進度表中時間敏感或關鍵的項目。

 

在規模較大且較為複雜的項目中，需要專門的人員採購和管理項目所需的設備、用品和材料。由於項目的暫時性，設備、用品和材料是作為項目成果的一部分或用於執行項目的工作而採購的。例如，為建築項目採購的磚塊將作為項目成果而採購，而砂漿攪拌機是為執行項目工作而採購的設備。在項目結束時，為執行項目工作購買或租賃的設備將被出售、歸還租賃機構或以其他方式處置。

 

更複雜的項目通常會通過不同的採購和管理方法來採購。商品是根據最低報價購買的常見產品。商品包括建築項目中的混凝土、辦公用品，甚至是研究項目的實驗設備等物品。第二類採購包括為項目指定的產品。能夠生產這些產品的供應商會競標合同。合同的授予可以包括價格、能否按項目進度要求完成、產品的適用性以及其他對項目重要的考慮因素。為新鋼廠製造爐子就是由項目供應商提供、專門為研究項目設計和建造的設備就是另一個例子。這些供應商的表現成為項目的重要組成部分，項目經理會分配資源來協調供應商的工作和進度。第三種採購方法是開發一個或多個合作夥伴。獲得鋼廠主要部分設計合同的設計公司以及正在進行研究關鍵子部分的研究公司都是潛在的項目合作夥伴的例子。合作夥伴為執行計劃做出貢獻並被整合進去。當合作夥伴分享項目成功的願景並對項目情感投入時，合作夥伴表現最佳。項目管理團隊制定並實施項目採購計劃，以識別最有效和最高效的採購方法來支持項目進度和目標。

項目利益相關方管理 Project Stakeholders Management

人員和組織對項目來說可以有許多不同的關係。最常見的是將這些關係分為將受到項目影響的人員和組織以及可以影響項目的人員和組織。

 

成功的項目經理將在項目早期識別利益相關方。對於每個利益相關方，重要的是要確定他們想要或需要什麼，以及他們對項目具有的影響或權力。根據這些信息，可以確定需要與利益相關方或利益相關方團體溝通，並創建利益相關方管理計劃。利益相關方登記表用於識別和跟踪項目與每個利益相關方之間的互動。此登記表必須定期更新，因為新的利益相關方可以隨時出現，並且特定利益相關方的需求和興趣水平可能隨著項目進展而發生變化。

Scrum開發概述

“Scrum”是另一種正式的項目管理/產品開發方法論，也是敏捷項目管理的一部分。 Scrum是橄欖球術語（scrimmage）的一個詞，意思是重新開始比賽的一種方式。它類似於每隔X週重新啟動項目工作。它的基本思想是你不真正知道如何事先計劃整個項目，因此你開始並建立經驗數據，然後從那裡重新計劃和迭代。

 

Scrum使用連續的Sprint進行開發。 Sprint類似於小的項目階段（理想情況下為兩到四周）。其基本思想是需要花費一天的時間來計劃現在可以做什麼，然後開發計劃中的內容，並在Sprint結束時展示出來。 Scrum使用開發團隊的短暫日常會議，檢查昨天完成了什麼，明天計劃完成什麼，以及是否有任何事情阻礙了團隊成員完成他們承諾的任務。在Sprint結束時，已經展示的內容可以進行測試，然後開始下一個Sprint週期。

 

Scrum方法定義了幾個重要的角色。它們是：

 

產品負責人：項目的業務負責人，了解行業、市場、客戶和項目的商業目標。產品負責人必須與Scrum流程密切配合，特別是Sprint的規劃和演示部分。

 

Scrum Master：有點像項目經理，但並不完全相同。 Scrum Master的職責主要是消除阻礙開發團隊進展的障礙，教導產品負責人如何在開發工作中最大化投資回報（ROI），促進團隊的創造力和授權，提高團隊的生產力，改進工程實踐和工具，運行每日站立會議，跟踪進展，並確保團隊的健康。

 

開發團隊：自組織（輕度領導），授權組。他們參與每個Sprint的規劃和估算，進行開發，並在Sprint結束時展示結果。已經證明，開發團隊的理想大小為7 +/- 2。開發團隊可以分成“小團隊”，並“群集”於在Sprint規劃會議上創建的用戶故事上。

 

通常，產品的開發方式是這樣的：有一個“前線”（當前衝刺的故事/任務），一個“後方”（下一個衝刺的故事）和一個“冰箱”（以及一些後來的故事和流程變更） 。可以將產品分解成以下結構：產品 — 特徵— 故事—任務。

 

通常使用“故事點”進行努力估計（微小= 1 SP，小= 2 SP，中等= 4 SP，大= 8 SP，巨大= 16+ SP，未知=？SP）。故事可以是各種類型。用戶故事是非常常見的，它們描述了用戶可以在給定起點處執行的操作以及不同操作的結果。其他類型的故事來自以下領域：分析，開發，QA，文檔，安裝，本地化和培訓。
每個迭代周期的計劃會議需要產品負責人、Scrum Master和開發團隊的參與。在計劃會議中，他們為即將到來的迭代周期設定目標，並選擇要處理的產品積壓清單的子集（擬議的故事），開發團隊將故事分解為任務並對其進行評估。開發團隊和產品負責人進行最終談判，以確定以下迭代周期的積壓清單。
Scrum方法論使用指標來幫助未來的規劃和跟踪進展，例如“燃盡圖” – 剩餘的小時數與天數之間的關係，“速度” – 實際上是團隊所花費的工作量。 （大約三個具有相同團隊的迭代周期之後，人們可以對團隊未來的工作情況有所了解。）
使用Scrum方法的一些注意事項：1）需要有承諾、成熟的開發人員；2）仍需要在前期或早期進行重要的需求定義、一些分析、架構定義和角色及術語的定義；3）需要公司和產品負責人的承諾；4）最適合需要頻繁發布或更新的產品，對於一旦發布後不允許頻繁升級的大型全新產品而言效果較差。

項目管理辦公室

許多大型甚至中型組織已經建立了一個部門來監督和支持整個組織的項目。這是為了減少高失敗率項目的數量（請參閱項目管理概述章節）。這些辦公室通常稱為項目管理辦公室或PMO。

 

PMO可以是組織中所有項目經理的歸宿，也可以只是為所有項目經理提供資源，他們向各自的部門報告。

PMO的典型目標是：

• 幫助確保項目與組織目標相一致
• 為項目經理提供模板和程序
• 提供培訓和輔導
• 提供協調支持
• 了解項目管理領域最新趨勢
• 作為項目報告和教訓的儲存庫

貢獻者和歸因 Text Attributions

This chapter of 企業策略: 高管項目領導指南 Strategy Consulting: A guide for executives leading projects is a derivative of the following text:

• Table 4.1 by Adrienne Watt. Licensed under a CC BY 4.0 licence.
• Text discussing PMBOK and all text after “Project Stakeholder Management” is by Adrienne Watts and licensed under a CC BY 4.0 licence.

This chapter adapted and remixed by Adrienne Watt from the following sources:

• Introductory text and text under “Project Management Institute Overview” adapted from “History of Project Management” in Project Management by Merrie Barron and Andrew Barron. Licensed under a CC BY 4.0 licence.
• Text under “Introduction to the Project Management Knowledge Areas” was adapted from “Introduction to the Project Management Knowledge Areas” in Project Management From Simple to Complex by author whose name has been removed at the request of the original publisher. Licensed under CC BY-NC-SA 4.0 licence.