1. Overcome the Barriers to Good Requirements Management Info-Tech Research Group “ As a CIO, if you do not understand your business requirements process, quit.” -CIO, Information Services Organization

4. Info-Tech Research Group Case Studies and Best Practices Business Acumen Understanding Requirements Validating Requirements Assessing Requirements Business Requirements Connect Project Success with Good Requirements Understand the Impacts of Poor Requirements Perform a Requirements Health Check on Your Organization

9. Recognize the need for trust and credibility with business partners. Info-Tech Research Group In organizations today it is common to hear IT staff talking about "the business“, and to hear IT’s internal and external customers referring to IT as “computer geeks”. Its as though both exist in separate worlds where common language isn’t spoken. In reality, until both sides can develop alignment and synergy , the organization cannot remain in business without IT for very long. And without the business, IT’s rasion d’etre evaporates. IT needs to spearhead the drive to forge a partnership with their customers. The first hammer stroke is working with stakeholders to develop best practices in business requirements management in order to build trust and credibility. Info-Tech Insight:

10. Don’t fall into common requirements management traps. Follow the tips and tricks of your peers to learn what not to do . Info-Tech Research Group Before you begin gathering requirements, have an open discussion with the project manager to define roles, expectations and the difference between a project issue and a requirements issue. “ We used to jump directly into projects - the BAs, the PMs and the stakeholders. I realized very quickly that project managers are a fairly direct, controlling breed because they have to be, and that you could easily have conflict between senior business analysts and the PMs. For example, we have had situations where there was pretty high tension, because a project manager felt that they should be the only person talking to the sponsors . For a long time, I didn’t really have the discussion with the project manager around, ‘This is how I see my role or the analyst’s role, and this is how we see the PM role, and here’s when it’s a requirements issue and here’s when it’s a project issue. How do you want to handle communication to the business?” You have to have that open discussion or the two are going to just run against each other. We also started defining the difference between a project issue and a requirements issue, so we knew who needed to be involved if a problem arose. This upfront, open conversation helped us to develop a sense of peer leadership instead of hierarchy on projects.” -Senior Systems Analyst, Insurance Industry The DON’Ts… The DO’s… Don’t leave role of BAs versus role of PM up for debate. Clearly define the role and expectations of the BA, the PM and the stakeholders. Don’t involve the technical analysts too early. Bring the developers and the designers into the conversation after the project objectives are defined. Don’t invest too much time, money and sweat equity in mockups. If they don’t work out, you may demoralize your IT group. Use mockups but keep them simple. They are meant to seek out issues and ideas, not offer a completed solution. Don’t forget to involve your stakeholders in review and assessment of requirements. Maintain dialogue and feedback loop with your stakeholders. Continuously assess and validate the requirements with them.

11. Define the objectives of the project before trying to solve the problem. Keep developers away until objectives are defined. Info-Tech Research Group “ I have let my technical analysts become overbearing on the requirements process before, and they start getting into what they think is easy to achieve as opposed to what’s needed. Introduction of the technical analysts too soon will get the group into solving a problem before they’ve defined what it is you’re actually trying to do. I think this might be a guy thing - because I do this too. For example, my wife comes home and she’s got this picture and asks me to hang it. Instead of asking where are we going to put it, how high should I hang it, how does this look, I’m immediately thinking, ‘I get to use this tool,’ and ‘oh, I don’t have any of those hooks. I’d better go to Home Depot.’ I’m immediately off solving the problem. In this analogy, the IT people are me, and they have to be brought back to the part where they’re just listening to the business user (my wife), talk about her requirements and think through those issues. She’s not going to walk in and say ‘I want it right here.’ It’s going to change. That requirement will move. You want to get the IT guys in at some point, but how do you control them so they don’t solve the problem too soon? It can ultimately lead to bad placement on the wall.” -CIO, Energy Industry

12. Assess the health of your organization’s requirements gathering practices to highlight areas for improvement. Info-Tech Research Group Signs that your requirement management process needs improvement : Perform your own health check. Use the “ Business Requirements Management Health Assessment Tool ” to assess the need for improvement.

13. Info-Tech Research Group Case Studies and Best Practices Business Acumen Understanding Requirements Validating Requirements Assessing Requirements Business Requirements Connect Project Success with Good Requirements Understand the Impacts of Poor Requirements Perform a Requirements Health Check on Your Organization

16. Business Acumen Info-Tech Research Group

22. Assign the Business Analyst as the pivot, ensuring understanding between both IT and the business Info-Tech Research Group They need to have a variety of characteristics, but at their heart, underlying it all, there has to be a little geekette or geek in them. -CIO, Financial Services Industry ” “ They have to be able to speak business speak, and translate that into speak that the developers and architects can make use of. They have to take technical issues to the business decision makers with options, in a way they can understand – so translate back from techie to business as well. -Senior Systems Analyst, Insurance Industry They have to listen to what the business is trying to do, not be judgmental about that, and then come up with ideas about how that could be accomplished. -IT Leader, Electric Energy Provider ” ” “ “ Info-Tech Insight: You are not doing your job if the BA feels they are constantly being dumped on. The BA can be the quarterback, but not the whole team . Make the BA role a formal one. Use the Info-Tech “ Business Requirements Analyst ” job description template to create the role in your organization.

24. Debate your alternatives when recruiting BAs – success can be achieved with BAs from the business or from IT. Info-Tech Research Group There is ongoing debate as to whether BAs should be recruited internally, externally or a mixture of both. With pros and cons for each argument, in the end, it comes down to the skills and competencies of the individual, and how they are cultivated in the organization. “ They’re bridging the gap between the technical part of IT and the actual process of the business. “ “ They certainly don’t have any chops that would allow them to have any level of discussion that would leave the technical people wailing away thinking of them as a credible interface.”

26. Understanding Requirements Info-Tech Research Group

30. Use specialized techniques to elicit requirements in ways that avoid the inherent limitations of stakeholder self-reports. Info-Tech Research Group 1 Have at least one collaborative session Group sessions sort out disagreements between stakeholders. They encourage creative input as individuals become inspired by the ideas of others. Don’t follow the process blindly Each interaction with a stakeholder is an opportunity to better understand their needs. Think critically about the information they provide and ask follow up questions. Use more than one elicitation technique to complement differences in each method. Techniques are outlined in the following slides. Use a variety of elicitation techniques. When choosing requirements techniques, keep the following in mind: 4 5 6 Choose at least one face-to-face technique. Interaction with end users through shadowing, prototyping, interviewing, or structured demonstrations can reveal valuable non-verbal information (e.g. reactions, difficulties, etc.) about requirements. Select an audience that is representative of key interest groups. Even a seemingly perfect combination of elicitation techniques can be undermined if the process ignores critical stakeholders. Missing stakeholders means missing requirements. Don't let the elicitation process eclipse project deadlines. Limit the number of techniques you choose to 2 or 3. Any requirements that are missed can be caught when testing prototypes. Avoid elicitation paralysis. 2 3 See Appendix I for a detailed list and descriptions of elicitation techniques.

33. Validating Requirements Info-Tech Research Group

37. Adopt Agile methodology for projects with frequently changing requirements Info-Tech Research Group Define System System Owner Customers Release Roadmap Track and Adjust Plan Releases Iterative Development Release Accept Work Products Agile Development is based on iterative development, where requirements and solutions are developed through the collaboration of cross functional teams. Agile methods follow a disciplined project management process based on frequent inspection and adaptation. Functional deliverables are small and time boxed. The best practices allow for rapid, small, high-quality releases that align development with customer needs and company goals.

42. Decide when good enough is good enough. Know when to commit. 0 Info-Tech Research Group IT Commitment. When does IT commit to a target of meeting the defined requirements? IT commits when stakeholders have signed off on the requirements. During design, issues may arise that mean IT will not be able to build or meet all requirements as defined. IT will initiate requirements change control to document, communicate and resolve the issue with the business and reach a new commitment. Confirm Decisions. How is consensus communicated? Document! Don’t make assumptions. Provide detailed documentation of requirements, issues and decisions to all stakeholders Close the feedback loop. When are requirements “good enough,” to move on to the next stage in the project? This depends on the nature of the project – its size, complexity and timeline. Requirements are good enough when: Stakeholders have reached consensus on requirements. Conflicts are resolved. Enough detail has been provided for the designers/developers to understand and proceed. Stakeholders have signed off. “ See first that the design is wise and just: that ascertained, pursue it resolutely do not for one repulse forego the purpose that you resolved to effect.” - William Shakespeare

44. Alternatives Recommendation Info-Tech Research Group

63. Appendix III: Top Level Graphs Info-Tech Research Group