採用敏捷專案管理的人員通常會擔憂以下問題：

敏捷不適用於大而複雜的專案。

敏捷太過開放，我們無法預測成本。這是“批准的範圍蠕動”。

敏捷太過關注“技術人員”。

軟體開發人員與客戶的交流不在同一頻道上。

客戶沒有時間參與計劃。

我們不希望客戶看到我們的醜事。

這個“團隊合作”的做法聽起來不實用。

日常會議？我們的員工會覺得自己暴露在顯微鏡之下。

敏捷過於僵化，抑制個人創造力。

事實是，上述擔憂合情合理。無論使用敏捷還是瀑布，專案團隊如果沒有注意到上述問題並找到解決這些問題的方法，就會面臨失敗。

需要理解的真正重要的問題是，什麼情況下使用敏捷更有利，什麼情況下使用傳統方法更好。

以下情形應使用敏捷管理專案：

1）團隊成員此前沒有合作過，或者沒有接受充分的培訓

從某種意義上說，敏捷方法比任何流行的傳統方法更為簡單，因為它的規則更簡單，規則遵從性也更明確。在這種情形下使用敏捷的原因不是為了節約培訓時間，而是為了規避培訓失敗的高可能性，因為培訓失敗會導致專案混亂。

2）團隊沒有可以保護專案資料完整性的、實時交易的專案管理工具

市場上大多數專案管理工具都不是實時交易工具，不能保護專案資料的完整性。如果專案團隊甚至沒有意識到，需要一個強大的專案管理工具才能使用其中一種傳統方法，那麼最好使用敏捷，因為它對強大工具的依賴性要小得多。

以下情形應使用傳統方法管理專案：

1）需要預先定義需求的專案

某些方案，特別是政府的方案，可能需要專案研究和提前定義需求，在需求定義後一段時間內進行大量審批，最後是獨立的專案（通常是與需求專案團隊不同的團隊），開發和交付需求中所說的內容。

如果是這種情況，請避免使用敏捷方法，因為它依賴不斷的互動作用和不斷變化的適應，而沒有清晰的開發過程文件。

2）客戶或使用者組無法參與

專案成功的最大因素是堅定的執行發起人或產品所有者。當客戶在整個專案過程中參與制定需求時，例如審查工作和確定優先順序，這意味著他們不太可能突然丟擲難以實現的需求。他們不斷將業務和使用者需求納入流程。

若客戶參與度不高，沒有將他們的要求正確地輸入到過程中，也沒有參與構思的演變，這樣就需要經常回溯專案並浪費了專案的時間，因此不適合使用敏捷方法。

3）團隊太大（200人或更多），無法進行跨部門溝通

敏捷過程要求團隊成員在專案期間做出很多關鍵的決定。如果你的團隊成員沒有足夠的經驗和責任心，則可能會破壞整個專案。

敏捷方法需要所有利益相關者（開發團隊，測試部門，管理層和客戶）之間不斷的互動。如果其中一支隊伍表現不佳、跨部門溝通不暢，那肯定會影響整體成績。如果這時使用敏捷，可能會適得其反。

如何選擇正確的專案管理方法？

實際上，沒有適合所有專案或組織的“千篇一律”的方法論。實施方法的選擇很大程度上取決於諸如專案性質、規模、涉及的資源等因素。

在大多數情況下，聰明的專案經理會考慮所有方面，然後決定採用哪種方法是針對特定專案實施的最佳方法。無論選擇哪種方法，確保能夠完成工作的正確專案管理工具到位是重要的因素。

8Manage 敏捷專案管理軟體支援增量式產品開發的短迭代管理和滿足競爭格局和產品需求動態變化的管理需求。你也可以靈活擴充套件8Manage系統以滿足傳統專案監控的管理需求（如時間管理，成本管理等）。

結論

儘管敏捷方法在軟體開發人員中廣受歡迎，並且具有許多優勢，但它並不是靈丹妙藥，不是都適用於你的每個專案。對於專案管理而言，最重要的一點是你的團隊要儘可能高效地完成任務。成功的企業不會只執行特定的單一策略，相反，它們會結合所有專案管理方法來解決不同的問題並實現不同的目標。