250 likes | 377 Views
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,
E N D
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, 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
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.
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
Challenges • When Challenges become visible • The ‘Top-10’ RM Challenges • The ‘Not-so-Simple’ Challenges • Common Patterns that emerge
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
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
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
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
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.
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.
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.
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.
Solutions • The ‘Top-10’ Solutions • Expected Complications to Solutions • Applying Solutions across the RM Components
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
Components to Solutions • Governance • Leadership • Operational
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
Requirements Management Leadership • Strategic Vision and Leadership • Adapter to the Operational Functional Managers
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
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.