Data Vault 2.0方法的項目規劃能力來自PMP。與敏捷的Scrum方法不同，它強調sprint中正式的項目計劃。每個項目都有壹個項目計劃:包括要完成的任務，作為任務輸出的預期結果，以及將執行任務的角色。根據項目的類型，有不同類型的角色來執行項目:
業務發起人:應該在項目、業務和遠景之間建立壹致性。
技術業務分析師:向業務部門匯報，但具有壹定技術技能的高級用戶，包括了解數據模型和直接使用或編寫SQL的能力。
項目經理:負責確保項目團隊完成項目。
IT經理:確保業務連續性和業務成功。
ETL開發人員:負責提取、轉換和加載(ETL)過程的開發人員。
報表開發人員:基於信息集市、業務倉庫表或者(在極少數情況下)直接在原始數據倉庫上實現業務驅動的報表。
數據架構師/信息架構師:負責信息架構和數據集成。
元數據管理員:負責元數據的構建。
變更管理人員:確保新功能在啟動時不會幹擾其他IT或業務服務，還負責確保新的發布可以在環境中進行，並且不會受到其他項目的阻礙。
許多組織錯誤地將責任分配給人，而不是定義角色。在團隊中定義壹個角色的好處是，這個角色中的人可以被另壹個技術熟練的人替代——例如，如果當前的人離開組織或者改變項目。角色定義在許多方面對組織有幫助:這些角色定義幫助人力資源部門在自由市場中為工作找到合適的人；新員工有可能快速確定自己的職責，完成自己應該完成的工作；最後，清晰的職責可以幫助團隊在處理開發項目中自然出現的問題時決定誰將做什麽。
在數據倉庫中，項目團隊已經知道所呈現的大多數角色。技術業務分析師是個例外。這個角色充當業務和IT之間的中間功能。圖3.2給出了關於這個角色的特征和職責的更多信息。
由於這個角色介於業務和IT之間，技術業務分析師的工作就是緩和雙方的關系，防止雙方之間出現“翻墻”的心態。這種雙方互不理解，互相支持共同努力的心態，往往是項目失敗的根本原因。這類項目的特點是業務需求不明確，技術工件不符合業務需求，不符合IT所理解的需求，以及未測試或測試不完整(從業務角度)導致的軟件不可靠。通常雙方都會互相指責，雙方都非常確信對方犯了錯誤。
這就是為什麽Data Vault 2.0團隊不建議將業務角色與IT角色分開。相反，這兩個群體應該合作，每個角色都應該註意自己的職責。如果可能的話，團隊應該在同壹個地方工作以提高效率。重要的是在業務和IT之間以及每個角色之間建立壹定程度的協作和相互理解，以防止出現上壹段中概述的情況。這是項目經理的責任。如果團隊在項目過程中開始分離，他們需要持續的行動。
需要從業務方面建立的部分理解是，在為期兩周的沖刺階段，我需要壹種相對不受日常問題影響的工作方式。運營中的問題壹定要安排在下壹次沖刺。為了實現這壹點，IT部門也必須改變他們的想法:他們的工作應該是讓業務部門在沒有IT部門參與的情況下自己解決壹些(如果不是大多數)問題。這就是“受管的”自助服務商業智能(BI)發揮作用的地方。Data Vault 2.0標準為IT部門提供了如何以業務用戶可以自己使用的方式提供數據的指南。這就需要把責任轉移到企業身上。例如，它不應該負責修復企業數據倉庫中的數據，以彌補業務系統中的錯誤。修復這些錯誤是業務部門的責任，以便IT部門可以通過數據倉庫將數據發送回業務部門，在那裏他們可以應用業務規則將數據轉換為信息。它將使用這些知識來標準化常用的信息集市。
為了防止任何中斷，系統需求的變更需要壹個既定的過程。圖3.3展示了這個DataVault2.0需求變更的溝通過程。
圖3.3溝通流程3.3 DataVault2.0需求變更
新的變更請求通常來自項目的業務方面。它需要評估風險和對當前生產系統的影響。這就是為什麽變更請求從業務用戶通過發起人(他們決定需求變更的優先級)和技術業務分析師(他們幫助將業務需求轉化為技術項目)傳遞給負責調度的IT經理和項目經理。當它完成風險評估時，它將這些信息返回給業務部門，這樣他們就可以根據風險和影響評估做出是否實現需求變更的最終決定。如果業務部門決定繼續處理需求變更，IT部門將根據業務部門之前的優先級，在下壹個沖刺階段安排需求變更。然後，他們負責新工件的開發和後續交付。在業務人員對變更進行了測試(開發測試除外)並接受了變更後，正式的簽署將使IT部門從該需求變更的更多責任中解脫出來。
在開發新版本的數據倉庫系統時，開發團隊使用與傳統軟件開發團隊相同的方法。他們在開發過程的早期使用Alpha (Beta)版本來測試新版本，beta (beta)版本易於針對有限的業務受眾進行測試，並制作了Gamma(候選)版本。Alpha (beta)版本應該只影響技術團隊成員，直到技術業務分析師。
除了技術IT團隊，在Alpha版本中通常還有3到5個技術業務分析師。當IT部門向分析師發布新的報告時，應該明確指出這些報告不打算分發給業務部門，因為報告或立方體(數據集)中的信息可能是錯誤的，甚至是不好的。然而，技術業務分析師將會收到這些報告，以幫助他們找到這些錯誤或識別誤算。在數據倉庫項目的最初兩三次沖刺之後，通常會將Alpha版本分發給技術業務分析師。
壹旦新版本達到測試狀態，它將顯示給更多的技術業務分析師、業務發起人、選定的業務經理和其他對新版本的功能有既得利益的用戶。
測試版已經過IT和業務代表的全面測試，不再包含任何明顯或已知的錯誤。但是，由於發布狀態的性質，生成的報告仍然不適合流通。相反，有限的團隊使用這些報告來識別開發和技術業務分析師到目前為止還沒有識別出的問題。如果有限的團隊同意產品發布的準備工作，數據倉庫系統將進入Gamma(候選)狀態。
Gamma或生產版本已部署並提供給所有業務用戶。此方法嚴格遵循CMMI，它是Data Vault 2.0方法的壹部分。後續文章介紹Data Vault 2.0的CMMI方法。