PARKSON.US
Saturday, July 25, 2009
  The business analyst and the RFP
Recently a group of business analysts I met with said that they are limited in what they do because the company outsources everything and all they end up doing is acting as an intermediary between the vendor and the business. I asked what part they play in the Request for Proposal (RFP) process to select the vendors that provide the solutions. They said that they were not involved at all. This is a shame. The business analyst can provide invaluable service to the organization in the development of an RFP and in the evaluation of the submissions from the vendors.

The RFP is a statement of a problem that the organization is having and a request for companies to submit solutions to the problem. Along with the statement of the problem are contractual information and constraints, such as dollar limits and ownership issues. The vendors submit their proposed solutions and the cost of that solution. Usually the solution and cost are submitted separately so that the solution can be evaluated without the influence of price of solution.

Since one of the primary jobs of the business analyst is to define the business problem to be solved, the business analyst can be instrumental in the unambiguous definition of the problem the business is having. Many times the RFP contains a set of requirements stating what the organization wants. Again, the business analyst is the ideal person to create these requirements.

Another job of the business analyst is to assist management in making decisions by researching and providing information to the decision-makers. This business analyst role is ideal to assist with the evaluation of the submissions of the vendors. The business analyst can provide the evaluation criteria derived from the business stakeholders. The BA can also manage the process of organizing the review process including vendor presentations.

While this particular company did not take advantage of the skills and knowledge of the business analyst in the bidding and procurement process, at least not yet, many companies are assigning their business analysts to manage the entire RFP process. This is a good thing.
 
Thursday, July 16, 2009
  System analysis and design vs. requirements analysis
Both the systems analyst and the business analyst analyze basically the same problem. However, the business analyst analyzes the problem to determine what to do to solve it from the organizational perspective while the systems analyst analyzes the solution that the business analyst provides to determine how the solution is going to be affected from the technical perspective. While the business analyst works primarily in the problem domain solving the problem, the systems analyst works in the solution domain implementing the solution.

The future state should be understandable by the stakeholders or users as an effective way of solving their problem. It is a good idea to show the solution in prototype, screen shot, storyboard, or diagram before committing to the requirements document.

The designer uses the models to also understand, but from a different viewpoint. She uses the models to look at the trade-offs and segmentation of the solution for eventual disposition in the design. The design itself will be a model that will depict exactly how the solution will be implemented. The communication in the designer’s model is more technical in nature and aimed at the developers who understand the more technical nuances of the implementation.

Both business analyst and system analyst / designer model the same problem. They also model the same solution, but from different perspectives. Each set of diagrams comprising the model is different, even if the same diagramming technique is used. A sequence diagram used by a business analyst will not be the same as the sequence diagram written by the designer and handed to the coder as part of the program specification, even when the business analyst hands the sequence diagram to the system designer as part of the documentation.
 
Saturday, July 11, 2009
  Politics and the business analyst
There is a tendency among IT professionals, and perhaps all professionals to view politics as evil. Politics are neither good nor bad; they just are. I am amused at IT people who will declare a decision that goes in their favor to be based on rationality and good sense rendered by a top notch manager or executive, while one that goes against what they espouse is clearly politically motivated. All organizational decisions are politically motivated. Just as with sports umpires or referees, every decision will be supported by half the people playing and decried by the other half.
One of the reasons IT people tend to be so anti-political is that their world is made up of clear-cut and unemotional outcomes. When you are wrong the computer tells you so. Everything ultimately is in bits - it's either yes or no, with no gray area in between. To us in IT everything can be reduced to simple reason. Anything else is politics.
"Playing politics" can be positive or negative. It can be positive when you as a BA from the IT side publish the information about the new system one department wants that is clearly of great benefit to the organization. You talk to other departments to determine whether the new system will negatively impact them, and alter the specifications accordingly. You present the benefits of the system to management, especially decision makers. You apply positive influence with those who are in decision-making positions. You overcome opposition with communication and information. Why would there be opposition to a new system that would positively benefit the whole organization? Because people are not informed of the benefits and listen to rumors or speculation. Because no facts have been presented to support the contention that the new system is beneficial. Because the money to be allocated to the new system is money that cannot be allocated to someone else's pet project.
We nerds might look on the BA who is making presentations in favor of the new system, going to lunch with executives to "push" the idea, and networking with mid-managers to apprise them of the impacts of the new system as "playing politics". We nerds figure that the benefits of the system should speak for themselves to any rational human being, so such activities are not necessary and therefore, by our definition, political. It is not. These activities are only "political" when you believe that everyone on the planet agrees with you intrinsically and therefore doesn't need an explanation of what you feel is right to do.
Katyani anbd Dawn are exactly right. There is no advantage to ignoring politics unless you simply want an excuse, especially when the layoffs come. However, there is good reason for all business analysts to understand and use politics. One definition of politics is "Politicks is the science of good sense, applied to public affairs, as those are forever changing, what is wisdom today whould be folly, and perhaps, ruin tomorrow. "
It is the business analyst who provides the information upon which organizatoinal decisions are made. When the business analyst withholds information or slants the information to favor a specific end or outcome rather than presenting the information in an objective manner, then the BA is indeed "playing politics" in the worst definition which is "to engage in political intrigue, take advantage of a political situation, or issue...to deal with people in an opportunistic, manipulative, or devious way."
Consider this: when the BA fails to gather all the information about a particular issue, say the request for a new system or feature on an old system, and presents only the information that supports the issue, is the BA playing politics or simply not doing his or her job?
 
Saturday, July 04, 2009
  Never Stop Learning
One of the common edicts one hears constantly is “never stop learning”. In the case of the business analyst that goes double.

First of all, you have to be current on technology to advise the business community and upper-level management about technology initiatives they are considering. You do not have to be a technological wizard. You simply have to know enough to explain why some things that appear feasible on a home computer cannot be done on the mainframe computer running most of the systems in use. You have to explain in understandable terms why building a system to take the information off a spreadsheet and make it accessible to everyone else in the department will take four months to do when the spreadsheet itself only took a few hours to create in the first place. You have to explain why infrastructure must be in place before that new wireless or interactive voice-response system can be built. You also have to know enough technology to understand what the technical people are telling you and know when they are trying to snow you.

Secondly, you must also be well versed in the organization: its products, its customers, its vendors, its business processes, its people, culture, and politics. Feasibility is not just technological. A significant overhaul of a system that is used by a large portion of the organization may not be feasible from an overall business or cultural perspective at this point in time. On the other hand, the business analyst can assist management by providing competitive market information that will enable decision-making at the strategic level.

Clearly, you cannot know everything. What you can do is know where everything is. Become particularly familiar with the information owned by the organization and the flow of that information, and where it resides, and you have the lifeblood of the organization. When you have the knowledge of the organization’s knowledge you are in a position to confidently facilitate decision making.

Labels: , ,

 
Parkson International Blog

Name:
Location: Sarasota, Florida, United States
ARCHIVES
April 2006 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / April 2010 / July 2010 / November 2010 / October 2011 /


Powered by Blogger