by Karl Wiegers | May 25, 2012 | Business Analysis, Collaboration, Uncategorized |
The first article in this three-part series proposed a Requirements Bill of Rights for Software Customers. In this article, I elaborate on the implications of these rights. In my experience, people who collaborate on project activities rarely take the time up front to discuss the nature of that collaboration. They don’t lay the groundwork for success by exploring just how they can work together effectively toward a common goal. Discussing these rights—or rights like them that better fit your environment—can go a long way toward forging that teamwork. The “you” in each of these rights is the user. Right #1: To expect analysts to speak your language Requirements discussions should center on your business needs, tasks, and objectives, using your business vocabulary, which you might have to convey to the business analyst through a glossary. You shouldn’t have to wade through indecipherable computer jargon when talking with a BA. Right #2: To have analysts learn about your business and objectives By interacting with users while eliciting requirements, the BAs can better understand your business tasks and how the product fits into your world. This will help developers design a system that satisfies your expectations. Consider inviting developers and BAs to observe what you and your colleagues do on the job. If the system being built is replacing an existing application, the BAs or developers should use the current system as you use it. This will help them see how the current application fits into your work flow and where it can be improved. Right #3: To expect analysts to write a software requirements specification The BA will sort through...
by Karl Wiegers | May 24, 2012 | Business Analysis, Collaboration, Uncategorized |
Customers who request a new or modified information system often do not understand the importance of obtaining input from actual users of the proposed system, in addition to other internal and external stakeholders. Marketing specialists with a great product concept sometimes believe that they can adequately represent the interests of prospective buyers. However, there’s no substitute for gathering requirements directly from the people who will actually use the product. This article, the first in a three-part series adapted from my book Software Requirements, 2nd Edition, addresses the customer-development relationship that is so critical to software project success. I propose a Requirements Bill of Rights for Software Customers and a corresponding Requirements Bill of Responsibilities for Software Customers. These lists underscore the importance of customer—and specifically user—involvement in requirements development. Who Is the Customer? A stakeholder is anyone who works on, is affected by, or can influence the outcome of a project. A customer is an individual or organization who derives either direct or indirect benefit from a product. Software customers include those stakeholders who request, pay for, select, specify, use, or receive the output generated by a software product. Other project stakeholders include business analysts, developers, testers, documentation writers, project managers, support staff, certifying bodies, legal staff, and marketing. Customers at the senior management or funding sponsor level are responsible for specifying the business requirements. They provide the high-level concept for the product and the business rationale for launching the project. Business requirements describe the business objectives that the customer, company, or other stakeholders want to achieve. Business requirements establish a guiding framework for the rest of the project,...
by John Parker | Feb 19, 2012 | Business Analysis, Collaboration, Uncategorized |
A recent analysis of enterprise software initiatives and of commercially available requirements management tools determined that 91% of participants used word processing programs to define and document system requirements. Many people believe that a simple list is sufficient to identify and communicate requirements to the development/implementation team. Still, from a practical perspective, it’s important to point out that Word Process applications were not designed for documenting and tracing requirements. Also, large word processing documents are not easily reviewed, shared, or amended across the cross-functional teams of business and technology users involved in a project roll-out. This approach also results in extreme version control issues and ideas and suggesting being overlooked. Reviewing large text-based documents often results in missing requirements or defects not detected. In addition, using documents, feedback from stakeholders rarely occurs until the individuals are affected, which can be as late as during testing or development. To be effective, requirements development should be incremental, iterative, and collaborative. Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Comments should be documented and tracked. Organizations should use a collaborative tool to define requirements and not a word processing application that was never designed to develop or manage requirements. With projects needing collaboration and interaction to succeed — and requirements needing to be created, collected, and easily applied — the notion of using large text-based documents is simply flawed. Nevertheless, it doesn’t stop companies for compiling single gigantic text documents, and then being frustrated with poor results and dissatisfied users. Rather, the focus for effective...
by Karl Wiegers | Jan 29, 2012 | Business Analysis, Collaboration, Uncategorized |
You might have noticed that requirements activities on projects sometimes lead to adversarial relationships. Customers don’t always feel that business analysts have their best interests at heart. Product managers get frustrated when customers demand never-ending changes in requirements but don’t want the delivery date to slip. Testers don’t appreciate having to redo their work because no one told them about updates to the requirements. Developers bristle when the project manager holds their feet to the fire to meet schedule despite piling on new features through scope creep. It’s a wonder anyone still speaks to their colleagues at the end of the project. If you’re interested in pursuing better requirements processes, you have to respect the many cross-connections between the software development group and numerous external stakeholders. This article identifies some of those important interfaces and suggests ways to engage such stakeholders in a collaborative approach toward more successful projects in the future. Figure 1 shows some of the project stakeholders that can interface with a software development group and some of the contributions they make to a project’s requirements engineering activities. Explain to your contact people in each functional area the information and contributions you need from them if the product development effort is to succeed. Agree on the form and content of key communication interfaces between development and other functional areas, such as a system requirements specification or a marketing requirements document. Too often, important project documents are written from the author’s point of view without full consideration of the information that the readers of those documents need. Figure 1. Requirements-related interfaces between software development and other stakeholders....
by John Parker | Jan 27, 2012 | Business Analysis, Collaboration, Uncategorized |
After years of focusing almost entirely on cost-cutting due to the recession, CIOs are now being asked to help the business find better ways to use technology to drive efficiencies that lead to competitive advantage and to implement technologies to improve customer acquisition. As a result, CIOs are increasingly demanded to be “more innovative,” “more collaborative” and to “add value” through the adoption of technologies such as cloud computing, mobile technologies, social networking, and business analytics to measure customer and market shift, all while concurrently driving down costs. Changing the cost-cutting mindset to delivering innovation and value will be challenge for many CIOs. There is an emerging view that IT should actually consist of two distinct yet integrated organizations: “Innovation IT” and “Operational IT.” They are conflicting in nature and responsibilities, underscoring the dilemma that IT organizations have today. Operational IT is less strategic than Innovation IT but the need to provide resilient, cost effective and reliable infrastructure to the business is critical and often takes precedence. As a consultant, I have advised many CIOs on strategy and business alignment. I have always been a proponent of innovation and business value and know that these objectives represent the real payback opportunity from IT. For example, in most organizations, IT spend represents about 4% of the total. A cost reduction in IT spend of 10% represent a total reduction in cost of .4%. This is relatively small compared to the benefits that could be obtained from other strategic initiatives that could for example increase revenues by 10%, reduce product costs by 5%, or reduce the cost of business processes by...
by John Parker | Jan 25, 2012 | Business Analysis, Collaboration, Uncategorized |
Active customer and user participation throughout the design and development lifecycle is essential to the success of any IT or business improvement project. Stakeholder communication is so important that it is specifically identified in the Business Analysts Body of Knowledge (BABOK): The Requirements Communication Knowledge Area is the collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience. Requirements communication is an ongoing, iterative activity that is done in parallel with Requirements Gathering and Requirements Analysis and Documentation. It includes presenting, communicating, verifying, and gaining approval of the requirements from the stakeholders and implementers of the project. Recognizing the importance of stakeholder communication and continuous collaboration, the Enfocus Requirement Suite™ provides subscribers the Web 2.0-based Stakeholder Portal.™ No other requirements management service offers a similar capability, providing access and transparency to users and other stakeholders throughout the software development and implementation process. The Stakeholder Portal™ is a secure cloud-based service dedicated to the myriad of interested parties that goes beyond meetings and shared word processing documents to truly connect stakeholders – including users, suppliers, customers, and consultants – no matter where they are located. It’s an easy-to-set-up, easy-to-use interface that makes conversations happen among business leaders, developers, project managers, and – most importantly – stakeholders about information that’s key to project success, including goals, needs, challenges, and opportunities. The Web 2.0 underpinnings of Stakeholder Portal™ allow stakeholders to engage and collaborate throughout the various stages of the project lifecycle, as enumerated below: Project Background – Stakeholders review the project vision, scope, and objectives to gain a good understanding of...
