1. Scope and Schedule Management
of
Business Analytics Project
Kamal Deep 12810041
Kaushik Dutta 12810044
Sharad Srivastava 12810076
Siddharth Dikshit 12810078
Group-4

2. Introduction

3. 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

4. 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

5. 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

6. 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.

7. 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

8. 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)

9. 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.

10. 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.

11. 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

12. Scope Management

13. 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)

14. 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 employee
Contact Phone: (xxx)xxxxxxx
Contact Email: xxxxxxxxxxxx
Technology Services Contract Attachment: xxxxxxxxxxxx
Due 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

15. The Scope Boundary

16. 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.

17.  Deliverables Excluded/Project doesn’t includes –


18. 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)

19. 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

20. 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

21. Scope Approval Document (Performa Copy)
Example of a Scope Change Request Log

22. Scope Approval Document (Performa Copy)

23. Note: Any work not explicitly included in the Project Scope Statement is implicitly excluded
from the project.
Scope Change Document (Performa Copy)

25. Schedule Management

26. 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.

27. 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.

28. 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

29. WBS Process

30. Continued…

31. WBS Chart Pro

32. Function Point Analysis

33. 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.

34. Risk Breakdown Structure

35. 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.

36. Schedule Control: Output
• Work performance measurements
• Organizational process assets updates
• Change requests
• Project management plan updates.
• Project document updates.

37. Schedule Control: Tools & Techniques
 Variance Analysis
 Control Schedule using Project Management Software
 Performance Review
 Resource Levelling
 What-if Scenario
 Schedule Compression
 Scheduling Tool

38. Case Study

39. 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

40. 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)

41. Project Deliverables

42. Project Approach

43. Scheduling and Milestones
 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.

44. 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.

45. 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.

46. Thank You !!