Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project

Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project
Joyce Redmon International Paper Dr.Bjarne Berg Lenoir-Rhyne College

What We’ll Cover … The project preparation phase Organizing your team Setting and managing project scope Budgeting and prioritizing efforts Customization vs. standard content Ideas for quick-hit implementations The drivers for your project and legacy systems The strategic plan Wrap-up

Planning an SAP BW project can be quite intimidating
Introduction Planning an SAP BW project can be quite intimidating It is hard to decide where to start and how to scope, size, staff, and budget the project You also have to put processes in place that minimize the risks and leverage the standard content as much as possible This session will give you some ideas on how to approach the tasks of getting your BW project organized and create a strategic plan for your enterprise data warehouse We will keep a rapid pace and give you real examples to illustrate the topics.

Timelines and Staffing Plan: Lessons Learned …
Developer training should start early for all project team members SAP R/3 skills are not easily transferable to BW; hands-on experience is needed (it is very hard to learn while being productive) Quality is much more important than the number of team members A skilled BW developer can accomplish in one day what three novice developers can do in a week

Timelines and Staffing Plan: Lessons Learned … (cont.)
Project and cost estimates should be based on experience levels Plan on formal knowledge-transfer from external resources from day one. Link inexperienced with the experienced members. Have identified “go-to” resources available in all areas (make a list) Don't underestimate the benefits of having strong developer skills on your team – R/3 experience does not substitute for hands-on BW skills

Example: Small BW Project for Single Subject Area (e. g
Example: Small BW Project for Single Subject Area (e.g., Billing, Inventory, or Accounts Payable) These are roles, not positions; (sometimes one team member can fill more than one role). Detailed role descriptions are included with this presentation on the take-home Conference CD Basis and functional R/3 support 4-5 team members and normally 3-6 months duration, depending on scope

8-10 team members and normally 2-4 months duration depending on scope
Example: Mid-sized BW Project for Single Complex Subject Area (e.g., Cost and Profitability, Internal Billing) These are roles, not positions; (sometimes one team member can fill more than one role) Basis and functional R/3 support 8-10 team members and normally 2-4 months duration depending on scope

Example: Large BW Project for Multiple Subject Areas (e. g
Example: Large BW Project for Multiple Subject Areas (e.g., Sales, Finance, and Material Management) These are roles, not positions; (sometimes one team member can fill more than one role) Portal developer(s) BW Architect Business analyst/(sub-team lead) BW developer Presentation developer(s) ETL developer Sales Team Finance Team Material Mgmt. Team Project Manager Project sponsor/ Steering Committee Basis and functional R/3 support 15-25 team members and normally 6-18 months duration depending on scope

On-Boarding and Training
Ideal Years Training days In-house Experience (if new in the role ) training (minimum) days BW Developer 2+ 15 3-5 ETL Developer 3+ 15-20 3-5 Presentation Developer 1+ 5-10 3-5 Project Manager 5+ 10-15 3-5 Business Analysts 5+ 5-10 3-5 Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes

Accurate Resource Planning
Why Use Change Control? Accurate Resource Planning Reduces impact on other planned work Strategic staffing vs reactive staffing Make best use of resources Enforce consistency between business/process and development project plans (i.e., dates, case names) Ensure that previously approved scope is re-planned appropriately Shows responsiveness and provides a forum for new requests Effectively manage requested changes to completed work by ensuring good decision making and strong follow through on action plans.

You have only three dimensions to work with:
Defining the Scope For the first Go-Live, keep the scope as simple as possible, in an area with solid standard BW content (i.e., Accounts Payable, Accounts Receivable, G/L, or COPA) You have only three dimensions to work with: Caution Basic documents on the source system side – AP, Invoice, Order, Delivery are great places to start. R3 Finance content in BW is strong and fits most companies processes. Great place to start Who doesn’t want to visibility to money earned/profitability and money spent/expensed. If one of these dimensions changes, you have to adjust at least one of the others or the quality of your BW system will suffer

The Scope Agreement Source: PMI First, determine what the business drivers are and make sure you meet these objectives. Define the scope in terms of what is included, as well as what is not included. Make sure you obtain approval of the scope before you progress any further. All your work from now on will be driven based on what is agreed to at this stage. Base to build from is very important if you are building in phases. Help the business understand the growth potential. A dump into a warehouse does not give you visibility to much of anything.

The Scope Agreement (cont.)
As part of the written scope agreement, make sure you implement a formal change request process. This typically includes a cost-benefit estimate for each change request and a formal approval process. Base to build from is very important if you are building in phases. Help the business understand the growth potential. A dump into a warehouse does not give you visibility to much of anything. Change management is done to manage scope, timelines, and competing business requirements

Managing Scope – The Change Control
Define change (what is a change?) Establish procedures and when to use change process Documentation Must be able to link to a requirement Description Timing and dependencies Test case and data availability Work effort to complete development Date when available for test Resource availability Impact to schedule Impact to existing development BW is an integrated environment. Late changes in one area can have large impacts across the system A proposed change to some aspect of the project (i.e.. requirements, rules, IDEFs, process flows, etc.) previously agreed upon and/or signed-off. Scope Change – Material change to the project scope or integration business case that requires Executive or Board approval. (e.g. acquisition, divestiture, etc.) Design Change – Any material change to an approved EDGE deliverable. (e.g. Approved to Not a fit, Proposed to Not a fit) New Requirement – Request for new functionality. Program Milestone Change – Request to change a committed milestone date. Effectively manage requested changes to completed work by ensuring good decision making and strong follow through on action plans.

Change Control Process – Example
After the cc meeting: Business/Process Tracks Add Functional Specification, Technical Specification, Code & Unit Test, and Acceptance Test tasks to project plan with Case Name Update Functional Specification with actual date Coordinate with development tracks. Development tracks Determine actual dates for Technical Specification and Code & Unit Test Coordinate with Business/Process tracks The date that technical specification and coding & unit test will be completed The previously approved work that needs to be re-planned if any Agree on final Acceptance Test dates and update project plan Update Technical Specification, Code & Unit Test, and Acceptance Test tasks with actual dates Create change control documents for work that needs to be re-planned if any Change control processes should be formal, with escalation rules that can be used if disputes occur. This example is from a large SAP project that included R/3 and BW and needed strong scope control.

Determining Scope Through a Release Plan
Plan multiple implementations and write a long-term outline that may change (using a formal change request process).

Determining Scope Through a Release Plan (cont.)

Writing the Milestone Plan
Use a milestone plan to illustrate dependencies and high-level tasks: Post this plan on the walls in the hallways. Don't hide it in the PM's office! Keep it under 30 items!

Example: Infrastructure to Meet the Milestone Dates
In a complex project with multiple development environments and releases, it is important to have a well-communicated and detailed chart to make sure everyone is in-sync at all times

Budgeting Process Steps
Create the milestone plan and the scope statement first before attacking the budgeting process! Start the budgeting process by estimating the workload in terms of the development effort Budgeting Process Steps: Size the BW effort based on the scope Prioritize the effort Map the effort to the delivery schedule Plan for number of resources needed based on the scope, delivery schedule. and the effort We will now take a look at how each of these steps can be done in practice

1. Size the BW Effort Based on the Scope (Real Example)
Remember that your sizing also has to be based on the team’s experience and skill level

2. Prioritize the Effort The next step is to prioritize and outline the effort on a strategic timeline Make sure your sponsor and the business community agree with your delivery schedule

3. Use Project Estimates and Timeline to Create Project Load Plan
There are 480 available work hours per project member per quarter. Knowing this, we can plan the number of team members we need.

4. Result: Good Input for the Staffing Costs and Planning …
Use this information to plan for training, on-boarding, and staffing: This spike in resource needs is due to an overlap in the delivery schedule Now might be a good time to review that decision … Many companies plan a 60%-40% mix of internal and external resources for a first Go-Live. Also, most use $50-$90 per/hr for internal budgeting and $90-$170 per/hr for external resources.

Standard Content vs. Customization
All functional areas are not equally supported by strong standard BW business content. Some areas have so much you can leverage, others will require more enhancements depending on your requirements. * Rapidly improving content The differences are often due to customization on the R/3 side by companies and/or industry solutions

Standard Content vs. Customization (cont.)
Start gathering your requirements and break those down to data requirements Map the data functional requirements against standard content (InfoCubes) Take the standard model of that InfoCube (provided by BW admin workbench), and add your additional data fields into the model Map the new data fields to the source and hand the logical model to the BW developer Do not remove fields from the standard cube, and do not rename objects (you will not be able to take advantage of current and future delivered queries and cockpits)

Ideas for “Quick-Hit” BW Implementations
Limit the first Go-Live to one source system (easier to source) Think about quick visibility to enterprise consolidated data Some easy InfoCubes to implement For a quick-hit Go-Live, limit yourself to as much standard content as possible in areas that have high-impact (document level) Sales Orders Deliveries Billing Accounts receiveables Accounts payables General ledger Purchase orders

Ideas for “Quick-Hit” BW Implementations (cont.)
Keep the scope focused and use a simple approach: Activate standard content Review data quality issues Create 2-3 sample queries Load infocube User acceptance session Request for modifications In- scope? Rejection In-future Make enhancements Test Deploy Yes No No functional or technical specs are used in this approach. The user acceptance session is used to refine requirements.

Your Company's Strategy
What are the drivers for the project? Why do you need visibility – increase revenue, decrease expenses, increase competitive advantage (how? and how do you measure this?) Who are the company’s customers – what do they have in common? Who are their vendors (your competitors)? How can the company’s customers be segmented? What changes are occurring in the customer base? Where is the company heading? The enterprise data warehouse should sets the stage for effective analysis of information to make strategic decisions and identify competitive advantages (proactive and not retroactive!)

Your Company's Strategy (cont.)
Typically the current state of Data Warehousing (DW) is a combination of centralized and decentralized resulting in inefficiencies Moving to a centralized DW should enable future projects to reduce costs by leveraging common hardware, standardizing on software, and leveraging a pool of technical resource (is your project a cost-saving project?) How can you provide information not data for decision making (KPIs?)

Is your company a low-cost provider, a research leader, a premium provider? The answer will drive what you should report on ... Is your company divesting or growing the business through mergers and acquisitions? The answer will drive how you prioritize the development The need for integrated, historical, and accessible data across the enterprise is key to a competitive advantage

For example, project X provides an end-to-end BW solution that empowers decision making to help provide better customer service and deliveries to increase profitability – How? Increased accuracy of reports Timely information in an interactive, easy to use manner Standardized reporting method and shared tools Access to enterprise-wide information Continuous monitoring of KPIs; profitability and margin analysis The goal is to give users the information when they need it and in a format they understand so they can execute day-to-day decisions and be more productive

Why Build BW and R/3 at the Same Time?
Leverage Resources The basis and the business knowledge is available at lower additional costs Avoid rework Avoid rework of standard content when the R/3 module is implemented. Many smaller configurations can be accommodated without impact to the project team. Consequently, if extensions are made without regards to the BW implementation, rework may be required. Know your users What they have versus What they want What they need You must minimize this impact with a proper training program, a sound development approach and with the business community having critical roles during every phase of the project. Know what BI tools you have, how to use them and what are there limitations prior to deployment. A wise person once remarked that: “a paper airplane can be constructed with little fore thought but a jet airplane cannot.” Similarly, a small stovepipe application with only a handful of users can get by without a set of carefully planned and executed activities, but a BI application certainly cannot. Building BW and R/3 at the same time is a challenge, but there are also benefits

Why Build BW and R/3 at the Same Time? (cont.)
Cost avoidance Avoid creating ABAP and custom reports that is available in BW Project success While R/3 is optimized for transaction processing, BW is maximized for analysis and user access to the data. The available reports and features improve the the quality of user experience thereby increasing the project’s likelihood of success. Know your users What they have versus What they want What they need You must minimize this impact with a proper training program, a sound development approach and with the business community having critical roles during every phase of the project. Know what BI tools you have, how to use them and what are there limitations prior to deployment. A wise person once remarked that: “a paper airplane can be constructed with little fore thought but a jet airplane cannot.” Similarly, a small stovepipe application with only a handful of users can get by without a set of carefully planned and executed activities, but a BI application certainly cannot.

Why Build BW and R/3 at the Same Time? (cont.)
Things to watch Usually the BW implementation starts by lagging 4-6 weeks behind the R/3 team in the Prep, Blueprint, and Realization phase. However, during the implementation phase, the BW and the R/3 team are both in-sync for the same Go-Live date. This lag allows the BW team to leverage the other team’s work without having to sit idle for the first few weeks of the project. It also allows the R/3 team to focus on the processes instead of the data in the beginning of each phase. Know your users What they have versus What they want What they need You must minimize this impact with a proper training program, a sound development approach and with the business community having critical roles during every phase of the project. Know what BI tools you have, how to use them and what are there limitations prior to deployment. A wise person once remarked that: “a paper airplane can be constructed with little fore thought but a jet airplane cannot.” Similarly, a small stovepipe application with only a handful of users can get by without a set of carefully planned and executed activities, but a BI application certainly cannot.

Retiring Legacy Reporting Systems
Building interim solutions while an implementation takes place is hard Interim reporting is expensive and the business need must be fully accessed and understood. However, if you must do this, be very careful. Duplicate reports leads to confusion and slow adoption. Politics – retool the legacy organization as soon as possible and develop advocates for the new tool set and process. You must involve legacy reporting groups to be successful. Significant work needed to keep legacy data and BW data in synch. Some data required by the Enterprise Reporting BW data model may not exist in the legacy source systems therefore preventing the affected business from being able to migrate to BW or at least realizing the entire value of a centralize/enterprise warehouse in BW. Leverage the investment made through Enterprise Reporting in SAP BW, and long term reduce cost by retiring sector legacy data warehousing solutions. Consolidation of data across the enterprise. Standardization of the decision support toolset for the enterprise Duplication of data, extract programs, . Cost of software, hardware, storage and communications. Have a "sunset" plan for legacy reporting systems – "burn the boats"

Writing the Strategic Plan for Your Enterprise Data Warehouses
Table of Content Executive Summary Background Strategy Motivator of change (why?) As-is state of systems and reporting To-be state of enterprise data warehouse Benefits of the enterprise data warehouse Proposed scope Proposed architecture Proposed rollout plan Proposed project organization Proposed support organization Resources Internal resource assessment External resource assessment Training needs Recruitment The strategic plan should contain these sections: Vendor overview and /or selection Hardware Software Partners Budgets Detailed budget Proposed funding approval Limitations, Assumptions, and Risks References

Failure to break from as-is environment
The Pitfalls of Many Failure to break from as-is environment Treating legacy systems as “requirements” Comparing and replicating old reports and system functionality Underestimating development effort of complex requirements R/3 is different than most legacy systems, as is reporting Failing to understand sources of information. (i.e., sales reporting) can come from sales orders, deliveries, billings, A/R, G/L, or COPA Single Sponsor Lack of corporate ownership and executive buy-in No succession plan and the Enterprise Data Warehouse often becomes an “orphan”

The Pitfalls of Many (cont.)
Failure to quickly disable legacy reporting systems Creates competing systems, politics, and no real cost savings Removes urgency and creates slow user adaptation Overly complex architecture and lack of enforcing of standards Technology is seldom the reason why EDWs fail; organization and strong leadership is paramount

The Living Strategy – How to Make It Work …
A strategy is a living document that is subject to change It is not a one-time effort that is ignored after the first change (many create a strategy only to file it in a drawer) The strategy should be clearly communicated to all team members and the business community Change control approvals are needed to make the strategic planning process work in reality A periodic review should be scheduled (e.g., quarterly) to monitor how well the implementations follow the strategy

Resources SAP Planning – Best Practices in Implementations, by George W. Anderson The Complete Project management Office Handbook, by Gerard M. Hill Waltzing With Bears: Managing Risk on Software Projects, by Tom Demarco & Timothy Lister Mastering the SAP Business Information Warehouse, by Kevin McDonald, Andreas Wilmsmeier, David C. Dixon

7 Key Points to Take Home Write the business case around the areas of greatest benefit to your users. Do not use a “shot-gun” approach, but keep it focused. Define your scope in terms of what is included and state what is not included Establish a formal change control process that is well communicated Plan your project based on the hours required for the effort and the project team’s skill level

7 Key Points to Take Home (cont.)
Establish milestone dates and map the work hours required to these dates Make sure you have a plan for retiring legacy reporting systems Evaluate staffing and training models periodically

Joyce Redmon Dr. Bjarne Berg
Your Turn! Questions? How to contact us: Joyce Redmon Dr. Bjarne Berg

Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project

Similar presentations

Presentation on theme: "Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project

Similar presentations

Presentation on theme: "Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project"— Presentation transcript:

Similar presentations

About project

Feedback