1 / 25

Speaker: Michael van Brugge Partner, Amoranto Consulting Inc, Spokesperson, BSA Leaders

Understanding & Solving the Challenges of Requirements Management (RM) at Large Financial Institutions. Speaker: Michael van Brugge Partner, Amoranto Consulting Inc, Spokesperson, BSA Leaders. The Central Idea. “If you can’t get the requirements right,

Download Presentation

Speaker: Michael van Brugge Partner, Amoranto Consulting Inc, Spokesperson, BSA Leaders

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Understanding & Solving the Challenges of Requirements Management (RM) at Large Financial Institutions Speaker: Michael van Brugge Partner, Amoranto Consulting Inc, Spokesperson, BSA Leaders

  2. The Central Idea “If you can’t get the requirements right, it doesn’t matter what process you use or how well you execute the rest of the project” Inadequate attention to the development of fundamentals across Knowledge Management, Resource Management, and Business Systems Analysis practices results in major challenges found across Governance, Leadership, and Operational components of Requirements Management (Engineering). From the Bridgetown Framework

  3. Flow of this Presentation

  4. Symptoms of Poor RM • Common patterns on project quality with mediocre Requirements Management practices: • Longer time-to-market • Increased number of change requests (scope creep), and • Generally much more spin (cost) • Less obvious patterns: • Lack of forward-thinking and integration to other systems that can reuse information within the project or afterwards • IT Management ‘s strong influence over the Business versus the other way around • Metrics for measuring the success of projects are never established • Continuous Improvement receives little attention thus has no impact • Poor ability to plan timelines and durations (based on guesses) • Unclear, unreliable, and inefficient Requirement Intake Practices • Initial sizing for new initiatives are wildly off • Quality Control Test Planning takes much longer than needed • Low expectations by Sponsors, Stakeholders, and project partners • The specification get satisfied, but the customer does not.

  5. Symptoms of Poor RM Continued… • Requirements exist in the heads of “the experts” but aren’t written down • Worker protectionism of information and knowledge increases • Many team meetings are needed to address small topics over and over again • Poor communications between the client and team members • Lost credibility and lowered revenue opportunities • Business or IT vision is unclear or unspecified • Customers become too busy to spend the required time to support the analysts • Developers are left to make things up due to ambiguity in requirements • Unnecessary numbers of iterations when they could have been done once • Lack of clear access to corporate memory / knowledge / information • BA team members’ tenure becomes either very short or very long • PMs feel the need to take functional control over the team, the matrix crumbles • Analysts often enter ‘Analysis Paralysis’ at every change to the system • Disillusioned analysts, QA, QC, Developers, and PMs • Teams spending too much time ramping-up for each initiative • Lack of clear integration with all other functional teams creates a project environment where more emphasis is placed on processes and governance than beneficial practices

  6. Challenges • When Challenges become visible • The ‘Top-10’ RM Challenges • The ‘Not-so-Simple’ Challenges • Common Patterns that emerge

  7. When Challenges Become Visible • Introducing new products and services across the enterprise • Introduction of powerful tools and technologies • Projects requiring eloquent and innovative solutions • Implementing process improvement initiatives like the Capability Maturity Model • When experienced workers join the team • When a department is starting an initiative to integrate with a project in an other division or line of business

  8. The ‘Not So Simple’ Challenges Complex Challenges come from the following • Organizing workers to become analysts who truly 'analyze‘ • Finding a Sponsor to endorse the exercise of improving requirements management (both financial & accountability) • Finding and defining the ideal state of the enterprise • Getting functional managers to take the initiative • Overcoming the firm’s immunity to change • Building technological systems for knowledge and corporate memory • The lack of inexpensive or easy-to-use technologies

  9. Patterns to the Top-10 Challenges

  10. Patterns Found in Challenges • The Requirements Management Maturity Model • Too much Process versus Good Practice • The Roles of the BAs and BSAs • Weak Knowledge Management • The lack of understanding of Requirements Engineering

  11. Struggling on the RM Maturity Path Counter forces ($ & t) RM is one of several Key Process Areas Level 5 Level 4 Level 3 Capability Maturity Model or other Software Quality Path Level 2 Mediocre Level 1

  12. Business & Systems Analysis Software Development departments are widening the gap between the BA and BSA roles. The number of ‘Business Systems Analysts’ (BSA) roles has grown dramatically in an attempt to more effectively deliver and understand the business requirements from an IT perspective. Stakeholders are assuming the role of the BA (and returning to the business). Workers with BSA titles are starting to learn their jobs require more than just understanding the business. They need to understand analysis, logical design, development, testing, and more.

  13. Process vs. Practices Many firms and leaders follow some CMM or similar approach to improving software quality but they undervalue the contribution by highly capable people. Instead of the focusing on cultivating better workers and improving the capabilities of their workers, companies follow a system of expanding the number of processes, thereby deferring higher quality software due to misdirected and unfocused energy.

  14. Requirements Engineering The basic system related to collecting and transforming requirements from one state to the next is a concept that appears to be poorly understood by many workers in the role of the Business Analyst or Business Systems Analyst. Workers believe their ‘titles’ qualify them to specify ‘the requirements’ when they do not have the full knowledge or understanding of their full domain.

  15. Knowledge Management Weak Knowledge Management practices abound Requirements depend on information and knowledge – that’s a given. However, ‘Analysis’ of requirements needs much more Knowledge. The ability to use, plan, transfer, integrate, share, modify, and create knowledge for the purposes of fulfilling requirements is critical, but so under valued by management. The lack in understanding and infrastructure to support Knowledge Management leads to the attrition of knowledge.

  16. Solutions • The ‘Top-10’ Solutions • Expected Complications to Solutions • Applying Solutions across the RM Components

  17. The Top-10 Solutions

  18. Expected Complications to Solutions • Counter-forces to implementing new ideas and tools begin to surface • Workers fear their incomes may decrease • Finding the right balance between force and collaboration needs to be continually monitored • Increasing support needed from senior management becomes a concern • Dependency on internal sponsor to be accountable for initiative becomes risky

  19. Components to Solutions • Governance • Leadership • Operational

  20. Requirements Management

  21. Requirements Management Operational / Functional Delivery • Tactical Delivery of Requirements Management by primary workers • Adapters to Governance workers, i.e. the Project Manager • Adapters to Leadership workers, e.g. the Functional Manager

  22. Requirements Management Leadership • Strategic Vision and Leadership • Adapter to the Operational Functional Managers

  23. Requirements Management Governance • Delivery of Governance over projects by Project and Program Managers • Adapter to Project Managers from the PMO and the drivers for process

  24. Q & A

  25. A fully-annotated version and reference materials from this presentation can be downloaded from the www.bsaleaders.com website during one week following the show.

More Related