The point behind collecting data and deploying technology is 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.
When results do not 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 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 is important to identify and address these issues early on, not once a project is in its final stages.
One way to increase the odds of a successful system deployment is to redefine the Business Analysis process. Most business partners want a set of tools that provide to their level of data manipulation capabilities. Regardless, no matter how resourceful the business user might be at data handling, there is 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 company only has a vague image in their minds-eye of what they think they want. Everything works in the company’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 achievable, 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 company to ensure the final project can actually be brought to life, value-engineering as needed when elaborate design elements exceed potential benefits.
The company 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 company also assumes their intermediary with the IT department is not just taking an order and making a list. However willing the business company 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 company may not even realize exist. Thus, if the project presented seems right, the company assumes the end deliverable will work without glitches. At that point, like a building owner who does not care how concrete gets mixed, business companies 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. The “Analyst” part suggests they will 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. Moreover, if the delivered results actually work, luck may be playing a big part.
Likewise, an architect who does not 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 company is more likely to include 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.
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.