Scope and Schedule Management of

Business Analytics Project

Kamal Deep 12810041Kaushik Dutta 12810044Sharad Srivastava 12810076Siddharth Dikshit 12810078

Gro

up -

4

Introduction

Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the scope is primarily concerned with defining and controlling what is and is not included in the project.

Meaning of Scope Management

The process of formalizing acceptance of the completed project deliverables.

The process of defining and documenting stakeholders’ needs to meet the project objectives.

The process of subdividing deliverables and project work into smaller manageable components.

The process of monitoring the status of the project and the product scope and manage changes to the scope baselines.

The process of developing a detailed description of the project and the product.

Overview of Project Scope Management

Project Schedule Management is the process of analyzing activity sequences, durations, resource requirements and schedule constraints to create the project schedule.

Develop Schedule: Inputs and Outputs

Project Schedule Management

Business Analytics Project

Business analysis is a mindset that focuses on which are at the core of all the things we need to think about. Business analysis is the conduit between the requested outputs and the solution created to address the identified need. Hence business analytics projects are where the extensive use of data, statistical and quantitative analysis, explanatory and predictive models and fact-based management are done to drive decisions and actions.

Business Analysis Framework

Who?: The Stakeholders, Sponsors, What?: Rapid planning, documentation, Why?: Managing and completing project, When?: Project Management Process, How?: Managing scope and team, Where?: Project Management Team place

Benefits of Business Analytics Project

Improving the decision-making process (e.g., quality and relevancy of decisions)

Speeding up the decision-making process Better align resources with strategies Realizing cost efficiencies Responding to user needs for availability of data on a timely basis Improving organization’s competitiveness Producing a single, unified view of enterprise wide information Synchronizing financial and operational strategies Sharing information with a wider internal audience (e.g., casual users) Maintaining regulatory compliance Sharing information with external users (e.g., customers and suppliers)

Business Analytics Project Requirement

Business analytics projects have multiple layers, all of which might need to have software requirements defined for them. These projects must deal with the data itself, the operations performed on the data, and the formatting and distribution of the data for use.

Process to Define Business Analytics Project Requirement

Prioritize work by using decisions: Describe the business decisions, link those decisions to the project’s business objectives and decompose the decisions to discover the questions that need to be answered. Determine how analytics could be applied to assist in making these decisions.

Define how information will be used: To find how the information will be used so that the correct data is transformed as needed and delivered to the interfacing system in a usable form.

Specify data needs: It involve identifying new data sources to analyze and to understand the data requirements, so that technical teams can design the often complex infrastructures needed to support analytics.

Define analyses that transform that data: Defining the necessary data analysis involves big-picture thinking and analytics results lead to decision-making capabilities ranging from descriptive to predictive.

Challenges for Business Intelligence Project

Lack of a Business Intelligence Vision

Insufficient visibility to the “Big Picture”

Inexperience resources

Inability to make ‘meaningful’ incremental deliverables

Lack of adoption by the business users

Scope Management

Scope Definition for Business Intelligence Project

Definition Continued - Scope involves getting information required to start a project, and the features the product would have that would meet its stakeholders requirements.

Project Scope - “ The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.“ Product Scope - “ The features and functions that characterize a product, service, or result.”

Note - Project Scope is more work-oriented, (the hows,) while Product Scope is more oriented toward functional requirements. (the whats.)

ITPM Definition – IT Project management Scope definition clearly states what all is included in Project and what all is not included in it (in terms of Deliverables/Output)

Scope Statement – Example (Generic)

Department/Agency: [Dept. Name]Issue Date: [Date]Project Name: [Project Name]Project Sponsor: [Sponsor Name]Project Contact contact must be a state employeeContact Phone: (xxx)xxxxxxxContact Email: xxxxxxxxxxxxTechnology Services Contract Attachment: xxxxxxxxxxxxDue Date for Statement of Work: [Time & Date]

Scope Statement Purpose

State briefly what this scope statement is for. Keep only this section on this page for clarity

The Scope Boundary

Scope Management for Business Intelligence Project

Deliverables Included/Project includes – Case Study Scope

– Install EPM, OBIEE – Extract data from the PS transactional system using ETL. – Using delivered data marts in each EPM pillar, create a proof of concept. – Using delivered and custom data marts, demonstrate research reporting and

dashboards. – Expand the POC of the Research Reporting in phase II. – This project is implemented in phases and the methodology is detailed in

Oracle’s Ordering – Document found in the Appendices provided within the Project Charter.

Deliverables Excluded/Project doesn’t includes –

Scope Management and Controlling (with documentation) for BI Project

Scope Verification Check List – MOV, Deliverables, Quality Standards, Milestones, Review and Acceptance

Scope Change Control - Keeps the “triple constraint” in balance. i.e. Scope, Schedule and Budget.

Project-Oriented Scope Definition Tools – Deliverable Definition Table (DDT) Deliverable Structure Chart (DSC)

Possible Scope Overshoots in ITPM – Scope Grope – i.e., scope poorly defined Scope Creep – i.e., increasing featurism Scope Leap – i.e., drastic change in project direction or the project’s MOV.

• Case Study – Scope Creep in BI Project• Reference - Scope• Focus - Scope Creep • Learning - Effects of Scope Creep

Learning from Scope Creep

Scope creep extends the project schedule Increase project cost Delay perceived value system Define requirements well Enforce change management process Document everything Get formal approval from customer for all changes

Key from Scope Creep

What are the effects to of Scope Creep? Extend your project schedule Increase your project cost Delay perceived system value

Scope Change Control Tools –

Scope Change Request Form Scope Change Request Log

Scope Approval Document (Performa Copy)

Example of a Scope Change Request Log

Scope Approval Document (Performa Copy)

Note: Any work not explicitly included in the Project Scope Statement is implicitly excluded from the project.

Scope Change Document (Performa Copy)

Schedule Management

Scheduling in Business Analytics Project

The following should be considered when determining the value and ultimately the Return on Investment (ROI) of a BI project:

Increased Income: better customer retention, better sales management, etc.

Decreased cost: better utilization of analyst time, shutting down legacy systems, identifying less expensive vendors, etc.

Decreased Risk: accurate regulatory reporting, fraud detection, quicker identification of problems, etc.

Work Breakdown Structure (WBS)

Define the major project tasks, and then decompose the tasks into sub tasks. In this step, we must know to achieve the task, what job need to finish? While these “job” are performed throughout the whole process of the real estate project.

Identify each deliverable to the level of detail with the preparation of the budget and cost, and clear the required resources.

Work packages: Make sure all work packages can be detected and allocated. The result quantified performance of the work packages can be tested. It is convenient for inspection.

When appropriate and necessary inspection decomposition, that is, the bottom of the decomposition is appropriate and necessary.

An Effective WBS

• Is a deliverable-oriented grouping of project elements • Is created by those doing the work • Contains 100% of the work defined by the scope or contract and captures all deliverables

(Internal, External, Interim) in terms of work to be completed, including Project Management

• Defines the context of the project, clarifies the work and communicates project scope to all stakeholders

• Is expressed as an illustration, chart or outline, providing a graphical or textual breakdown • Arranges all major and minor deliverables in a hierarchical structure - and is constructed so

that each level of decomposition contains 100% of the work in the parent level • Should contain at least 2 levels • Uses nouns and adjectives – not verbs • Evolves along with the progressive elaboration of project scope, up to the point of scope

baseline, and thereafter in accordance with project change control - allowing for continual improvement

• Employs a coding scheme for each WBS element that clearly identifies the hierarchical nature of the WBS when viewed in any format

WBS Process

Continued…

WBS Chart Pro

Function Point Analysis

Challenges in Scheduling

Neglecting to create WBS Dictionary

Expecting More than 100% from WBS

Ignoring the Change Management Control

WBS should be outcome oriented and not prescriptive of methods.

To-do list mentality gives rise to micro management

Skipping the buy-in or limited inputs from experts

Too many tasks ultimately results in mismanagement.

Risk Breakdown Structure

Schedule Control: Process

Capture the current schedule status.

Determine the variance from the schedule baseline.

Understand the nature of the variance and its causes.

Respond by taking appropriate action.

Schedule Control: Output

• Work performance measurements

• Organizational process assets updates

• Change requests

• Project management plan updates.

• Project document updates.

Schedule Control: Tools & Techniques

Variance Analysis

Control Schedule using Project Management Software

Performance Review

Resource Levelling

What-if Scenario

Schedule Compression

Scheduling Tool

Case Study

Overview of the Case

The case will explain the scope and schedule management of a Data Warehouse – Business Intelligence implementation. This project will move the University to a more structured data and strategic decision support system. The organization of the project will reflect the need to not only extract information in usable ways but to correlate it across multiple dimensions.

Where: University of Akron

Objective: Facilitate better strategic and tactical decision

Project Scope

Install EPM, OBIEE Extract data from transactional system using ETL (Extract, Transform, Load) Using delivered data marts in each EPM pillars, create a proof of concept. Using delivered and custom data marts, demonstrate research reporting and

dashboards. Expand POC of research reporting in second phase.

EPM: Enterprise Performance Management (PeopleSoft)OBIEE: Oracle Business Intelligence Enterprise Edition

EPM Pillars: Campus Solutions Warehouse (CSW) Human Capital Management (HCM) Financial Management Systems (FMS)

Project Deliverables

Project Approach

Scheduling and Milestones

Adobe Acrobat Document

The project will be implemented in three phases.

Deliverables, Milestones and Quality Standards will serve as a part of Scope Verification.

Project Sponsor will be responsible for approving the scope change.

Project Scope Change Control

Only the UA Project Manager and the designated Oracle Project Lead can submit a request for a change to address additional requirements.

For UA-generated change order requests, the UA and Oracle Project Lead will inform UA within 5 business days if Oracle does not have resources to prepare a response to the request in a timely manner.

For non-complex requests, the time period to respond to the change order request will generally be within 4 business days, and the time period for more complex change orders will be 10 business days.

If Oracle notifies that it does not have sufficient resources currently to respond to the change order request, then Oracle shall indicate when it will respond, not to exceed 14 business days or longer period as agreed by the UA Project Manager.

Project Scope Change Control

For UA-generated change order requests, Oracle will analyze and report back to the UA PM on the impact of the change order request relative to project timing, cost, resource allocation and other aspects that may adversely affect the project.

If there is agreement on the response, the parties shall execute a change order to reflect the change and amend the Exhibit if there is a change to the scope, schedule or resources.

If there is not agreement, the matter will be referred to the change control board, and the change control board will evaluate the request. The change control board will be comprised of project Executive Sponsor, the UA Project Manager, designated Oracle Project Lead and one other person designated by Oracle who is associated with the project, and may be the Oracle Executive Sponsor.

If the change control board wants to accept the change order request and Oracle is not in agreement, the matter shall be referred to dispute resolution.

Thank You !!