BI Project Business Intelligence Cookbook A Project Lifecycle Approach Using Oracle Technology John Heaton

A program or a project New a definition A program – This is defined as several interrelated projects that have a goal of improving an organization's performance A project – This is defined as a unique and temporary construct with a defined beginning and end, to meet a set of goals or objectives

Business culture 1.Open your Readiness Assessment Worksheet and add a new worksheet called Business Culture: 2. Create questions in the worksheet which focus on the way the organization has grown, the phase in which the organization is, information accessibility, tools availability, and so on. See the Readiness Assessment for more sample questions. 3. This time distribute the worksheet to a selective people within the organization at first to gain an understanding. 4. Collect responses to the questions and collate the information. 5. Set up follow-up meetings with the survey participants to review their answers.

Typical project delivery methodology phases

lightweight methodology

Project team

Then, By understanding the roles required for the project, you can effectively recruit your team and identify any gaps in your resource pool. Option 1: Model based on subject areas with multi- skilled resources. Option 2: Model based on resource specialized skills.

Option 1: Model based on subject areas with multi-skilled resources. Separate your team into business initiative and subject area resources:

Option 2: Model based on resource specialized skills. Separate your teams based on technology and business skills:

Establish the project Creating Definition work practice Creating Data Discovery work practice Creating Development work practice Creating Testing work practice Creating Promote work practice Creating Production work practice Building a standard work breakdown structure Identifying and quantifying the effort drivers Creating your estimation tool

Definition phase of a BI project

Data Discovery

Building a standard work breakdown structure

Create the estimation tool #1

Create the estimation tool #2 Three point estimation: Optimistic = base hoursx# Most likely = (base hoursx#)+15% Pessimistic = (base hoursx#)+25% Weighted Average with Estimate E = (optimistic+4 most likely+pessimistic)/6 Standard Deviation = (pessimistic–optimistic)/6 Confidence levels based on Weighted Average (E): E value is approximately 50% E value+SD is approximately 85% E value+1.645×SD is approximately 95% E value+2×SD is approximately 98% E value+3×SD is approximately 99.9%

Requirement Traceability Matrix Create the numbering system

Requirement Traceability Matrix List sub-categories

Requirement Traceability Matrix

RFMEA (Risk Failure Mode and Effect Analysis) Create your basic headings for your RFMEA or Risk Log: a. Risk ID is a unique number assigned to each risk. b. Risk event is a description of the risk. c. Likelihood is the probability that the risk event will occur. d. Risk score is the calculated and determined score of the risk event. e. Detection outlines the ability to detect a particular risk event. f. Risk Priority Number (RPN) calculates the priority of the risk event. g. Requirements # is the unique requirement ID that the risk is related to. The Requirements # is from the Requirements Traceability Matrix.

Likelihood: i. 9 or 10 – Very likely to occur ii. 7 or 8 – Will probably occur iii. 5 or 6 – Equal chance of occurring or not occurring iv. 3 or 4 – Probably will not occur v. 1 or 2 – Very unlikely

Impact – if one of the below is true then the impact is: vi. 9 or Schedule – impacts delivery of related component by > 25% OR 2. Cost – impacts cost of related component by > 25% OR 3. Solution – renders related component unusable vii. 7 or 8 1. Schedule – impacts delivery of related component between 10% and 25% OR 2. Cost – impacts cost of related component between 10% and 25% OR 3. Solution – changes the specification of the component which may only deliver partial requirements and may not obtain client approval

Impact – if one of the below is true then the impact is: viii. 5 or 6 1. Schedule – impacts delivery of related component between 5% and 10% OR 2. Cost – impacts cost of related component between 5% and 10% OR 3. Solution – changes the specification of the component which may only deliver partial/all requirements but will meet with client approval ix. 3 or 4 1. Schedule – impacts delivery of related component by < 5% OR 2. Cost – impacts cost of related component by < 5% OR 3. Solution – changes the specification of the component and the original scope of work and may require internal or client approval

Impact – if one of the below is true then the impact is: x. 1 or 2 - Very unlikely 1. Schedule – impact insignificant and can be absorbed OR 2. Cost – cost increase inconsequential or can be contained within current budget OR 3. Solution – changes are not noticeable

Detection xi. 9 or 10 –Cannot be detected or forewarned, therefore no contingency can be included xii. 7 or 8 – Detection method is available but not proven very difficult to identify and react within sufficient time xiii. 5 or 6 - Detection method is identified and has been used in the past with mixed success xiv. 3 or 4 - Detection method is well known and a moderate degree of effectiveness xv. 1 or 2 - Detection method is well known and has been very successful in the past

RFMEA a. Risk Score = Likelihood*Impact b. Risk Priority Number (RPN) = Likelihood*Impact*Detection

Issues Issue ID: A unique ID assigned to the issue Risk ID: The associated Risk ID the issue is related to Requirements #: The associated requirement # for the issue Decision/Action/Note: The decisions, actions, or notes for the issue Status: The status of the issue Description: The description of the issue Assigned To: The individual that the issue is assigned to Start Date: The date the issue was raised Planned End Date: The date the issue is expected to be resolved Comments: Any additional information for the issue

Create a defect and enhancement register #: This is the defect or enhancement number Type: This determines whether this is a defect or enhancement Test Script: This contains the test script which uncovered the issue Requirement # : This is the associated requirement Priority: This is the priority for the defect or enhancement Status: This is the status of the defect or enhancement Description: This is an outline of the defect or enhancement Test Release: This is the release in which the defect or enhancement was found Schedule Date: This is the date the defect or enhancement is scheduled to be completed Prod Release: This is the production release the defect or enhancement will be included into

Priority Critical: Should only be used when this causes a stoppage to activities on the project High: Realized risk or new issue that will have significant impact on the project if not solved Medium: Realized risk or new issue that will have moderate impact on the project if not solved Low: Realized risk or new issue that will have low impact on the project if not solved

Status New: New defect or enhancement. No action taken Open: Defect or enhancement is being worked on Test Migrate: Defect or enhancement is completed and ready for migration to test environment Test: Defect or enhancement has been migrated to a test environment and is ready for testing Prod Migrate: Defect or enhancement has passed testing and is ready for migration to production Prod Sign Off: Defect or enhancement passed testing in production and is ready to be closed Closed: Defect or enhancement is resolved Re-Open: Defect or enhancement does not pass testing and requires additional work

Create a cyclical build and test process

Release note Environment Release Number Requirements included in the release Defects included in the release Enhancements included in the release Requirements which did not make the release Defects which did not make the release Enhancements which did not make the release