Business Analyst, IT Must Be Buddies for Effective Business Intelligence

Business analysts and IT programmers should be friends, or at least effective collaborators. They are carrying out separate agile processes, and the value of these to business intelligence and to overall business agility is halved if they fight with each other instead of abetting each other.

One of the songs in the musical “Oklahoma!” involves a politician attempting to persuade farmers and ranchers to be friends, so they can present a united appeal for statehood. Of course, says the rancher, I’m happy to be friends, even if the farmer’s fences are constantly injuring my cattle. Absolutely, says the farmer, I’d love to be friends, although the rancher is constantly trampling my crops. They end up pretending to be friends while glaring at each other.

Is there a similar dynamic at play in the new world of business analytics? Today business analysts are rapidly implementing and incrementally refining new analytics capabilities that yield useful new insights, based on incessant interactions with other business folks who are the end users of their solutions. In fact, the process of business analytics implementation resembles nothing so much as that of agile software development.

So who is a big hindrance? Why, IT, that “hideously inflexible” (in the words of one respondent to a recent Sloan Management Review survey) bureaucracy that guards the data warehouse – according to the business analysts interviewed by SMR.

Meanwhile, 25 years after programmers started talking about the concepts (e.g., fourth generation languages) and 10 years after the arrival of the Agile Manifesto, most IT development shops are awash with Scrum-type agile programming, spiral processes, user stories, technical debt (the idea that code should be refactored periodically to ensure ease of further change), and the use of agile development techniques to achieve agile business intelligence.

And who is a big hindrance? Why, that rigid, unresponsive business bureaucracy that demands and then objects to cost estimates for a process whose time span is by definition indeterminate, and imposes counterproductive formal project management and “governance.” Business analysts, by definition, must be part of the corporate bureaucracy.

And yet, the business analyst and the IT programmer should be friends, or at least effective collaborators. They are carrying out separate agile processes, and the value of these to business intelligence and to overall business agility is halved if they fight with each other instead of abetting each other. Collaboration doesn’t necessarily require that the two cultures be friends; but it does require that organizations think carefully about how to mesh the two without diminishing the enormous, productive reservoirs of enthusiasm that each side brings to its tasks.

The Dual End User Approach

The key to business analyst/developer cooperation is the fact that they should be tackling different levels of the same problem. That is, the business analyst is more tactical. He or she moves briskly from immediate problem to immediate problem.

Meanwhile, the business intelligence developer is (or should be) more strategic. He or she moves briskly from new type of analytics functionality to new type of analytics functionality. So, for maximum effect, each of their agile processes should feed into the output of the other.

To achieve this, I propose what I call the “dual end user” approach. That is, in a certain number of cases at least, one side should take on the role of the end user, with the other taking on the more familiar role of the implementer. Then, as appropriate, they should switch roles.

Let’s see how that would work out in a particular case. Suppose the business analyst is implementing a factor analysis of social-media data, but the necessary statistical tools are not there. In this case, the developer first acts as an end user, while the business analyst tries out various factor analysis capabilities that will also satisfy future factor analysis needs.

At that point, the two switch roles. Having created a general factor analysis “core capability,” the developer now tunes that solution for the immediate needs of the business analyst “end user” – who can then apply them to the needs of real end users.

The obvious objection to this is that it produces two additional sequential processes before the business analyst delivers a solution. Not at all; the business analyst and agile developer can actually to a large extent perform their own processes in parallel with the two processes cited above. They can, in fact, (if they want) perform the two processes simultaneously. The only additional complication is that both business analyst and developer are dealing with two end users -- the “real” end user and each other -- instead of one.

The positive result of the “dual end user” approach is that both IT and business analysts are no longer slowed in their processes, the business analyst by waiting for IT to supply general capabilities, the business intelligence developer by no longer dealing with lack of information about use cases from the “cowboy” business analysts. The subtle cultural effect of the approach is that neither the developer nor the analyst should wind up regarding each other with quite as much frustration or disdain.

The Business Intelligence Bottom Line

The problem of coordinating multiple agile processes in multiple areas is a happy one, and one that will increasingly arise as business agility arrives in more and more segments of the organization. IT should realize that they typically are the pioneers of agile, and therefore they should be proactive in anticipating the stray arrows from widening its use to other business functions.

This means, specifically, raising the question of how IT can best coordinate with other agile processes, whether by the “dual end user” approach or some other. It also means IT should lead the way in setting up an agile process for coordinating multiple-function agile processes and collaborating with those agile processes that arise on the business side. And it means, yes, that the business analyst and business intelligence developer should be friends – or at least effective collaborators.

As noted, the immediate benefits of such an approach should be to increase, if not double, the business value from each agile process operating separately. In the long term, the organization will figure out a way to develop business agility from the bottom up, function by function, which will be absolutely necessary for creating an organization of loosely coupled agile processes that in all likelihood will offer the right formula for true business agility.

Analytics and software development are leading the way in business agility. That the two are now coming into conflict is a symptom of success, not failure. But that doesn’t mean business intelligence can’t do much better. Efforts like the “dual end user” approach should be viewed as strategic and be pursued (with appropriate investigation of vendor tools and use of consultants) now rather than later.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.