隨著企業(yè)開始采用云計算、移動和物聯(lián)網(wǎng)等技術(shù)，與數(shù)據(jù)中心相關(guān)的項目不斷增多。這些項目可能包括遷移到云，關(guān)鍵業(yè)務(wù)應(yīng)用程序重要升級，服務(wù)器品牌變更或新款基礎(chǔ)設(shè)施管理工具。

雖然這些變化可能改善業(yè)務(wù)，但也同樣存在著巨大風(fēng)險。17%的IT項目預(yù)算在1500萬美元甚至更高，以至于威脅到企業(yè)生存，因為他們確實經(jīng)濟拮據(jù)，參考自McKinsey&Company顧問公司2012年的調(diào)查結(jié)果。毫不夸張的說，公司未來成功或失敗，與下一個主數(shù)據(jù)中心升級息息相關(guān)。幸運的是，管理者可以采取一些正確方法來確保數(shù)據(jù)中心項目計劃的成功。

設(shè)置初始基調(diào)

第一個也是最苦難的步驟就是設(shè)定明確的預(yù)期。企業(yè)需要將關(guān)于新業(yè)務(wù)機會或潛在內(nèi)部改進(jìn)的想法轉(zhuǎn)換為書面形式，以項目定義和管理文檔開始。這些文檔將項目分為不同的類別，如基于項目規(guī)模分為大、中、小，并且系統(tǒng)規(guī)格與交付大綱。這些往往可以通過商業(yè)化工具實現(xiàn)，如Altassian的JIRA、Celoxis或Microsoft Project。文檔越清晰，公司項目成功的機會越大。

IT可能會跳過規(guī)劃而直接進(jìn)入過程。這樣的行動是錯誤的。開發(fā)周期中花費1美元的變更，可能在生產(chǎn)環(huán)境系統(tǒng)中造成10,000美元的影響，根據(jù)顧問公司Scott Ambler + Associates的調(diào)查。每個涉及新數(shù)據(jù)中心項目計劃的人都必須從頭開始完成規(guī)劃。

任何重大改革的范圍都遠(yuǎn)超IT部門范圍。如果要建造新數(shù)據(jù)中心，IT必須與設(shè)施管理單位交互。如果工資應(yīng)用程序正在經(jīng)歷重大重寫，IT需要和財務(wù)部門協(xié)作。

IT嚴(yán)格控制技術(shù)采購的日子已經(jīng)一去不復(fù)返。隨著云計算和其他消費者級別技術(shù)，業(yè)務(wù)部門經(jīng)理可以很容易地繞過數(shù)據(jù)中心員工。數(shù)據(jù)中心經(jīng)理需要民主而不是獨裁，與業(yè)務(wù)經(jīng)理合作，以提升數(shù)據(jù)中心基礎(chǔ)設(shè)施。

把控數(shù)據(jù)中心項目規(guī)劃細(xì)節(jié)

數(shù)據(jù)中心經(jīng)理需要知道在發(fā)生重大變化時如何反應(yīng)，如增加新服務(wù)器或延期一個月交付時間表等。項目經(jīng)常因為團隊收到了一個原本不是業(yè)務(wù)要求內(nèi)的需求而無法按時交付——這也就是范圍蔓延。

例如，業(yè)務(wù)單元要求改變用戶界面。需要在數(shù)據(jù)庫中增加一行，并且將用戶數(shù)量從25增加到28。一系列小變更不斷積累，會對項目造成嚴(yán)重的影響。這個問題在依賴于DevOps的組織更放大——他們更專注于制造快速、小規(guī)模變更，而不是將他們在主版本中一起發(fā)布。要避免范圍蔓延，數(shù)據(jù)中心經(jīng)理需要追蹤微小變更，并且為其建立指標(biāo)，以衡量其累積效應(yīng)。

其他警示信號可能預(yù)示著數(shù)據(jù)中心項目計劃將面臨困難，如與計劃表的小方差或增加預(yù)算。有時候，數(shù)據(jù)中心員工可能認(rèn)為很快就能縮短差距，但不久之后出現(xiàn)的新的、未知的問題使得差距越來越大。如果目前項目進(jìn)度不佳，數(shù)據(jù)中心員工需要盡快做出調(diào)整。IT忽視的時間越長，問題規(guī)模和之后減少最終損壞的挑戰(zhàn)就越大。

IT經(jīng)理們必須確保項目失敗或失誤不會導(dǎo)致大家都丟掉飯碗。隨著數(shù)據(jù)中心系統(tǒng)成為核心業(yè)務(wù)的依賴，數(shù)據(jù)中心經(jīng)理必須將需求覆蓋范圍延伸到整個組織。