第三個誤區：把全部希望都寄託在外包廠商那邊。
不少企業在把某項任務外包給其他軟件廠商或者開發公司以後，就會放手不管。就只會在那邊等着讓他們把成品送過來。其實，這是非常危險的。因爲外 包公司由於種種限制，其並不能夠了解你們企業的全部操作方式。如果就讓軟件公司在那邊閉門造車，則最後出現的東西很難保障符合企業的需要。所以我認爲，如 果企業把某個信息化項目外包，不能夠把全部希望都寄託給外包廠商。而是應該自己把好每道任務的關口。
具體來說，筆者建議案如下的方式操作。
首先，應該要求外包廠商把確認好的需求與解決方案通過書面的方式跟我們CIO進行再次確認。因爲口頭確認的內容，很容易引起誤解。而且時間久 了，也很容易遺忘。再說，一個外包項目也不是短時間內可以完成的。如果外包廠商跟企業之間有一些實質性的書面文檔，則對於外包廠商的開發人員來說，也有了 一個對照的依據。同時，即使以後出現分歧的話，也有一個書面文檔的佐證。所以，筆者建議CIO，不要怕麻煩。當把企業的需求交待給外包廠商的話，還要讓對 方出具一份書面的需求文檔，並配上解決方案。這有利於雙方消除分歧。
其次，不要到外包項目完工再進行驗收。而是每完成一項功能或者一個模塊之後，就進行驗收。這主要是因爲，雖然通過前期的交流，再通過書面文檔的 確認，但是仍然無法百分之百的消除彼此的分歧。如果等到產品完成驗收的時候，才發現雙方存在意見的分歧，那麼對於雙方的損失都很大的。對於外包廠商來說， 他們必須對軟件或者解決方案進行修改。由於已經是成品的東西，修改起來就會更加麻煩。而對於企業來說，則就面臨着時間上的損失，時間成本會增加。故如果在 成品完成階段才進行驗收的話，對於雙方都是不利的。筆者如果把一個項目外包給其他合作伙伴的話，則會對整個過程進行追蹤。如筆者會讓對方在每個週末把本週 完成的任務跟我說。然手把這個月完成的成果先交給我。然後筆者進行測試。若發現問題的話，馬上跟對方聯繫，讓對方進行修改。如此的話，效果會比較好。一方 面筆者可以在程序開發的時候就發現一些不滿意的地方或者對方誤解的地方，提出來讓對方修改。如此的話，到了成品交付的時候，成品的缺陷會少許多。另一方 面，通過對方每週一報，可以讓筆者瞭解項目的進度。如果項目沒有按進度進行的話，筆者就會馬上督促對方。 這有利於項目在規定時間內完成。
最好，需要讓對方提供項目文檔。如前不久筆者委託一家軟件公司，幫助我們完善一些ERP系統中的功能。事先筆者就要求他們，必須把ERP系統中 修改的內容，以書面的文檔記錄下來。如要實現某個功能，在ERP系統中修改了哪些地方;在數據庫中是否增加了內容;你們是如何進行測試的;對其他作業的影 響等等。每完成一個功能的開發，就需要把這份文檔交付給我們。也就是說，他們的工作成果，不僅僅是成品而已;還有中間所產生的文檔。因爲筆者必須要了解這 中間發生了什麼事情，功能是如何實現的。這對於筆者日後維護ERP系統是非常重要的。而且當出現問題的時候，筆者還可以藉此判斷這是否是對方的二次開發所 造成的。
所以，筆者建議各位CIO，如果你們要把某個項目外包的話，則最後的成果既然重要，但是也不能夠小瞧中間的過程。若不對中間的每一道過程進行把 關的話，則很難保障最後成果的質量。最重要的是，如果對方不提供中間實現過程的文檔，那麼對於CIO日後維護來說，會有很大的難度。總之，不能夠把全部希 望都寄託在外包廠商那邊，CIO要跟蹤整個外包過程。
