Summary of key points
To act as a true advocate for the business, the business analysis professional must understand the business terminology, objectives, and processes of the business area within the scope of each project.
When the BA is organizationally placed inside the business area, he or she understands the employee’s perspective and can easily advocate for the business. When the BA is organizationally assigned somewhere outside the business area, in IT for example, this is a more challenging step.
The BA should be comfortable using various elicitation techniques and should be able to select the most appropriate approach for each situation.
Essential business process analysis is a core skill of the business analysis professional and requires the BA to be able to see through current procedures and software support to find the core business activity.
The BA must not assume that software or technology is the answer to every business problem. Business analysis involves research to completely understand a problem, and its root cause, before suggesting a solution.
The BA is also responsible for solution implementation planning. Rollout plans may include organizational/personnel changes, business policy changes, procedural changes, or software or technical support.
Business analysis involves eliciting business requirements from various stakeholders whose viewpoints are different. The BA confirms his or her understanding by learning from various sources, filling in gaps, and developing complete business models.
Bibliography
Constantine, Larry L. and Lucy A.D. Lockwood (1999). Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley.
Hertzel, Bill (1993). The Complete Guide to Software Testing. Second Edition. Wiley-QED Publication.
Kit, Edward (1995). Software Testing in the Real World. Addison-Wesley.
McMenamin, Stephen and John F. Palmer (1984). Essential Systems Analysis. Yourdon.
Myers, Glenford J. (2004). Art of Software Testing. John Wiley and Sons.
Pande, Peter S., Robert P. Neuman, and Roland R. Cavanagh (2000). The Six Sigma Way: How GE, Motorola, and Other Top Companies Are Honing Their Performance. McGraw-Hill.
Robertson, Suzanne and James Robertson (1999). Mastering the Requirements Process. Addison-Wesley.
Stevens, W., G. Myers, and L. Constantine (1974). Structured design. IBM Systems Journal. 13(2), 115–139.
Weisberg, Herbert F., Jon A. Krosnick, and Bruce D. Bowen (1996). An Introduction to Survey Research, Polling, and Data Analysis. Third Edition. Sage Publications.
Wood, Jane and Denise Silver (1995). Joint Application Development. Second Edition. John Wiley.
Yourdon, Edward and Larry L. Constantine (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall.
Chapter 5: Know Your Technical Environment overview
Technical awareness of the possible is one of the values that business stakeholders expect from business analysis professionals. It is important that you stay current on what technology is being used for what purposes. Business stakeholders expect business analysts (BAs) to recommend technology that supports the business requirements and helps the business operate more efficiently and effectively. IT stakeholders expect BAs to communicate requirements in their “language” and not overpromise to the business stake-holders. Often, business stakeholders will hear of a new technology and ask if it could be used in their business area. The more you are aware of technology, the more valuable you will be to your stakeholders, even when your answer to them is no. Sometimes the new technology is in its infancy and not yet ready for production use. Sometimes the technology is too expensive for the business area being addressed. Maybe the new technology holds promise for the future and should be included in the business’s strategic plan. Even if you are not an IT expert, you should be able to talk intelligently about the possibilities.
|