In most of my recent consulting engagements related to business intelligence projects, I've recommended the use of a BI SWAT team. That's because most BI programs (or at least the ones whose managers call me for help) need a shot of energy, expertise or agility that a team modeled after police SWAT units can deliver.
With backing from top executives and an arsenal of modern tools and techniques, a BI SWAT team can reinvigorate a business intelligence program that suffers from poor design, development backlogs, inflexible reports, insufficient funding or other ailments. It can deliver the all-important "quick win" that transforms a failing BI program, giving it instant credibility in the eyes of business leaders.
Successful BI programs can also benefit from SWAT teams. BI managers overwhelmed with new project requests might turn to a SWAT team to keep departmental and divisional execs from going their own way (for example, by bringing in external consultants) and creating analytical data silos in the process. A SWAT team might also be used to tackle a gnarly problem or manage a high-profile project that the regular BI team doesn't have the time or skills to handle.
Who's on the team?
A BI SWAT team is a small group of experienced internal and external workers whose skills enable them to build entire BI systems and applications in six to 12 weeks. The team is led by a BI program manager -- either an internal BI director or an outside consultant. It also consists of both technical experts -- initially often consultants -- and business subject matter experts who should always be internal employees.
The technical side should include a business-savvy data architect who gathers business requirements and builds data models; a data integration architect who profiles source data, creates mappings and develops extract, transform and load programs; and a BI architect who builds dashboards and reports, trains business users and maintains applications. Part-time technical resources, such as a database administrator and a quality assurance specialist, may also be needed.
On the business side, a SWAT team usually includes a business analyst who knows the business, processes, people and data in an organization, and a systems analyst who knows the specific data in source systems or a data warehouse that is relevant to the BI project at hand. These members roll off the team once the BI application they're working on is built and are replaced by others who are familiar with the next application on the SWAT roadmap.
The speed with which a SWAT team works depends on the complexity and condition of a company's current BI and data management environment. In a dysfunctional BI environment, the SWAT team's program manager (in this case, an external consultant) and data architect might spend the first six- to 12-week iteration getting the lay of the business and data landscape and helping the company prioritize planned applications using a risk-reward matrix. Then they might need another six to 12 weeks to install new BI tools and data management technologies and convene a data governance committee that can define core metrics and terms for the first few applications.
In a well-managed BI environment, a SWAT team starts by taking over a high-priority project or two from the regular BI team. In this case, an internal program manager typically is tapped to create the project plan, put the SWAT team together and oversee its work. The SWAT team spends two weeks getting oriented to the project and then dives in, spinning out working code on an incremental basis with major deliverables every six to 12 weeks.
SWAT team goal: Deliver value fast
The primary goal of a BI SWAT team -- especially in a dysfunctional BI environment -- is to deliver business value fast. It shouldn't be constrained by architectural standards, except that the BI applications it builds should plug into a larger framework (i.e., an enterprise data model) when practical.
If a SWAT team needs to take a shortcut and break a key architectural standard -- for example, by creating an independent data mart for analysis with a non-standard BI tool -- it should do so consciously, knowing that it will need to refactor the application at a later date. By this point, the team hopefully has gained enough credibility with the business side that it can spend time refactoring applications and building out the BI architecture and computing infrastructure required to support them.
Once a BI SWAT team proves it can deliver value quickly, business executives might decide to fund multiple teams or replace its consultant members with new full-time staffers. The SWAT approach also lays the groundwork for a federated BI organization -- the only kind that really delivers business value consistently fast -- because it places BI developers into each department where it deploys a new application. These developers report into the business unit where they work, but also have a dotted-line relationship to the corporate BI director. This reporting relationship is the glue that holds a distributed BI organization together and forms the centerpiece of a formal BI center of excellence.
There's a lot to like about the BI SWAT team concept. Although not appropriate for every organization, a SWAT team can turbocharge stalled business intelligence projects and assist well-run BI programs that can't keep up with the demand for their services.
About the author:
Wayne Eckerson is principal consultant at Eckerson Group, a consulting firm that helps business leaders use data and technology to drive better insights and actions. His team provides information and advice on business intelligence, analytics, performance management, data governance, data warehousing and big data. Email him at firstname.lastname@example.org.
More from Wayne Eckerson: Get rid of bad BI data by evicting its evil twin sisters
See why he thinks Hadoop clusters provide a good home for spreadmarts
Read about the data management and analytics disruption that Hadoop 2 and YARN could cause