Mastering Software Project Requirements: A Framework for Successful Planning, Development & Alignment
296
Mastering Software Project Requirements: A Framework for Successful Planning, Development & Alignment
296Hardcover(New Edition)
-
PICK UP IN STORECheck Availability at Nearby Stores
Available within 2 business hours
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781604270914 |
|---|---|
| Publisher: | Ross, J. Publishing, Incorporated |
| Publication date: | 09/01/2013 |
| Edition description: | New Edition |
| Pages: | 296 |
| Product dimensions: | 6.00(w) x 9.00(h) x 0.80(d) |
About the Author
Read an Excerpt
CHAPTER 1
Identifying The Solution
DEFINED VERSUS UNDEFINED SOLUTION STARTING POINTS
While it is usually true that by the time the average business analyst joins a project the solution has already been defined, this is not always the case — especially on projects where the analyst is more experienced as senior business analysts tend to be brought in earlier in the initiation of a project. In fact, sometimes the analyst is a part of the discovery team who goes in to define the solution, even before the project has been initiated. Both of these starting points, which will be called "predefined solution" and "undefined solution," present different sets of challenges for the business analyst. Each challenge must be overcome and mitigated if success on the project is to be achieved.
Challenges that may be present when the solution has been defined by others include (but certainly are not limited to): a preexisting escalated level of commitment; a lack of fundamental understanding of the problem to be solved; an incorrectly defined solution; a lack of business planning (such as benefits realization, vision or mission definition); a limited operational perspective on the problem to be solved; as well as limited exploration of various alternative solutions.
An escalated level of commitment occurs when people and companies are heavily invested in the success of the project because they have spent a lot of money, time, and effort on it, or have done a lot of promotional and marketing work to "talk up" the new solution to employees, clients, and vendors. The best example of an escalated level of commitment is when gamblers refuse to leave their seats at the table because they have spent a lot of money and believe they will (or MUST, as the case may be) get it back, if they simply play long enough. The problem is that the gambler is not only sitting there. Spending more and more money in the pursuit of getting back the investment becomes a no-win cycle.
Sometimes, before an analyst joins the project, the business is already in this mode. They have spent a lot on the solution and are in the process of forcing it. "Failure," in their minds, is not an option — whether this is a realistic goal or not, and whether or not they are on a path to correct the situation. In this case, sometimes it is best to either shut down the project altogether or get the right resources in to fix it and let them have the authority to fix it. If the business analyst is a part of the team to fix the broken project, they must have the authority to do the whole job and to help the business make some tough decisions, or they simply will not be successful and the company ends up as a sad gambler waiting for the right cards and doing nothing but losing.
Believe it or not, there are times when a business analyst comes on board and there is a lack of fundamental understanding of what the problem to be solved actually is. It can be difficult for a business analyst (more so when this is a junior to intermediate analyst) to get a clear picture of the reason for the project, when the business stakeholders themselves are not clear.
Since the energy company could not afford a complex solution, and it was important not to build a mammoth solution that could not be tested, the executives could not agree on what the most significant impacts of the problem were and how to prioritize them. While in this example the disagreement took place before initiation, it is not uncommon for this situation to exist when the project has already started and the business analyst is working to elicit the requirements. The average business analyst can spend a lot of time working with and mentoring the stakeholders through this process so that they can start the requirements.
Unfortunately, the biggest danger from this situation is that the perception of the problem can change and the analyst will later see excessive and unnecessary changes to requirements throughout the remainder of the project life cycle. This problem can be compounded when the analyst was not a part of the solution definition and is viewed as an order-taker by the business.
Another problem analysts face when they were not a part of the solution definition is that the incorrect solution can be defined. Unfortunately, when this happens, the business has an escalated level of commitment, and it falls to the analyst to make the best of the situation. In this case, the analyst may have little control or influence and will still get the lion's share of the blame when things fail.
To further compound the problems already described (many of these problems could be present in any given project in varying degrees), many stakeholders and project sponsors forget that some basic business planning must occur in order to ensure the success of a project. It takes more than a timeline, a budget, and resources to be successful.
DEFINING THE BUSINESS NEED, VISION, AND MISSION
In reality, building a new process, infrastructure, or system means building a new part of the organization and must be planned as such. These plans should include (and yet rarely do): a benefits realization plan, a clearly defined and articulated vision (SHARED across the team and stakeholders), and a clearly defined and articulated mission (again, SHARED across the team and stakeholders).
One of the primary issues, as cited previously, which impacts projects and the success of business analysis, is that the solution is often defined before the analyst comes on board, and it has been defined by inappropriate resources (executives, employees, contract, or other). These resources may be well-intentioned, however, this does not mean that they have done the due diligence required to develop a great solution to the problem or even to fully understand the problem.
What often happens is that an executive, a team of executives, or a group of managers from a single division identifies a problem within the purview of their responsibilities (the teams for whom they are responsible and accountable). They may then investigate a few solutions and invite a couple of solution vendors or consulting firms in to estimate the development and implementation. The business team will not necessarily consult other groups about their perspective on the problem. They are not asked about how, or if, the problem impacts them and what results or changes they need to see. This leads to a limited business perspective on the problem to be solved and ultimately, can lead to developing and implementing the wrong solution.
The consulting firms and vendors will make their respective presentations and the stakeholders will choose a solution. This choice is not always based on a sound investigation of the decision or (business) case for the solution. Unfortunately, this will also lead to a limited exploration of alternative solutions that may be available. Certainly, there is good evidence to suggest that business analysts should — no, must — be involved in the solution definition. The benefits to the solution far outweigh any costs associated with additional perspectives of the trained problem-solver supporting the solution definition.
Alternatively, there are challenges that arise when the business analyst is involved in the discovery and definition of the solution. These challenges include: an inconsistent framework for discovery activities; mismatched expectations between the business stakeholders and information technology; the availability and commitment of resources before financial commitment to the project; as well as the occurrence of the "snowball effect" during needs analysis and problem definition sessions.
One of the biggest challenges that a business analyst will face, if they are included in discovery and definition of the solution, is that (as with business analysis as a practice area) there is little in the way of industry standards. This leads directly to an inconsistent framework for the performance of discovery activities. It cannot be stressed enough that processes (all processes) must follow the Capability Maturity Model (CMM), as illustrated in Figure 1.1, in order to be truly successful. The CMM illustrates how processes go from chaos to managed and optimized through careful management and the application of consistent frameworks and improvement principles.
Several years ago, I put the average consulting firm discovery process under a microscope and examined it from start to finish. Unbelievably, I found in excess of fifty seemingly small and insignificant errors that ultimately led to problems in the execution of the project. Having an analyst on the team during the discovery phase will significantly reduce the problems caused — when this analyst is truly analyzing and advising the business about the solution. This involvement and the discovery must be repeatable, measured, and assessed consistently across the board. No exceptions!
Another challenge business analysts will face in discovery is a set of mismatched expectations between the business stakeholders and information technology. They will have to understand and embrace their role as mediator in order to overcome this and build bridges between the two groups.
In this case, disconnect led to a complete misalignment of expectations for what was being built and delivered. Incidentally, it also led to high levels of conflict on the team because people were being ignored and had no influence on the project.
Another significant challenge the business analyst will have during discovery and solution definition is the availability and commitment of resources before the company's formal and financial commitment to the project. In other words, the company may not be willing to spend money up front because the return on investment (ROI) has not yet been established or proven.
It is also important to understand the level of personal commitment from the resources in this situation. Simply because the company may have allocated appropriate funds and resources (personnel), it does not follow that those resources have buy-in. Thus, when the company does make those resources available, they may not perform the work with any degree of skill or dedication.
Part of the problem could come from outside the project. For example, if a company has a track record of starting and stopping projects in the early stages — regardless of justification — the buy-in and dedication of the resources may drop, simply because they feel as though it does not matter what they do: it will be dumped and their work will be fruitless.
One of the problems with needs analysis and problem definition sessions is that discussions about the problems can turn into one big "venting" session, and the business analysts will be overwhelmed with an avalanche of information. In essence, it becomes a "snowball effect," with the amount of information increasing as the session progresses. Unfortunately, much of this information is unnecessary. However, to a degree, a wise business analyst will allow it to occur before taking control and asking pointed questions. When a problem has existed for a long time, people have become increasingly frustrated; above all, they have probably been complaining and when nothing was done, they did not feel heard. Allowing a degree of venting and then responding to it helps those people to feel heard and may also reveal critical details that will impact the solution.
This story illustrates how venting, if left unchecked, can simply turn into chaos. The best way to get past frustration and the need to feel heard is to listen. Listening does not mean that the meeting facilitator should simply let people go while they sit there like a lump, saying nothing. It means letting them release some of the anger and frustration and then guiding them towards the solution with active listening techniques.
Active listening is the process of engaging participants by asking questions about the problem and the solution they see. This is the only way to help people feel heard. When people feel heard, their satisfaction with the solution goes up, even if the solution does not address all of their complaints. In addition, when people feel heard, it is easier to get their overall buy-in because they feel they are working on the same team.
All in all, in spite of the challenges, there is a reason for business analyst involvement at each of these starting points. However, it is important to know and understand how each of these challenges can and will impact the quality of the requirements that are produced in the final document. Again, the reasons for analyst involvement at each of these starting points is to reduce the amount of time it takes to define the solution, to ensure that the solution defined is the right one, and to increase the buy-in of the stakeholders.
The goal of this material is to attempt to address these challenges in more detail, since it is important not only to identify but also to address each one. Well-known business analysis expert, Glenn Brule, once asked, "If you were only able to ask stakeholders three questions about their solution, what three questions would you ask?"
My response to this question is swift and simple:
1. What is the solution intended to resolve or do (this is to say, what are the RESULTS that the solution must produce)?
2. What other solutions/systems do they already have in place that works well?
3. What do they like and dislike about those solutions?
First and foremost, a business analyst must be able to identify the problem that needs to be solved, no matter what type of start they made on the project (defined or undefined). Unfortunately, not every analyst can identify the problem quickly and easily. For some analysts the inability to answer this simple question comes from having a defined solution before they arrive. For other analysts it may be attributed to the egos of the management team, and for still others, it results from a lack of clarity within the business and the other team members about the real problem to be solved.
Often, when the solution was defined before the business analyst became involved, the expectation is that this information has served its purpose of laying the foundation for the business analyst to follow in defining the requirements for the solution. This expectation exists because the solution has already been selected or identified. So, how can the business analyst ensure that the solution actually resolves the problem? Further, how can the analyst ensure that the requirements they write to define the detailed specifications to create this solution will actually align to the right solution (even if it is merely customizing and implementing a commercial off-the-shelf software solution)?
To be clear, verifying that the solution is going to solve the problem is one thing, and validating that the defined requirements actually support the development of this verified solution is quite another. These are discussed in depth in chapter 9, "Validation."
The bigger question, which often arises here, is whether it is the business analyst's job to verify that the solution is the right one to meet the need or to address the problem. After all, the business analyst, who arrives after the solution has been selected, has been allocated to define the requirements to create this defined solution. The answer is "yes." It is the business analyst's job to ensure that the identified solution is actually the right solution for resolving the problem or meeting the need. In the development of the requirements, the analyst must ensure that those requirements not only create the identified solution but also address all aspects of the problem.
Again, in some cases the business analysts are unable to clearly identify the problem, and sometimes this inability stems from an ego issue with the management team. In other words, management may be treating the information as if it is on a "need to know basis" and — to them — the business analyst does not need to know. When there is ego involved, questioning and researching the problem (its roots and impacts) can be interpreted as questioning the management decision about the solution. However, the business analyst is simply working to maintain alignment between the final solution and the business objectives through complete and accurate requirements.
Finally, the inability to identify the business problem to be solved may stem from a lack of clarity on the part of the business and management team. In other words, management has not clearly articulated the problem to the business analyst. When management has difficulty articulating the problem, the business analyst must work with the business and management team to help them clearly articulate the problem before any requirements activities can begin. After all, the analyst is accountable for defining the right requirements in order to ensure that the final solution meets the objectives and resolves the problem.
At the end of the day, if the analyst cannot articulate and identify what the problem is, it will be impossible to document the requirements. Moreover, why should the business spend money on it? The project will be riddled with interpersonal conflict, change requests, defects, and budget and schedule overruns. The project will probably only end up like so many other projects before it: digital roadkill along the information technology highway.
(Continues…)
Excerpted from "Mastering Software Project Requirements"
by .
Copyright © 2013 Barbara Davis.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Dedication,
Preface,
About the Author,
SECTION I: IDENTIFYING AND UNDERSTANDING THE BUSINESS SOLUTION,
CHAPTER 1 Identifying the Solution,
CHAPTER 2 Stakeholder Involvement and Management,
SECTION II: REQUIREMENTS PLANNING AND MANAGEMENT,
CHAPTER 3 The Evolution of Requirements on a Project,
CHAPTER 4 Requirements Management and Development Strategy,
CHAPTER 5 Establishing Metrics and Benchmarks,
SECTION III: ALL THINGS REQUIREMENTS,
CHAPTER 6 Elicitation,
CHAPTER 7 Analysis,
CHAPTER 8 Specification,
CHAPTER 9 Validation,
SECTION IV: APPLYING PROJECT AND ARCHITECTURE METHODOLOGIES,
CHAPTER 10 Implications of Agile on Requirements,
CHAPTER 11 Implications of Waterfall on Requirements,
CHAPTER 12 Implications Of WAgile On Requirements,
CHAPTER 13 Implications of TOGAF Enterprise Architecture on Requirements,
CHAPTER 14 How Business Analysis Can Leverage DO-178C Aviation Engineering Specifications,
APPENDICES,
APPENDIX A Writing Effective E-Mails,
APPENDIX B Sample Document Templates,