The Hidden Costs Ba World V2 1
- 1. The hidden costs of Visio, Word & Excel -better requirements at a lower cost Ben Clohesy Future State Consulting
- 2. Agenda • Requirements definition is still difficult • The traditional approach • The model-driven approach • Beyond use cases - the strategic BA Holocentric 2 July 2010
- 3. REQUIREMENTS DEFINITION Holocentric 3 July 2010
- 4. System delivery success % Project failure 100 90 80 70 60 Robins-Gioia 2001 50 Meta Group 2001 40 Deborah Weiss - Meta 30 Group 2003 Standish 2010 20 10 0 Robins-Gioia Meta Group Deborah Standish 2001 2001 Weiss - Meta 2010 Group 2003 • Implementation costs were found to average 25% over budget, 40% of the projects failed to achieve their business case within one year of going live (Conference Board Survey 2001) Holocentric 4 July 2010
- 5. Specs to save CIO necks Karen Dearne NOVEMBER 14, 2006 “With two out of every three projects failing to produce any discernible benefits whatsoever, it's only a matter of time before boards are forced to be more accountable for their inability to apply strategies and the massive waste, estimated at up to one-third of total capital expenditure. “Based on overseas estimates, the cost of terminated projects in Australia in 2002-03 was $1.4 billion, while another $3.2 billion was spend on projects that delivered no benefits.“ I.T. Matters – at least until everyone can get this right! Holocentric 5 July 2010
- 6. Why do projects fail so often? • Poor communication among customers, developers, and users • Unrealistic or unarticulated project goals 95% of the time it's a project management • Badly defined system requirements projects set issue. The managers of these Not engineering • Inaccurate out the requirements at the beginning of a estimates of needed resources project and Not requirements (IDC, 2004) they get it wrong management • Poor project and risk management …the market places It‟s all about a disproportionate • Stakeholder politics definition and co-ordination! emphasis on tools for requirements • Commercial pressures The real opportunity lies in management. requirements definition… (Forrester, 2006) • Use of immature technology • Sloppy development practices • Inability to handle the project's complexity IEEE Spectrum, September, 2005 Holocentric 6 July 2010
- 7. THE TRADITIONAL APPROACH Holocentric 7 July 2010
- 8. All the usual suspects... Visio Process Process Business Case Diagrams Metrics Requirements Vendor Information Policy and User Training Requirements e.g. Use Cases Procedures Materials & Specifications Holocentric 8 July 2010
- 9. THE MODEL-DRIVEN APPROACH Holocentric 9 July 2010
- 10. Process Modeling is the key • Roles emphasise a „People view‟ of process. • Personal level of responsibility for work unit output • Key link in chain of requirements responsibility Holocentric 10 July 2010
- 11. The difference ... • Engage business representatives – better quality requirements • Greater functionality to verify the integrity of your requirements • Model as single repository used to derive all the information you need – no more documentation nightmares • Impact analysis to manage change Holocentric 11 July 2010
- 12. Project Model Project Model Business Outcomes Capabilities Business Constraints Risks Assumptions Metrics Measures External Document References Business Process Model Business Process Model Business Process Diagrams Process Roles Process Steps Business Process Area Diagrams System Requirements Model System Requirements Model Build Buy System Features Functional Requirements Non Functional Rules Register Requirements System Use Information User Interface System Process Case Model Model Model Diagrams Holocentric 12 July 2010
- 13. Holocentric 13 July 2010
- 14. Case Study • Traditional vs. model-based approach • The consulting firm: • Cost: $2.5 million • 6000 requirements in excel, word • Model-based team: • Cost: $0.55M • Of the 6000, 1500 were invalid, unnecessary or duplicated • 450 were missing Holocentric 14 July 2010
- 15. * Accelerator Item Linkable {abstract} Subject Of {abstract} * «Project Model» «Project Model» «Project Model» Assumption Risk External Document Reference Business Case Inputs «Project Model» Business Outcome * Constrainable Gaugable {abstract} {abstract} Requires * * Constrained By Gauged By * * * «Project Model» «Project Model» * «Project Model» Refined By Business Constraint Metric Capability * * * Operates On * * «Project Model» Project Scope Diagram «Project Model» Utilizes Comprises Measure * * * Business Requirements Modeling Capability Utilizer Capability Element Measured By {abstract} {abstract} «Business Process Model» Business Process Area Diagram * «Business Process Model» Competency Process Role «Business Process Model» {abstract} Process Step «Business Process Model» * * * Business Process Diagram Requires * Capacity * {abstract} «System Requirement» «System Requirement» Enabled By Functional Requirement System Feature * * * Characterized By * Elaborated By Realizes «System Requirement» «Project Model» Non Functional Requirement Capability Usage Diagram Implements System Requirements Modeling * «System Model» * * System Actor «System Model» «System Model» Rule Subject System Use Case Diagram * System Use Case {abstract} Governed By Elaborated By * * Supplementary System Diagram * «Rule» Screen Flow Node * {abstract} Proceeds To Rule Set {abstract} * 1..* Information «System Model» {abstract} Groups * System Process Diagram «User Interface Model» Dialog Message «Rule» Rule «User Interface Model» Screen Flow Diagram «User Interface Model» Screen «Information Model» Information Field 15 «Information Model» «Information Model» Information Structure Diagram Information Set Holocentric July 2010
- 16. DEMONSTRATION Holocentric 16 July 2010
- 17. RACI Matrix Holocentric 17 July 2010
- 18. Impact Analysis - Requirements Holocentric 18 July 2010
- 19. Impact Analysis - Measures Holocentric 19 July 2010
- 20. Drawing versus Modeling • Isolated „flat‟ drawings – difficult to maintain model integrity • Difficult to analyze across the full spectrum of a business • Little re-usable content • Holocentric Challenging to maintain on an ongoing basis 20 July 2010
- 22. Joining the dots Policy System Positions Requirements Business Processes The ‘Why’ The ‘How’ Business processes also provide a meaningful context to define accurate system requirements Business Processes implement the policy intent Functional Specification The ‘Who’, ‘When’ and ‘Where’ 22 Holocentric July 2010
- 23. BEYOND USE CASES - A MORE STRATEGIC ROLE FOR BA’S Holocentric 23 July 2010
- 24. From process mapping Generally used to “map” the “AS-IS” and/or “TO-BE” process in a Holocentric 24 July 2010 more visual way. Thought be easier to communicate to the workforce
- 25. To modelling What is the process to be followed? Model the Process - Using Role Based Notation How will it impact my role? - Identify Enabling and Supporting Systems - Highlight manual Tasks What manual tasks and other systems will we need to use? - Link it do what we need it to Will to Business Requirements do? -Does everyone have Create and Link - Link to External Documents What official documentation System Roles the same access? do I need to know about? - Will it still ensure we Create and Link - Create and Link the system? How do we use Use Cases Regulations regulations? adhere to the -What happens when the Rate the process for - How doTraining Material Create we train users on system doesn’t work? Business Continuity within thesystem? the new Model Holocentric 25 July 2010
- 26. To training Holocentric 26 July 2010
- 27. To regulations Process Policies & Procedures Regulations Business Requirements Use Cases Holocentric 27 July 2010
- 28. Tangible Benefits • Requirements refinement and validation • At very little cost • Creation of framework to generate Material for Training • At very little cost • Creation of framework to generate Material for Change Programs • At very little cost • Processes and Documents reflect Regulations • At very little cost and with high integrity • Creation and capture of Use Cases • Applications Vendor provide “software steps” • Manage Applications functionality • Synchronisation of all key Project work Furthermore, model-based information is maintainable Holocentric 28 July 2010
- 29. * Accelerator Item Linkable {abstract} Subject Of {abstract} * A meta model «Project Model» Assumption «Project Model» Risk «Project Model» External Document Reference Business Case Inputs «Project Model» Business Outcome * Constrainable Gaugable {abstract} {abstract} Requires * * Constrained By Gauged By * * * «Project Model» «Project Model» * «Project Model» Refined By Business Constraint Metric Capability * * * Operates On * * «Project Model» Project Scope Diagram «Project Model» Utilizes Comprises Measure * * * Business Requirements Modeling Capability Utilizer Capability Element Measured By {abstract} {abstract} «Business Process Model» Business Process Area Diagram * «Business Process Model» Competency Process Role «Business Process Model» {abstract} Process Step «Business Process Model» * * * Business Process Diagram Requires * Capacity * {abstract} «System Requirement» «System Requirement» Enabled By Functional Requirement System Feature * * * Characterized By * Elaborated By Realizes «System Requirement» «Project Model» Non Functional Requirement Capability Usage Diagram Implements System Requirements Modeling * «System Model» * * System Actor «System Model» «System Model» Rule Subject System Use Case Diagram * System Use Case {abstract} Governed By Elaborated By ...everyone * * Supplementary System Diagram * «Rule» Screen Flow Node * {abstract} Proceeds To Rule Set {abstract} * Information 1..* should {abstract} Groups «System Model» System Process Diagram «User Interface Model» Dialog Message * have one «Rule» Rule «User Interface Model» Screen Flow Diagram «User Interface Model» Screen «Information Model» Information Field 29 «Information Model» «Information Model» Information Structure Diagram Information Set Holocentric July 2010
- 30. Summary • A model driven approach can help drive business outcomes quicker and more accurately than disconnected documents. • As BA’s our job is not to write documents – it’s to help ensure that the business outcomes are achieved. Holocentric 30 July 2010