專案為何這麼難管？
在討論「專案為何這麼難管」、「專案經理為什麼這麼難做」之前，我們先來了解一下什麼叫做「專案」？
很多人對「專案」有認知上的誤解，認為所謂的專案，就是非日常具有重複性質的工作或作業，但是這樣的定義，其實無法顯示出專案的特性。我個人認為「專案」就是：
在有限的時間內，
透過一群人共同合作，創造出獨特的產品、服務或成果，
來解決重要的問題，或者做到使命必達。
從上述定義來看，可以看到管理專案很困難的痛點。
痛點1 有限的時間
企業以「獲利」為主，企業要賺錢，才有辦法養活員工，所以對企業而言，利潤最為重要。因此，企業成立專案，大多是要解決重要且急迫的問題，要嘛就是想辦法提高營業額，要不然就是降低成本。
由於專案通常「誕生」在公司的利潤出狀況、營業額無法成長，或者是庫存或成本降不下來的時候。請各位想一想，當老闆想用「專案」的方式來解決上述問題時，你覺得 老闆給的專案期限是長是短？他真的希望負責執行專案的專 案經理做到期滿嗎？
當然不是，「有限的時間」其實在老闆的心裡面就叫做 「越快越好」！當現有產品賣得不好，營業額開始出現危機，你覺得老闆會期待你的新產品研發專案多久能完成？當然最好是馬上就把新產品變出來，尤其現在環境變化得太厲害， 客戶需求變得更頻繁的壓力下，老闆對專案成果的等待會更 加地沒耐心。
所以，當老闆跟你說專案最多做六個月，而你真的搞了六個月才做出來，對老闆來說，這個專案經理雖不算「失職」，卻也談不上「稱職」，更遑論「優秀」或「高效」了。所以擔任企業的專案經理往往是一個非常高壓的工作，這也是為什麼很多人當了專案經理，做沒幾年就受不了的主因，當然也有很多人根本是想盡辦法來逃避當專案經理。
痛點2 透過一群人共同合作
一般企業組織都是以「部門」型態運作，例如採購部 門、生產部門、研發部門、業務部門等等。但公司內卻很少會有「專案部門」，那是因為專案具有臨時性，常常是突然成立的，所以專案團隊也並非一個穩定的組織。
通常，當專案成立之後，專案團隊成員會是各部門派人 來支援的臨時性組織，也就是說，專案經理要管理的是來支援的各部門同仁。如果經理人連自己部門的同仁都管不好， 為了做專案還要去管不熟的其他部門同仁，那可真是雪上加霜，苦不堪言。
另一方面，不同部門之間因為功能性不同，做事的思維模式與習慣也會很不一樣。例如會計部門的同仁總想省錢， 以利公司降低成本；業務部門的同仁總想花錢，以便讓公司擴大營收。光這兩個部門都來支援，專案經費該如何妥善運用的討論，可能就已經吵翻天了。
請記得，專案時程是有限的，當專案經理花太多時間處理跨部門的溝通協調問題，執行專案的時間就會縮短。何況很多大公司的專案還是跨國合作，跨國合作之間又存在著文化與環境差異的問題。比方說，專案團隊裡有外國人，光是專案會議要在早上開，還是在晚上開？就得傷腦筋協調。
此外，「共同合作」就像是夥伴關係、一起打拚的感覺。 任何一位團隊成員的工作出問題，或是不太會做時，夥伴們理應主動協助他克服難關，不會讓任何一位團隊成員孤軍奮戰；而且專案時間有限，為了不浪費時間在「卡關」上，彼此共同合作是非常必要的。
但是在實際執行時，每一個人手頭上都負責了其他的工 作，經手的可能也不只有一項專案，所以就算是部門內專案，都不見得每一位同仁會相互協助了，更何況是具有跨部門性質的大型專案，彼此共同合作的難度肯定更高。
痛點3 解決重要的問題，或使命必達
由於專案的目的往往是要解決公司「重要」且「迫切」 的問題，而且通常都跟「利潤」有關。所以擔任專案經理之前，你要有所認知：專案一旦能搞定，你將成為公司的救世主；同樣地，一旦搞砸了，你也將成為公司的罪人。這種不是進天堂、就是入地獄的結果，導致擔任專案經理需要很強的抗壓力。
此外，「使命必達」的真正含意，很可能是老闆希望你所管理的專案完成速度更快、成本降得更低、成果品質更高。這種又要馬兒好，又要馬兒不吃草的情況，就是專案經理的真實處境，這也是為什麼很多人對擔任專案經理避之唯恐不及的主因。
專案難管的解方：換個系統腦
在了解「專案」是什麼，以及管理專案的痛點又是什麼 之後，面對問題，當然要尋求解方。
在《專案管理基礎知識與應用實務》書中提及，專案管理源自「系統管理」的概念，專案管理被視為是系統管理的 應用。可見專案的本質是系統，管專案，其實就是管系統。
什麼是系統？「呼吸系統」就是解讀系統的最佳案例。
呼吸系統是：
「在一段時間內，藉由身體中相關連的器官，彼此進行因 果互動，才能順利完成通氣和換氣的呼吸功能。」
我們把這段話跟「專案」的定義連在一起比較： 「在有限的時間，透過一群人共同合作，創造出獨特的產 品、服務或成果，來解決重要的問題，或者是做到使命必達。」
呼吸系統是在「一段時間內」進行，而專案也是在「有限時間內」進行；呼吸系統是藉由「身體內相關連的器官， 彼此進行因果互動」來運作，而專案是藉由「一群人共同合 作」來運作；呼吸系統要完成「通氣和換氣的呼吸功能」，而 專案則是要完成「解決重要的問題，或做到使命必達」。
有沒有發覺，這兩者簡直就像是雙胞胎？
系統就是藉由「組成元素」（如鼻子、咽喉和肺等器官） 彼此之間的緊密連動，以達成整體的功能或目的（呼吸）；而 專案則是藉由具備各種技能與專長的成員組成團隊，每一位 專案成員就像是一種器官，需要一位專案經理驅使各個「組 成元素」彼此互動、共同合作。
所以，專案經理首先要分派誰適合當鼻子、誰適合當咽 喉、誰適合當肺⋯⋯接著想辦法讓成員互動，達到共同合作 的境界，才能「如期」、「如質」、「如預算」地完成專案的交付標的（獨特的產品、服務或成果），讓專案贊助者可以使 用交付標的來解決重要問題或順利達標。
另一方面，當呼吸功能發生問題時，我們也不會只關心 鼻、咽喉或肺等單一器官，而是會去想：喉嚨裡有痰，這是 喉嚨造成的嗎？還是鼻涕倒流所致？如果是喉嚨的問題，解 決策略是吃喉糖或喝水來紓解；然而吃了喉糖、喝了水，喉 嚨卻仍然有痰，而且還因為喉嚨不舒服而想咳嗽，咳久了， 肺又受到影響⋯⋯這就是系統「牽一髮動全身」，以及「見山非山」的特性。
然而，「牽一髮動全身」與「見山非山」的問題，在專案 管理經常發生。最明顯的就是專案經理在管理專案時，很容 易把「如期」、「如質」、「如預算」當作獨立目標來追求，而陷入「治標不治本」的錯誤：
進度出問題而無法「如期」時，就直接加班；
品質不良而無法「如質」時，就重作；
成本超支而無法「如預算」時，就設計變更。
這種「見山就是山」的管理行為，就是專案陷入「治標 不治本」惡性循環的開始。
換個系統腦，進行系統思考
時間、品質、成本就類似於器官，彼此之間互相連動， 如果為了解決「如期」的問題，以致過度加班，有可能發生 成員因疲勞而容易做錯，造成品質不良的現象而無法「如質」；還有，加班要發放加班費，重作也是要花成本的，這些 都會侵蝕專案的利潤，讓專案後續進行無法「如預算」。
這種會互相影響的因果關係，就是系統的必然性。 當專案經理沒有把專案當成系統，或是在解決專案管理 相關問題時，忽略了前述「牽一髮動全身」與「見山非山」的特性，很容易會想出火上澆油的對策，衍生出後遺症或反效果。可是，面對問題時要能「見山非山」、分析問題時要仔 細考慮「牽一髮將會如何動全身」，恰恰不是我們台灣人思考問題的 DNA，有時候反而會被冠上「想太多」、「腦迴路太 複雜」的大帽子。難怪專案對很多人來說，是越管越難管，問題越管越多。
無論你現在管的是三人小專案，還是跨國大專案，唯有 換個系統腦，開始進行系統思考，才能徹底擺脫專案難管的 困境。接下來，我將在各章介紹系統思考如何具體有效地應 用在專案管理的各階修練上。
搞懂投入／產出的因果關係
我們要介紹另一個更好用的工具：ITTO圖，它可以明確地展現所有工作包，相互之間投入／產出的 因果關係，幫助專案經理找出源頭，對症下藥。
ITTO 圖主要包含四大部分：
1. Input 投入
2. Tool 工具
3. Technique 技術
4. Output 產出
因此，在 ITTO 圖中我們會把工作包視為「處理單元」，運作概念為：
1. 投入項目（Input）
2. 經由處理單元內的工具（Tool）
3. 或是技術（Technique）
4. 處理成產出項目（Output）
接下來，我們以「咖哩飯」作為交付標的，製作其工作分解結構，分解後會有三個處理單元（工作包），分別是：
1.1「燉煮」處理單元
1.2「電鍋煮飯」處理單元
1.3「盛盤」處理單元
我以 1.1「燉煮」處理單元，示範說明 ITTO 圖的邏輯：在 1.1「燉煮」處理單元內，「投入」馬鈴薯、洋蔥、肉、咖 哩粉等食材，經由單元內的燉煮「工具」和燉煮「技術」進 行處理，「產出」了咖哩。
由於「投入」與「產出」，具有流進／流出處理單元的 「流量」特性，若是只用箭頭符號（→）難以表達「流量」的 概念，所以引入系統動態學（System Dynamics）裡的流量符號來替代箭頭符號。
系統動態學是由美國麻省理工史隆管理學院的 J.W. Forrester 教授所發展的一門科學，結合了控制、系統論、資 訊理論、決策論、電腦模擬等理論成為一體的管理新方法、 新工具和新概念。系統思考可以視為系統動態學在解決動態 複雜問題時的理解基礎，系統動態學則是把解題的系統思考 圖轉化為具體的數學模型，並進行電腦模擬來協助決策的制 定。由於專案的本質是系統，管專案就是管系統，而且系統動態學與系統思考的關係密切，此為我們引入系統動態學的原因。讀者若對學習系統動態學有興趣，請參考相關書籍， 本書只是借用其流量符號來重新演繹 ITTO 圖。
咖哩醬產出之後，接著在 1.2「電鍋煮飯」處理單元內， 「投入」白米、水，經由單元內的煮飯「工具」和「技術」進 行處理，「產出」白飯。最後，在 1.3「盛盤」處理單元內， 「投入」咖哩醬、白飯，經由單元內的盛盤「工具」和「技 術」進行處理，「產出」交付標的—咖哩飯。
從咖哩飯的 ITTO 圖中，可以具體呈現各個處理單元（工作包），投入／產出相互之間因果關係的全貌。
當交付標的出現問題時，運用 ITTO 圖可以很迅速地找出 根本原因。例如：餐廳的咖哩飯出現負評，透過 ITTO 圖看到 咖哩飯是 1.3「盛盤」處理單元的產出，所以可以先追蹤是不 是 1.3 裡的盛盤「工具」或盛盤「技術」出了問題？
如果並非 1.3「盛盤」處理單元的問題，接著可繼續追蹤 1.3「盛盤」處理單元的投入：咖哩醬、白飯。
由於咖哩醬嚐起來很正常，因此就停止追蹤 1.1「燉煮」 處理單元。然而，白飯吃起來口感不佳，所以繼續追蹤 1.2 「電鍋煮飯」處理單元內的電鍋（工具），是不是出了問題？
由於電鍋在檢查之後沒有發現任何問題，接著就繼續追蹤 1.2「電鍋煮飯」處理單元內的投入：白米、水。最後，發現白飯口感不佳的原因就是水加太多，所以 煮飯時少加點水，負評的問題就此消失。
將「ITTO 圖」轉換「甘特圖」
接下來，我們採用第三章「量身訂做個人化售後服務教 育訓練課程」專案為例，藉由五步驟把 ITTO 圖，轉換成大家 熟知的甘特圖。這樣不僅可以幫助專案經理掌握專案的工作 流程與執行進度，也能知道工作包相互之間的「因果關係」。
甘特圖（Gantt Chart），也稱為條狀圖（Bar Chart），其 設計原則很簡單，基本上就是一個個長條的排列組合，圖形 橫軸表示「時間」，縱軸表示「工作包」或「活動」。 其中，每一項長條，就代表一個工作包，長條的起點與 終點就是工作包開始與結束的時間，主要呈現的就是工作包 的「流程」與「進度」資訊，以確保專案能如期完成。
但是如果發生無法如期、如質、如預算的問題時，甘特圖無法顯示工作包之間的「因果關係」，所以我們很難從中找到問題發生的根本原因。在這種情況下，將 ITTO 圖轉換甘特圖，對於專案經理來說，就是一個很好的工具。
在討論「專案為何這麼難管」、「專案經理為什麼這麼難做」之前，我們先來了解一下什麼叫做「專案」？
很多人對「專案」有認知上的誤解，認為所謂的專案，就是非日常具有重複性質的工作或作業，但是這樣的定義，其實無法顯示出專案的特性。我個人認為「專案」就是：
在有限的時間內，
透過一群人共同合作，創造出獨特的產品、服務或成果，
來解決重要的問題，或者做到使命必達。
從上述定義來看，可以看到管理專案很困難的痛點。
痛點1 有限的時間
企業以「獲利」為主，企業要賺錢，才有辦法養活員工，所以對企業而言，利潤最為重要。因此，企業成立專案，大多是要解決重要且急迫的問題，要嘛就是想辦法提高營業額，要不然就是降低成本。
由於專案通常「誕生」在公司的利潤出狀況、營業額無法成長，或者是庫存或成本降不下來的時候。請各位想一想，當老闆想用「專案」的方式來解決上述問題時，你覺得 老闆給的專案期限是長是短？他真的希望負責執行專案的專 案經理做到期滿嗎？
當然不是，「有限的時間」其實在老闆的心裡面就叫做 「越快越好」！當現有產品賣得不好，營業額開始出現危機，你覺得老闆會期待你的新產品研發專案多久能完成？當然最好是馬上就把新產品變出來，尤其現在環境變化得太厲害， 客戶需求變得更頻繁的壓力下，老闆對專案成果的等待會更 加地沒耐心。
所以，當老闆跟你說專案最多做六個月，而你真的搞了六個月才做出來，對老闆來說，這個專案經理雖不算「失職」，卻也談不上「稱職」，更遑論「優秀」或「高效」了。所以擔任企業的專案經理往往是一個非常高壓的工作，這也是為什麼很多人當了專案經理，做沒幾年就受不了的主因，當然也有很多人根本是想盡辦法來逃避當專案經理。
痛點2 透過一群人共同合作
一般企業組織都是以「部門」型態運作，例如採購部 門、生產部門、研發部門、業務部門等等。但公司內卻很少會有「專案部門」，那是因為專案具有臨時性，常常是突然成立的，所以專案團隊也並非一個穩定的組織。
通常，當專案成立之後，專案團隊成員會是各部門派人 來支援的臨時性組織，也就是說，專案經理要管理的是來支援的各部門同仁。如果經理人連自己部門的同仁都管不好， 為了做專案還要去管不熟的其他部門同仁，那可真是雪上加霜，苦不堪言。
另一方面，不同部門之間因為功能性不同，做事的思維模式與習慣也會很不一樣。例如會計部門的同仁總想省錢， 以利公司降低成本；業務部門的同仁總想花錢，以便讓公司擴大營收。光這兩個部門都來支援，專案經費該如何妥善運用的討論，可能就已經吵翻天了。
請記得，專案時程是有限的，當專案經理花太多時間處理跨部門的溝通協調問題，執行專案的時間就會縮短。何況很多大公司的專案還是跨國合作，跨國合作之間又存在著文化與環境差異的問題。比方說，專案團隊裡有外國人，光是專案會議要在早上開，還是在晚上開？就得傷腦筋協調。
此外，「共同合作」就像是夥伴關係、一起打拚的感覺。 任何一位團隊成員的工作出問題，或是不太會做時，夥伴們理應主動協助他克服難關，不會讓任何一位團隊成員孤軍奮戰；而且專案時間有限，為了不浪費時間在「卡關」上，彼此共同合作是非常必要的。
但是在實際執行時，每一個人手頭上都負責了其他的工 作，經手的可能也不只有一項專案，所以就算是部門內專案，都不見得每一位同仁會相互協助了，更何況是具有跨部門性質的大型專案，彼此共同合作的難度肯定更高。
痛點3 解決重要的問題，或使命必達
由於專案的目的往往是要解決公司「重要」且「迫切」 的問題，而且通常都跟「利潤」有關。所以擔任專案經理之前，你要有所認知：專案一旦能搞定，你將成為公司的救世主；同樣地，一旦搞砸了，你也將成為公司的罪人。這種不是進天堂、就是入地獄的結果，導致擔任專案經理需要很強的抗壓力。
此外，「使命必達」的真正含意，很可能是老闆希望你所管理的專案完成速度更快、成本降得更低、成果品質更高。這種又要馬兒好，又要馬兒不吃草的情況，就是專案經理的真實處境，這也是為什麼很多人對擔任專案經理避之唯恐不及的主因。
專案難管的解方：換個系統腦
在了解「專案」是什麼，以及管理專案的痛點又是什麼 之後，面對問題，當然要尋求解方。
在《專案管理基礎知識與應用實務》書中提及，專案管理源自「系統管理」的概念，專案管理被視為是系統管理的 應用。可見專案的本質是系統，管專案，其實就是管系統。
什麼是系統？「呼吸系統」就是解讀系統的最佳案例。
呼吸系統是：
「在一段時間內，藉由身體中相關連的器官，彼此進行因 果互動，才能順利完成通氣和換氣的呼吸功能。」
我們把這段話跟「專案」的定義連在一起比較： 「在有限的時間，透過一群人共同合作，創造出獨特的產 品、服務或成果，來解決重要的問題，或者是做到使命必達。」
呼吸系統是在「一段時間內」進行，而專案也是在「有限時間內」進行；呼吸系統是藉由「身體內相關連的器官， 彼此進行因果互動」來運作，而專案是藉由「一群人共同合 作」來運作；呼吸系統要完成「通氣和換氣的呼吸功能」，而 專案則是要完成「解決重要的問題，或做到使命必達」。
有沒有發覺，這兩者簡直就像是雙胞胎？
系統就是藉由「組成元素」（如鼻子、咽喉和肺等器官） 彼此之間的緊密連動，以達成整體的功能或目的（呼吸）；而 專案則是藉由具備各種技能與專長的成員組成團隊，每一位 專案成員就像是一種器官，需要一位專案經理驅使各個「組 成元素」彼此互動、共同合作。
所以，專案經理首先要分派誰適合當鼻子、誰適合當咽 喉、誰適合當肺⋯⋯接著想辦法讓成員互動，達到共同合作 的境界，才能「如期」、「如質」、「如預算」地完成專案的交付標的（獨特的產品、服務或成果），讓專案贊助者可以使 用交付標的來解決重要問題或順利達標。
另一方面，當呼吸功能發生問題時，我們也不會只關心 鼻、咽喉或肺等單一器官，而是會去想：喉嚨裡有痰，這是 喉嚨造成的嗎？還是鼻涕倒流所致？如果是喉嚨的問題，解 決策略是吃喉糖或喝水來紓解；然而吃了喉糖、喝了水，喉 嚨卻仍然有痰，而且還因為喉嚨不舒服而想咳嗽，咳久了， 肺又受到影響⋯⋯這就是系統「牽一髮動全身」，以及「見山非山」的特性。
然而，「牽一髮動全身」與「見山非山」的問題，在專案 管理經常發生。最明顯的就是專案經理在管理專案時，很容 易把「如期」、「如質」、「如預算」當作獨立目標來追求，而陷入「治標不治本」的錯誤：
進度出問題而無法「如期」時，就直接加班；
品質不良而無法「如質」時，就重作；
成本超支而無法「如預算」時，就設計變更。
這種「見山就是山」的管理行為，就是專案陷入「治標 不治本」惡性循環的開始。
換個系統腦，進行系統思考
時間、品質、成本就類似於器官，彼此之間互相連動， 如果為了解決「如期」的問題，以致過度加班，有可能發生 成員因疲勞而容易做錯，造成品質不良的現象而無法「如質」；還有，加班要發放加班費，重作也是要花成本的，這些 都會侵蝕專案的利潤，讓專案後續進行無法「如預算」。
這種會互相影響的因果關係，就是系統的必然性。 當專案經理沒有把專案當成系統，或是在解決專案管理 相關問題時，忽略了前述「牽一髮動全身」與「見山非山」的特性，很容易會想出火上澆油的對策，衍生出後遺症或反效果。可是，面對問題時要能「見山非山」、分析問題時要仔 細考慮「牽一髮將會如何動全身」，恰恰不是我們台灣人思考問題的 DNA，有時候反而會被冠上「想太多」、「腦迴路太 複雜」的大帽子。難怪專案對很多人來說，是越管越難管，問題越管越多。
無論你現在管的是三人小專案，還是跨國大專案，唯有 換個系統腦，開始進行系統思考，才能徹底擺脫專案難管的 困境。接下來，我將在各章介紹系統思考如何具體有效地應 用在專案管理的各階修練上。
搞懂投入／產出的因果關係
我們要介紹另一個更好用的工具：ITTO圖，它可以明確地展現所有工作包，相互之間投入／產出的 因果關係，幫助專案經理找出源頭，對症下藥。
ITTO 圖主要包含四大部分：
1. Input 投入
2. Tool 工具
3. Technique 技術
4. Output 產出
因此，在 ITTO 圖中我們會把工作包視為「處理單元」，運作概念為：
1. 投入項目（Input）
2. 經由處理單元內的工具（Tool）
3. 或是技術（Technique）
4. 處理成產出項目（Output）
接下來，我們以「咖哩飯」作為交付標的，製作其工作分解結構，分解後會有三個處理單元（工作包），分別是：
1.1「燉煮」處理單元
1.2「電鍋煮飯」處理單元
1.3「盛盤」處理單元
我以 1.1「燉煮」處理單元，示範說明 ITTO 圖的邏輯：在 1.1「燉煮」處理單元內，「投入」馬鈴薯、洋蔥、肉、咖 哩粉等食材，經由單元內的燉煮「工具」和燉煮「技術」進 行處理，「產出」了咖哩。
由於「投入」與「產出」，具有流進／流出處理單元的 「流量」特性，若是只用箭頭符號（→）難以表達「流量」的 概念，所以引入系統動態學（System Dynamics）裡的流量符號來替代箭頭符號。
系統動態學是由美國麻省理工史隆管理學院的 J.W. Forrester 教授所發展的一門科學，結合了控制、系統論、資 訊理論、決策論、電腦模擬等理論成為一體的管理新方法、 新工具和新概念。系統思考可以視為系統動態學在解決動態 複雜問題時的理解基礎，系統動態學則是把解題的系統思考 圖轉化為具體的數學模型，並進行電腦模擬來協助決策的制 定。由於專案的本質是系統，管專案就是管系統，而且系統動態學與系統思考的關係密切，此為我們引入系統動態學的原因。讀者若對學習系統動態學有興趣，請參考相關書籍， 本書只是借用其流量符號來重新演繹 ITTO 圖。
咖哩醬產出之後，接著在 1.2「電鍋煮飯」處理單元內， 「投入」白米、水，經由單元內的煮飯「工具」和「技術」進 行處理，「產出」白飯。最後，在 1.3「盛盤」處理單元內， 「投入」咖哩醬、白飯，經由單元內的盛盤「工具」和「技 術」進行處理，「產出」交付標的—咖哩飯。
從咖哩飯的 ITTO 圖中，可以具體呈現各個處理單元（工作包），投入／產出相互之間因果關係的全貌。
當交付標的出現問題時，運用 ITTO 圖可以很迅速地找出 根本原因。例如：餐廳的咖哩飯出現負評，透過 ITTO 圖看到 咖哩飯是 1.3「盛盤」處理單元的產出，所以可以先追蹤是不 是 1.3 裡的盛盤「工具」或盛盤「技術」出了問題？
如果並非 1.3「盛盤」處理單元的問題，接著可繼續追蹤 1.3「盛盤」處理單元的投入：咖哩醬、白飯。
由於咖哩醬嚐起來很正常，因此就停止追蹤 1.1「燉煮」 處理單元。然而，白飯吃起來口感不佳，所以繼續追蹤 1.2 「電鍋煮飯」處理單元內的電鍋（工具），是不是出了問題？
由於電鍋在檢查之後沒有發現任何問題，接著就繼續追蹤 1.2「電鍋煮飯」處理單元內的投入：白米、水。最後，發現白飯口感不佳的原因就是水加太多，所以 煮飯時少加點水，負評的問題就此消失。
將「ITTO 圖」轉換「甘特圖」
接下來，我們採用第三章「量身訂做個人化售後服務教 育訓練課程」專案為例，藉由五步驟把 ITTO 圖，轉換成大家 熟知的甘特圖。這樣不僅可以幫助專案經理掌握專案的工作 流程與執行進度，也能知道工作包相互之間的「因果關係」。
甘特圖（Gantt Chart），也稱為條狀圖（Bar Chart），其 設計原則很簡單，基本上就是一個個長條的排列組合，圖形 橫軸表示「時間」，縱軸表示「工作包」或「活動」。 其中，每一項長條，就代表一個工作包，長條的起點與 終點就是工作包開始與結束的時間，主要呈現的就是工作包 的「流程」與「進度」資訊，以確保專案能如期完成。
但是如果發生無法如期、如質、如預算的問題時，甘特圖無法顯示工作包之間的「因果關係」，所以我們很難從中找到問題發生的根本原因。在這種情況下，將 ITTO 圖轉換甘特圖，對於專案經理來說，就是一個很好的工具。
