個人屬於政府部門，為了做好系統運維的外包，因此考慮在投標商專案經理的資格設限，要求廠商指派的專案經理應取得經濟部ITE專案管理職類的認證，以便工作的溝通協調有一定的基礎，同時在問題發生時，可以做最佳的處理。為此個人也參加了最近一次的考試，以瞭解題型，俾考慮設限的適當性。

專案管理職類的考試區分為專案管理及軟體專案管理兩項。個人觀察，這兩項考試很重視理論，更奇怪的是軟體專案管理的試題中，出現了許多CMMI的觀念題目，而且比例還不低。

基本上，管理理論的來源，多半是經過對實際問題的觀察、田野調查、歸納、演繹等，而得到理論，有些管理理論放到實體世界時，如果條件不同，將得不到預期的效果。另外，一些理論的出現還有其時空因素，經過一段時間會修改、甚至於消失，不再受到人們的重視。但這些理論，在ITE認證中是否該考？個人認為是值得審傎逐項考慮的。專案管理最主要談如何儘可能做到「如期、如質、如預算的」完成專案，這裡會有許多技術的應用，這些技術有些是作業研究的結果、有些是財務管理、人力資源管理......。但認證考試考理論的內容是不恰當的，因為理論的陳述只是某位名家的想法或看法，想想，對於流派林立的管理學領域，誰講的話才算數？就以General Management來說，管理學有幾個基本的Functions，學者都有多種不同的區分，這種狀況，到書店或圖書館裡對照幾本著作，就可發現。這些名家過往的理論陳述，經過數年或數十年的時空變換，是否還是成立、適用？倒不如回歸到技術的應用上來，多考一些專案管理的技術應用。

另外，對於軟體專案管理，國際標準考得很少，還考到早已廢止多年的標準IEEE Std 729(IEEE 的軟體工程標準彙編裡根本找不到這個標準)，但卻考了許多軟體組織管理評鑑的模型--CMMI。這兩年CMMI在台灣雖然逐漸受到重視，但對於一個沒有通過CMMI的公司，光拿者CMMI中Stage Representation Level 2及Level 3的Practice去做專案是行不通的，因為這個Model是個Road Map，用這個Model做評鑑，是告訴被評鑑的單位，在成為高能力成熟度組織的路上，你的位置在那裡，接下來你要怎麼走才能夠具備更高一級的能力成熟度。所以，因為目的不同，所以個人以為在ITE的軟體專案管理是不應該考CMMI的。我們不能以CMMI取代軟體工程管理，這是相當危險的，想想，以國際標準組織來說，他們定出了ISO/IEC 12207軟體生命週期過程標準，卻還定出了ISO/IEC 15504軟體過程評鑑標準，另外還有ISO/IEC 15288生命週期管理--系統生命週期過程，也沒有拿15504取代12207的走向，反而因應15504中的評鑑需要，而不斷在補充12207，因為兩者的目的是不同的。ITE的軟體專案管理部分，個人以為它的方向應該是要設法測試出，受測人員是否有能力結合需求、軟體生命週期模型，做出專案的軟體生命週期過程，經由專案的SLCP分出WBS，做出成本計畫、資源分配計畫、時程表等等的決策，另外就是如何結合驗證與確認技術、測試、軟體審查做好軟體品質保證，這些作為最好是依循國家標準、ISO或IEEE的標準而來，(為何採用標準？因為標準中列的可都是工作的最低要求)。

ITE應該多考些實務上的東西，理論的東西就留給在校學生或研究生做研究時研讀會比較恰當。否則，只懂理論的東西，到了真正做專案時，大概只能打高空而已，對於做好專案是沒有幫助的。