Practical IT Research that Drives Measurable Results Overcome the Barriers to Good Requirements Management “As a CIO, if you do not understand your business requirements process, quit. ” -CIO, Information Services Organization
Introduction • • • Implementing solutions that enable and support business operations and goals is the obvious mandate for IT organizations. However, given IT’s reputation for poor project quality, overruns and rework, it is clear that fulfilling this mandate successfully is far more difficult than it appears. A critical cause of this difficulty is the failure to understand business requirements completely and to translate those needs successfully into technical functionality that drives value. In this research report, Info-Tech has outlined successful practices for business requirements management gathered from the experiences of your peers. Case studies demonstrate how to overcome common barriers to success to deliver technology solutions that enable the expected business results. Through case studies, IT Leaders share their tactics and techniques for requirements management in a way that will enable you to adopt similar solutions and realize similar benefits. This storyboard will help you: • Quickly assess the health of your requirements gathering practices. • Objectively identify the challenges you need to overcome. • Identify and select tactics for improving your organization’s requirements gathering capability.
Executive Summary • • Most IT leaders recognize that poor project performance leads to management dissatisfaction and disappointment. However, many miss the link between poor requirements management and project performance. They focus more on project execution instead of delivering a solution that really fits the needs of the business. This mistake becomes a vicious cycle resulting in poor quality, overspending, rework, and damage to IT’s reputation. To correct this problem, IT leaders need to help their organizations adopt four key principles of business requirements management: • Become intimate with how the business operates – information needs, activities and outcomes. • Determine what the business needs from IT – information and functionality that will drive efficiency, speed, and improved outcomes. • Validate IT’s understanding of requirements – continuously communicate and test that the intended solution will achieve expected results. • Recommend alternate solutions – proactively suggest ways where IT can deliver less costly, more efficient solutions or more effective results than otherwise envisioned. Adopt tactics practiced by your peers to establish these principles in your organization: • Build a Business Analysis competency. • Employ an Agile development/implementation methodology. • Adopt standards for managing changing requirements. • Resolve conflicting stakeholder needs.
Business Requirements Case Studies and Best Practices Connect Project Success with Good Requirements Business Acumen Understand the Impacts of Poor Requirements Understanding Requirements Perform a Requirements Health Check on Your Organization Validating Requirements Assessing Requirements
Less than 9 out of every 20 projects are considered successful, damaging the credibility of many IT organizations. Project success is defined differently depending on the organization, but staying on time and on budget are always considerations when evaluating the success of a project. A large majority of IT projects don’t meet timelines or stay on budget, and 62% of projects exceed both time and budget. 88% 84% Poor requirements are cited as a major factor in both project delays and budget overruns Series Exceed Time Estimate 93% Over budget 90% % of IT leaders that state poor requirements lead to delayed and over budget projects Exceed Time Estimate Over Budget Ø A successful track record of project delivery is vital for building credibility and reputation of the IT organization and the IT leader. Ø With their credibility on the line, IT leaders need to take action to ensure that good requirements management practices are in place, projects are being completed satisfactorily and IT is respected as a partner in achieving business objectives. Source: Info-Tech Survey. Interviews with Info-Tech Panel members, N= 250.
IT leaders cite poor requirements management as the leading cause of project failure. Poor requirements is cited as the major contributor to project problems 23% of the time, which is more than all other issues combined. Poor requirements is the most cited cause of project problems “ Requirements gathering is the most important stage in the project process. If you don’t collect those requirements properly, if business’s expectations are one thing, and yours are something else, the project is going to fail. -CIO, Real Estate For an overview explanation of requirements management, refer to Appendix I. ” The net result of a “poor requirement”? Poor requirements come in a variety of forms, but they all fail to adequately specify the actual needs of end users and/or stakeholders. The net result of a poor requirement is that the solution will either fail to have a capability that is needed or it will include features that are unnecessary. In both cases, poor requirements run the risk of inflating the cost of the project. Source: Info-Tech Survey. Interviews with Info-Tech Panel members, N= 250.
“ Employ tactics to effectively gather requirements to avoid post-production rework. On average, 26% of projects require post-production rework – most of which could have been avoided with an improved requirements gathering process. We consistently see that defects in requirements – requirements that are wrong, don’t meet the business need, ambiguous, etc. – take up about 20 to 30 percent of the effort on an average project. That’s a huge amount of overhead from poor requirements technique. -VP Professional Development, International Institute of Business Analysis ” üIdentify stakeholders: single out the knowledge experts üSet up individual and group interviews: probe for the whats and whys, not the hows. üDefine organizational strategy and project goals: meet with business leaders to understand their objectives üUse elicitation techniques to get out the five W’s: employ use cases and prototypes üSeparate the needs from the wants: be the arbiter and make recommendations When you look at statistics for why projects fail or why organizations struggle, it’s because they spend more time redoing stuff than actually doing it right the first time. -President & CEO, IIBA
To minimize cost overruns, catch mistakes early – a correction during the design phase costs 1% of a correction post-release. Architect’s adage: "I can move lines on a page very easily, but it is tremendously expensive to move brick walls. ” ØThe importance of strong requirements is aptly illustrated by the maxim that a defect found in design costs $1 to correct, one in testing costs $10 and one in production costs $100 (Barry Boehm, Software Engineering Economics). ØFurther, a defect that goes into production undetected can result in lost business productivity, lost sales or lost reputation. Projects possessing the following characteristics demand strong requirements processes to avoid escalating costs. üProjects have requirements that must be documented and managed for legislative compliance. üLarge, complex projects that result in many requirements documents. üSmaller projects with complex or shared requirements. üProjects with many stakeholders involved in the requirements definition. üProjects where requirements remain dynamic e. g. development of a new product or process vs. . a well-understood change to an existing system. üProject team is geographically spread out, making it difficult to communicate changes to requirements. üMaintenance/enhancements projects that start with net new requirements.
Recognize the need for trust and credibility with business partners. Info-Tech Insight: 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.
Don’t fall into common requirements management traps. Follow the tips and tricks of your peers to learn what not to do. 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. 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
Define the objectives of the project before trying to solve the problem. Keep developers away until objectives are defined. “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
Info-Tech Helps Professionals To: Sign up for free trial membership to get practical Solutions for your IT challenges “Info-Tech helps me to be proactive instead of reactive - a cardinal rule in stable and leading edge IT environment. ” - ARCS Commercial Mortgage Co. , LP
Скачать презентацию Practical IT Research that Drives Measurable Results Overcome
cbf0c514007c70f20efc68bcf983f5b5.ppt