Business Intelligence for Executives: Assemble the Right Team

In our 3-part series, we'll examine action items executives and project managers must understand and integrate into their BI implementation staffing strategy:

• Part I: Achieve buy-in and improved user adoption by collecting input from horizontal and vertical cross-sections of the organization. Remember BI is a continually evolving process, not a product or technology for IT to implement and maintain.
• Part II: Make sure your project leader matches skills and roles for each phase of the project, by understanding the spectrum of skills including business analytics, development, and infrastructure that BI professionals specialize across. Although BI professionals do cross-train, rates and expectations are set according to the role you're filling.
• Part III: Have better interactions with the project team by understanding Kimball's Lifecycle Methodology as a framework for understanding BI project phases (starting with defining business goals and data analysis, followed by development, and concluded by handover) and match the required BI skills.

If we view implementing BI as a series of conversations between organizational resources (executives, managers, analysts, end users), we'll understand the importance of staffing 'the right' BI professionals to each phase of the project.

Part I:  Which Path Will You Take?

To better understand the depth and importance of data projects, let's illuminate with analogies to a data-driven finance project:
The CFO and COO want to implement a 9-month project to implement a series of analytics and controls around optimizing production floor scheduling and inventory tracking. The result translates into an expected 10% improvement in profit margins by reducing raw materials waste and idle man-hour costs.

1) Would the CFO start by purchasing new software and then delegate responsibility for implementation to the IT department and a staff accountant?

2) Or, would the CFO:

1. Work with an experienced controller to focus and define strategic objectives.
2. Then, delegate an implementation team consisting of AP, Inventory, Production and Finance managers as well as technical staff to develop a solution;
3. And, lastly delegate a team to administrate the new measures?

Although the second seems like the 'the right answer', the first is the path more commonly traveled. Is your company making the same decision?

Because 'data analytics and reporting' sound like the domain of IT or IS, executive staff frequently underestimate the value of a cross-departmental implementation team.  As a result, project leaders use common IS/IT staffing models for hiring or outsourcing BI expertise--find out if the candidate is technically proficient by using a questionnaire like Data Warehousing Interview Questions, and then hire them to singlehandedly implement BI.

Hiring a singular technical resource solves only half of the staffing puzzle and puts the project at risk for limited success, increased risk of stalling, or complete failure.
Your BI team will require additional skills beyond the technical developer.

Action:  Recognize (and Fill) the Gaps
At the start of the project, you need a management consultant or business analyst to work with executives to explore and define how data can bring business value to a company

• Ex. Which metrics will allow us to measure and prevent raw material waste?
• What kind of labor and production statistics are necessary to understand the true labor cost?

By integrating requirements from and communicating with end-users and stakeholders around functionality and data consumption, savvy project teams can secure stake-holder buy-in and improve adoption rates.

• Ex.  What kind of Dashboards will help us track improvement month over month?
• What kind of reports can help day to day operations prevent waste?
• What kind of reports can help HR and Production efficiently schedule staff and minimize downtime?

Budget resources for end-user training and set aside time for hand-over dialogue to ensure that stakeholders within the organization can use the product.
​
As executives and project managers shift their paradigm to recognize that BI encompasses more than technology and software, successful organizations plan and staff their initiatives with cross-sectional input (both horizontally across departmental lines as well as vertically throughout the organizational hierarchy).

Part II:  Specialties under the BI Umbrella

We concluded that business intelligence (BI) is an evolving process that cannot be 'solved' by purchasing software. In addition to raw developer resources, your project team needs BI professionals who can communicate with executives, managers, and end-users.
To this end, we'll ensure your project leader matches skills and roles for each phase of the project, by understanding the spectrum of skills including business analytics, development, training, and infrastructure that BI professionals specialize across.
​
Note:  Although BI professionals do cross-train, rates and expectations are set according to the role you're filling.

Who will you talk to?
To maintain stakeholder support and buy-in, at any stage in project evolution, it is not unreasonable (even expected or recommended) that executive suite and mid-level managers ask the BI team to translate new reporting or analytics capabilities into tangible business value.

The question then becomes, who is the organization talking to? A SQL developer, though expert at writing code or the DBA who maintains your database applications may not have the language for communicating business value to non-IT staff.  

• Early conversations will involve strategic planning with management and executives
• Later conversations will involve functional planning with business analysts and internal technical resources

Recognize that specialization makes certain BI professionals natural candidates for specific phases of the project (and inappropriate resources for others).

The Risk of Undervaluing Specialization
Although it is common for BI professionals to have cross-over knowledge in many areas, project leaders should be conversant and aware of a BI professionals' specializations before pairing them with internal business resources (management executives, internal IT resources or business analysts).
The risks of failing to match BI talent with the right internal stakeholders include:

• Stagnant meetings where the two parties are unable to communicate efficiently. (A SQL developer is a poor match for a meeting with the CEO to discuss strategic objectives of the BI initiative)
• Wasted time / money. (Just as you wouldn't ask the Director of Sales to handle client invoicing, there are better (cheaper) resources than a Solutions Architect for writing code)

An Overview of BI Tracks and how they Apply to You
At PASS Summit (the world's largest Microsoft SQL BI conference) there are 4 major tracks (excluding career development):

• Platform Architecture
• Information Delivery
• Database Development
• Database Administration

Although there is crossover in knowledge, specialists in each of these tracks are suited for different phases of your BI Project (see Part III)

Platform Architecture addresses how the whole business intelligence environment should come together. The solutions architect will confer with:

• the C-level suite to understand the underlying reasons, purposes, and desired uses of corporate data.
• the internal information systems team to profile existing corporate data for suitability in achieving strategic objectives outlined by the BI project.

• end users and subject matter specialists confer with the architect to identify how and where the data enters and exits the system.

The architect develops a high-level requirements document to guide the new BI initiative. 
If your organization is outsourcing BI, this is the role you should fill first, and it is arguably the most critical in the success of your endeavor.

Information Delivery, or data visualization, speaks to how users will interact with the data. The CFO and high-level data consumers frequently get involved with this layer of the BI project because it is the most visible and accessible (both in terms of tangible-ness and demo- ability).
Note: It's common (though very much not recommended) for stakeholders to approach vendors or information delivery specialists about visualization software like Targit, PowerBI, Tableau, and QlikView before working with a solutions architect or business analyst team to define user requirements and plan the BI Environment. See section below on Sex Sells Technology.

Database Development is the BI role people are most familiar with--a developer in front of a computer frantically hacking out SQL code.
Erroneously, this is often the first and only role recruiters and project manager's fill when outsourcing a BI Project. Your project is more likely to stall, go over budget, or fail to gather user buy-in if this is the only technical resource in your BI project.

Database Administration, these professionals are usually the first call when 'the system goes down' or 'things are running slowly'. Instead of developing raw code writing skills, DBAs specialize in tuning database performance and managing server resource allocation.
​
Your DBA's (preferred) Roles in a BI Project:

• assess available physical (server) resources
• ascertain whether allocating or purchasing new hardware is required.
• assess options like cloud storage
• implement backup and recovery plans.

If you don't believe me, ask them.

Although DBA's are often first choice candidates for throwing into BI projects and training, it's critical to assess their overall availability. In larger organizations, DBA's and the rest of the IT staff are known for not sleeping more than a few hours a night because demand for their time is so high, making it unreasonable to expect them to engage in an extended BI project beyond the initial consult and ongoing maintenance.

In cases where users have the bandwidth to engage the project as a technical developer, Kimball's Data Warehouse Toolkit is recommended (required) reading to get started.

Sex (still) Sells Technology

Warning: Sex (Still) Sells Technology but You Must Resist
The wow factor of visualization software typically 'sells' a BI project and purchasers are lulled into the expectation that "now that we bought the software, we have BI." Unfortunately, this is far from the case, because visualization is the last layer of business intelligence.

I like to describe visualization software as the icing on a cake. Yes, icing made our mouths water and convinced you to buy a cake, but if you're buying software, you've only bought icing. And, yes, you still want a cake.

Work with an architect to define "What can software do for you" then customize the software to work for your organization.
A large serving of caution to balance the sugar high--one size does NOT fit all!

• Owning a tool and customizing it or even leveraging it within the organization are not the same thing.
  

If I could hand you Dell's BI solution for supply chain management, it may be thrilling to have, but your organization may (or may not) look at the supply chain as a critical value-added process.  Additionally, your success metrics (and or business model) may look completely different! Again, one-size does not fit all!

Action Steps before Buying Software:

• Objectively assess the depth of your organization's internal BI knowledge before selecting a product or committing significant resources to a project.
  
• Collaborate with a (neutral) BI specialist to develop a preliminary action plan if your internal team expects to leverage external resources for implementing BI.
• Develop a requirements document around what your organization wants to get out of business intelligence. Detail how various levels of your organization will interact with the tool before approaching vendors.

I encourage organizations to approach buying software with the same shrewd eyes used when new car shopping. You're less likely to get dazzled with features you don't need and walk away with the solution you and your team want and need.

Final Thoughts: Ensure Project Success with Better Staffing Decisions.
With a base-level understanding of the specialties within the BI niche, project managers can differentiate BI resources as well as understand the skillsets required during the different phases of a BI project. The last piece of the puzzle matches phases of a BI project with the skills required.

The Perfect Team for each Project Phases

When planning BI implementation phases with executives, Onyx Reporting uses Kimball's Lifecycle Methodology as a baseline framework which we condense to a series of conversations between organizational and technical resources (executives, managers, analysts, and end users vs strategists, architects, DBAs, and developers). By matching project phases, conversations, and specialist knowledge we create a holistic vision of the ideal BI project team.

Each iteration of a BI Project has 4 broad phases with different requirements for which team members and BI skills are required:

1. planning & strategy
2. design
3. development & implementation
4. maintenance.

Planning & Strategy
Because Project Planning and Business Requirements Gathering typically involves prioritizing data projects and strategic objectives with executives and mid-level managers, management consultants and data strategists are generally better suited for leading largely non-technical conversations and interviews.
By outlining the value the BI initiative will bring to the organization, the BI team can secure leadership and management buy-in as well as support the efforts of the project champion. 
A poor execution of this critical phase, in contrast, frequently results in a project stalling when it's time to allocate resources to future endeavors.

The deliverables from this phase are documents which translate strategic goals into a set of measurements, controls, and indicators as well as a set of conformed dimensions (the 'who', 'what', 'where', 'when', 'how') which provide context to the business processes and analytics.

Design & Modeling
During the design phase, the architect will review end-user requirements for information delivery (mobile reporting, website portal etc.) before recommending an information delivery solution. The Data Strategist or Architect and DBAs will profile the existing information systems infrastructure before recommending any upgrades and allocate physical resources for the new BI environment.
Having mastered Kimball's tenants of Dimensional Modeling, Data Strategists and Architects transform the strategic requirements and measures into a scalable data model consisting of conformed dimensions and fact tables. The Architect looks at the requirements at a holistic level to answer "What will the data model look like?"

Development and Implementation
The SQL developer will implement the BI solution and occasionally consult the database administrator (DBA) to optimize performance.
If you're considering outsourcing BI development, it is critical, that strategic requirements have been converted into a thoroughly documented data model, because it is unlikely that the average SQL Developer has the skills to translate complex business requirements into a data model. (If they did, because rates are commensurate with skills they'd present themselves as data architects).

Administration
Once development has finished, the databases are handed over to IT/IS for maintenance and upkeep.
As a rule, DBAs are uninvolved with database design or heavy-duty development. It's a bit like hiring a pit mechanic to design the chassis of a race car. Yes, a mechanic can service and tune an engine, but they generally don't work with engineers in wind tunnel facilities to analyze airflow.

Tower of Babel: Success hinges on clear communication

Do I Really Need Different BI Resources?
As data professionals interact with different members of the organization, vocabulary and expectations shift. Executive staff speak a different language than DBAs. And Business analysts have different concerns than line workers when evaluating user acceptance.

When staffing for the phase, ask yourself "Where are we at in the game?"

Do we need business conversations with the C-suite to outline the Measures & Controls that will support and achieve strategic goals?

• Ex. What strategic decisions are you making based on your customer loyalty program?

Do we need an analyst to work with mid-level managers to translate requirements into measures?

• [% of Overall Sales to Loyalty Customers]
• [% of Overall Sales to Non-Loyalty Customers]
• [Avg Sale Amt to Loyalty Customer]
• [Avg Sale Amt to Non-Loyalty Customer]
• [% Change in Avg Sale to Loyalty vs. Non-Loyalty].

Do we need a data modeler to convert measures into a functional and scalable data model?

• 1 Fact Tables
• 1 SCDII Customer Dimension
• and a Junk Dimension?

Do we need someone to write the code to implement the data model?
​
If your current projects suffer from communication breakdowns between IT and the rest of the organization or lack of support from key stakeholders, perhaps you should include a business-savvy resource who 'speaks data' in future conversations.

Action Steps
Business Intelligence spans data manipulation, hardware, software, functional business acumen and analytic skills with professionals. The depth of the project can range from simply describing business processes to prescribing action based on a predictive model.
When it's time to address BI at your organization

1. Objectively assess the depth of BI knowledge your internal team possesses by reviewing a few online interviews and answers. Follow up by assessing staff's bandwidth to commit to managing (and potentially learning about) BI.
2. If choosing to lead a BI project using internal resources, start by understanding BI project management. At Onyx Reporting, our consultancy follows the methodology prescribed and perfected by the Ralph Kimball in The Data Warehouse Lifecycle Toolkit. If choosing to outsource BI project management, start with a scoping project before committing significant resources to a longer project.
3. Staff (internal or external) talent appropriate to the project phase by understanding which skills are required to advance the project to the next phase.
4. MOST IMPORTANTLY: To retain stakeholder buy-in, align project initiatives with strategic values and objectives of the organization.

This article was co-written by Jae Wilson, a lead business intelligence consultant at Onyx Reporting, and Joel Conarton from Catalystis.

For more articles like this delivered straight to your inbox, please sign up for our bi-monthly mailing list.