The previous article in this series examined the teams and roles that comprise a data analytics program. This article focuses on the importance of establishing a strong relationship between business and technical teams and describes various business engagement models that sit at the heart of all successful data analytics programs. 

Business-IT Gulf 

There has always been a yawning gulf between business and technical teams. The two often speak a different language, sit in different departments, and have different goals and objectives. The business has a short-term perspective: it wants to move fast and adapt quickly to changing market conditions so it can meet business goals. Conversely, technical teams (often in the IT department) have a long-term perspective: they want to develop standard processes and architectures so they can deliver economies of scale and universal truth. These competing visions and objectives inevitably lead to conflict. 

Until recently, the IT department had the upper hand: it controlled all the technology, data, and technical expertise and could dictate technical solutions. However, when IT forces every business unit to stand in line and wait to be served, mutiny results. IT’s perennial backlog causes business leaders to circumvent IT processes and standards, creating data silos and conflicting data. 

Facilitate, Not Dictate. In the past ten years, IT’s hegemony has disintegrated, thanks to the advent of self-service tools, cloud-based data platforms and services, and a bevy of low-cost and open-source tools that make it easier for departments to create their own data and analytic environments. IT’s role has reversed 360 degrees: rather than dictate the terms of engagement, it facilitates how the business uses data and analytic solutions. 

Centers of Excellence. Not surprisingly, this change in power dynamics has altered the fundamental nature of data analytics programs. Rather than act as a corporate shared service, today’s data analytics programs consist of “centers of excellence” or “competency centers” that help business units create business intelligence and data science solutions rather than always build solutions for them. (See figure 1.) 

Figure 1. Business Engagement Models and Centers of Excellence

Of course, corporate technical teams haven’t forfeited responsibility: they maintain a corporate repository of data shared among business units and departments (otherwise known as a data lake or data warehouse or data lakehouse.) They build enterprise data analytics solutions, such as executive dashboards. And they still build complex, custom solutions that business units don’t have the skills or resources to develop or maintain. 

Although self-service has changed everything, everything still remains the same: data analytics technical teams must still engage with the business and build applications for them. That begs the question: how best should IT engage with the business to ensure optimal outcomes? 

BUSINESS ENGAGEMENT MODELS

There are four primary business engagement models: 1) business requirements analysts 2) agile teams and methods 3) IT co-location and 4) spanners. (If you know others, please let me know!!) 

Business Requirements Analysts 

For decades, technical teams have used business requirements analysts (BRAs)-or simply business analysts—to engage business users. In fact, many companies still have large departments dedicated to these business intermediaries. One client has 75 staffers in its “Business Architecture” department—their job is to meet with business users at the outset of a technical project, gather requirements, and translate those requirements into technical specifications for developers. 

The major problem with BRAs is that they are generalists—they don’t have deep technical or business expertise in a given domain. Consequently, they lack the context to fathom the real need behind business requests. Moreover, their requirements gathering process is generally serial in nature, not iterative: BRAs rarely reopen requirements documents because they have already moved on to the next project. BRAs are the cornerstone of waterfall development, which works well when requirements can be defined with certainty upfront, but work less well in data analytics where customers often don’t know what they want until they see it. 

At Eckerson Group, we recommend clients replace BRAs with relationship managers (RMs) who are more senior than BRAs. The best RMs are business people with technical proclivity who come from the business they serve: they know the people, issues, politics, and challenges facing the business unit and speak their language. Thus, they quickly become trusted partners: they regularly attend strategic planning meetings and provide proactive advice on ways the business unit can use data analytics technology to solve problems and seize opportunities. 

Whether a data analytics program uses BRAs or RMs, it’s imperative that the individuals are dedicated to a single business unit (or two smaller ones). To gain the business context they need to serve as trusted advisors, they should spend the majority of their time in the same physical location as the team they serve. The more they know the people, hear their conversations, and interact with them in formal and informal ways, the more valuable they become. Rather than order takers, RMs serve as internal consultants who devise clever ways to use technology for business gain. 

In addition, the best RMs can develop a report or dashboard prototypes to help business people understand what is possible and provide a springboard for technical developers to build a robust solution. Sometimes a picture is worth a thousand words—or a thousand pages of technical specifications. Putting requirements into software fosters a healthy, iterative exchange of ideas that ultimately expedite development and guarantees customer satisfaction. 

Agile Teams 

Many data analytics programs have replaced BRAs with agile teams that adhere to Scrum or other agile methods. The beauty of agile is that it supports an iterative approach to fleshing out requirements, using two- or three-week sprints that generate working code that business users can touch and feel. Iterative design and development work much better in data analytic projects than in traditional waterfall projects. 

Business Involvement. The key to agile, however, is to get business participation on the team. This requires the business to allocate a portion of the time of a valuable subject matter expert. That person must be available during every sprint to reshuffle user stories (a lightweight form of business requirements) and review the output. Sometimes, this is a big ask and many agile teams fail to get adequate business participation, which undermines the value of the approach. Consequently, some agile teams refuse to work on projects unless the business commits to full participation. 

Cross-Training. Another virtue of agile is that it encourages self-organizing, cross-functional development teams. Each agile team is staffed with functional experts—data architects, data engineers, BI developers, quality assurance analysts. In other words, everyone required to build a complete solution quickly. To avoid delays and increase skills, agile team members must learn each other’s roles and fill in if one person on the team is absent. This cross-training creates a stronger talent pool, improves staff motivation and engagement, and accelerates delivery cycles. 

Retrospectives. The best part of the agile methodology is the “retrospective” conducted at the end of each sprint (and sometimes as a sprint itself.) During a half-day retrospective, team members review their work, identify problems, and suggest ways to improve the process. When conducted openly and candidly, retrospectives become the foundation for continuous improvement and heightened productivity. All grandmasters in a given domain—whether chess, football, art, management—learn by continually reviewing their mistakes and making adjustments.

IT Colocation 

Many IT departments have discovered the value of collocating technical experts in the business units they serve. This is great unless the IT experts represent multiple IT disciplines and thus become generalists whose job becomes more about consolidating and translating requirements for a corporate development team than building functionality. In other words, a glorified BRA with a tad more technical expertise. 

We are a firm believer in the power of colocation. Technical developers, not BRAs, should be embedded inside departments so they are viewed as members of a business team who happen to have strong technical skills. They can report to the business unit head with a dotted line to the director or IT or vice versa—they can report to the director of IT with a dotted line to the business unit head. Embedded technical developers often create the most widely adopted solutions in an organization. 

But colocation or embedding doesn’t work if the developer serves too many masters. In the data analytics realm, each department should have one or more embedded BI developers and perhaps a data engineer as well. As long as the embedded developers are aligned with the corporate data analytics team (i.e., a center of excellence) and its policies, processes, and standards, then they are likely to develop scalable, aligned solutions, not data silos. 

Spanners 

The last business engagement model is the least common. It extends the IT colocation model to its logical conclusion. Rather than embed a technical specialist who can only build part of an analytic solution, a spanner builds the entire solution from start to finish. Spanners, as their name suggests, “span” the development stack: they gather requirements, create data models, build transformation scripts, design and publish reports and dashboards, run tests, manage operations, and generate insights for the business domain they serve. Phew!

As you can imagine, spanners are rare. They often exist in start-up environments or small departments, where one or two people design and build an entire reporting stack. As the company or department, and its appetite for data and reports grow, the scale of the solution often exceeds the ability of a single person to deliver it. Or the criticality of a solution requires a systematic workflow with multiple checks and input. In other words, you don’t want a spanner creating a financial report for public investors. 

Summary: Choose Your Engagement Model 

Perhaps the most important decision facing data analytics leaders are how to engage with the business to develop value-added solutions. Every approach has its tradeoffs:

BRAs are good for waterfall projects where requirements are straightforward and don’t change; RMs are great for building trust between business and IT and creating proactive solutions that circumvent the need for more traditional requirements processes; agile teams are great when short, iterative work cycles with active business participation can rapidly flesh out business requirements and deliver working applications quickly. IT colocation is valuable for building context-rich solutions as long as technical experts are not diluted with too many domains. And spanners are great for startups and small departments that need custom solutions built quickly. 

A Champion Greases the Wheels of Business Engagement. For any business engagement model described above to work, data analytics leaders need to set the tone for business-IT relations. They need to proactively court business leaders, keep them apprised of new developments and relevant technology, and continually evangelize the value of data and analytics. A champion at the top greases the wheels for all business-technical interactions.