2.1.1 项目准备就绪必须条件:
-
首要的,强力型高级业务管理发起人
-
强制性业务动机
-
技术可行性(DW/BI系统准备及数据本身),使用数据探查工具迅速进行一次评估 第九章数据探查系统
2.1.2 不同情形下,应对风险,确保系统稳定运行的建议方案:
-
低质量数据
必须先解决数据问题
-
能力弱的业务发起人和仅懂IT的发起人
1、理解业务管理部门战略性计划
2、为每个核心业务确定绩效度量标准
3、确定业务信息访问的改进对其绩效度量的潜在影响
-
多个业务发起人提出过多要求
可行性、业务影响效果最大的机会点达成共识
-
过于冒进的业务发起人
IT遵循原则,每引入一个新的主要数据源,整体开发周期延长半年
-
已存在多个DW,业务相似但不规则,数据冗余
确立正确的架构
2.1.3 确定初步范围和章程(划定项目范围)
PM需要提交范围界定和合理性证明
-
集中关注单个业务过程,项目初期仅从单个源系统中提取和转换数据,不轻易尝试包含多个业务过程的展现形式,例如仪表盘
-
敏捷开发,快速迭代。专注于最有业务价值的目标,业务和开发紧密合作,当面沟通确认优先级。快速适应新需求。避免建立孤立数据集。
-
项目范围文档落地,文档规范和关键点见书
项目范围随着任务提交会更加清晰,不可避免发生变更,修订内容要做到范围求精(即范围不变的前提下)而非范围蔓延(范围扩大)
2.1.4 合理性证明
预期财政回报和预期投资做对比,但不局限与ROI
-
确定成本
软硬件、人员、外部服务、运维、业务增长后的开销
-
确定收益
2.2 项目规划
2.2.1 确立项目标识
为系统设计名称,首字母缩写、logo
2.2.2 项目人员
-
决策人(不参加项目,但有重要影响):
1、业务发起人/业务驱动者:COO
2、系统主管/项目经理:CIO
-
指导者
1、项目经理
2、业务领导者(运营、市场)
-
项目团队
1、业务分析员,需求转换为技术架构、维度模型、BI应用(IT充当)
2、数据管理员/QC,定义业务规则和DW数据域值(懂业务IT充当)
3、数据设计建模师、DBA,数据架构,可重用性,为BI服务,维度模型转化为物理表,包括物理设计、磁盘布局、设计索引,确保完整性和性能
4、元数据管理员,监管每个流程中的元数据
5、ETL设计开发员,ETL系统设计,了解维度建模,熟悉ETL工具
6、BI
-
专门团队
项目核心成员担任
技术支持专家、安全管理员、首席测试员、数据分析/挖掘师、施训人员
-
顾问
2.2.3 制定项目计划
从项目任务和项目人员出发,制定一份综合详细的计划,包括了建模任务计划、ETL开发计划、架构定义计划等。
使用项目管理工具进行项目任务跟踪。
对未知事项进行充分估计,制定计划后应尽快启动项目。
2.2.4 制定沟通计划
通过频繁沟通管理期望,PM主动考虑沟通需求。
-
项目团队沟通
-
发起人和驱动者情况介绍(IT领导及业务领导)
PM每4至6周发起一次会议,内容简练,包括情况介绍,问题解决方法研究。与发起人面对面地沟通,不依赖会议记录及文档。
-
业务用户沟通
避免技术性词汇,简短易懂,项目范围文档更新或再版时需向参与项目的业务用户提供
-
其他
得到其他相关业务部门的认可,没有参与项目的IT同事介绍项目,主动将项目消息传递至各个部门。
-
交叉功能实施团队:成员承担不同职责关注监视项目状态
-
迭代开发周期:问题跟踪且文档化以确保后期功能提升迭代
-
不可避免的数据问题:尽早进行数据探查排除未知数据问题
-
高可见度:管理期望,主动沟通确保在掌控范围之内
2.3.1 项目启动会议
2.3.2 监控项目状态
项目状态报告,即项目总体进度的快照
2.3.3 维护项目计划
每周更新一次项目计划,准确反映项目进展,排除计划中存在的问题,选择适当的策略。
项目关键路径上的任务应在计划安排中,一旦落后于安排,就需要重新选择处理方法,可能是缩小项目范围,否则只能延期完成,而非追赶进度。
2.3.4 整理项目文档
包括所有的沟通情况和需要提交的主要项目资料副本,已一套正式的活页项目文件形式存储,也可存储为同生命周期找那个各个主要活动相对应的电子文档格式。
2.3.5 范围管理
管理项目范围变更,面对未预先定义的用户请求是,有以下几种选择:
-
拒绝
-
保持工作总量不变,对范围内外的内容进行调整
-
扩展范围,并延期,增加预算
与团队和业务共同确定范围,不独自承担变更范围的工作
问题跟踪和变更请求的方法论
1、问题跟踪
优先考虑将问题简化,两类问题
-
影响项目的重大问题
-
执行重要任务是与之相关的问题
2、变更控制
主要变更,PM细致观察变更并进行集体决策
次要变更,不接收过多问题,产生质变
2.3.6 期望管理
-
执行沟通计划
-
业务人员参与生命周期
项目计划中应当包含业务用户对生命周期中每次提交的主要内容的验收情况
DW项目返工不可避免,是必要条件,而非执行失败
2.3.7 辨识项目困境
2.6~2.12 行动蓝图见书