Defining and Managing Requirements: a Framework for Project Success and Beyond Requirements Are Critical As Project Managers Try to Control Project Failure Rates
Total Page:16
File Type:pdf, Size:1020Kb
RG Perspective Defining and Managing Requirements: A Framework for Project Success and Beyond Requirements Are Critical as Project Managers Try to Control Project Failure Rates 11 Canal Center Plaza Alexandria, VA 22314 HQ 703-548-7006 Fax 703-684-5189 teamRG.com © 2017 Robbins-Gioia, LLC Defining and Managing Requirements Conventional wisdom says you will never reach Get at the true requirements your destination if you don’t know where you’re Enforce tracking and management of going. However, all too often, that’s exactly how requirements throughout the life-cycle projects are implemented, most often as a result Allow for a structured approach to the of the business and technical staff being unable to review and approval process communicate their needs to each other. This Contribute to future projects so that communication gap usually occurs early in a valuable assets are not lost project, and the negative impacts manifest Each of these four critical success factors is themselves throughout the entire life-cycle. discussed next. Extensive re-work, scope creep, missed deadlines, low morale, and required features being dropped Critical Success Factor #1: Eliciting from product releases are just some of the issues the True Requirements that are costly and can be traced back to a The key to uncovering real requirements (and by fundamental lack of understanding of the business that we mean those that meet true needs) is needs. three-fold. You must have an efficient and For the project manager, unclear requirements are effective process to guide the way requirements the cause of mounting frustration throughout the are gathered and documented; your process must life cycle. Everything may seem fine – goals were include an architectural structure for capturing set, the team was built, all the necessary tracking requirements information so that all parties and management tools were in place, technology understand what they are trying to document; the was selected, requirements gathered and signed process must emphasize the use of models as a off, and the development staff was off and coding. mechanism to gather the information and Then it starts to become apparent everything communicate with all stakeholders – the sponsor, wasn’t fine after all. Faced with unclear the subject matter experts, and the developers. requirements, a development staff has two The process you follow should provide a solid options; either go back to the business and gain a foundation for gathering, documenting, and better understanding of its needs, or implement maintaining requirements, and should eliminate best-guess. These “false starts” are time- the communication gap between IT and the consuming for both staffs. Requirements may business. This can best be achieved, we feel, by also be uncovered that result in a significant re- using communication tools and techniques that evaluation of work effort (usually more, not less). both IT and the business understand, including Implementing best-guess will post-pone the issue visual models. These models, while detailing until later in the life-cycle; at user acceptance complex business processes and system behavior, testing it will become apparent to the business are not themselves complex to understand or that they are not being delivered what they paid create; thus the business is as comfortable for. Obviously, these are both situations the participating in their creation and review as is the project manager will want to avoid. IT staff. So what can be done? To prevent risk of failure, The emphasis on using models to elicit the project manager should incorporate practices requirements is in contrast to processes and tools that: that would have you build requirements by extracting text statements from documents. It is true that some requirements – particularly initial 1 Defining and Managing Requirements business objectives – lend themselves to text Critical Success Factor #3: statements. And text statements are also a good Structuring the Review Process way to capture operational requirements such as Review and approval of requirements can be the number of users that must be supported, or cumbersome and difficult to control. To be the necessary levels of security. successful, the project manager must be able to But process requirements, functional make review assignments to users or groups of requirements, user interaction requirements, and users and track comments that have been made. information requirements can best be understood It may seem obvious, but performing review using models. It might take several pages of text cycles via the web clearly has advantages over to describe the process of, say, taking an order. paper-based approaches. Your approach should Even then, you risk missing some key business include sharing and review of the information via rule or forgetting to document the necessity for the web. In that way, you can support any using a particular piece of data. For these kinds of number of reviewers in any number of locations. requirements, a visual approach is preferable to a Critical Success Factor #4: Moving written one. If you’ve ever been part of a building Beyond the Project – Reuse project and reviewed architectural drawings, you’ll know exactly what we mean when we say that Once a project is complete – that is the visual models are superior to text descriptions. requirements have been realized – then what? Typically, there’s some kind of documentation, but Critical Success Factor #2: Tracking that’s it. But if your process has reuse as one of and Managing Requirements its embedded disciplines, you can reap many Once you’ve gathered requirements, you need a advantages beyond the project close date. In process for tracking them and managing changes this way, your process can provide support for to them as they go through the design and continuous business improvement – not just one development phases of the life cycle. It’s a given project at a time. that there will be changes over the life of a Reuse of project artifacts can serve multiple goals. project, especially for complex or lengthy projects; The most obvious is that the requirements why not plan for them? The process you follow artifacts serve as documentation of the delivered should incorporate techniques to meet this goal. functionality. If an enhancement is requested, the First, you must be able to track the status of each requirements artifacts can be used to perform requirement. Is it approved, or only under impact analysis and to judge the appropriateness, review? Second, you must be able to trace the cost, and complexity of implementing the request. requirements from the origination through to their The second goal is to provide a jump-start to development. What was the business objective subsequent projects. For example, the that caused this requirement to be stated? How deliverables generated from understanding and will this requirement be realized? Third, you must modeling the claims process can apply to other know the impact of a proposed change. If this projects that touch the claims area. Finally, the change is accepted, what other requirements will models developed for a project can become input be affected and do these also need to change? to developing an architecture of information that Finally, you must know the history of requirements can be shared enterprise-wide. changes. How was this requirement initially stated, when did it change and why? To fulfill these four important critical success factors, you need two things: first, a defined 2 Defining and Managing Requirements process for the requirements lifecycle; second, a Understanding the business process provides a requirements definition and management tool (or context for all other project work. It can help set of tools) to make the process practical. discover business policy and business rules that may be appropriate for a rules engine. It also Let’s talk about the process first. uncovers “process rules”, that is, those rules that A Defined Process for the Requirements Life outline when things should occur and in what Cycle order. Finally, business process understanding There are many methodologies out there, yet helps you identify the pain points and the most are missing some crucial component: they opportunity areas that a technical solution could aren’t model-based, or they don’t address the address. critical task of managing requirements throughout (I) Identify Critical Requirements. the life cycle, or they don’t include a mechanism Follow a systematic approach to identifying the for the review and approval process. Look for a requirements that the business deems important. comprehensive, complete, repeatable, and Use repository-based tools to capture the teachable approach that can be used for many requirements and develop the architecture types of projects, including ones focused on: (sometimes called the “meta model”) so that users Building and managing enterprise of the process know exactly what needs to be architectures documented, where it needs to be documented, Understanding and improving business and how it needs to be documented. The meta processes model provides a template structure that makes it Changing organizations easier to gather information, to build relationships Developing new systems or enhancing among the information, and to produce project existing ones documentation based on the information. Exploring new technologies (N) Navigate the Deliverables. Developing new product offerings Architect the business analysis and requirements There are four basic principles of a good approach deliverables so that they can be used in many that can be summarized by the acronym “L-I-N-K”. ways through the life of a project and beyond. Following these principles leads to requirements For example, use cases and data models can be that link the business side of the house with the IT transferred to an object-oriented development tool side of the house. to jump-start the design effort, or they can be (L) Lead with Business Understanding.