What’s the point behind collecting data and deploying technology?  Simply put, it’s to allow an enterprise to sell, operate, and deliver goods or services profitably. The individuals who undertake this effort are called Business Intelligence Analysts, or alternatively, Business Analysts. Business Analysts identify, document, and translate all the operational, marketing, and financial data relating to the needs of each business unit within an organization. Virtually every organization has some sort of infrastructure to achieve these necessary goals in support of the business as a whole.

While this all sounds good on paper, not every organization witnesses a happy collaboration between business partners and IT support staff. Even though a Business Analyst’s role may differ somewhat based on where it resides—whether solely within the IT organization, or even within one single business unit—when there are disconnects, they can often be traced back to breakdowns in communication and expectations because seemingly well-documented requirements get lost in translation. 

Get the Facts vs. Make It Up as You Go Along

When end results don’t meet expectations, most people resort to revisiting the requirements to explain that they made themselves clear, or conversely, that nothing being requested was ever totally clear. What naturally follows is rampant educated guessing and missed opportunities to clarify requirements before consuming additional resources . . . and then having to walk them back. Alternately, a systems and data deliverable may not match its intended purpose because critical data were not available, or at least not sufficiently transformed to deliver their expected functionality. These types of constraints, or oversights, can be pervasive and persistent, so it’s important to identify and address these issues early on, not once a project is in its final stages.

Business Analysts as Business Architects

One way to increase the odds of a successful system deployment is to redefine the Business Analysis process. Most business partners—whether high-level staff or less sophisticated users who want their results without understanding any data details—want a set of tools that cater to their level of data manipulation capabilities. Regardless, no matter how resourceful the business user might be at data handling, there’s still a need for someone to capture their intentions and functional needs and develop it into a cohesive configuration.

This is where the architect analogy comes into play. Before any contractor/builder sets out to build a new structure, they employ an architect to visually map out required and realistic dimensions to enable end-use functionalities. To this purpose, the architect plays a dual role as an artist and a design engineer:

  • Artistically, there is a visual and properly proportioned representation of the would-be result, but the sponsor only has a vague image in their minds-eye of what they think they want.  Everything works in the sponsor’s vision because they can assume away any practical limitations.  However, once those desires are translated to a physical image it becomes possible to better understand what is doable, how the structure will function in the real world, and where there might be serious cost implications.
  • As design engineer, the architect intermediates with experts who will actually build the intended deliverable, determining what the artistic rendition implies against realistic constraints and costs.  These insights are reviewed with the sponsor to ensure the final blueprints can actually be brought to life, value-engineering as needed when elaborate design elements exceed potential benefits.

The sponsor assumes the architect will bring their intentions to life, specifying clear project requirements that can be interpreted and then executed by a structural contractor. Applying the architect analogy to business stakeholders, the business sponsor also assumes their intermediary with the IT department is not just taking an order and making a list. However willing the business sponsor seems to be in exploring ideas, they intrinsically assume that the Business Analyst is going to look out for data and systems subtleties that the sponsor may not even realize exist. Thus, if the blueprint presented “feels right,” the sponsor assumes the end deliverable will work without glitches. At that point--like a building owner who doesn’t care how concrete gets mixed and poured—business sponsors typically lose interest in how data are captured and manipulated. 
Most people assume Business Analysts can translate requirements and goals in such a way that the IT department can specify and deliver a successful solution. Maybe it’s the title—there is an unstated expectation that the “Business” part of Business Analyst implies that the order taker has a significant level of practical understanding regarding business unit goals. The “Analyst” part suggests they’ll proceed with the mind of an engineer. However, if the requirements process is only a matter of collecting a phonetically correct reflection of what a business says it wants, it’s a good bet the real business goals will never be fully understood. And if the delivered results actually work, luck may be playing a big part. 

Likewise, an architect who doesn’t understand how to translate their artistic visions is less an architect than just a competent artist. When a building owner is truly receptive to the architect suggesting what “could be done” and why it might be useful to have that functionality, great things happen. Similarly, a business sponsor is more likely to embrace an IT partner who, because of an in-depth understanding of their goals, can offer suggestions that would otherwise be overlooked. The best Business Analysts can envision underlying possibilities in data that offer valuable business intelligence in ways the business may not even be aware.  Thus, like a skilled architect, the skilled Business Analyst can solidify the vision and map the practical implications to a blueprint.

Designing Bridges and Wheelhouses

Whether a sponsor seeks to work with a Business Analyst or an Architect, intermediate bridges and wheelhouses are required.  Divergent purposes, along with business unit wish lists traveling on different tracks must be synchronized.   This is an ideal time to consider outside expertise to fulfill the Business Analyst or “middleman” role.   Why?  Because consultants in business intelligence intrinsically provide more depth and objectivity in what IT departments usually call Business Analyst functionalities.   Sometimes, business units can be too close to a problem to solve it. BI consultants, like architects, enjoy the advantage of a fresh perspective—unencumbered by internal politics or entrenched routines—and can offer temporary or ongoing expertise that supplements, rather than supplants internal staff, allowing enterprises to use existing resources more efficiently.  Another advantage of this buffer-zone approach is that it takes the heat, so to speak, off of internal staff; consultant change agents, with appropriate support from their business sponsors, generally have more room to achieve positive outcomes.

Once a business sponsor has the Business Analyst “middleman” role in place, the first consideration is to determine if the strategy for success will be through empowerment or enablement, or perhaps a blend of both.  Empowerment is building somewhat from scratch to the sponsor’s vision.  Enablement is deploying an existing “structure/facility” that can become satisfactory to the goals at hand with appropriate collaboration and perhaps some enhancements and retro-fitting. 

Regardless of the choice of strategy, the steps are the same at the highest levels.  It’s just a question of whether the design starts with the Business Objective as a first step or effectively addresses the Business Objective as the last step because a suitable infrastructure already exists.  Chart 1 demonstrates that success is more likely if there is a Business Analyst in the middle with the ability to make a positive impact, translating and negotiating the desired functional specifications.

 

Chart 2 gets more tactical about the Business Analyst role, but the message remains one of employing the Business Analyst as the translator of the Business Needs into an actionable IT Blueprint.

 

Cementing the Business Unit and IT Partnership

The Business Analyst can help solidify the spirit of partnership by focusing on shepherding a deliverable schedule that impacts the business in a measurable and concrete fashion at least every 90 days.  All too often a project loses its momentum and perhaps even its funding because it languishes behind the scenes in the thralls of elaborate development processes.  The business seldom understands and even less often cares about the complexities of delivering new data infrastructures.  Business partners need to see an evolution that benefits them in the timelines of their customer facing world.

In order to assure signs of progress and avoid chasing down the wrong deliverable path, even if the deliverable is built exactly to specification, is to deploy Proof of Value phases and interim prototypes.  These methods not only guarantee agreement and show concrete signs of progress, they also allow for refinements of specifications that respond to unforeseen, unexpected events after the start of a given project.

Ron Brooks is VP of strategic consulting at CBIG Consulting