面對這種問題，我們可以有很多方式處理， 暫勿論我們如何回應，這和專案經理處理問題手法是一脈相承。與早前看到同人老哥的文章一 樣，他提及專案經理不應自廢武功，老仙深表贊同；不過看到讀者回應，提到人在江湖（身不 由己），為勢所逼，要抵住專案時程壓迫，真是談何容易，老仙也身同感受。事實上，撇下一 堆爛攤子升官發財的確大有人在，而僅存的專案經理仍舊是每天面對相類似的難題，需求變更 （Change Request）日日新鮮，老闆的壓力、客戶的不滿、下屬的不悅，要順利完成一個項目， 委實不是件易事，更遑論要按自己的意願和方向下達至「多贏」局面。
誠然如此，專案經理要如何自處呢？老實說，老仙也沒有答案！如果把一大堆看過的書籍 資料或理論搬出來就可以把問題解決的話，老仙很願意把這些資料歸納整理出來，不過不幸的 是沒有一個專案項目是完全相同的，如此也沒有一套可以放諸四海皆準的解決方法。但是，既 然在ZDnet這裡佔了一小格空間，老仙總得要寫點東西，多賺點稿酬，那就把多年來的「惡行」翻出來和大家分享，是拋磚引玉也好，是前車之鑑也罷，就請諸公多多包涵！
先回引上例，當一個專案，發展到中途，客戶對專案經理的表現甚為不滿，認為他提供的 （Deliverables）並不是他們所需要的，並要求更換專案經理時，作為供應商（Service Provider）又或是作為即將接任的專案經理的你，你會有那些相應對策呢？
〔仙按：談到這裡， 老仙其實很想就此擱筆，讓讀者先行回應他們的看法和處理方式，然後再一起分享和檢驗老仙 的處理方式，不過編輯們大概擔心沒有人會回應老仙的提問，所以構想就此打住，如果讀者 （們）和議以上構想，不妨在此留言，讓大家能有個正面雙向的交流機會。〕
作為供應商，他們當然可以接受或拒絕客戶的要求，但是無論做那方面的決擇，同樣都會 面對很大的風險－就是失去這些客戶，因為不切換專案經理（導師），即使不用賠償損失，將 來也不要期望可以在業內繼續經營（註：導師不會忽然能讓客戶滿意，同業競爭者亦會免費為 你的失敗個案廣泛宣傳）；儘管是換了專案經理，誰可以保證他／她可以挽回客戶的信心？ 在餘下一半的時程，又如何追回失去的進度？面對一個如此單純的需求變更，其實一點也不輕 鬆。
不過，我相信這家公司是本著「客戶永遠是對的」的服務態度（仙按：老仙是不信這一套 的，我只相信客戶永遠是需要尊重的而已！）來運作，所以他們輕易地選擇了更換專案經理的 決定，而他們的對策是向業內最有名的顧問求助，但礙於種種因素，這位朋友便轉而向老仙查 詢，是否能抽空幫忙。
老仙的答覆也簡單不過－「如果你認為我成，那就這樣辦！」（仙按： 哈哈，半句價碼問題都沒有談，最後發覺他們的酬勞也真是低得可以，難怪找不到好的專案經 理。）如此這般，供應商的問題便初步平息，不過頭腦清晰的專案經理們大概都會發現如此的 應對好像有違專業舉措，我們不是要先行判斷需求變更的佐證以及相關的支援資料嗎？我們不 是要作風險及衝擊評估嗎？風險對策與二次風險（Secondary Risk）又將如何面對？理論是沒有錯，不過對一個餘時不到一個月的專案，換了是老仙，也管不了那麼多啦！老 實說，供應商的處理手法實在不妥，不過他的運氣很好。碰上了自視甚高的老仙，理論上，老 仙是甚麼專案都敢接的，只要專案發起／贊助人（Project Sponsor）認同老仙就好了，哈哈！然 而當老仙決定接下這兩個爛攤子時，問題便一再發生，首先：兩個課程雖然是同樣過了一半， 但是供應商所提供的背景資料竟然是全部是錯誤的、客戶（學員）的層次與及需求都有所不 同，老仙先前的準備工作可謂一點也用不上。
先說專案一的學員，他們都是在職的工程人員， 儘管行業類別不同，但目標一致，為的只是考取PMP的專業認證，而先前導師所提供的教材與 進度大致和老仙預知者相若，不過問題是他們並沒要求更換導師，被告知更換導師的原因不外 是對方沒有空繼續執教而已。當老仙滿以為供應商錯誤地把問題複雜化後，以較輕鬆的心情去 面對專案二的學員時，老仙才驚覺他們全部來自一家大型的跨國藥廠，其中不乏高層主管，專案 管理經驗豐富，他們不但對導師的表現甚為不滿外，最可笑的是他們所使用的教材竟然是上手 導師私下付（按：合法與否，老仙就不知啦！）給他們的，完全出乎老仙意料之外，還未來得 及反應已經開始被學員質詢「老仙到底清不清楚所謂何事？」 「該如何滿足他們的期望？」 ．．．。
作為一個專案經理，在數據不足下作出判斷與應變是時有發生，但在大部分資料錯誤的狀 況下被派到戰場上，面對「敵人」的砲火，恐怕大多數人都會慌忙失措。不過，如此的狀況正 好再一次証明－－－「溝通管理是專案成功與否的最關鍵因素！」（仙按：別忘了，這是必考 題哦！）
事實上，擁有業內技術專長的專案經理做起事來當然會感到駕輕就熟，然而有多少這 類型專案經理會犯上「多一事不如少一事」、「你做十天不如我做一天」的毛病把眾人的任務 攬在身上，而忘卻了自己的職能？記得先前老仙強調專案經理不過是一名號大的雜役而已，面 對以上的問題，並不會因為你是一個稱職的講師而順利解決，如果你無法解決（Confronting－ 嘻嘻，又是考試的題目哦！）當前的衝突，胸有再厲害的專業知識，也是於事無補。 對以上的問題，老仙不打算詳述解決方案，畢竟它不是一個專屬的軟體專案，對諸公的參 考意義不大，兩個專案的重點：
<一>在於如何取回客戶的信任，讓他們相信老仙有能力提供他們想要的服務（仙按： 很多專案經理會採取攻擊前人或對手的策略來換取客戶的認同，老仙並不認同此法，無論在道 德層次或專業操守上，這種方法並不可取，與其罵別人如何不濟，不如拿自己的本事出來吹噓 一下還實際一點。）
<二>對過往的失誤致歉（仙按：對的，不是我的錯，但當你承擔了專案經理的職務 時，你就得承擔一切的責任。），讓他們相信機構是有誠意去解決問題。
<三>最後當然是按排合適的培訓計劃，讓客戶追回失去的進度。
經過上述的處理，最終兩個專案還是在獲得好評下順利完成，或許大家會以為這全因為專 案並不需要其他團員協助，又或老仙有過太多類似的經驗，所以能夠安然渡過。這無疑是成功 因素之一，不過，老仙還是深信誠信的溝通技巧才是致勝的主因，下一回，讓老仙和大家 分享一個原本預算一年便可以完成的軟體專案，為何最終需要二年時間方可順利結案，而老 闆、客戶以至工程師三方都能同心協力地完成這個專案，屆時，諸公便可以評斷老仙這句話的 真確性。
