名出色的項目經理知道什么樣的組織、團隊和產品不適合自己。如果你發現自己身處下面的狀況，問題可能不是出在你的身上。所在的組織可能有問題，而現狀可能已經無法控制了。
至少，你總是可以有下面幾個選擇：接受目前的狀況并心中有數，轉換到組織中的其他項目，改變所處的組織。你有可能促成組織的改變。下面是應該注意的警告信號。
什么樣的組織不適合你
你不能選擇團隊成員。很多項目經理的團隊成員會隨著他們轉戰各個項目。偶爾，有一個成員不能完成你分配的工作，或者不能融入團隊。你也無權讓他離開團隊。
如果項目經理不能獲得自己需要的人，先想想自己是不是解釋過為什么需要這些人，而且要確保這么做。如果能夠把成本或是收益與這個職位相關聯，那再好不過。我曾經要求給項目分配一個發布經理，結果被告知：“JR，我們是不會把錢白白花在一名發布經理上的。開發人員非常清楚如何簽入他們自己的代碼。”
我不擔心代碼簽入的問題，我擔心的是不同分支和不同平臺的代碼如何管理。我讓每個人記錄日志，記下自己使用SCM遇到問題時耗費的時間，還有必須自己手工寫SCM腳本用去的時間，等等。這樣記錄了一周，發現團隊在SCM上用去了30小時。我把這個結果告訴我的經理，可他不相信。我讓團隊再記錄一次相關的時間。下一周，他們用了38小時。這下我的經理同意了，我也雇傭了一個人作為承包商，后來此人成為了雇員。項目經理可能要用“人時”（person-hour）來說明項目的損失。
不過問題不僅僅是無法雇傭新人。我見過一些團隊，項目經理備愛一個團隊成員的困擾，這位成員要么是無法完成工作，要么是無法跟團隊整合。如果你處于類似的狀況，要確認你首先提供了有效的反饋。要是你已經事先說明了你要的結果，并且已經工作或是個人的行為提供了反饋，那么讓這個人離開團隊是有意義的。
我曾試圖將工作狀況不佳的團隊成員與團隊離開，可從未成功過。讓這些人在身邊轉來轉去，會令其他的團隊成員焦躁不安，這像是有問題的人反而得到了獎勵，因為他沒有從事相關工作，或是沒有融入團隊。
項目經理要讓不合適的人從團隊中離開。如果不能，想想你自己吧。也許是該換到別的項目，更有可能的是，離開這個組織的時候了。
出席會議變成行政任務。如果在開會時，高層總是盯著誰列席了會議，誰沒有來，你也因此不能選擇參加哪些會議，那干嘛還在這樣的組織里浪費時間？要先打聽下是不是有人在盯著會議的人員參加情況。也許你做出了與事實不符的假設。如果你的假充正確，還是收拾收拾東西走吧。現在的這個組織很快會被淘汰掉。
出資人讓你不得好死。你告訴出資人，讓他對不太樂觀的項目前景有個心理準備，結果他跟你說：“那我把你的頭擰下來。”如果人們受到威脅，或是覺得項目的失敗全都歸罪于自己，他們很難在工作上再現出色，起碼我見過的大部分人如此。
有些項目經理覺得這樣的環境很能鼓舞人，我不這么想。要是你這么想，那恭喜你，希望你能更加強壯。你會需要它的。不過要小心，這是一種命令與控制式的環境，而不是協作式的。協作是絕大部分項目成功的必要條件。
出資人堅持認為人們都應該同時處理多個任務，而且不愿意作出改變。你已經解釋了多任務會帶來的延遲效應，而出資人仍然無法想清楚哪個項目的優先級高。而且，能否成功交付項目對你來說至關重要。
如果拿下著高薪的這幫人不愿意做出關于項目組合的決策，那你為什么還愿意管理一個注定要失敗的項目，并將自己置于毫無獲勝希望的局面之中呢？你不必如此，還有別的選擇。
別人想讓你承擔一些開發相關的工作。項目團隊除了你之外，還有三個人，而且別人覺得你應該寫代碼、測試、寫文檔以及其他的工作。反正人家覺得你處理完項目管理的工作之后，應該做一些技術和開發上的事情。
咳咳，如果你擔任項目經理的團隊成員多于三個人，而且你也兼任他們的項目經理，那你是不會有閑暇時間的。（如果只有兩個人，你還有可能干點兒技術活兒，只要你能確保自己的工作永遠不會處于關鍵路徑上。）要是團隊成員以矩陣式方式加入項目，而且他們只從事與項目相關的工作，并可以按時完成，假定有5個成員，那么你也許還能做一些沒有處理關鍵路徑上的技術工作；要是少于5個人，那么你所負責的任何技術任務將位于項目關鍵路徑之上。（如果所在的項目應用敏捷式生命周期，你作為教練或是Scrum master，而且團隊已經做到了自行組織和管理，那你每周能騰出來更多時間干技術活兒了。）
我看到的情況是，項目經理沒有管理項目。他們在編寫代碼，但是沒有管理風險，他們沒有留意測試的進度，他們沒有產生儀表板上的數據，他們也沒有評估版本發布條件。如果你在一個喜歡開會的公司工作，還得把所有的會議加到工作列表上去。
如果你在管理項目時，要幫助大家看清目標、移除障礙，還得監控他們的進度，你是沒有時間間從事技術工作的。
管理層強制切分項目工作。假如你是開發經理。你啟動了一個項目，努力工作，并聲稱開發已經完成，并向下一個項目進發。你的同事——測試經理——開始測試工作。兩天以后，他沖進你的辦公室，跟你說：“你的開發人員活兒沒有干完。項目是不可能在四天之內完成了。你得把你的人都給我用，好修復缺陷。”可是你已經把人員都分配到另一個大項目中了。現在怎么辦？
你們都是職能兼項目經理。兩個人都不能完全對項目負責，而且你們有人（很可能是測試經理）會因為延遲發布而遭受責罵。這并不是測試人員的錯，也不是開發人員的錯。當高層將項目組織成互相隔離的部分，而且作為職能經理的你對此毫無怨言，這都是管理層的問題。
在7.3.1節中，我提出了一些建議，讀者可以嘗試一下。不過對你來說，真正的問題在于：當組織不以結果作為導向時，你能在自己的職位上發揮作用嗎？要想一想：是不是值得花時間和精力來改變組織？還是干脆改換組織？
噢，成為拯救公司的英雄，這種感覺真得很好。不過當你卷起袖子，接受并不完整的資源并準備啟動項目時，這么做對于團隊其實毫無益處。在資源不足的情況下啟動項目，是完全不可接受的。
如果項目經理不能幫助管理層發現項目的驅動因素，這個組織不適合你。這個組織會繼續利用你善良的天性，并將你推入必死的項目之中。別讓自己掉進去。要么改變項目，根據驅動因素、約束和浮動因素來重新組織，要么走人。在資源不足的情況下啟動項目，必敗無疑。
你總是聽見人們說“你沒法融入團隊”。項目經理的工作要求你將項目視為組織中重要的工作，而且必須依此行事。如果你為了項目的成功而推行的做法得不到認同，而且總是聽到“你沒法融入團隊”這樣的說法，那么也許這個組織根本不需要你。
工程經理的視角并不于一個項目。不過，即使是工程經理也不允許組織對他們橫加干涉。你是項目經理，你說了算。你對項目的成功負有責任，要滿懷熱情地實現這個責任對你的要求。
