BI Project

Business Intelligence
Project
Mike Hannigan
Business Intelligence Project Manager
Via Systems Inc.
660 Southpointe Court, Suite 300
Colorado, CO 80906
(719) 579-6800
September 2006
September 2006 © 2006. Via Systems, Inc. 1

Business Intelligence
Definition:
“Analysis of business data. Business Intelligence is the name
given to a class of software tools specifically designed to aid
analysis of business data. BI tools have traditionally been
associated with in-depth analysis of historical transaction data,
supplied by either a data warehouse or an online analytical
processing (OLAP) server linked to a database system. BI has a
wide range of commercial and non-commercial applications, with
the most common being the analysis of patterns such as sales and
stock trends, pricing and customer behavior to inform business
decision-making. For this reason it is sometimes referred to as
decision support software.”
Source: Procullux Media Ltd., 2005
September 2006 © 2006. Via Systems, Inc 2

Introducing Business Intelligence
BI focuses on the
“outside,” and should be
seen as a company’s radar
unit, scanning the external
environment for
opportunities and dangers.

It’s not just another term for
Market Research….
Good BI is broader in
scope and more forward-
looking than market
research.

Fundamentals
“Business Intelligence initiatives are expensive
endeavors. Disparate business data must be extracted
and merged from online transaction processing (OLTP)
systems, from batch systems and from external data
sources. Business Intelligence decisions – support
initiatives also call for new technology, additional tasks
to be performed, roles and responsibilities to be shifted,
and analysis and decision-support applications to be
delivered quickly while maintaining acceptable
quality.”
Source: BI Review, 2005

Fundamentals
“Sixty percent of Business Intelligence projects
end in abandonment or failure because of
inadequate planning, missed tasks, missed
deadlines, poor project management, undelivered
business requirements, or poor quality of the
deliverables.”
“Failure to Plan is a Plan for Failure”
Source: DMReview by Jonathan Wu, October 2000

Fundamentals
• Unlike static stand-alone applications, a
properly designed BI system cannot be built in
“one big bang”
• Data and functional capabilities must be rolled
out in iterative releases
• BI applications are very different from stand-
alone applications

Fundamentals
Do we know the type
of customers we
Can we forecast have? Are our products &
long-term buying services priced
habits of our competitively?
customers?
Do we know why we
are losing market Do we know what
share? our best customers
have in common?

Fundamentals
• Business Intelligence vs. Standard Application
• Business opportunity • Business needs
• Implement across the • Department decision
organization support
• Strategic Information • Operational functional
requirements requirements
• Best deployed as • Best released at the
release/evaluate same time with all
environment functional capabilities

Fundamentals
• BI requires a Cross-organizational development
approach
– Information consolidation
– Seamless business functionality
– Information integration
– Streamlined organizational business processes
– Information integrity
– Organization changes
– Corporate culture shifts
– Parallel development tracks (subprojects)

Fundamentals
Business Intelligence Project Lifecycle:
Business
Justification
Analysis
Deployment Design
Planning Construction

Outline (Sixteen Steps)
Justification Design
1. Business case assessment 8. Database Design
9. ETL Design
Planning 10. Meta Data Repository Design
2. Enterprise Infrastructure
Evaluation Construction
3. Project Planning 11. ETL Development
Business Analysis 12. Application Development
4. Project Requirements Document 13. Data Analysis
5. Data Analysis 14. Meta Data Repository
6. Application Prototyping Development
7. Meta Data Repository Analysis Deployment
Note: ETL - Extract/Transform/Load
15. Implementation
16. Release Evaluation

Presentation Notes
• Handouts
• Two slides with
– Activities (do) – end of each step
– Deliverables (produce) – end of each section/stage

Stage One
Justification

Stage One: Justification
(1) Business case assessment
• The business problem or business opportunity is
defined
• Cost-justified
• Define the benefit
• Solving a business problem or taking advantage of a
business opportunity
• Balance between the costs involved and the benefits
gained
• Must be business driven not technology driven

Business Justification Components
Business Cost
Drivers Benefit
Business Risk
Analysis Assessment

Business Drivers
• Strategic business goals of the organization
• Substantiate business justification i.e.
– Customer satisfaction
– Reduced costs
– Critical business data available
• Must be in line with the company’s business
direction

Business Analysis
• What business issues will be resolved?
• Define information requirements for the business issue
• Determine subject area, level of detail, internal data
and external data needed
• Identify the user community
• Possible data sources
– Online Transaction Processing (OLTP)
– Private data (internal department data)
– External data (i.e. statistics, customer profiles, credit reports,
etc.

Cost Benefit
• Warning: ROI can be difficult to cost justify
• Remember do not justify by solving
operational problems
• How are you solving a business problem?
• What new business opportunities will be
available?

Risk Assessment
• All projects have risk
• Identifying risk triggers
• Create a mitigation plan for all important risks
• Create a contingence plan for all important
risks

Risk Assessment
Variable Low Medium High
Technology Experienced with Minimal experience New technology little
technology with technology experience
Complexity Simple, minimal Moderate, some Mission critical,
workflow impact workflow impact requires extensive
work
Integration Stand-alone Limited integration Extensive integration
Organization Solid internal support Supportive to a large Little internal support
extent
Project Team Business experience, Some business No business
talented, great attitude experience, talented, experience, only
fair attitude technology-driven,
bad attitude
Financial ROI in short time ROI within a moderate ROI after a few years
Investment time frame

Business Case Justification Activities
1. Determine business need
3. Access operational sources 4. Access competitors BI

2. Assess current solution
and procedures support initiatives
5. Determine BI
application objectives
7. Perform cost benefit

6. Propose BI solution 8. Perform risk assessment
analysis
9. Write assessment report

Justification Deliverable
Business case assessment report
• Strategic business goals
• Objectives of the proposed BI application
• Statement of the business need
• Explain how the BI application will satisfy the business need
• Ramifications of not addressing the business need
• Cost-benefit analysis
• Risk assessment
• Recommendations
Note: Remember to include an executive overview

Stage Two
Planning

Stage Two: Planning
(2) Enterprise infrastructure to support the cross-
organization initiatives
– Technical infrastructure
– Non-Technical infrastructure
(3) Project Planning
– Including scope, time, budget, staff, technology,
business representatives and sponsors
– Include in the plan must be detailed plans to track
and report progress

Planning the Technical
Infrastructure
• Description of the current structure
• Plan the future structure (changes)
• Middleware to the DBMS
• DBMS requirements

Middleware Platform
• Middleware – Runtime software
• Client/Server Architecture
• Middleware categories
– Distributed Logic Middleware: supports program-
to-program communications between two pieces of
custom application code
– Data Management Middleware: connects an
application or DBMS on one platform with a
DBMS running on another platform
DBMS Platform
• Handling queries and data load
• Database scalability
• Internet integration
• Availability of advanced index schemes
• Unattended operations
• Network support
• Administrative support
• Future use/expansion
• Hardware scalability
• Query performance
• Load process and performance
• Security system
• Data dictionaries

Technical Infrastructure
• Data volumes
• Update frequency
• Data access patterns
• Number of reports and queries
• Number of people accessing the BI database
• Number of tools running against the BI
database
• Number of data feeds for the BI database

Technical Infrastructure Evaluation Activities
1. Assess existing platform
2. Evaluate and select

3. Expand current platform
new products
4. Write technical
Infrastructure report
Planning the Non-Technical
Infrastructure
• Assess effectiveness of non-technical
infrastructure components
• Write non-technical infrastructure assessment
report
• Improve non-technical infrastructure

Enterprise Standards
• Development Approach
• Data naming and abbreviations
• Meta data capture
• Logical data modeling
• Data quality
• Testing
• Reconciliation
• Security
• Service-Level Agreement (SLA)
• Policies & Procedures

Technical Infrastructure Evaluation Activities
1. Assess effectiveness of
non-technical infrastructure
2. Improve non-technical
infrastructure
3. Write non-technical
Infrastructure report

Project Planning
• Managing the BI project
• Plan for setbacks
• Creating a project charter
– Goals & objectives
– Scope issues
– Project risks
– Constraints
– Assumptions
– Change Control
– Issues Management
• Project planning activities

Project Planning – Simple Terms
• What will be delivered?
• When will it be done?
• How much will it cost?
• Who will do it?

Four Major Project Constraints
Effort Scope
Budget Resource
s
Scope
• Impossible to create a valid estimate for a project
without a solid understanding of the scope
• Traditionally, scope is measured in functions
performed
• BI projects should be measured by data elements
–Analysis and preparation of data takes much longer
–Assume 80% effort for data and 20% effort for function
Note: It is not reasonable to request a significant scope change to a carefully

deliberated and agreed-upon project plan without adjusting any of the
other constraints.

Project Risks
• Every project has risks
• Risks are unavoidable
• Use the Risk Assessment generated in Stage 1 (Business case
analysis)
• Depending on the likelihood and the impact on the project a
mitigation and/or contingency plan should be in the project
plan
– Triggers are situations that signal a potential, perhaps imminent
materialization of a risk
– The mitigation plan specifies what action the project team can take to
prevent the risk from materializing
– The contingency plan specifies alternatives in case the risk does
materialize

Project Risks
• Common project risks
– Lack of management commitment
– Lack of business participation
– Imposed, unrealistic schedule
– Unrealistic scope for the schedule
– Unrealistic budget
– Unrealistic expectations
– Untrained or unavailable staff
– Constantly changing business priorities
– Ineffective project management
– Limited scalability

Constraints
• All projects are subject to the same project
constraints: Effort, Scope, Budget & Resources
• In reality, there is a fifth constraint: Quality
• Quality and Effort (time) are polarized constraints
–Higher quality requires more effort
–Since time is a driving factor for most originations,
Effort always has top priority
Note: For a BI project, quality should have a higher priority than
any other constraint: Quality, Effort, Scope, Budget &
Resources

Assumptions
• Anything taken for granted
• (Wrong assumptions become risks)
• Important assumptions should have a
counterpart risk, identifying triggers, a
mitigation plan and contingence plan

Change Control
• Manage change
• Curb scope creep
• Change (unless minute) always impacts the project
– Effort (time), Scope and Quality
– Sometimes Budget and Resources
• Changes should be submitted to change control board
• Changes must be logged and reviewed/approved by Change
Control Board and tracked in project meetings
• Change log of the following information should be kept and
updated: Change number, Change date, Change description,
Status (approved, not approved or deferred), Current status or
Resolution and Closed date

Change Control Board
• Each change that must be added to a project
requires a business decision:
– Cut back on the current scope
– Extend the deadline
– Declare the change “not applicable” to the current
release and postpone it
– Incorporate the requested change in the next release
– Eliminate complicated transformations, edit checks,
and testing (impacts Quality)

Issues Management
• Issues, related to business or technical concerns,
always occur during a project
• Issues need to be tracked and managed
• Every issue needs to be assigned to a person who has
the responsibility to get resolution
• Issues must be logged and reviewed and tracked in
project meetings
• Issue log of the following information should be kept
and updated: Issue number, Issue date, Issue
description, Assigned to, Action taken, Action Date,
Resolution and Closed date

Planning the BI Project
• Not a one-time activity
• Estimates must be adjusted frequently
• The more detail you have in the first version of the project plan, the easer it will be
to manage the project
• Sequence of activities for preparing a project plan (software available for these
activities)
– Create a work breakdown structure (WBS) listing activities, tasks and subtasks
– Estimate the effort hours for each activities, tasks and subtasks
– Assign resources for each activities, tasks and subtasks
– Determine the task dependencies
– Determine the resource dependencies
– Determine the critical path based on the dependencies
– Create the detailed project plan
• Expect to revisit and rework the plan often based on development activities
• Needs to be revisited when a Change is approved for this project by the Change
Review Board

Estimating Techniques
• Historical, based on learned patterns (how long
it took on the last project)
• Intuitive, based on intuition and experience
(“gut” estimating)
• Formulaic, based on the average of possibilities
Best Estimate + (Average Estimate X 4) + Worst Estimate

6

Resource Assignment
• Effort estimates cannot be completed until the
activities and tasks are assigned
• Estimates must take into consideration each
team member’s skill level
• Remember to take into account
– Administrative factors: meetings, other projects,
emails, in-baskets, training, etc.
– Non-work-related: vacation, illness, jury duty,
personal time off, medical appointments, holidays

Task Dependencies
• Not all activities and tasks have to be performed serially
• Many can be performed in parallel
• Identify task dependencies:
– Finish to Start Finish to Start Start to Start
– T2 cannot start until T1 finishes
Task 1 Task 1
– Start to Start
– T2 can start with T1 Task 2 Task 2
– Finish to Finish
– T2 cannot finish until T1 finishes Finish to Finish Start to Finish
– Start to Finish
Task 1 Task 1
– T2 cannot finish until T1 starts
Task 2 Task 2

Project Schedules
• Once you have all the tasks, resources,
dependencies and estimates you can create a
project schedule
• Creating a useful plan requires effort
• Once done adjusting it is not labor intensive
• Using a proper software tool, any changes
automatically cascade through the entire project
• Get a skilled Project Manager

Planning Activities
1. Determine project
requirements
2. Determine condition
of source files
and database
3. Determine or revise 5. Identify Critical 4. Revise risk

cost estimates Success factors assessment
6. Prepare project 7. Create high-level

8. Kick off project
charter project plan

Planning Deliverables
• Technical infrastructure report
– Scalability & Limitations: Servers, Workstations,
OS, Middleware, Network, DBMS, Software, etc.
• Non Technical infrastructure report
– Standards, Methodology, Estimating guidelines,
Scope management, Issues management,
Roles/Responsibilities, Security process, Meta data
capture, Process for merging logical data, Data
quality, Testing process, SLA’s, Support, Dispute
resolution, Communication process, etc.

Planning Deliverable (continue)
Project Charter
• Represents the agreement between the IT staff and
business sponsor
– Goals and objectives
– Statement of business problem
– Proposed BI solution
– Results from cost-benefit analysis
– Results from the infrastructure gap analysis
– Functional project deliverables
– Subject areas to be delivered
– High-level logical data model
– Items not within the project scope

Planning Deliverable (continue)
Project Charter (continue)
– Condition of the source files and database
– Availability of security requirements
– Access tool requirements
– Roles and responsibilities
– Team structure (core and external)
– Communication plan
– Assumptions
– Constraints
– Risk assessment
– Critical Success Factors
Project Plan
– i.e., WBS, Pert chart, Gantt chart, task estimates, task dependencies and
resource dependencies
– Hint: Use a project planning tool

Stage Three
Business Analysis

Stage Three: Business Analysis
(4) Project Requirements Definition
– Manage Project Scope (avoid everything instantly)
– Plan for change (change control board)
(5) Data Analysis
– Quality and source of data
– Learn what you have – consolidate and reconcile
(6) Application Prototyping
– System Analysis
– Prove or disprove a concept or an idea
– Allows the business people to see the potential and the limits of the
technology
(7) Meta Data Repository Analysis
– Technical meta data needs to be mapped to the business meta data
– Can be licensed (bought) or built (from internal systems)

Project Requirements Definition
• General Business Requirements
• Project-Specific Requirements
• Get input from users
• Get input from business management
• Create application requirements document

Requirements Documents
General Business Project-Specific
Purpose Determine the general Define the specific functions and
business need delivery date
Interviewees •Business executives •Business sponsor
•IT managers & staff •Business representative
•Line-of-business managers •Knowledge worker/Business
•Subject matter experts analysts
(SME) •Subject matter expert (SME)
Deliverable Business requirement report Application requirements document
Content of •Findings •Functional requirements
deliverable •Issues •Data requirements
•Opportunities •Data-cleansing requirements
•Recommendations •Performance
•Next steps •Security
•Availability
Project Requirements Definition Activities
1. Review project scope
7. Define preliminary
6. Expand logical
service-level
data model
agreements
8. Write application
requirements
document
2. Define requirements 3. Define requirements

for non-technical for technical 4. Define reporting 5. Define requirements
infrastructure infrastructure requirements for source data
enhancements enhancements

Data Analysis
• Bring business data together from multiple sources
• Business-focused data analyses
• Top down logical data modeling
– Integrate enterprise logical data model data-specific
business meta data components
• Bottom up source data analysis
– Transformation rules, technical data conversions, business
data domain rules and business data integrity rules
• Data Cleansing Activities

Top Down Logical Data Model
• Logical data model (AKA Enterprise Logical Data Model)
– Unique identifiers
– Correctly named
– Properly defined
• Validated for all business people who access the data
• Formal representation of the data exactly as it exists
without redundancies and ambiguity
• A logical data model, representing a single-cross
organizational business view of the data

Top Down Logical Data Model
• Standardized Business Meta Data defined:
– Name (no synonyms & no homonyms)
– Definitions (description of the data)
– Relationship (business associations/rules/policy)
– Type (structure: character, number, decimal, date, & time)
– Length (size)
– Content (available values)
– Rules (content of the data)
– Policy (content and behavior)
– Ownership (who can establish and control the data)

Bottom Up Source Data Analysis
• Defining the source data files
• You will find business rules violations and
some data quality issues
• Map the source data elements to the new top
down logical data model
• Decide what elements of the source data can
build the new top down logical data model

Bottom Up Source Data Analysis
• Typical problems in the source data
– Missing data values
– Strange “default” values i.e., 999999, 9/9/9999
– Intelligent “dummy” values i.e., 888-88-8888
– Cryptic or overused values i.e., letters to define
customer type

Final Source Data Selection Process
• Identify the required data (logical data model)
• Analyze the data content (source data)
• Select the data for BI
• Prepare the data cleansing specifications
• Identify the ETL cleansing requirements
1. Identify the required data
2. Analyze data content
3. Select data for BI
4. Prepare data cleansing specifications
5. Select tool or method

Data Analysis Activities
1. Analyze external
data sources
2. Refine logical 6. Write data- 3. Analyze source

data model cleansing specifications data quality
4. Expand enterprise 5. Resolve data

logical data model discrepancies

Application Prototyping
• If time & budget permits
• Prototyping can be effective way to validate
application requirements
• Can find missing pieces & discrepancies in the
requirements
• Verifies the selected DBMS and/or tools
• Limited time period
• Limited scope
• Choose the correct data

Types of Prototyping
• Show-and-tell (Demo)
• Mock-up (simple throwaway)
• Proof-of-concept (explores implementation risks)
• Visual-Design (complex mock-up)
• Demo Prototype (sophisticated show-and-tell)
• Operational prototype
– Most involved, most complete & almost fully functional
– Functioning pilot (alpha/beta release)

Application Prototyping
Activities
1. Analyze access
Requirements
2. Determine scope 4. Prepare 3. Select tools

of prototype prototype charter for prototype
5. Design reports
6. Build prototype 7. Demo prototype
and queries

Meta Data Repository Analysis
• Database
– Meaning & content of the business data
– Policies that govern the business data
– Technical attributes of the business data
– Specifications that transform the business data
– Programs that manipulate the business data

Business Meta Data vs. Technical Meta Date
Business Meta Data Technical Meta Data

Provide by business people Provided by technicians or tools
Documented in business terms Documented in technical terms
on data models in databases, files, programs &
tools
Used by business people Used by technicians, databases,
programs & tools
Names fully spelled out in Abbreviated names (as the rules
business terms of the database dictates)

Data Standardization
• Every BI project must address the existing
data chaos
• Pull together all existing documentation &
create documentation where missing
• Building a proper BI database is not a trivial
task
• Be aware of missing data!
Note: Lack of data is a frequent reason used for BI application failure

Meta Data Repository Analysis Activities
1. Analyze meta data

repository requirements
2. Analyze interface 3. Analyze meta data

4. Create logical
Requirements for repository access &
meta data model
meta data requirements reporting requirements
5. Create physical
meta data model

Business Analysis Deliverables
• Project Requirements
– Applications Requirements Document
• Technical & Non-Technical infrastructure
• Reporting requirements
• Requirements for source data
• Data cleansing requirements
• Security requirements
• Data Analysis
– Logical & Business data model
– Data cleansing specifications
– Document enterprise logical data model

Business Analysis Deliverables (continue)
• Prototype Charter
– Purpose
– Objectives
– Data used
– Hardware & Software
– Measure of successes
– Application interface
• Completed prototype
• Revised application document
• Issues Log/Lessons Learned
• Logical & Physical data models

Stage Four
Design

Stage Four: Design
(8) Database Design
– Store the business data
– Detailed or Aggregated forms
– Must match the information access requirements of the
business user
(9) Extract/Transform/Load (EDL) Design
– Most complicated/Least glamorous part of the project
– Cleansing and transformation of the source data
– Data quality
(10) Meta Data Repository Design
– Has to meet the requirements of the logical data model

Database Design
Operational Database BI Database
Geared towards eliminating Geared towards supporting a wide
redundancies, coordinating updates range of queries & reports
and repeating same types of
operations
Sub-second response time Sub-second cannot be expected
Highly normalized to support Highly de-normalized to provide
consistent updates quick retrieval of a wide range of
large amounts of data
Data is usually deliver when needed Store large amounts of data to save
time on delivery
Historical records are archived Store large amounts of historical data
Lightly summarized, mostly for Many levels of pre-calculated
reporting purposes summarized data – from lightly
summarized to highly summarized
BI Target Databases
• BI databases are designed for simplicity
• High-performance data retrieval
• Not for efficient data storage & maintenance
• Eliminate or minimizing data redundancies is not a
goal – but must be controlled
• Readily accessible
• Design is driven by access and usage
• Intuitive for a business person
• BI data must be derived from current internal or
external data sources

Physical Database Design
• BI databases can be enormous
• Consider indexing (B-tree, inverted files, etc.)
• Remember to factor in backup and recovery

Database Design Activities
1. Review data
access requirements
2. Determine
aggregation
requirement
6. Develop database
3. Design BI 4. Design physical 5. Build BI target
maintenance
target database database structure database
procedures
7. Prepare to monitor
8. Prepare to monitor
& tune database
& tune query design
design

Extract/Transform/Load (ETL) Design
• Build a loading process in which all BI target databases are
integrated & reconciled
• Integrated strategy – one common database for all the data
regardless of the source
• One common ETL procedure
– Reformat
– Reconcile
– Cleansing
• Set of ETL programs
– Initial Load (from current operations)
– Historical load (from archive data)
– Incremental load (daily batch data)

ETL Process
Customer E T
T
E R
Accounting X E A T L
T N
O
R S
A
A F BI Target
D
C E O T Database
Inventory
T R
M
Orders E T

ETL Design Activities
1. Create source-to-
target mapping
document
2. Test ETL tool 3. Design ETL

function Process flow
4. Design ETL 5. Set up ETL

programs staging area

Meta Data Repository Design
• Meta data repositories used to be called data
dictionaries
• Design is based on database chosen

Meta Data
A definition and classification of the various levels of end user meta data.
Level Level Name Genesis

5 Report data Within a report, data is manipulated into a format that is
required.
4 Business intelligence data Data which has been extracted by a BI application. This data
may be manipulated using business rules.
3 Transformed data Data that has been transformed using business rules into a
format that is meaningful and is stored within a database.
2 Cleansed data Data which has been processed through a cleansing routine
which standardizes the format and is stored within a database.
1 Source system data Data which has been migrated from several source systems
into one database and is commingled.
0 Migrated data Data which has been entered or processed by an online
transaction processing application.
Note: While the levels define the transgression of data from its origin to a report, the complexities of each
level can have a significant impact on the definition of the data. Please note that not all levels of end-user meta
data are encountered by an individual using a BI application.

ETL Design Activities
1. Design meta data
repository database
or
2. Install/test meta
data repository product
3. Design meta data 4. Design meta data

migration process application

Design Deliverables
• Database Design
– Physical data model
– Physical design of the BI target database
– Data definition
– Physical BI target database
– Database maintenance & procedures (backup)
• ETL Process
– Source-to-target mapping document
– ETL process flow diagram
– ETL program design document
– ETL programming environment description
• Meta Data Repository
– Physical data model
– Data definition (data dictionaries)
– Data control language (MV Access statements)
– Data repository programming specifications (programming logic)

Stage Five
Construction

Stage Five: Construction
(11) Extract/Transform/Load (ETL) Development
– Build the programs based on ETL Design
(12) Application Development
– Based on the prototype or finalized design
– Can be done in parallel with ETL Development
(13) Data Analysis
– Uncover the hidden information in the data
(14) Meta Data Repository Development
– Implement the database design

ETL Development
• Source data transformation
• BI projects present the best opportunity to
eliminate useless data
• Data transformation activities
– Cleansing/Clean data
– Summarization/Condensed data
– Derivations/New data
– Aggregation/Complete data
– Integration/Standardized data

Reconciliation
• Common complaint: BI target database does
not match the operational source files
• Reconciliation Process
– Record counts
– Domain counts (unique data values)
– Amount counts
• Prove the BI data is correct or business users
will not trust the results

ETL Testing
• Formal test plan
– Purpose
– Schedule
– Test cases
– Test log
• Unit tests (does it work)
• Integration tests (do the programs run together)
• Regression tests (did the new programs break original code)
• Performance tests (does the program perform with volumes)
• Quality Assurance tests (documentation an affect on other
programs)
• Acceptance tests (does the application work)

ETL Development Activities
1.Build & unit test
ETL process
2. Integration or
3. Performance test
regression test ETL
ETL process
process
4. Quality assurance 5. Acceptance test

ETL process ETL process

Application Development
• Online Analytical Processing Tools
– Many
– Popular features:
• Multidimensional views
• Summarizations & Aggregation
• Query & Analysis capabilities
• Business Analysis
• Drill-down, Roll-up and Drill Across
• Trend Analysis
• Display data in Charts & Graphs

Development Environments
• Prototyping
• Development Environment
• QA Environment
• Production Environment

Application Testing
– Purpose
– Schedule
– Test cases
– Test log
• Regression tests (did the new programs break original code)
• Performance tests (does the program perform with volumes)
• Quality Assurance tests (documentation an affect on other
programs)

Application Development Activities
1. Determine final
project requirements
2. Design application 3. Build & unit test

programs Application programs
4. Test application 5. Provide data access

programs & analysis training

Defining Data Analysis
• Blend of Components
– Intelligence
– Pattern Recognition
– Databases
– Traditional Statistics
– Graphics
– Present hidden relationships & patterns in the data
pool

Data Analysis Tools
• Executive Information System (EIS)
• Query & Reporting tools
• Statistical tools
• Online Analytical Processing (OLAP) tools

Data Analysis Activities
1. State business
problem
3. Consolidate &
2. Collect data 4. Prepare data
cleanse data
5. Build analytical
data model
6. Interpret data 7. Perform external 8. Monitor analytical

analysis results validation of results data model over time

Meta Data Repository Development
• Populating a Meta Data repository
• Receives most of its Meta Data from sources
• Data sources
– Spreadsheets
– Case tools
– Internal databases (dictionaries)
– ETL tools & programs
– OLAP tools & programs
– Data Analysis tools
• Meta Data repositories are active
• Prepare for rollout

Meta Data Repository Testing
– Purpose
– Schedule
– Test cases
– Test log
• Regression tests (did the new programs break original
code)

Meta Data Repository Devlopment Activities
1. Build meta data

repository database
2. Build & unit test 4. Test meta data

3. Build & unit test
meta data migration repository programs
meta data application
process or functions
5. Prepare meta
6. Provide meta data
data repository for
repository training
production

Construction Deliverables
ETL Development
– ETL Test plan
– ETL Programs
Application Development
– Application design document
– Application test plan
– Application programs
– Training materials
Data Analysis
– Database
– Analytical model
Meta Data Repository Development
– Physical Meta Data Repository Database
– Meta Data Repository test plan
– Meta Data Repository Programs
– Meta Data Repository documentation
– Meta Data Repository training materials

Stage Six
Deployment

Stage Six: Deployment
(15) Implementation
– Rollout of the database and application
– User training
– Support functions begin (help desk, database backup,
operations)
– Monitoring of performance and database tuning
(16) Release Evaluation
– Lessons learned
• Any missed deadline, cost overruns, disputes, dispute resolutions
should be examined and processes adjusted for future projects
• Any tool, techniques, guidelines and processes that were not
helpful should be reevaluated and adjusted or discarded

Implementation
• Incremental rollout
– Small group
– Training & support
– Consider another test – perhaps adjust application
• Security management
– Test security policy's
– Secure at file/table level may not be enough
– Consider program control
– Network security – review network architecture
– Look for security gaps
• Password violations
• Data security
– Security for internet access
• Authentication (user ID & password)
• Authorization (access to resource)
• Encryption (encrypt data from server to workstation)

Implementation
• Data backup & recovery
– Full backups
– Incremental backups
– Partial backups
• Monitor utilization of resources
– Computer utilization
– Network utilization
– Personnel – who is using what & when
• Monitor Growth
– In data
• Calculate average daily growth
• Remember to calculate any indexing
– In usage
– In hardware

Implementation Activities
1. Plan
implementation
2. Set up production 3. Install all BI 4. Set up production

environment application components schedule
5. Load production
database
6. Prepare for
ongoing support

Release Evaluation
• Nothing works 100% the first time
• The application release concept/guidelines
– Schedule release every 3-6 months
– Small & manageable deliverables
– Manage expectations
– The first release should deliver the basics
– Management must accept a partial delivery
– Everything is negotiable (scope, schedule, budget, resource & quality
– Infrastructure must be robust
– Data must be an integral part of each release
– Change control procedure
• New requirements
• Defects
• Review deferred functions/data/change

Post Implementation Review
• Measure Success / Problems / Failures
– Schedule
– Budget
– Scope
– Staffing
– Skill & training
• Plan for the next release
– Review Topics:
• Project planning & reporting
• Development approach
• Contractors, consultants & vendors
• General communications
• Lessons learned

Release Evaluation Activities
1. Prepare for post-
implementation review
2. Organize post- 3. Conduct post-

implementation review meeting implementation review meeting
4. Follow up on
post-implementation review

Development Deliverables
• Implementation
– Production Code
• ETL
• Application
• Database
• Data Repository
– Production Documentation
• Release Evaluation
– Post implementation review agenda
• Remember to review all deferred change requests
– Post implementation meeting minutes
– Create action item list
– Produce lessons learned report
– Save actual work efforts (time) for future projects estimates

Stage
QED
Quod Erat Demonstrandum
(Latin: Which Was to Be Demonstrated)

BI Project

Uploaded by

Copyright:

Available Formats

BI Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BI Project

Uploaded by

Copyright:

Available Formats

Business Intelligence

September 2006 © 2006. Via Systems, Inc. 1

September 2006 © 2006. Via Systems, Inc 2

September 2006 © 2006. Via Systems, Inc 3

September 2006 © 2006. Via Systems, Inc 4

September 2006 © 2006. Via Systems, Inc 5

September 2006 © 2006. Via Systems, Inc 6

September 2006 © 2006. Via Systems, Inc 7

September 2006 © 2006. Via Systems, Inc 8

September 2006 © 2006. Via Systems, Inc 9

September 2006 © 2006. Via Systems, Inc 10

September 2006 © 2006. Via Systems, Inc 11

September 2006 © 2006. Via Systems, Inc 12

September 2006 © 2006. Via Systems, Inc 13

September 2006 © 2006. Via Systems, Inc. 14

September 2006 © 2006. Via Systems, Inc 15

September 2006 © 2006. Via Systems, Inc 16

September 2006 © 2006. Via Systems, Inc 17

September 2006 © 2006. Via Systems, Inc 18

September 2006 © 2006. Via Systems, Inc 19

September 2006 © 2006. Via Systems, Inc 20

September 2006 © 2006. Via Systems, Inc 21

3. Access operational sources 4. Access competitors BI

7. Perform cost benefit

9. Write assessment report

September 2006 © 2006. Via Systems, Inc 22

September 2006 © 2006. Via Systems, Inc 23

September 2006 © 2006. Via Systems, Inc. 24

September 2006 © 2006. Via Systems, Inc 25

September 2006 © 2006. Via Systems, Inc 26

September 2006 © 2006. Via Systems, Inc 28

September 2006 © 2006. Via Systems, Inc 29

1. Assess existing platform

2. Evaluate and select

September 2006 © 2006. Via Systems, Inc 31

September 2006 © 2006. Via Systems, Inc 32

September 2006 © 2006. Via Systems, Inc 33

September 2006 © 2006. Via Systems, Inc 34

September 2006 © 2006. Via Systems, Inc 35

Note: It is not reasonable to request a significant scope change to a carefully

September 2006 © 2006. Via Systems, Inc 37

September 2006 © 2006. Via Systems, Inc 38

September 2006 © 2006. Via Systems, Inc 39

September 2006 © 2006. Via Systems, Inc 40

September 2006 © 2006. Via Systems, Inc 41

September 2006 © 2006. Via Systems, Inc 42

September 2006 © 2006. Via Systems, Inc 43

September 2006 © 2006. Via Systems, Inc 44

September 2006 © 2006. Via Systems, Inc 45

Best Estimate + (Average Estimate X 4) + Worst Estimate

September 2006 © 2006. Via Systems, Inc 46

September 2006 © 2006. Via Systems, Inc 47

September 2006 © 2006. Via Systems, Inc 48

September 2006 © 2006. Via Systems, Inc 49

3. Determine or revise 5. Identify Critical 4. Revise risk

6. Prepare project 7. Create high-level

September 2006 © 2006. Via Systems, Inc 50

September 2006 © 2006. Via Systems, Inc 51

September 2006 © 2006. Via Systems, Inc 52

September 2006 © 2006. Via Systems, Inc 53