Business Analyst — A Programmer's Best Friend

One day a friend of mine was telling me a story of when she was a little girl. It was holiday time and all the family was over for dinner. Her mom was busy in the kitchen, when she pulled out this big beautiful roast from the oven. She placed it on the big fancy cutting board and the first thing she did was cut the roast in half. Why did you do that she asked her mom and she was told '"Well, that is what grandma always did." With grandma in the other room, she ran over and asked, "Grandma, why did you cut the roast in half as soon as you put it on the cutting board?" And grandma said, "Well, that is what your great grandma always did." Seeing great grandma over in the corner, she ran over to great grandma and asked, "Great grandma, how come after you take the roast out of the oven, the first thing you did was cut the roast in half?" And great grandma said, "Because it would never fit on my cutting board."

Unfortunately, too often, too many companies are the mom in the kitchen dealing with the roast when it comes to methods of doing business. Management tends to overlook the fact that 25 years ago, how they were doing business was a great idea (because the cutting board was too small) but times change (the cutting boards got bigger). I know of one company that was making some major system changes. The "this is the way we have always done things" corporate mentality was so deeply entrenched that they broke the cardinal rule of implementing a new system. Prior to initial implementation, they twisted and contorted the new application with modifications to meet their current methodologies, rather than adjusting those same methodologies to meet the core design of this new system (which somebody thought was a better idea for the company). Failing to utilize a qualified project manager and business analyst, who would have steered this project effectively by providing the necessary analytics and direction, cost this company dearly.

I have worked in a few MultiValue shops throughout my programming lifetime and have experienced numerous senior I.T. managers that are just as ensconced in their "old" ways of doing things. To broach them with the idea of employing something like a business analyst would be like (in their minds) putting three legs on an ostrich. It may be nice, but we do not need it, nor does it really serve a purpose. Besides they would probably cry, what is a business analyst anyway, and why do we need them? With all my experience and understanding of business, what benefit is gotten by utilizing a business analyst? And what the heck do they really do anyway besides generate paperwork and more levels of procedures and red tape?

Business Analysis is the practice of enabling change in an organization by defining needs and recommending solutions that deliver value to stakeholders. A business analyst is used to identify and articulate the need for change and how an organization will work to facilitate that change. A qualified analyst has mastered the skills to act as a guide and lead the business through the unknown territory to get to its desired destination. Some products of a business analyst that propels a project forward are:

• Project scope
• Business Requirements
• Functional Requirements
• Operational Requirements
• User Requirements and User Case Studies
• Product Requirements and Product Case Studies
• Change Management

Thinking about your company or the company of friends or customers, how many function in reaction mode instead of strategic? How many times do we find that we are reworking and re-reworking tasks because there was not enough time initially to properly map out the needs and requirements? In today's economy, it is more and more important to get it right the first time because the consequence of a "do-over" could be enormous.

Did you know :

• 71% of failed software projects are traced to poor requirements - CIO Magazine
• 40% of the effort in an average software project is fixing errors
• Requirement defects account for 56% or re-works - Butler Group 2005
• $250 billion of annual waste is traced to poor requirements (globally speaking)
• $46 billion is spent in the US on fixing error caused by poor requirement definition (US Bureau of Economic Analysis 2008)

So what is an organization supposed to do? They say that the definition of crazy is a person who does the same thing over and over again and expects a different result. More and more companies are finding that a structured, detailed analysis of projects is not only more effective but proves a greater return on their investments. The growth of business analysts in companies today is greater than ever and is a reflection of this corporate mindset. Let us take a few minutes and see what a BA would bring to a task you might encounter.

Wilber's WorldWide Widgets, Inc. wanted to develop a new order entry management system. First thing, the BA meets with the project sponsor and related stakeholders to gather the essential information to compose a written description of the project at hand. This section describes some of the steps that the business analyst would follow to model the resources, business items, and activities involved in the process. I will consolidate and not include many thoughts for the sake of brevity in this example.

Initially, our analyst meets with the project sponsors, in this case the director of sales and the customer service manager. The goal of this meeting is to establish the purpose and items they want to see accomplished (from a tree top level). Now the initial business requirements have been established for this project.

Business Requirement

1. A customer calls the customer department. The caller is initially defined as a new customer or existing customer
2. Actions for new customer:
1. The service representative creates an account for the customer on the system
2. A credit check is performed and a price list formula is developed for the customer.
3. If the credit check comes back with a negative result, the account manager is notified.
1. The account manager reviews the order and decides whether or not to approve it.
2. If the account manager approves the customer, then the customer service creates the order. .
3. If the account manager does not approve the order, then the account manager notifies the customer of the rejected credit check.
3. If a customer currently has an order in the system and is calling to verify or update their order:
1. The customer service representative brings up the customer's existing order and reviews it with the customer.
2. if no changes are required, then customer order remains unchanged in the system, the customer service representative thanks the customer and disconnects.
3. If the order requires updates, the service representative updates the order. After the order is updated, it follows the same path as a new order
4. If an existing customer is calling to place a new order:
1. The service representative creates a new customer order. (There would be multiple steps associated here but for brevity, this will do.)
2. The system performs credit status, inventory availability and other status checks related to this order.

Our business analyst now meets with the customer service supervisor, possibly the customer reps, and all the other key players within the company who would be directly affected by the new order management process. After discussions and meetings, our BA is able to start breaking down the business requirements into actual tasks, business items, data flows, and processes.

Tasks

There are several activities that are performed in the process. Here is an initial list of tasks (some of these might be subprocesses that can be broken down further) :

Identify the customer as a new or existing customer

Retrieve the customer record from the database and create or modify as required

Determine whether the customer is calling to place new or update existing order

Create and review the order with the customer and modify if necessary

Verify customer credit and notify the account manager of a failed credit check

Submit order for processing

Business Items

These are a few items that are created or modified during this process:

The order that is placed by the customer

The customer account record that tracks customer information

The e-mail message that is generated if a customer's order is approved

Because Wilber wants to track data such as call times, a tracker of customer's call activity needs to be maintained.

Order Handling Process Diagram (a small piece thereof)

In order to add definition to the business flow for the project, the business analyst very often will use flowcharts (basic, business, cross function, engineering, etc.) like the one in figure 1. As you can see, this flowchart clarifies the process flow to the stakeholders. The process starts with the customer call, then the CSR identifies the customer, sees if this an existing customer, and flows through to the end of the process. In many cases, this flowchart may well be accompanied by a cross function chart to define responsibilities.

Fig. 1

Data Model

Very often with new tasks, there is the addition of new files and attributes within the files to support the new process. In order to be sure that all stakeholders (I.T. included) have what information they will need within the database, a simple data model can be used by the BA to define these new values of data. Accompanying this simple chart (fig. 2) might be a data flow diagram flowchart to elucidate within the flow of the process how, where, and when the database is accessed and updated.

Fig. 2

I have not included other matters a BA would have identified like hardware demands, personnel needs, and other points. Our analyst now needs to define the scope of the project along with all the requirements entailed, along with user cases, so that there is a clear picture of all the facets that will be involved in this task. The BA presents this final presentation to the key stakeholders, who sign off on all points, after which it is presented to the development team.

Once the actual design and coding begins, the BA is then responsible for controlling and documenting any and all change requests that are subsequently made to the project at hand, adjusting the baseline as needed. This prevents any extraneous or unnecessary additions to the project that extends beyond the agreed upon baseline and scope of the matter at hand. Should a change be required for the project, the business analyst will formally expand the scope and alter the baseline to account for the alteration.

This example has touched lightly on what would actually be a very sizable project. The benefits of a business analyst can extend to the smallest of tasks as well as the largest of tasks. Let us say that a manager wants a minor screen adjustment that would take (virtually) no time to produce. How many times have you heard, "While you are here…" or, "While you are doing that, can you also….." or, "That is not what I wanted…." while doing this couple lines of coding change. A BA would construct the definition of the scope, requirements and baseline and have the requesting sponsor sign off on these matters. In what would amount to two or three pages of documentation, a clear, approved picture would be built, leaving the (couple lines of code) change for the development team to make and implement.

At a basic level, business analysis reduces the overall costs for a project. Although an I.T. manager would grasp this immediately , this concept is often counter-intuitive for managers unfamiliar with business analysis. At first blush, adding a business analyst and producing additional project documentation appears to be an additional cost. If you are managing without a business analyst today and you introduce one, the cost and the labor involved may appear to increase, especially at first. However, in actuality, business analysts are focused on reducing costs. This could be measured in the following ways:

• Reduction in rework — the team stays focused on the right requirements, which will reduce the amount of unnecessary change. There will always be some change, as implementation encourages learning. However many projects without structure are plagued by change requests because requirements were not well understood. This kind of change is waste and can be greatly reduced or eliminated by a business analyst.
• Reduction in requirements churn — Stakeholder time is valuable, but without someone in the business analyst role, stakeholders might spend excess time in unproductive discussions. An analyst can help drive logical and efficient decision-making processes, track open issues, and document discussions, reducing the amount of time spent rehashing previous discussions and going down rabbit holes.
• Discovering more cost-effective solutions — When the business analyst is licensed to find any number of solutions to a problem, specifically solutions that may not involve information technology, the business analyst actually might help reduce costs by finding more cost-effective solutions.

The business analyst can also help the project team by increasing the potential benefits yielded by the solution. Some key areas come to mind.

• New business needs or requirements are discovered — A business analyst does not just pick up or "gather" the requirements. Most often a business analyst must actively mine for or discover the requirements (intl-spectrum.com/s1057). By actively discovering requirements, the business analyst helps the business come to an improved understanding of what is needed from the solution to be successful.
• Prioritization ensures focus on value — I know where I work, left unto itself, priorities would be linear (every need as important as the other). By using various prioritization techniques and prioritizing at several stages in the requirements lifecycle, it ensures that the stakeholder efforts are invested in the requirements with the greatest importance and most potential benefit.
• More effective implementation of new solutions by the business — Even without formal change management practices, focusing on the business analyst principles of clarity and alignment help the organization prepare for change.
• Providing a framework in which an IT team can scale — as an organization grows, so does the number of stakeholders and project. As this happens, the natural patterns of communication that worked for a smaller team tend to fall apart. Business analysis can be a component in enabling a small team to scale to a larger one, thereby increasing the benefits realized because more projects can be successful investments.

The business analyst can help with formulating a plan of action which allows the stakeholder to pinpoint where a problem exists. Narrowing down the problem can be handled by the BA through research and interviews (meetings). Once the problem has been uncovered and defined, the business analyst will be able to work to determine which is the best course of action. A project report can be written outlining the step needed to reach a predetermined solution.

The good BA will be able to act as a liaison between departments and work with them to be sure there is no second guessing on points of the project and that all tasks expected by the department are being met. The business analyst will be able to express the needs of the stakeholder and the end user in such a way for the I.T. department and others involved to understand. There are times when users, stakeholders and the development team are on the same page but each is interpreting key items in different ways. The qualified business analyst will be able to set the wheels in motion that will allow stakeholders and development team to understand what is needed.

Corporations that employ business analysts have a higher rate of productivity from their I.T. department and find that the programmers within generate cleaner code that falls closer to the needs of the user base. As the title states, the business analyst is a friend to the I.T. development team, not an adversary but an ally. They remove all the time needed to define and structure a stakeholders needs, freeing the development team for tasks that better suits their skills. A good BA will present a project to the programmer with clear definitions and requirements. He will generate mock ups of screen designs when applicable so it is clear what the user wants. He will manage all the change requests that occur within a project, preventing creeping expansion. The business analyst may work with all stakeholders to plan and implement a testing process for the given task.

Can companies in today's world live without business analysts? Obviously they can. However, the business analyst can bring structure (i.e. methodology to gather requirements, process baseline) and formalization of requirements (i.e. gather the required capabilities) into this process, which may lead to increased foresight or outcome among business owner.

Featured:

Sep/Oct 2012