数据仓库项目启动与管理
数据仓库项目启动与管理
确定项目
评估项目就绪情况
项目就绪的三个条件
- 强力型高级业务管理发起人
- 对数据仓库解决方案的影响有先见之明
- 是所在组织内有影响的领导者
- 要求严格,但是又比较现实,会为其他成员提供强力支持
- 强制型业务动机
- 数据仓库系统和战略性业务动机紧密结合在一起
- 可行性
- 数据仓库准备过程中和数据本身相关的可行性,若缺失,脏造成预处理十分复杂,甚至没有收集到,就会面对比较重大的可行性问题.
- 评估可行性主要是使用数据探查技术,主要描述数据的内容 一致性 结构
弥补不足并确定下一步工作
- 低质量的数据: 项目不当继续进行,应当为业务发起人确定另一个业务价值高且数据可行性障碍比较少的需求,同时在项目延缓期间,解决数据方面的问题
- 能力弱的业务发起人和仅动IT的发起人: 需要再机构中物色新的业务发起人 最有效的方法是进行一次高层业务需求分析
- 理解业务管理部门的战略性商业计划
- 为他们监控和施加影响的每个核心业务过程确定主要的绩效度量或者成功标准
- 确定业务信息访问的改进对业务的潜在影响 进行概念验证不能成为放弃与功能性业务部门直接交互的理由,不应该单纯地进行概念验证
- 多个业务发起人提出过多要求: 借助促谈会进行一次协商 基于对业务价值和可行性的综合评估业务需求优先次序
- 过于冒进的业务发起人: 坚持在项目中立即继承多个重要的源系统 每引进一个新的主要数据源就将数据仓库的开发周期延长6个月,有助于将精力集中到正确的主题上
确定初步范围和章程
项目范围的确定应该由业务需求来驱动,在生命周期图中,这种关系是由"项目/项目群规划" "业务需求定义"两个方框之间的双向箭头来表示的
-
聚焦与一个单独的业务过程: 集中关注单个业务过程有助于为设计和开发迭代确定一个更易处理的范围,在项目缺的早期成型阶段 较为合理的做法是仅仅从单个源系统重提取和转换数据
- 在项目早期,每次迭代中都应当将数据的来源限定到单个业务过程中,当单个实现周期中多个业务过程的度量固定下来的时候,数据抽取,转换,装载方面的工作量都会成指数增长
- 补充原则
- 范围有意义且易于处理
- 需要IT代表与业务代表的共同努力
- 一旦范围确定下来就应当确立项目的成功标准
-
快速应用程序开发
- 精力集中于要交付业务价值的主要目标上
- 业务代表与开发团队之间的价值协作
- 同业务代表进行面对面沟通 反馈和确定优先级等熊东
- 尽快适应金华后的需求 变更是不可避免的
- 以迭代 怎两的方式处理可冲用软件的开发问题 多层任务并发重叠
- 一种开发模型并不能适用于所有项目群 BI团队成员在工作中要尽可能接近业务 另一方面 在显示世界中提取 转换 装载过程本来就比较复杂 而且还依赖于结构与顺序
- 不要凭空创建分析方法 或者报告方案 如果条件合适 鼓励使用敏捷开发方法 但是必须避免建立孤立的数据集
- 经常需要进行功能发布 也必须在整体架构 和总体规划的背景下实现
-
编制项目群范围 章程文档
- 背景
- 工程范围
- 工程之外的事项
- 工程成功的标准
- 风险和降低风险的行动方案
建立商业报告和合理性证明
- 确定财政投资和成本
- 确定财务效益和收益
- 利用投资和回报计算ROI
项目规划
-
确立项目标识
-
项目人员配备
- 决策人员
- 数据仓库主管
- 指导者,项目经理和项目领导者
- 核心项目团队
- 专门团队
-
指定项目计划 数据仓库项目需要一份详细的综合的项目计划 应当从项目任务和项目参加人员两个方面来考虑复杂性
-
细节跟踪
-
任务目标跟踪
-
人员
-
原来估算的工作量
-
原来估算的开始日期
-
原来估算的完成日期
-
状态
-
更新后的开始日期
-
更新后的完成日期
-
完成工作量
-
延迟天数
-
完成百分比
依赖关系
-
-
制定沟通计划
- 确定每个团队每个团队的沟通频率 形式 消息
- 需要和发起人和驱动者面对面的沟通
- 与业务用户us合区沟通
- 同其他有关方进行沟通
项目管理
-
交叉功能实施团队: 该团队所有成员在DW/BI项目中承担不同职责 紧密监控项目状态
-
迭代开发周期: 数据仓库环境的开发过程没有尽头 需要更多沟通来保证人员的同步 需要对问题/变化进行跟踪 确保今后系统功能的提升 需要详细的项目文档来支持团队各项工作的展开
-
不可避免的数据问题: 数据项目很容易受到各种未知数据问题的困扰 这会严重损害进行精心制定的项目计划 需要再设计各个候选数据源的数据管道之前 尽可能早地进行数据探查
-
高可见度: 业务机构对数据仓库的期望值都会很高 因此必须进行主动沟通来确保这些期望在掌控之中
召开项目团队启动会议
- 工程目标与目的
- 工程范围
- 团队角色与职责
- 团队工程管理
- 问题与解答
- 后续步骤
监控项目状态
- 项目状态会议
- 审查项目计划
- 审查问题和后续工作
- 审查变更请求
- 公告/一般性评论.问题和解答
- 项目状态报告: 项目状态报告提供了项目进度和高层快照,报告的提交和定期安排的状态会议应当同步
维护项目计划
整个项目计划应当每周更新一次 以便能够准确地反映项目的进展情况 随后还应当同核心团队共享更新后的计划.
项目计划应当反映事实 不论是好事 坏事 还是令人讨厌的事情 今早识别出项目计划中存在的问题 就可以使项目团队制定适当的策略 从而使下游连锁反应减少到最小
整理项目文档
数据仓库项目具有不断发展的特性 这就需要对项目文档进行整理 当时间压力不断增加 首先会考虑取消的事项通过长是编制正式的文档 一定要避免调入这样的陷阱
项目文档包括:
- 所有项目沟通的情况
- 需要提交的主要项目资料的副本
范围管理
数据仓库项目必然会发生变化,项目经理必须管理项目范围变更
- 鼓励关注业务用户和他们的需求
- 需要沿着系统开发的轨迹前进
对于未定义用户请求时:
- 对请求说"不"
- 保持工作量总体不变 对范围内外的内容进行调整
- 对项目范围进行扩展 随后强制性地延长项目期限 并适当增加项目预算
项目经理不应当凭空确定项目范围 在评价项目范围候选方案时 IT和业务的密切合作至关重要
问题跟踪
- 问题和问题描述
- 问题识别日期
- 呈报方
- 归属方
- 状态
- 优先级别
- 预定解决日期
- 结束日期
变更控制
- 变更请求控制和相关描述
- 请求日期
- 请求递交方
- 优先级别(按业务影响)
- 归属方
- 估计工作量
- 估计成本
- 状态
- 结束日期
范围管理
- 执行沟通计划
- 使用户参与生命周期的整个过程
辨识项目陷入困境的征兆
- 没有从高级业务机构引入有影响力的设计人员
- 认为参与项目的人员能够学习工作中所需的所有知识
- 一次性处理的任务过多
- 一心专注于技术层面而没有集中注意力于业务目标和需求
- 认为在整个项目生命周期中不需要业务机构参与就可以进行数据仓库项目的开发
- 在明知数据源质量较差甚至很糟的情况下 没有认真研究数据能否支持开发任务 就承诺向前推进项目的开发进程
- 低估了数据清洗和质量保证的工作量
- 过于关注ETL而葫芦哦了BI查询性能和是否易于使用
- 没有认识到数据仓库项目的成功与用户的验收息息相关 如果业务机构并没有认可数据仓库系统 也没有将其作为改进决策指定的基础 那么努力就白费了
项目群管理
- 确立管理职责和管理过程
- 将数据管理员的地位提升到企业层 建立企业级架构是项目群层应该关注的重要问题 与其让每个部门都建立独立的 以部门为中心的数据库 不如对公司的信息资源预先进行规划和管理 数据管理员应当为企业内部的所有交叉机构信息确立通用的定义和业务转换规则
- 机构的描述性主数据应当进行集中处理 随后分发给需要相关信息的项目
- 核心的绩效度量应当从源系统中一次性抽取和共享 而不是每个部门重复的抽取自己感兴趣的信息
- 利用高效的方法和架构最优方法
- 进行定期评估
- 沟通沟通沟通沟通