One Company’s Journey in Building a Successful Requirements Engineering Center of Excellence

1. One Company’s Journey in Building a Successful Requirements Engineering Center of Excellence Joni Wheeler April 2016

2. What Can you Expect Today? During this session, you will hear about a journey where ‘Requirements Delivery was deemed the number one company problem and a top priority to fix’, and how an organization turned this statement into a very successful Requirements Engineering Center of Excellence model in less than a year.  If you are an organizational manager or leader, you will walk away with insights and strategies that went into building a high performing, highly motivated Business Analysis organizational model.  For those of you in a BA role, or even an individual contributor partner role, we’ll share some of the learnings the BA’s and their role counterparts gained through this journey and how they were able to enhance their toolkit for long term, sustainable success.

3. What? My Requirements are Bad? Errors in requirements are estimated to cost U.S. businesses between $30 and $80 billon dollars a year What is the cost of a requirement error? – King & Marasco Average effort spent in the development lifecycle Time Spent! vs. Average proportion of errors built in during development Errors! BA Solutions Ltd 2012

4. Whatis the Cost of Bad Requirements? Compared with defects found during requirements, defects cost 10 times more if not found until testing and 10 to 200 times more if not found until after development! Eliciting and Analyzing Quality Requirements – Firesmith Cost of defects goes up the later they are found! 25% to 40% of a project’s budget is attributed to requirements defects. - Eliciting and Analyzing Quality Requirements, Firesmith

5. Where the Company’s Journey Began Metrics indicated that requirements issues represented a significant impact to the Company’s cost and quality of deliverables The US development shop identified a direct correlation between high severity production issues and late requirements The Company’s international development shop rejected an average of 55% of requirements for further clarification In 2009, the Company spent over 1.26 million hours on software development. Assuming a conservative 10% error of margin, efforts to improve requirements and reduce defects would potentially save 126,000 hours, or 8.1 million dollars! The decision to start the journey was an easy one …

6. Assess the Current State The Company set out to determine their level of requirements maturity against best in class standards 75 examples of the Company’s business requirements were assessed by external experts against industry standards and best practices 45% The Company assessed at Level 1.3 on the requirements capability matrix • No standalone requirements documentation • No organizational oversight and direction to requirements analysis discipline • No sharing of best practices or collaboration • No requirements analysis training offered • Standards loosely defined and differ between different units • Requirements process, as applied, is inconsistent and informal Starting Point Year 1 Goal

7. What are the Typical Pain Points? Listened to IT partners describe their pain around requirements documentation We have to interpret and extract the requirements from the write-up It doesn’t describe the problem that needs to be addressed They don’t identify business objectives, expected benefits, or value Need more detail We have to start each project from scratch when trying to understand the current state Write-up is unclear and could lead to misinterpretation It describes some “how’s” that limits technical options It doesn’t describe the “should be” Needs to be higher level and identify functions that are needed It doesn’t explain the why or the what

8. Next Stop - Executive Buy In The Company achieved buy in from leadership to invest in requirements maturity and adherence to its discipline by expounding on its REWARDS!

9. Achieving the Objectives A framework and road map was established to begin building the organization Solidify metrics to measure success Process definition and role alignment Formal roll out of upfront analysis, requirements definition, and HLE COE model Operational Excellence Establish integration with IT partners Standardize processes across the Company Organizational alignment, training, formal process documentation, success metrics Launch pilot on projects >1000 hours Establish formal KPI metrics Optimize resources, deliver high quality results Institutionalize processes, enhance skill sets Establish initial metrics and reporting Deploy Develop Framework Build foundation for up-front consulting and analysis, requirements definition, and solution architecture design Standardize (Q2 & Q3) Build (Q4 /Q1) Operationalize (Q4) Pilot (Q1)

10. Hiring the Right People Over the first 6 months of the journey, the Company built the team from the ground up, hiring internally, based primarily on the RIGHT ATTITUDE! First 3 months Next 3 months By the End of the First Year I am really excited about trying a new approach! Welcome to the Team! By the end of the first year, the Company had a team of well trained and highly motivated Requirement Engineers supporting requests across the global organization, as well as consulting and training requirement gatherers from other teams on best in class standards! Over the next 3 months, the word about this incredible new team -- working to have a significant impact on the Company’s delivery while having fun and learning amazing new skills -- had spread across the Company, and the team grew to over 120! In the first 3 months, the Company interviewed internal candidates and hired 85 people with varying degrees of experience … but with one common characteristic -- A GREAT ATTITUDE!

11. Established a Positive Culture The Organizational leadership fostered an environment where employees felt empowered to face some of their toughest challenges … and loved their jobs! Empowered to act and make change Work / Life Balance Learn from our mistakes “I have been searching for something like this my whole career” Have Fun! You have the tools to succeed Round Table & Skip Level Discussions You have support You have a voice

12. Defined Role of the Requirement Engineer The Organization made sure Requirements Engineers, as well as business and IT partners, understood the role • We are Requirements Engineers, and we will … • Work with the business to identify their needs • Write / edit business requirement documents • Consult with solution architects for high level designs and estimates • Act as an additional reviewer for design and test planning • Consult with business, as needed, through project lifecycle • We are not… • Business idea owners • Project managers • Project owners • Solution authors • Testers • Documentation writers

13. Built Requirement Engineering Tool Kit The tools and templates used in gathering business requirements were developed pursuant to industry standards, in cooperation with professional consultants

14. Defined Business Requirement Standards Requirements Engineers were coached on the fundamentals of good business requirements

15. Defined Requirement Engineering Process A road map for requirement documentation was established within the project lifecycle Business Requirement Artifact Road Map

16. Implemented a Training & Development Plan Developed training plan in collaboration with industry professionals

17. Team Motivation and Career Development Motivated employees by providing a clearly defined career path, as well as development opportunities Requirement Engineer Career Path Requirement Engineer Certification

18. Measure Successes Established metrics that would track successes and enable improvements • Project Estimate to Actual rates • Percent of redundant code introduced across applications • Number of one off custom development initiatives • Cost to deliver solutions • Frequency of change in the requirements • Defect rejection rate of Requirements • Rate of introduction of new requirements • Number of requirements changes to a requirements baseline • Percentage of defects with requirement errors as the root cause • Number of requirements-related change requests • Post-production defects • Number of change requests for rework – both pre-launch and post-launch • Improved Customer Experience & Increased Speed to Solution

19. Metrics Drive Results! Utilized metrics to drive continued implementation of RECOE requests and “sell” its service to business and IT partners

20. Audit & Governance Audited its performance and provided a forum for its employees to help the organization learn and grown Audit Audit Criteria Purpose of Audit • Clearness • Completeness • Consistency • Traceability • Verifiability • Content • To ImproveQuality • To Reduce Rework in later stages of development • To increase Customer Satisfaction • To use a Consistent requirements methodology • To provide an organizational Transformation Catalyst Governance Purpose of Governance Scope of Governance • To provide a forum for all individuals across the Company to recommend Improvements to the artifacts and processes within the Company Requirements Process . • To promote Consistency in the documentation. • To ensure the Continued Growth of the Requirements Process, to suit the changing needs of the Company. • All Company Requirement Process artifacts (i.e., templates, diagrams, checklists, workflows, etc.). • All requirement elicitation processes. • Change Requests can be submitted by any individual utilizing the Company Requirements Process.

21. Continuous Improvement Surveyed customers to ensure continued improvement in processes and stakeholder support

22. And by the End of the First Year … Level 5 - Process Improvement - Quantitative results ID causes of variations Level 3 - Refined practice - Lifecycle integration - Managed & audited RECoE Year 1 RECoE achieved a Level 3! • On-boarded 128 Requirements Engineers (106 FTE, 22 Contractors) • Assessed competencies & developed training plans • Created an Industry Best Practice Standard Operating Model and Artifacts We Launcheda new organization and Deployed our Operating Model • Provided Professional Training, IIBA Membership and monthly Brown Bag sessions to staff • Established RE Metrics Model and Executive Dashboard • Implemented an RE Forum & Leadership Panel Discussions We Identified and Developed the right Balance of Skills And finally, we IMPLEMENTED our Service Delivery Models Full Service Delivery Model Pro Re Nata Service Delivery Model Delivered 400+ roadshows to multiple business areas throughout FD Presented Process overview sessions to over 500 attendees Introduced Requirements Delivery Model to 1500+ Requirements Authors Improved requirements duration on large projects by 60%* Completed 94 BRDs & 7,000+ requirements in 9 months Reduced time to deliver requirements an average of 22%* VOC survey sent to 10,000 participants across FD – 20% participation (2,031) Conducted intensive Requirement “boot camp” training in multiple countries Developed Best-in-Class Requirement Quality Index Audit model Developed Description of Work (DOW) training module in LMS 32 Projects implemented using Requirements Model RECoE supported FD Top Strategic initiatives

23. Key Take-Aways You don’t always need the entire tool suite to be successful! Be selective – use what works for each situation • For aspiring Requirement Engineers … • Would a use case diagram help to clarify my functional requirements? • Are my requirements clear, completeand traceable? • Would having a set of various tools that allow multiple approaches to requirement gathering be helpful? • Are my requirements free of technical solutions? • Am I eliciting the ‘what’, and not the ‘how’ from my business partner? • For aspiring Centers of Excellence … • Do I have a standard process and template to ensure requirements are documented consistently? • Are my team’s roles and responsibilities clearly established? • What are my defect rates related to requirements? • What level of support will my partners invest in? • Having multiple groups of Requirement Engineers trained and using the same tools allows for several perspectives on gathering and then using requirements.

24. Questions?