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

1. Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project Joyce Redmon International Paper Dr.Bjarne Berg Comerit Inc.

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

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

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

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

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

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

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

9. Basis and functional R/3 support 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) 8-10 team members and normally 2-4 months duration depending on scope

10. Project sponsor/ Steering Committee Project Manager BW Architect Portal developer(s) Sales Team Finance Team Material Mgmt. Team Business analyst/(sub-team lead) Business analyst/(sub-team lead) Business analyst/(sub-team lead) BW developer BW developer BW developer Presentation developer(s) Presentation developer(s) Presentation developer(s) Basis and functional R/3 support ETL developer ETL developer ETL developer 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) 15-25 team members and normally 6-18 months duration depending on scope

11. On-Boarding and Training Ideal Years In-house Training days Experience training (if new in the role ) days (minimum) 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

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

13. Why Use Change Control? • 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 • Accurate Resource Planning • Reduces impact on other planned work • Strategic staffing vs. reactive staffing • Make best use of resources

14. Caution 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: 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

15. The Scope Agreement • 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. Source: PMI

16. 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. Change management is done to manage scope, timelines, and competing business requirements

17. 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 • Establish procedures and when to use change process • 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

18. Change Control Process – Example 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.

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

20. Determining Scope Through a Release Plan (cont.)

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

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

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

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

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

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

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

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

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

30. * Rapidly improving content 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. The differences are often due to customization on the R/3 side by companies and/or industry solutions

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

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

33. 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 For a quick-hit Go-Live, limit yourself to as much standard content as possible in areas that have high-impact Some easy InfoCubes to implement (document level) Sales Orders Deliveries Billing Accounts receiveables Accounts payables General ledger Purchase orders

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

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

36. 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!)

37. 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?)

38. Your Company's Strategy (cont.) • 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

39. Your Company's Strategy (cont.) • 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

40. 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. Building BW and R/3 at the same time is a challenge, but there are also benefits

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

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

43. 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. Have a "sunset" plan for legacy reporting systems – "burn the boats"

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

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

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

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

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

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

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