© 2005, The Board of Trustees of the University of Illinois 1 Project Methodology for Building and...

1

© 2005, The Board of Trustees of the University of Illinois

Project Methodology for Building and Enhancing a University Data

Warehouse

Prepared for Northwestern University ForumBest Practices in Data Warehousing in Higher Education

by Andrea Ballinger, Director of Data Warehousing

and Lisa Courtney, Project Coordinator

University of IllinoisApril 19, 2005

2


Objectives UI Background Methodology Resource Management Project Reporting Lessons Learned Summary

3


ObjectivesLearn ways to…..

1. Reduce project time by using a methodology that works for DW

2. Increase resource efficiency without sacrificing collaboration

3. Provide high-value outcomes to users

4


“You can have it good … You can have it fast … You can have it cheap ... Pick any

two.” Red Adair

Fast Cheap

Good

SCOPE

Meets User Needs – Creates Value

High Level of Communication

Users are Equipped

Minimal Errors: “Production Ready”

BUDGET

Efficient Use of Resources

Cost of Producing Deliverables

Productivity

TIMELINE

Meet Critical Dates

Provide Early Access for Report Developers

Other Key Dates

5


Know your criteria for success before you begin

If you don’t know where you are, where you’ve been, and where you’re going, you’re out of control

Incorporate formal project check points

Planning is cheap - reacting is expensive

Start with a baseline for duration, cost, and performance; it’s all about choices …..

Fire Prevention Guidelines for Project Coordination

6



7


UI Background• History, Mission and Focus of the

University of Illinois Data Warehouse and Decision Support

• Staffing• Products, Services and Uses• Post ERP Organization

8


UI history of decentralized data management Past warehouse-like projects with limited or no success UI-Integrate implementation of ERP system - SCT Banner started in

2000 ERP planning team told they must have a way to “get the data out of

the ERP” Decision Support team launched with intention of building a permanent

unit Parallel deployment and development of SCT Banner Common Attitudes:

• Mistrust of central projects - Give me the data and get out of the way! • Minimal experience with data warehouses or data marts - A what mart?• Operationally and report focused - Who will replace my reports?• Expectations of extensive data clean up - Give me access now; I have a lot to do.

Intense growth of the group since 2000

History of Data Warehousing at University of Illinois

9


UI Decision Support Mission

To support integrated and secured management reporting, analysis and decision making by providing the University with the infrastructure and services to access data and metadata.

10


UI Decision Support Focus During the Project Years (FY01-FY05)

Develop a Data Warehouse - a new component of the University’s information management architecture

• 5 year project concurrent with ERP implementation

• $17.7 M budget allocated for staff, software, and data projects

Major steps • Build the technical infrastructure• Create the processes to move data from the production systems to the EDW• Create the basic data model • Populate with data collected from Banner as each module of ERP implementation

was completed• Create education and training materials and process for users

Features• Single integrated source for analysis and ad-hoc reporting• No longer have separate systems for data on students, staff, finances, etc.• Maintain daily history for trend reporting • Format data for ease of use • Support use of data with documentation and training

11


Staff Levels Peaked During 5-Year ERP Related Project

0

10

20

30

40

50

60

70

80

Jul-

02

Au

g-0

2

Se

p-0

2

Oct

-02

No

v-0

2

De

c-0

2

Jan

-03

Fe

b-0

3

Ma

r-0

3

Ap

r-0

3

Ma

y-0

3

Jun

-03

Jul-

03

Au

g-0

3

Se

p-0

3

Oct

-03

No

v-0

3

De

c-0

3

Jan

-04

Fe

b-0

4

Ma

r-0

4

Ap

r-0

4

Ma

y-0

4

Jun

-04

Jul-

04

Au

g-0

4

Se

p-0

4

Oct

-04

No

v-0

4

Project FTE

Actual FTE

12


Today, the Data Warehouse is Established and Supported

UndergraduateAdmissions

“Library” of all data Special-purpose “data marts”

GraduateAdmissions

RegistrationCensus

RecruitingContacts

Financial Awards

FinanceHuman

Resources/Payroll

BiographicDemographicFinancial

AidRecords &

Registration

Catalog & Schedule

Recruiting &Admissions

699 tables 15,022 fields 145 GB total database size 470 MB daily increase

13


Services are User-Centric

Self-service data education

Query tool training

Data views thatmake connections

Daily questionanswering service

Monthly user group sessions

Regular schedule ofdata enhancements

Nightly integration of new data

Listservannouncements

Data documentation(metadata)

Campus practice labs

Query Clearinghouse

Standard Report Directory

14


Business Intelligence Uses are Evolving

Reports (4,300 users of Business Objects Reports from multiple data sources)

– General ledger statements– Grant summaries– Encumbrance listings– Payroll transactions– Employee directories and staffing reports– Course listings

Download warehouse data for applications – Campus staff directory– Federal SEVIS compliance program– Tuition assessment monitoring system– Grants monitoring

Detailed analysis (currently 2,000 data warehouse accounts with 600 active users)

Facilitate student recruitment with analysis of recruitment strategies and their effectiveness by student category

Increase timeliness of requisition processing by analysis of time required at each stage

Disbursement analysis and compliance reviews for grant funding

Support faculty retention and success of faculty teaching and research with a “whole person view” of courses, students, grants, compensation & benefits, leave & sabbatical data

Salary analysis

– Class rosters– Legislative reports– Instructor lists– Insurance eligibility– Applicant counts and profiles

– Instructor list system– Activity reporting– Graduate admissions information

Items on this slide are samples of current uses and planned uses as reported by users.

15


Hierarchy of Needs

Maslow's Hierarchy of Needs Hierarchy of Data/Reporting

Physiological

Safety

Love

Esteem

Self-Actual-ization

Replacing Static Legacy Reports

Creating Own Queries

Sharing Queries

Downloading Current Data via Reports

Accessing ReportsDynamically

Traditionally Analytical(Fewer #s)

Traditionally Operational(Larger #s)

Value Add

16


Decision Support Organization Structure for FY 06

Decision Support’s post-project organization combines business, data and technical positions in an integrated structure that facilitates close coordination among staff.

17



18


Methodology

• How DW project methodology differs from application development methodology

• Iteration vs. specification at key points in the process

• Project structure and key deliverables• Using checkpoints during design to

reduce rework in the build phase

19


Wh

at

is n

eed

ed

?W

hat

is t

he t

ask

?

Staff Retention• Department level data

incorporating changes over time• Leave balances by multiple

staff types, over several time periods

• Length of stay by multiple staff types

• Repeatable comparative analysis output (graphs, charts) to identify trends

Leave Adjustment Transaction

•Department level data for current period only

•Leave balances for active staff only in the current period

•Report output for monitoring•Application form for adjustments

vs.

Staff RetentionIs there a higher retention rate for department staff that take leave on a regular basis compared to those that carry over leave balances from year-to-year? Is this an anomaly or a trend?

Leave Adjustment TransactionLeave balances need to be monitored and adjusted to reflect leave accrued and/or taken for the department

vs.

Analysis Requirements Are Broader Than Applications

HR Analysis HR Transaction

20


Data Warehouse Development is Highly Iterative

Traditional Application Development: Because there are a limited number of

use cases, specifications can used to communicate requirements and test cases.

Data Warehouse Development: Uses prototyping and collaborative

reviews to refine the requirements for the most common queries, without limiting the possible analyses. Common queries are used for test cases, but open testing is also used.

21


Analysis Requires Relationships: The Data Warehouse relates data among faculty, staff, students, alumni and vendors, enabling proactive management of constituent relationships.

Designed with Data Relationships:Data relationships in the Data Warehouse reflect the real influences and impacts that occur in the University. Unlike “workflow” relationships needed to support transactions, data relationships can change as new data is added or new relationships occur in real life.

Data Warehouse Development Focuses on Data Relationships

22


Data Warehouse Development Process Involves Users with both Business Staff and Data/Technical Staff

BusinessRequirements

Work Planning

Metadata Development

Implementation Coordination

Deploy to Users

FunctionalDesign

TechnicalDesign

Development QualityAssurance

Iterative IterativeSpecified SpecifiedSpecifiedSpecified

Business Expertise

Data/Technical Expertise

Business Expertise

Begins with user’s business priorities

Business & Data Experts work with

users to create design

Business & Data Experts work with

users to test design

23


Positive Outcome Example: Budget Operating Statements Project – Stage 1 – Fall, 2004

Objective: Relate data from HR Salary Planner and Finance Budget with existing data in the EDW, so that users - primarily business managers in colleges & departments - could develop comparative reports of budgeted dollars, FTEs and accounts with actual dollars, FTEs and accounts grouped by college and department, including detail at the job level

Approach: Prototyping in the design step enabled users to interact with the data and share with both the business and technical staff feedback regarding data relationships, business rules, and granularity. User/business/technical team allowed for iterative design process, and actual user queries to be used in testing.

Outcome: Achieved high user satisfaction, with less work effort than anticipated. Users had only a few minor adjustments in the User Acceptance Testing process, and there were no post-implementation corrections.

24


Iterative Design Process Required Team of Business & Technical Staff Collaborating Face-to-Face with Users for Positive Outcome on Budget Operating Statements


Work Planning

Metadata Development


Deploy to Users

FunctionalDesign

TechnicalDesign

Development QualityAssurance

Iterative IterativeSpecified SpecifiedSpecifiedSpecified

Business Expertise

Data/Technical Expertise

Business Expertise

Need to compare HR and Finance Budget data in

detail

Created working prototype of data model and users

provided feedback through several iterations

User-developed queries from functional design

step became test cases in for final data structures

and universe

25


Goals for Methodology

Management and Stakeholder “Ownership”: Gained through planned review points

Business Solution Driven: Clearly identify the business tasks, business purpose and functional roles at project inception.

Rapid Delivery of User Value: Release new functionality in 90 to 120-day development stages

Reduce Development Rework: • Clear definition of project scope• Iterative functional design using prototyping• Implement change control on technical design

26


Month 7 Month 8Month 1 Month 2 Month 3 Month 4 Month 5 Month 6

Data Project Process: Multiple Stages of 90-120 Day Cycles

Stage 1: Initial Functionality

Stage 3: Additional Functionality

Entire Project Feasibility

& Work Planning

Stage 2: Additional Functionality

ReviseWP

ReviseWP

ReviseWPB

4321

ReviseWP

4321

A

4321

CLOSE

Review PointsA = Strategic Scope Review 1 = Design Scope Review 3 = QA2: Technical Review

B = Statement of Work 2 = QA1: Technical Review 4 = Go/No-Go Decision

27


Feasibility Analysis

Work Planning

Requirements& Functional Design

Technical Design

Development QA & Delivery

Business Case

StrategicScope Review

Input ReviewPoint

Output

Project Statement

Of Work

Statement ofWork Approved

Prototype

Requirements +Data

Design ScopeReview

Design Plan

QA1:TechnicalReview*

Developed Code

QA2:TechnicalReview**

Testing

Go/No-GoDecision

Rollout

*QA1: Does the technical design meet the requirements?

**QA2: Does the developed code meet the technical specification?

Project Initiation

Functional Specification

TechnicalSpecification

Code Modifications

Data Project Short Cycle Methodology: 90-120 Day Cycle per Stage (High Level)Once Per Project

Project Plan

Repeated Each Stage

28


Feasibility Analysis

Work Planning

Requirements & Functional Design

Technical Design

Development QA & Delivery

Business Case

FAC/RMC andStakeholders

StrategicScope Review

for fit & commitmentDirector

Input ReviewPoint

Output

Project SOW• Deliverables• Timeframe

• Work EstimateProject Mgr

Statement Of Work Approved

BAM, DAM, TAMProject

Coordinator

Prototype•Business Needs •Data Behavior

• IterationsDA/DM/RA/FAC

Design ScopeReview

BAM, DAM, Services Mgr

& Stakeholders

Design Plan•Logical/Physical

Data Model• Design Specification

DM/DA/TA

QA1:TechnicalReview

BAM, DAM, TAM

Developed Code• ETL with Validation

• Universe (unit tested) ETL/BOS

QA2:TechnicalReview

BAM, DAM, TAM

Testing• System

•Integration•UAT

•Regression FAC/RA/DA/PM

Go/No-GoDecision

DS Management& Stakeholders

Rollout• Training

• Post-Deployment QA

FAC/RA/DA/PM

Project Initiation• Schedule

• Assign Project Mgr• Identify Resources

ProjectCoordinator

Functional Specification• Logical Data

Model• Universe Mock-Up

RA/DA/DM

Project Plan• Deliverables,

Tasks, & Subtasks• Work Assignments

• MilestonesProject Mgr

TechnicalSpecification

• Source to Target Maps

• Universe Specification

DA/BOS

Code Modifications

• Revised Specs •ETL with Validation

• Universe (unit tested)

DA/ETL/BOS

Once Per Project Repeated Each StageData Project Short Cycle Methodology: 90-120 Day Cycle per Stage (Detail)

FAC – Functional Area Coordinator DA – Data Analyst TAM – Technical Architecture ManagerRMC – Requirements & Metadata Coordinator DM – Data Modeler TA – Technical AnalystBAM – Business Architecture Manager ETL – ETL DeveloperDAM – Data Architecture Manager BOS – Bus Obj Specialist

29


• There will be changes after go-live• Plan the transition into the project plan – 30-60

days after go-live and retain project resources• Involve production support in the transition• Manage production work (post go-live) in a

similar manner as project work, i.e., Change Management

• If there is a large amount of work, group it into post go-live releases

Transition to Production is an Essential Project Phase

30


• Statement of Work– Business Case (Need, Audience, Outcome)– High-Level Timeline– Resources– Risks

• Project Plan– Phases– Deliverables– Tasks– Resources

• Issue Log– Description – Impact– Actions– Owners and Resolution Date

• Communication Plan– Groups and Individuals– Type of Communication (Presentation, Review, etc.)– Frequency and/or Dates– Contacts– Owners

Implement the Methodology with Key Project Documents

31


• Functional Specification– High-Level Requirements– Line Item Requirements (Data Elements & Business Rules)– Sourcing Analysis– Security Requirements– Application Specification

• Technical Specification– Data Model– Load-Flows & Source to Target Mappings – Application Structure

• Testing and Change Control– Test Cases– Queries– Change Control Document

• Production Turnover– Change Control Document or Production Change Request– Log of Changes and/or Release Plan

Implement the Methodology with Key Project Documents

32


Keys to Building Effective Collaboration With Users Into Data Warehouse Development Determine the mix of users for the products you are developing

• College & Department Users: Data Analysts, Business Managers, etc.• Functional Offices: Admissions, Business & Financial Services, HR, Payroll, etc.• Data Offices: Institutional Researchers, Planning, Budgeting

Invite these users into the process by providing input and review options• Focus Groups• Interviews• Specification Documents Review• Model and Application Prototype Reviews• Large Group Information Session Presentations (eg., Business Managers Group)

Identify Obstacles and Seek Input• Address objections early• Request participation

Involve the Same Users in Requirements Definition and Testing• User Acceptance Testing – Hands-on• Preview with Power Users

33


ERP Teams

Decision Support

InformalContact

Between DSand ERP team

Collaborate to Plan: SCT training for DS ERPDS and BOOverview DS CRP attendance ERP team participationin DS Focus Groups

Resolve Issues

Work Planning

Document "AS IS" processPlan "To Be" process

Finalize "TO BE"process

UI2 informs DS about Banner mods, Security roles, Privacy concerns, Conversion plan Conversion of History plan, Banner interfaces Completion of report

functional designspecification

ERP sends DS Report specifications, Reporting Needs Inventory

Iteratively execute scripted test cycles, sub cycles and businessprocesses using prepared data elements

ERP sends filelocations toDS:

CurrentReports

Interfaces Banner

Tables Current

systemsto convert

Prepare and Conduct CRPsComponent Design

Develop Conversion Plan

Design

Detailed AnalysisDesign

Implementation

Build Databases andMetadata;

Create Business Objectsuniverse ;Unit Test;

Plan Training

Design and confirmPhysical Model(s) and

Data Staging

Construction

Resolve Data Issues; Validate Data;Test and Train

User TestSystem TestBusiness Reqs Analysis

Work Plan Rev.

Analysis

Plan Focus Groups to Determine # of Groups and # of Participants;Conduct Focus Groups, Collect Requirements; Design and Confirm

Logical Model(s)

WorkPlanning

DesignPhaseOrg'n

PlanImpl.phase

GO

LIVE

Iterative full volume mock conversions and dress rehearsals ; catchand fix data exceptions

Confirm Banner data model;Overview of Business Objects &

EDW;Consensus on DW Reports;

Report walkthrough - ERP reportssourced from DS

Weekly status meetings to coordinate test phases & test data availabilityTest plan development & phase integration

Production quality data available to pull from Banner environment

Integration Testing

Implementation

DesignBuild and Unit Test

Components

End User TestingIntegration Testing

System Testing

Mock Conversions, Data Purifications

Rollout

Plan System Testing

DS-ERP joint meetings

Design, Build, and Unit Test Interfaces, Conversions, Business Objects

Universe, Banner Reports

UI Sample Structure for Collaboration

34



35


Resource Management• Project roles• Gaining ongoing commitment from

owners of shared resources• Estimation of resource time• Tracking resource time

36



WorkPlanning

Ensures that development activities are driven by needs of users

Metadata


•What is the business problem and what data solution is needed?

Deploy to Users

Explain how to use the data andthe Business Objects Universe

Enable security and access

FunctionalDesign

•What specific data is needed from the source system?

•How does it need to be related?

TechnicalDesign

What is the technical road map from the source to the EDW?What definitions and business rules apply?

Development

• Build code to Extract, Transform and Load data

• Build Business Objects Universe or Application

QualityAssurance

•Load data and validate with counts and comparisons•Test the Business Objects Universe

Business Analyst Data Designer ETL Developer Project Coordinator

Functional Area Coordinator Data Architect Business Intel. Spec. Technical Analyst Implementation Coordinator

Communication Specialist

BA

FAC

DD

DA

ETL

BIS

PC

TAIC

BA

PC

RolesBA FAC DD BA DD ETL BISDA DD BA

CS FAC

TA

IC

DD

BA FAC

CS

Iterative Iterative

Project Roles Require a Mix of Business and Technical

37


Business/Functional:• Functional Area Coordinator (FAC): Knows the data and how it is used;

understands the functional uses and potential uses for the data• Business Analyst: Defines high-level business case, refining to detailed data

elements and business rules; writes test queries and refines with users; Coordinates metadata definition and publishing

• Communications Specialist: Creates messages to users regarding availability and usability guidelines

Data/Technical:• Data Designer: Determines data structures, sourcing and relationships• Data Architect: Reviews for consistency with design standards and quality• ETL Developer: Develops ETL and validation scripts• Business Intelligence Specialist: Develops application layer• Technical Architect: Reviews for optimization within technical environment

Coordination and Support:• Project Manager: Plans and manages work, issues and risks• Implementation Coordinator: Coordinates environments and migrations; works

with Project Manager to transition to production

Project Roles Used by Decision Support

38


“Matrix Managed” Projects – The Good, The Bad & The Ugly• Resources supervised by an external manager who is responsible for work

quality• Work is assigned by a Project Manager for a specific project with a view of

the project goals only• Resources often assigned to more than one project, causing conflicting

priorities and animosity between managers and staff

Planning and Communication is the Key to Success• Project Manager plans work assignments and gains buy-in from external

manager, reviewing periodically, not just once• Work quality issues are communicated to external manager with impact

statement to help the external manager determine what action to take• Cross-project assignments must be monitored on a resource plan, which

ideally includes other, ongoing work as well (ex., customer support responsibilities)

Gaining Commitment from Resource Owners

39


Start with a planning estimate based on your typical history• For example, on the average, it takes x number of hours to develop an ETL mapping

Adjust the planning estimate based on complexity factors• Clearly defined scope vs. Planning exercises involving many people• Requirements are clear across user groups vs. Multiple high-level requirement

groupings• Small, knowledgeable group of users involved vs. Many users with different jobs and

priorities• Data relationships clear vs. Multiple sources or subjects not previously related• Modification of existing structures vs. New structures• Minimal testing required vs. Full cycle with full regression testing• Modification to existing training vs. New training materials• Modification to existing metadata vs. Detailed new definitions, model and STT maps to

be published

When more detail is known – REVISE!!!

Resource Estimates are Always Subject to Revision

40


Use the resource feature in MS Project (or whatever tool you are using) to assign resources to tasks – sweating the details is well worth the effort• Don’t assign work to a role, unless it is a temporary placeholder• Estimate both hours and duration reasonably• Remember all entries are estimates until the work is done

Update progress on tasks weekly Review resource plans every 1-2 weeks with team members

and with resource owners, focusing on a 4-6 week window Focus on remaining work – Estimate to Complete (ETC) is the

most useful information Use a Resource Pool if you are managing resources across

multiple projects Put the day-to-day work in a project plan so that the real

demands on time can be determined

Use a Resource Plan to Track Assignments by Person

41


Objectives Background Methodology Resource Management Project Reporting Lessons Learned Summary

42


Project Reporting

• Must Be Clear

• Sample of Project Documents– Integrated Project Deliverable Status– Project Work Investment Distribution– Implementation Timeline– Issues and Risks Summary

43


• Focus on the key points that management needs to know

– Integrated Project Deliverables Status– Project Work Investment Distribution– Implementation Timeline (Short-Term)– Issues and Risk Summary– Scope Overview

Project Reporting Must Be Clear – Challenge is in Rollup

44


Integrated Project Deliverable StatusThis report shows the deliverables (major work products) completed for the project, or in process at the time of the report. Scheduled start and finish dates are shown for each deliverable. Work effort, in hours, is indicated for both the total work invested in each deliverable, and the remaining work for deliverables in process. The percent of work complete for each deliverable shows the progress to date.

ID Start Finish Deliverable Name % Work Complete Total Work Remaining Work1 Mon 3/31/03 Fri 10/15/04 Registration Census 50% 1,704.25 hrs 844 hrs2 Wed 1/21/04 Fri 4/9/04 P3. Design 100% 67.35 hrs 0 hrs

28 Wed 2/4/04 Fri 7/23/04 P4. Construction 89% 620.87 hrs 66.8 hrs33 Mon 3/22/04 Tue 3/23/04 D4.2 Physical Environment 100% 24.5 hrs 0 hrs44 Wed 2/4/04 Fri 4/9/04 D4.3 Universe Design Specifications 100% 10 hrs 0 hrs56 Mon 4/12/04 Wed 6/16/04 D4.5 ETL Build 100% 162.75 hrs 0 hrs63 Mon 4/12/04 Fri 6/11/04 D4.4 Universe Builds 100% 41.67 hrs 0 hrs69 Wed 5/12/04 Fri 5/28/04 D4.5 System Testing 100% 167.88 hrs 0 hrs

135 Mon 4/12/04 Fri 7/23/04 D4.6 Security Implementation 56% 150.2 hrs 66.8 hrs163 Mon 5/24/04 Mon 5/24/04 D4.7 Implementation Preparation 100% 0.8 hrs 0 hrs168 Mon 3/31/03 Fri 10/15/04 P.5 Implementation 24% 1,016.03 hrs 777.2 hrs

169 Thu 5/27/04 Mon 6/28/04 D5.1 Integration Testing 84% 213.18 hrs 34.17 hrs258 Mon 3/31/03 Fri 7/2/04 D5.4 Final Fixes & Appworx set up & Other 44% 136.1 hrs 76.3 hrs

2 Mon 12/30/02 Fri 12/10/04 Student Records 57% 5,158.5 hrs 2,236.32 hrs1 Tue 4/1/03 Mon 10/20/03 P1. Work Planning 100% 584.88 hrs 0 hrs

73 Mon 3/24/03 Thu 3/4/04 P2. Analysis 100% 605.53 hrs 0 hrs199 Wed 9/10/03 Fri 7/23/04 P3. Design 100% 969.03 hrs 0 hrs283 Mon 2/2/04 Fri 9/17/04 P4. Construction 69% 1,099.33 hrs 336.6 hrs

286 Mon 2/2/04 Tue 2/3/04 D4.2 Physical Environment Build 100% 10 hrs 0 hrs297 Mon 2/9/04 Tue 5/18/04 D4.3 ETL Build 100% 443.03 hrs 0 hrs310 Mon 3/22/04 Wed 6/2/04 D4.4 Universe Builds 100% 85.43 hrs 0 hrs331 Thu 6/3/04 Mon 6/28/04 D4.6 System Testing 56% 69.8 hrs 30.5 hrs367 Mon 3/1/04 Tue 8/17/04 D4.7 Security Implementation 48% 338.1 hrs 175.1 hrs432 Thu 4/1/04 Tue 7/6/04 D4.10 Construction Wrap up 4% 51 hrs 49 hrs

3 Thu 4/1/04 Mon 3/14/05 HR Finance 15% 2,547.2 hrs 2,169.7 hrs13 Thu 4/1/04 Wed 9/1/04 S1. EDW Budget Tables 35% 818.67 hrs 534.67 hrs14 Mon 4/12/04 Tue 7/6/04 P2. Analysis/Functional Design (EDW Budget Tables) 85% 188 hrs 29 hrs15 Mon 4/12/04 Fri 4/16/04 D2.1 User Profile 100% 20 hrs 0 hrs17 Mon 4/19/04 Wed 4/28/04 D2.2 Interview Records 100% 35 hrs 0 hrs19 Fri 5/14/04 Tue 5/25/04 D2.3 Requirements Matrix 80% 30 hrs 6 hrs21 Mon 4/19/04 Fri 5/14/04 D2.4 EDW Prototype 100% 80 hrs 0 hrs27 Mon 5/17/04 Fri 7/23/04 P3. Technical Design (EDW Budget Tables) 39% 316.67 hrs 191.67 hrs28 Mon 5/17/04 Tue 7/6/04 D3.1 Baseline Data Model (Logical/Physical) 77% 162.67 hrs 37.67 hrs4 Mon 1/5/04 Thu 9/16/04 Standard Reports 68% 1,340.33 hrs 432.2 hrs2 Mon 1/5/04 Tue 2/24/04 P1. Work Planning 100% 191 hrs 0 hrs

32 Wed 2/18/04 Wed 9/15/04 P2. Standard Report Environment 62% 1,149.33 hrs 432.2 hrs33 Wed 2/18/04 Wed 9/15/04 D2.1 Standard Report Publishing Procedures 76% 456.23 hrs 108 hrs34 Thu 2/26/04 Fri 3/12/04 SD2.1.1 Model Service Level Agreement 100% 115.12 hrs 0 hrs37 Wed 2/18/04 Thu 3/25/04 SD2.1.2 Processes and Procedures 100% 213.02 hrs 0 hrs45 Wed 2/25/04 Wed 9/15/04 SD2.1.3 Communications/Training/Demo Planning 16% 128.08 hrs 108 hrs70 Wed 2/25/04 Fri 8/27/04 D2.2 Standard Report Inventory Web Application 55% 672.27 hrs 304.33 hrs71 Mon 3/29/04 Thu 5/20/04 SD2.2.1 Design Specification for Report Inventory Web Application 100% 146.68 hrs 0 hrs

77 Tue 3/2/04 Thu 3/18/04 SD2.2.2 Pilot Report Inventory Web Application 100% 8.57 hrs 0 hrs83 Mon 4/19/04 Wed 4/21/04 SD2.2.3 Integration Requirements with Existing Applications 100% 7.92 hrs 0 hrs85 Wed 2/25/04 Tue 6/1/04 SD2.2.4 Prepare Technical Environment 100% 26 hrs 0 hrs91 Tue 4/27/04 Fri 8/27/04 SD2.2.5 Develop Report Inventory Web Application 37% 483.1 hrs 304.33 hrs

45


Project Work Investment DistributionThis chart shows how work hours are invested across the active projects at the time of the report. Total Work Investment is the planned hours of work required to complete the project. Work Completed is the work already invested in the project, and Work Remaining is the remaining hours expected to be invested in each project.

46


Implementation Timeline

The timeline shows the major events scheduled as part of the implementation phase of the projects, for a three month window.

47


Issues and Risks Summary

These are issues or risks that impact more than one project, or have been deemed by the project manager to be of high impact or high likelihood to occur.

Risk or Issue Project(s) Description Impact Mitigation

ETL Resource Shortage

HR Finance

and Data Integrity-ETL

Two ETL resources have left the organization in the past month. New staff will need time to be trained before deployment to project work.

HR Finance Stage 1 Deployment has been postponed for one month.

Data Integrity – ETL project is on hold until a full time ETL resource can be obtained.

Postponement of HR Finance Stage 1 is not critical, since final budget numbers from Banner Salary Planner will not be available until at least 9/1/04. Data Integrity –ETL should be able to make significant progress once a resource is assigned full-time.

Data Integration Between HR and

Finance

HR Finance Source data in Banner may not have the detail necessary to provide a clean integration between HR and Finance data.

May not be able to deliver a cleanly integrated HR to Finance solution at the levels of aggregation users will want.

Perform requirements analysis for stage 2 early, then assess HR and Finance data for feasibility

Replication of Production

Environment for Testing of Census

Dates

Registration Census

Census dates are built on timing and batch parameters that can not be replicated in a test environment, so triggers cannot be fully tested prior to go live.

Census will not truly be tested until first nine census dates have actually occurred.

Contriving dates for test pulls as well as setting up "fake" batch trigger runs

48


Objectives Background Methodology Resource Management Project Reporting Lessons Learned Summary

49


A. Management

B. Partners and Procedures

C. Cultural

D. Reporting

E. Post Go-Live

F. If We Could Start Over, We Would….

Lessons Learned

50


To be most successful, matrix management should be accompanied by documentation, particularly when everyone is busy.

Staffing agreements for assigned staff should be negotiated up front, including personnel issues, then revisited as the situation evolves.

Working partner agreements might need to include some very practical issues: rumor management, agreements on staff movement from one group to another, agreeing to share in service opportunities, etc.

Project partners must make basic decisions about external communication, such as that to campus constituencies.

A. Management

51


Project partners must understand each others’ project plans (milestones, terminology, critical path) and project plans must be more than task lists.

Coordinated project planning must be reinforced by strong team lead relationships, at multiple levels.

Project partners must understand each others’ methodology at a high level, particularly at the outset.

For all partners: when similar sounding methods are different, e.g., requirements or modeling, there must be an understanding of those differences.

External technical partners must have a chance to hear and understand internal approach to technical issues.

Existing technical procedures may not be documented or formal. Intrusion into this process may be perceived as problematic.

B. Partners and Procedures

52


Assumptions must be aired regularly and relentlessly.

Understand the culture and expectations of each partner. Where there is miscommunication about culture or expectations, a lot of time is wasted in seemingly small matters.

Shared celebrations and congratulations help. Frequent interaction solving problems together helps more.

C. Cultural

53


Report development has a life cycle of its own, with requirements, sign offs, negotiations, assignment of roles, metadata, deployment issues, etc. that are in addition to those involved in deploying an ERP or a Data Warehouse

In the press of building a Data Warehouse and/or implementing an ERP, it’s easy to subsume this life cycle under other tasks

Inadequate attention to reporting means you don’t fully appreciate its importance to users and are putting project at risk

Best to have an owner who is accountable to users for report success

D. Reporting

54


Designate a production team that can take over the maintenance of the product after 60 days. Shared development and production staff on a long-term basis does not work.

It is important to show the users that you designed a flexible environment to accommodate their changing needs.

There are many guides for development but few for 60 days after.

E. Post Go-Live

55


Have organized the department the same way but designate staff as development or production

Still be led by and focus on business need

Still create a flexible architecture as a baseline

Negotiated interlocking timelines between the Data Warehousing and ERP efforts. Preferably offset warehouse release from ERP release to allow breathing room for the ERP to settle

Focus on operational reporting for the initial phase (concurrent with ERP deployment)

Have a recurring IT contract for staffing from the beginning

F. If We Could Start Over, We Would….

56


We would have formally defined our relationship with ERP partners, rather than from the bottom up.

In the early days it might have been good to do a small project using legacy data. This could have been used to formalize procedures and work out internal relationships and issues.

We would have taken a more critical look at how technical skills of staff like DBAs and modelers are different in a warehouse environment than in a general IT environment. We could have helped the IT staff to a smoother transition.

We would have secured critical staff early in the process (Data Architect and Technical Architect)

We would have recommended greater recognition of the report development process as an independent effort, possibly with separate leadership.

And…

57


Objectives Background Methodology Resource Management Techniques, Tools and Lessons Summary

58


Thank You!

For more information visit our site at: http://www.ds.uillinois.edu

Questions? Discussion?

© 2005, The Board of Trustees of the University of Illinois 1 Project Methodology for Building and...

Documents

Transcript of © 2005, The Board of Trustees of the University of Illinois 1 Project Methodology for Building and...