#title 기획과 프로젝트 관리
[[TableOfContents]]

==== 장의 목표 ====
 * 데이터 웨어하우스를 위한 기획의 본질적인 요소를 검토한다.
 * 데이터 웨어하우스 프로젝트와 OLTP 시스템 프로젝트를 구별한다.
 * 데이터 웨어하우스 프로젝트를 위한 생명 주기 접근법을 적응시키는 방법을 배운다.
 * 프로젝트 팀 조직, 역할 그리고 책무를 논의한다.
 * 경고 신호의 성공 요인을 숙고한다.

업계 전문들에 따르면, DW 프로젝트의 50% 이상은 실패로 간주된다. 많은 경우에 프로젝트는 종료되지 않는다. 프로젝트가 어떻게든 완성되어도 그 데이터 웨어하우스는 데이터 지하실(basement)로 판명난다. 실패한 프로젝트는 부적절하게 규모가 잡히고 설계되고, 사업과의 Alignment 시키지 못했다. 

==== 데이터 웨어하우스 기획 ====
기획과 프로젝트 관리는 다른 어떤 요인보다 더 실패에 이르게 한다. 데이터 웨어하우스를 구축하기 위해서는 다음과 같은 물음에 답을 할 수 있어야 한다. 
 
 * 정말 데이터 웨어하우스가 필요한가?
 * 정말 데이터 웨어하우스 프로젝트를 위한 준비가 되었는가?
 * 데이터 웨어하우스로부터 기대되는 가치를 평가하는 기준은 개발되었는가?
 * 구축될 데이터 웨어하우스의 형태와 그것을 어디에서 유지할 것인가?
 * 데이터를 어디에서 가져와야 하는가? 
 * 모든 필요한 데이터를 가지고 있는가?
 * 누가 데이터 웨어하우스를 사용할 예정인가?
 * 그들이 언제 어떻게 데이터 웨어하우스를 사용할 것인가?

===== 기본적인 이슈 =====
 * 가치와 기대(Value and Expection) - 출발점
  * 데이터 웨어하우스로의 가치평가 후 구축을 진행해야 한다. 
  * 데이터 웨어하우스의 적합성 수립 후, 이익과 가치를 열거해야 한다.  
  * 이익과 가치
   * 더 좋은 기획, 더 나은 의사결정에 도움을 줄 수 있는가?
   * 순이익을 개선시킬 수 있는가?
   * 시장점유율 또는 고객점유율을 증가시킬 수 있는가? 얼마나 많이?
   * 예상되는 것은 무엇인가? 
   * 데이터 웨어하우스를 통하여 무엇을 달성하기를 원하는가? 
  * 현실적인 이익과 예상되는 목록의 작성 -> 이것이 데이터 웨어하우스의 출발점.
 * 위험평가
  * 데이터 웨어하우스가 끌어낼 수 있는 이익이 없어도 회사에 직면하는 위험들은 무엇인가?
  * 어떤 손실들이 발생할 수 있는가?
  * 어떤 기회들을 놓칠 수 있는가?
  * 위험평가서를 기획 문서에 포함시켜라
 * 하향식 or 상향식
  * 전체적인 기업 수준에서 필요조건들을 먼저 계획하고 정의해야 한다.
  * 사업적인 필요에 따라서 하향식 또는 상향식을 결정한다. 
  * 기획 문서에는 어떤 방식을 사용하던지 합당한 이유를 설명해 놓아야 한다. 
 * 구축 또는 구매
  * 각 구성요소에 대한 써드파티 도구와 솔루션과 조직내에서 작성된 소프트웨어는 적절한 균형을 이루어야 한다. 
  * 은 탄환은 없다. 핵심 요소는 사전 조사를 하는 것.
 * 단일 벤더 또는 최고의 제품(다수 벤더)
  * 단일 벤더
   * 도구들 사이의 높은 수준의 통합
   * 일정한 관점과 느낌
   * 구성 요소들 사이의 무리 없는 협동
   * 중앙에서 관리되는 정보 교환
   * 전체 가격 조정가능
   * 몇 개의 벤더만이 충분히 통합된 솔루션들을 제공하므로 주의해야 한다. 
  * 다수 벤더
   * 조직의 환경에 맞게 구축할 수 있다.
   * 데이터베이스와 지원 도구들 사이를 절충할 필요가 없다
   * 기능에 제일 맞는 제품들을 선택한다
   * 호환성이 심각한 문제가 될 수 있다. (호환성 확인이 필수)
   * 벤더의 지구력(생존력, 벤더가 도산하면 지원이 불가능하다) 확인
   * 구매 교섭력이 줄어들고, 높은 비용이 발생할 수 있다.
 * 권장방법
   * 데이터베이스와 정보 전달 기능을 위한 한 벤더를 선정한다.
   * 나머지 기능들을 위한 다른 벤더들을 뽑아서 선택한다.
   * 환경이 아주 기술적이지 않다면 다수 벤더 접근법은 권장 사항이 아니다.

===== 기술이 아닌, 사업 요구사항 =====
데이터 웨어하우스 구축은 기술주도가 아닌, 사업 요구사항들에 의해 추진되어야 한다. 데이터 웨어하우스는 기술에 관한 것이 아니다. 데이터 웨어하우스는 전략 정보를 위한 사용자들의 요구를 해결해 주기 위한 것이다. 요구사항을 이해하기 전에 데이터 웨어하우스를 구축할 계획을 세우지 말아야 한다. 어떤 정보가 필요한지에 대한 초점을 맞추어 시작하고 정보를 어떻게 제공하는지에 대한 초점을 맞추지도 말아야 한다. 도구들은 강조하지 말아야 한다. 

전체 계획을 세우기 전에 예비 조사를 실시해야 한다. 상세한 것은 필요치 않다. 단지 사용자들의 전체 요구사항들을 이해하려고 노력하면 된다. 예비조사는 사업의 넓은 이해를 얻고, 프로젝트의 범위를 결정하는 것의 근거가 된다. 또한 개개의 데이터 마트들에 대한 공개 계획을 정하고 우선순위를 매기는 것을 도울 것이다. 다음은 예비조사에서 수집되어야 하는 정보들이다. 

 * 각 사용자 그룹의 임무와 기능들
 * 그 그룹에 의해 사용되는 컴퓨터 시스템들
 * 기본적인 성과 지표들
 * 사용자 그룹의 성공에 영향을 주는 요인들
 * 고객들이 누구이며, 그들이 분류되는 방법
 * 개인적이거나 그룹별로 고객들을 추적한 데이터들의 형태들
 * 제조되거나 판매된 제품들
 * 제품들과 서비스들의 범주
 * 사업이 시행되는 위치들
 * 고객별, 제품별, 구역별로 측정되는 이익의 수준들
 * 비용 명세와 소득수준들
 * 전략 정보를 위한 현재 질의들과 보고서들

또 다른 예비조사의 부분으로 소스 시스템의 구조를 검토하는 부분이 있다. 전체 계획에 소스 스스템들에 대한 정보를 포함해야 한다. 

 * 데이터 품질 부분
 * 문서화 부분
 * 데이터 추출 메커니즘

===== 최고 경영진의 지원 =====
데이터 웨어하우스 프로젝트는 고위 경영진의 지원 없이 성공할 수 없다. 이것은 사실이다. 전체 기업의 정보 관점을 통합하는 다른 모험적인 프로젝트는 없다. 전체 조직은 전략적인 이익을 위해 필요로 하고 위치해야 한다. 프로젝트가 중심을 유지하기 위해서 경영진의 최고위직으로부터 후원을 받는 것을 확인하라. 

===== 데이터 웨어하우스 정당화 =====
데이터 웨어하우스의 ROI를 계산해 내는 것은 쉽지 않다. 또한 모든 경영진이 만족해하지 않는다. 다음은 데이터 웨어하우스의 정당화 표본 접근법이다. 

 * 방법1
  1. 현재 전략적 의사결정을 지원하는 어플리케이션과 보고서들 산출하는 기술의 비용 계산 
  1. 데이터 웨어하우스를 위한 견적 비용과 비교 -> 비율찾기
  1. 비율을 고위 경영진이 수락할만한지 알게 한다.
 * 방법2
  1. 데이터 웨어하우스의 사업 가치를 계산(이익, 배당금, 임금 성장, 소득 성장, 시장 점유 성장)
  1. 사업 가치를 검토하여 정화를 찾아낸다.
 * 방법3
  1. 데이터 웨어하우스에 의해 영향 받을/주는 모든 구성요소 확인
  1. 하드웨어 구매, 벤더 소프트웨어, 개발된 소프트웨어, 유지보수 비용들에 대한 비용 산출
  1. 비용 감소, 소득 증진, 그리고 유효성을 포함한 유/무형의 이익들에 대한 가치 평가
  1. 현금 흐름 분석하고 ROI 계산

DW 정당성의 주장
본질적인 사업 목표와 연결 -> 조직이 목표를 달성하는데 어떻게 도움주는가 보여주면 된다. 

Critical Sucess Factor of DW
사용자가 정보를 찾을 수 있게 잘 도와주는 것이 데이터 웨어하우징의 결정적인 성공요인
===== 전체 계획 =====
여기서 말하는 전체 계획은 기초를 다지고, 요구를 인지하고, 전체 프로젝트를 인가하는 전체 계획이다. 다음은 전체 계획에 포함될 내용들이다. 
 * Introdution
 * Mission Statement
 * Scope
 * Goals & Objectives
 * Key Issues & Expectations
 * Justification
 * Executive Sponsorship
 * Implementation Strategy
 * Tentative Schedule
 * Project Authorization

==== 데이터 웨어하우스 프로젝트 ====
데이터 웨어하우스의 주요 구성요소
 * 데이터 획득 구성요소
 * 데이터 저장장치 구성요소
 * 정보 전달 구성 요소

데이터 웨어하우스 프로젝트의 특성(OLTP 시스템 개발 프로젝트와 비교했을 때)
 * 더 넓은 범위를 갖고, 더 복잡하게 될 경향이 있고, 다른 기술들을 수반한다.
 * 새로운 형태의 활동들을 위해 특별한 시간과 노력을 고려
 * 전문가가 없을 경우 아웃소싱은 일상적이다.
 * 메타데이터는 특별한 취급을 필요로 할 만큼 중요하다.
 * 써드파티 도구를 사용하고, 도구들의 평가와 선택을 위한 시간이 계획에 포함된다.
 * 기반구조를 만들고 완성하도록 막대한 시간을 허용한다
 * 구조 설계를 위한 충분한 시간을 포함한다
 * 프로젝트의 모든 단계에서 사용자들을 관련시킨다. 기술과 사업의 상호협력은 절대적으로 필요하다.
 * 도구들에 있어서 사용자들을 훈련시키는 충분한 시간을 허용한다.
 * 프로젝트에서 많은 작업들 때문에, 병렬 개발 트랙은 절대적으로 필요하다. 프로젝트 생명 주기에서 병렬 트랙을 수행하는 도전에 대해 준비

===== 준비의 평가 =====
준비 평가 보고서의 목적
 * 구현 중에 일어나는 중대한 뜻밖의 일들의 위험을 낮춘다.
 * 문제 해결에 사전 행동 접근법을 제공한다.
 * 공동의 약속을 재평가한다.
 * 프로젝트 범위와 크기를 검토하고 재확인한다.
 * CSF[* Critical Sucess Factor]을 확인한다. 
 * 사용자의 기대를 재진술한다. 
 * 훈련 요구들을 알아낸다. 

===== 생명주기[* System Development Life Cycle] 접근법 =====
생명주기 접근법의 장점
 * 질서 정연함을 강요한다. 
 * 체계적인 접근법이 컴퓨터 시스템 구축을 가능하게 한다. 
 * 프로젝트의 복잡도를 분석하여 프로젝트 팀 맴버들의 책에 관해서 모호성을 제거한다. 
 * 예측할 수 있는 작업들 세트와 도달 가능함을 의미한다. 

전통적인 개발방법은 Waterfall Method가 아니다. 데이터 웨어하우스는 정련의 순환[* Cycle Of Refinement]을 통해 반복되는 작업을 포함해야 한다. 
attachment:기획과프로젝트관리/dw_project01.jpg

프로젝트 계획서의 Sample 개요는 다음과 같다. 
 * 도입(Introduction)
 * 목적(Purpose)
 * 준비의 평가(Assessment Of Readiness)
 * 목표와 목적(Goals & objectives)
 * 이해관계자(Stakeholders)
 * 가설(Assumptions)
 * 필수 이슈(Critical Issues)
 * 성공 요소(Sucess Factors)
 * 프로젝트 팀(Project Team)
 * 프로젝트 스케줄(Project Schedule)
 * 진행단계 상세(Deployment Details)

===== 개발 단계 =====
데이터 웨어하우스의 기능적 구성요소인 데이터 획득, 저장, 전달 구성요소를 지원하기 위한 적합한 기술적인 기반구조가 필요히다. 그러므로 개발단계에서는 이 3가지의 구성요소들과 관계되는 작업들이 포함되어야 한다. 특정한 요구사항에 3가지 트랙 중 1가지 트랙을 강조할 수 있다. 예를 들어 데이터 품질이 문제라면 관련된 단계에 관심을 둘 필요가 있다. 

==== 프로젝트 팀 ====
다른 소프트웨어 개발과 마찬가지로 데이터 웨어하우스 프로젝트도 사람-집중적이다. 프로젝트의 성공은 사람에 달려있다. 프로젝트 팀을 구성하는 것은 적절한 기술과 경험의 수준들을 가진 다양한 역할에 어울리는 사람들 찾아내야 한다. 쉬운 것은 아니다. 

다음의 2가지는 프로젝트를 깨뜨릴 수 있다. 

 * 복잡도의 과부하
 * 책임자의 모호성

복잡도의 과부하는 프로젝트 팀의 팀원 각각 기술력과 경험수준을 고려하여 각각의 작업에 적절히 할당하는 것으로 최소화 할 수 있다. 또한 기술력과 경력에 근거한 역할 및 책임을 가짐으로써 책임자의 모호성을 제거할 수 있다. 

===== 프로젝트 팀의 조직 =====
팀을 조직하는 것은 적재적소에 사람을 배치하는 것이다. 하지만 OLTP성 프로젝트와는 다른 많은 역할을 필요로 하게 된다. 다양한 역할들을 모두 충족시켜주기 위한 출발점으로 필요로 하는 모든 프로젝트 난제들과 전문 기술들을 목록으로 만드는 것이다. 목록은 다음과 같을 것이다. 

 * 계획
 * 데이터 요구사항 정의
 * 질의 유형 정의
 * 데이터 모델링
 * 도구 선택
 * DB 설계
 * ETL 설계
 * 데이터 품질
 * 메타데이터 프레임웍
 * 기타등등

다음으로 기술들과 예상되는 난제들의 목록을 작성하는 것이다. 목록을 작성하면 프로젝트 진행을 위한 내부자원, 외부자원을 끌어오면 된다. 

프로젝트 팀의 결정적인 특성
 * 팀 멤버에게 중요한 것
  * 기술
  * 경험
  * 지식
 * 비슷하게 중요한 것
  * 자세 
  * 팀 정신
  * 데이터 웨어하우스 노력에 대한 열정(passion)
  * 그리고 강력한 서약 


===== 역할과 책임 =====
역할과 직무 직함의 분류 방법
 * 분류: 
  * 초기 개발을 위한 직원을 둠, 
  * 검사를 위한 직원을 둠, 
  * 계속 진행되는 관리를 위한 직원을 둠, 
  * 데이터 웨어하우스 관리를 위한 직원을 둠 
 * 넓은 분류: 
  * IT와 최종-사용자, 
  * 그런 다음에 두 개의 넓은 분류들의 각자에 속한 하위분류들, 
  * 더 세부적인 하위분류들이 따른다 
 * 분류: 전위 사무실 역할, 후위 사무실 역할 
 * 분류: 지도원, 정규 사원, 특별 팀 
 * 분류: 관리, 개발, 지원 
 * 분류: 경영, 데이터 획득, 데이터 저장, 정보 전달 

팀 역할들의 기본 세트
 * 임원급 후원자(Executive Sponsor) 
 * 프로젝트 관리자(Prject Manager) 
 * 사용자 섭외 관리자(User Liaison Manager) 
 * 선도 구축기사(Lead Architect) 
 * 기반구조 전문가(Infrastructure Specialist) 
 * 사업 분석가(Business Analyst) 
 * 데이터 모델러(Data Modeler) 
 * 데이터 웨어하우스 관리자(Data Warehouse Administrator) 
 * 데이터 변환 전문가(Data Transformation Specialist) 
 * 품질 보증 전문가(Quality Assurance Analyst) 
 * 시험 조정자(Testing Coordinator) 
 * 최종-사용자 응용 전문가(End-user Application Specialist) 
 * 개발 프로그래머(Development Programmer) 
 * 지도 훈련자(Lead Trainer)

역할과 책임
attachment:기획과프로젝트관리/RnR.jpg

===== 기술과 경험 수준 =====
attachment:기획과프로젝트관리/SkillnExp.jpg

===== 사용자 참여 =====
사용자들은 데이터 웨어하우스 프로젝트 팀의 일부이어야 한다. OLTP 시스템 프로젝트보다 더 많이, 데이터 웨어하우스 프로젝트는 진지한 합동 응용 개발(JAD) 기법들을 요구한다. 사용자의 적절한 멤버가 특정한 역할을 하는 팀 멤버로 수락하는 경우에만 성공할 것이다.

 * 사업에서 그들의 전문 의견과 지식을 사용하라. 
 * 사업 결정들을 할 적에 그들의 경험에 박자를 맞추어라. 
 * 그들을 정보 전달 도구들의 선정에서 활동적으로 관련시켜라. 
 * 완성하기 전에 시스템의 시험에서 그들의 도움을 구하라. 

사용자들이 개발에서 참여할 수 있는 팀 역할들의 목록 
 * 프로젝트 후원자 - 내내 프로젝트 노력을 지원하는 데 책임이 있는 임원 
 * 사용자 부서 섭외 대표자 - IT에게 회의를 중재하고 세션을 검토하는 것을 도와준다; 사용자 부서들에 의한 능동적 참여를 보장한다 
 * 주제 영역 전문가 - 특정 주제 영역에서 사용자들의 요구사항에서 가이드라인을 제공한다; 기업에서 사용되는 사업 용어들의 의미론상의 의미를 분명하게 한다. 
 * 데이터 검토 전문가 - IT에 의해 준비된 데이터 모델들을 검토한다; 데이터 요소들과 데이터 관계성을 확증한다 
 * 정보 전달 컨설턴트 - 정보 전달 도구들을 검사하고 시험한다; 도구 선정을 조력한다 
 * 사용자 지원 기술자 - 그들 각자의 부서에서 사용자들을 위해 첫 번째-수준으로 전위 지원자로 활동한다 

==== 프로젝트 관리 고려사항 ====
실패 시나리오
 * 데이터 창고 - 데이터 품질이 낮아 사용하지 않음
 * 데이터 무덤 - 데이터 품질도 낮고, 성능이 떨어져 접근하지 않음
 * 데이터 집 - 데이터 사용자의 요구사항이 반영되지 않음
 * 데이터 판자집 - 형편없는 데이터 덤프가 완료되기 전에 무너짐(?)
 * 데이터 별장 - 통합되지 않은 데이터
 * 데이터 교도소 - 쓰지도 못하게 데이터를 가두어 둠.

===== 안내원칙 =====
OLTP 시스템의 프로젝트 관리에서 안내 원칙들
 * 분석 마비(analysis paralysis)에 빠지지 마라
 * 범위를 조금씩 미끄러져 나가게 하지 마라
 * 지연을 감시하라
 * 프로젝트가 트랙에 있도록 유지하라
 * 기타등등

DW 프로젝트 관리에서 안내 원칙들
 * 후원(Sponsorship) - 데이터 웨어하우스는 유력하고 헌신적인 임원의 후원이 없으면 성공하지 못한다. 
 * 프로젝트 관리자(Project Manager) - 사용자-중심적이고 사업-중심적인 것보다 더 기술-중심적인 사람을 프로젝트 관리자로 두는 것은 심각한 잘못이다. 
 * 새로운 패러다임(New Paradigm) - 데이터 웨어하우징은 대부분의 회사들에게 새롭다; 혁신적인 프로젝트 관리 방법들은 예상치 못한 난제들을 처리하는 데 필수적이다. 
 * 팀 역할(Team Roles) - 팀 역할은 임의로 배정되지 않는다; 그 역할은 각 개개의 데이터 웨어하우스 프로젝트의 요구들을 반영해야 한다. 
 * 데이터 품질(Data Quality) - 데이터 웨어하우스에서 세 개의 결정적인 양상은: 품질, 품질, 그리고 품질이다. 
 * 사용자 요구사항(User Requirements) -비록 명백하지만, 사용자 요구사항들만으로 프로젝트 예정표에서 모든 작업의 추진력을 형성한다. 
 * 성장을 위한 구축(Building for Growth) - 사용자들의 수와 질의들의 수가 배치 후에 아주 빠르게 치솟는다; 성장을 위한 구축을 하지 못한 데이터 웨어하우스는 빠르게 망할 것이다. 
 * 프로젝트 정치(Project Politics) - 회사에서 첫 번째 데이터 웨어하우스 프로젝트는 다른 수준에서 사용자들에게 도전과 위협을 주게된다; 프로젝트 정치를 다루는 것은 극도의 조심으로 걸어가는 유명한 줄타기 줄을 타는 것과 같다. 
 * 현실적인 기대(Realistic Expectations) - 첫 번째 데이터 웨어하우스 프로젝트에서 그 세계를 약속하는 것은 쉽다; 올바르고 달성할 수 있는 수준들에서 기대를 설정하는 것은 최선의 방침이다. 
 * 차원 데이터 모델링(Dimensional Data Modeling) - 잘-설계된 차원 데이터 모델은 요구되는 기초와 청사진이다. 
 * 외부 데이터(External Data) - 데이터 웨어하우스는 내부 데이터만으로 생존하지 못한다; 관련된 외부 소스들로부터 온 데이터는 절대적으로 필요한 재료이다. 
 * 훈련(Training) - 데이터 웨어하우스 사용자 도구들은 서로 다르고 새로운 것이다. 만약 사용자들이 그 도구들을 사용하는 방법을 모른다면, 그들은 데이터 웨어하우스를 사용하지 않을 것이다. 사용 안되는 데이터 웨어하우스는 실패한 데이터 웨어하우스이다.  

===== 경고신호 =====
attachment:기획과프로젝트관리/warning_signs.jpg

===== 성공징후 =====
 * 질의와 보고서(Queries and reports) - 데이터 웨어하우스로부터 직접 사용자들에 의한 질의들과 보고서들의 개수에서 급격한 증가 
 * 질의 유형(Query types) - 질의들이 더 정교해져 가고 있다 
 * 적극적인 사용자(Active users) - 사용자들의 수에서 안정된 증가 
 * 사용법(Usage) - 사용자들은 솔루션들을 찾으려고 데이터 웨어하우스에서 더 많은 시간을 소비하고 있다 
 * 소요 시간(Turnaround times)  - 전략 정보를 얻기 위해 요구되는 시간의 현저한 감소 

===== 실용적인 접근법 채택 =====
 * 결과만이 중요하다.
 * 실용적인 접근법
  * 완전히 결과 중심
  * 우선 순위 조정
  * 사업 요구사항에 의한 움직임

실용적인 접근법을 채택하는 데 몇 가지의 조언들 
 * 실용주의 방법으로 프로젝트를 수행하는 것은 일탈과 지연을 감시하고 그리고 진로에 머물도록 진행 중의 교정을 하는 것을 의미한다. 
 * 프로젝트 예정표를 일의 흐름과 결과를 이루기 위한 안내로 행동하게 하고, 단지 독창성을 제어하거나 금하지 않도록 한다. 
 * 프로젝트 작업 종속성들을 연속적으로 검토하라. 
 * "너무 많은 계획세우기"와 같은 일이 실제 있다. 
 * 비슷하게, "너무 많은 분석"이 "분석 마비"를 만들 수 있다. 
 * "첨단(bleeding edge)"과 증명이 안 된 기술들을 피하라. 
 * 항상 프로젝트의 일부로서 빨리 인도할 수 있는 것들을 산출하라. 
 * 이런 인도할 수 있는 것들은 사용자들의 관심을 유지할 것이고 또한 개념-의-증명(proof-of-concept) 시스템들로 기여한다. 
 * 구조가 먼저, 그리고 다음이 겨우 도구들이다. 
 * 사업 요구사항에 근거하여, 먼저 구조를 세우고, 그런 후에 그 구조를 지원하는 도구들을 선정하라. 

==== DW구축 반복-점진 모델 ====
'''준비 -> 발사 -> 조준!!'''
{{{
요구분석 -> 구축 -> 배포 -> 사용 -> 적격여부판단 -> 적용 -> 처음으로

1. 요구분석
	1.1 준비단계
		1.1.1 프로젝트 조직구성
		1.1.2 인원배치
		1.1.3 전체적인 프로젝트 계획서(전체관점)
	1.2 사용자요구분석
		1.2.1 BQ(Business Question) 수집
		1.2.2 KPI수집
	1.3 소스시스템분석	
		1.3.1 주제영역 분석
		1.3.2 개념적 ERD의 분석(Attribute 위주)
		1.3.3 코드분석
	1.4 계획서작성
		1.4.1 DW프로젝트 설계일정 및 진행방향 설정 
		1.4.2 업무분석시 미협의 사항 및 쟁점사항 도출/문서화
	1.5 분석보고서 작성
		1.5.1 분석보고서 작성
		1.5.2 업무분석시 미협의 사항 및 쟁점사항 도출/문서화
2. 구축(설계:구현:테스트 = 1:1:1 시간투입)
	2.1 다차원 모델링
	2.2 ETL
	2.2 테스트
3. 배포
4. 사용
5. 적격여부판단
6. 적용
}}}
일반적인 OLTP성 프로젝트 성과물의 최종 특징 및 프로젝트의 최종원가에 대한 이해관계자의 영향력은 시작할 때 가장 높으며, 프로젝트가 진행됨에 따라 점차적으로 낮아진다. 하지만 DW에서는 이해관계자의 영향력은 다르다. 이해관계자들은 DW를 사용함으로써 사용자의 수준이 높아져 결과물에 대한 영향력이 점차적으로 늘어난다. 

==== 장 요약 ====
 * 당신의 데이터 웨어하우스를 계획하는 동안, 고려되어야 할 주요 이슈들은 다음을 포함한다
  * 적당한 기대를 설정하기
  * 위험들을 평가하기
  * 하향식 또는 상향식 접근법들 사이에서 결정하기
  * 벤더 솔루션들로부터 선택하기
 * 기술이 아닌 사업 요구사항들이 당신의 프로젝트를 추진하게 한다. 
 * 최고 경영진의 충분한 지원이 없고 강하고 열성적인 임원급 후원자가 없는 데이터 웨어하우스 프로젝트는 첫 날부터 실패하게 되어진다. 
 * 데이터 웨어하우스로부터 이익은 사용자들이 그것을 충분히 사용을 하게 된 후에만 생긴다. 
 * 응용 개발의 전통적인 생명 주기 접근법은 데이터 웨어하우스 프로젝트를 위해 변경되고 조정되어야 한다. 
 * 조직과 팀 역할들의 배정에 대한 표준은 여전히 많은 프로젝트들에서 실험 단계에 있다. 당신의 프로젝트를 위해 중요한 것에 맞는 역할들을 수정하라. 
 * 사용자들의 참여는 데이터 웨어하우스 프로젝트의 성공을 위해 강제적이다. 사용자들은 다양한 방법들로 참여할 수 있다. 
 * 경고 신호들과 성공 요인들을 고찰하라; 최종 분석에서, 성공적인 데이터 웨어하우스를 구축하기 위해 실용적인 접근법을 채택하라.