Gathering And Documenting Your Bi Business Requirements
26 likes27,524 views
The document discusses the importance of effective requirements gathering in business intelligence (BI) projects, highlighting that poor practices can lead to significant budget overruns and project failures. It identifies common mistakes such as mismanagement of project scope, use of complex jargon, and lack of defined methodologies, stressing the need for clarity and stakeholder engagement. Additionally, it emphasizes the importance of traceability, usability testing, and the use of appropriate tools to ensure successful requirements analysis and implementation.
Gathering And Documenting Your Bi Business Requirements
- 1. Gathering Business Requirements Nikita Atkins (nikita.atkins@au1.ibm.com)
- 2. Why?
- 3. > Companies that have poor requirements practices will be on budget less than 20% and 50% of the time the project will experience massive time and budget overruns. Companies that fall into this category will spend, on average, $5.87 million for that $3 million project. That is a 95% increase in budget. > 60% of system errors are due to inadequate specification and design > Top 3 reasons out of 10 that systems fail to meet cost and schedules is because of requirements: Changes in Requirements, Inadequate Requirement Specification and Lack of user input
- 4. > 56% of errors in installed systems due to poor communication between user and development during requirements development > 82% of staff time (especially IT staff) is spent correcting requirements errors in installed systems > 24-40% of a projects budget consumed due to requirements errors
- 5. Cost to Repair a Defect or Error > Requirements = $500 - $1000 > Design = $2,500 > Build = $5,000 > Unit Test = $10,000 > UAT = $25,000 > Maintenance = $100,000
- 6. Why Requirements for BI is so Difficult > Broad Objectives and Endless Possibilities > Hard and Soft Deliverables > Identifying Start and End Point > Ever Changing Scope
- 7. Mistake 1: Just Another IS/IT Project > Common but dangerous mistake IS/IT start with Technical Requirements Information Tools and Software BI start with Business Requirements Alignment and Governance People, Processes and Culture Support, SLAs and Capabilities Fully engage business stakeholders Large amount of unknowns
- 8. Mistake 2: Traditional Requirements Give employees what they need not what they want Strategic Goals & Objectives Role and Responsibilities Key Performance Indicators Tools and Enablers Industry Best Practices Decisions and Questions Rewards and Incentives
- 9. Mistake 3: Using Wrong Jargon > Using unnecessary, vague or complex jargon when communicating & gathering requirements Employees instead of Users Software purpose instead of name Process instead of department name > Business Metadata
- 10. Mistake 4: Dont Manage Project Scope > What is in and out of scope > Scope too large > No defined end point > Dont forget the 3 legged stool: Scope (Quality) Time Resources
- 11. Mistake 5: Making Documents too Complex Complex Requirements Documents = Complex Project = Too Hard Basket? Simple template Line items and cross references Visualisation tools Requirements traceability matrix Drill-through matrix
- 12. Mistake 6: Not Understanding Prerequisites Mixing up Program and Project Requirements Finite beginning and end Build and implement something Support business processes Scope Standards
- 13. Mistake 6: Not Understanding Prerequisites Strategic Plan Business Case Project Charter Business Strategic Goals BI Roadmap Scope Statement Requirements Strategic Program Project Requirements Planning Roadmap Scope Program of Work Req. Analysis Vision Standards Business Model Use Cases Strategy BICC Context Specifications Objectives Governance Processes Architecture
- 14. Mistake 7 Not Having A Clear Methodology > Elicitation - Gather, Draw Out, Extract > Analysis - Refining, Understanding, Decomposing > Specification - Consistent, Accessible and Reviewable Documentation > Validation - Correct, Quality, Test Cases, Correct Ambiguities and Vagueness
- 15. IBM Cognos Solution Implementation Methodology (SIM)
- 16. Mistake 8 Not Having Traceability > Source Systems > Metrics and KPIs > Dimensions > BI and Reporting Objects > Training > Documentation > Any Deliverables
- 17. Keys to Requirements Traceability > Unique Numbering > Cross Referencing > Referred To During Project > Key To Testing > Simple to Understand > Easy to Search For
- 18. Mistake 9 Not Linking to Testing Usability, Data Quality, Operational Readiness User Business Requirements Verify Acceptance Testing Business Analysts Business Users System Design Testing Application, BAs / Developers BAs / Developers Integration, Performance Component Development Testing Developers Developers Scorecards, Dashboards, Cubes, Reports, Models & DW
- 19. Mistake 10 Know Your Tools Requirements Brainstorming Domain Models Requirements Quality Review Document Use Cases Document Peer Review Analysis User Stories Technical Customer Review Focus Groups Process Models Requirements IT Review Interface Analysis Interface Designs Non-Technical Project Sponsor Interviews Workflow Models Requirements Phase Gate Models Business Rules Requirements Requirements Manuals Metrics Dictionary Attributes Presentation Observations Business Glossary Prioritisation Prototyping Data Dictionary Matrix Reverse Risk Assessment Risk Management Engineering Value Mapping Plan Surveys Change Workshops Management Plan Elicitation Analysis Specification Validation
- 20. Cognos Professional Services The Enablers Solution Planning Services Solution Implementation Services Project Guardian Assist Services Services Services Business Improvement Services
- 21. Related Reading > Business Analysis Essential Library Professionalizing Business Analysis: Breaking the Cycle of Challenged Projects The Business Analyst as Strategist: Translating Business Strategies into Valuable Solutions Unearthing Business Requirements: Elicitation Tools and Techniques Getting it Right: Business Requirement Analysis Tools and Techniques The Art and Power of Facilitation: Running Powerful Meetings From Analyst to Leader: Elevating the Role of the Business Analyst