In recent posts, I have focused on the key decisions you should consider when building an analytics team in your organization. This post is the second in a two-part article taking a deeper dive into that same topic. We’re unpacking the critical decisions to build a high-powered analytics team for your organization.

Grab a refill on that coffee, because part two of this article is as value-packed as part one.  As a refresher, Part 1 of this article breaks down into the following sections (read it here , if you haven’t already):

• Use cases
• Infrastructure
• Staffing
• Budget

This week, Part 2 covers the following additional sections:

• Organizational Structure
• Governance
• Analytic Processes
• Cultural Change Management

Organizational Structure

Before you build your analytics team, you need to decide how the team will be incorporated into the org chart. Your primary options are to have analytics centralized, decentralized, or matrixed.

Centralized Analytics

In a centralized structure, leadership houses the analytics team in a single business unit. Team leads throughout the organization send all analytic requests to the group for processing. The analytics team allocates resources and processes within the unit to meet demand.

A centralized analytics structure creates economies of scale as its primary advantage. Analysts collaborate and develop processes to manage organizational data and streamline analyses across other business units.

The primary disadvantage of a centralized analytics structure is it requires greater management oversight for resource monitoring and allocation. Business units requesting analyses do not have a line of sight to all demands on analytics. During peak demand periods, the analytic team negotiates with other units to establish analytic priorities and timelines.

Decentralized Analytics

In a decentralized structure, leadership distributes analysts throughout other organizational units. Each business unit becomes responsible for planning and executing its analyses.

Decentralized structures are advantageous because analysts develop deep knowledge of the needs and priorities of their assigned business unit. Analysts have a better line of sight to anticipate demand and can tailor their code and processes accordingly.

The primary disadvantage of a decentralized analytics unit is its failure to provide economies of scale. When analysts are distributed across business units, they cannot develop projects as quickly as when working in a larger group.

Additionally, decentralized analysts often duplicate basic tasks such as data extraction, cleaning, and preparation. Aside from the inefficiencies of duplicated efforts, distributed analysts also risk developing analyses differently across units, leading to discrepant results.

Matrix Analytics

In a matrix structure, analytics staff are organized with two reporting lines. First, analysts report to an analytic team lead who oversees all analysts, similar to a centralized structure. Second, analysts are assigned another business unit to work with on a project-by-project basis, similar to a decentralized structure.

The primary advantage of a matrix structure is its flexibility in allocating limited staff across different types of projects. This structure is particularly helpful when analytics tackles large and complex projects spanning multiple business units.

The primary disadvantage of a matrix structure is the increased effort managers need to coordinate multiple lines of authority. Management must coordinate good communication to reduce conflicts in staff assignments and ensure feasible project timelines.

Additionally, as analytic demands grow over time, the matrix structure may mask the increased workload. Only the leaders with oversight across all analytics will know the full scope of all projects. Therefore, a matrix structure also demands management perform careful and regular reviews to ensure proper staffing levels.

Three Types of Organizational Structure

As you plan to build your analytics team, pay careful attention to the organizational structure. Each type of organizational structure has pros and cons, and there are no sure-fire methods for selecting one over another. Examine your current business structure and look for the least complicated approach to begin.

Governance

Regardless of where you are in building your analytics team, your organization needs a governance structure in place. With respect to analytics, governance consists of two pieces: data governance and analytic governance.  Both types of governance consist of the policies and processes required for managers to run the organizational analytics effectively. You can learn more about data governance and analytic governance here. 

Data Governance

You create a data governance structure to properly manage organizational data assets. Typically, data governance is designed to collect complete and accurate data and protect data from unauthorized access.

Most data governance policies have at least four distinct components: data quality, privacy, security, and stewardship.

Data Quality

The data quality section outlines how the organization will capture and maintain complete and accurate data. Data quality includes the methods and sources used to capture data for internal storage. Additionally, data quality includes the systems used to verify the accuracy and completeness of data added to your internal storage.

Data Privacy

The data privacy section describes the methods the organization will use to safeguard any sensitive data help within its systems. Sensitive data might include client or employee identification, credit card numbers, health insurance member IDs, or other sensitive records.

Data Security

The data security section lists the methods the organization will use to prevent unauthorized access to data. Data security precautions can include restricting physical access to data through secured server rooms and computer access points. They also might include software restrictions through protected drives and folders on a secured network.

Data Stewardship

The data stewardship section describes how your organization will enforce its data governance policies and procedures. The data stewardship section may define individuals responsible for securing specific data sources as “data owners.”                                                 

Analytic Governance

You create an analytic governance structure to ensure that all data analysis projects are appropriately managed. A typical analytic governance model will focus on having the right people for the right projects and avoiding duplicative work.

Analytic governance policies often define four minimum components for analytic projects: data owners, subject matter experts, routine vs one-off analyses, and skill alignment.

Data Owners

All analytic projects require data, which frequently comes from internal sources. As part of your analytic governance structure, describe the responsible party for providing access to specific data.

A strong analytic governance structure also included mechanisms for ensuring data sharing across business units when necessary. These goals can be achieved through standardized data request mechanisms or by creating cross-functional teams to develop new projects.

Subject Matter Experts

Nearly every analytic project also requires a subject matter expert (SME) for the business unit or analytics, and sometimes both. Strong analytic governance will identify specific organizational stakeholders to serve as SMEs on various topics.

The SMEs should be brought into any project that touches on their areas of expertise. These procedures reduce the likelihood of producing duplicative analyses, with different results due to methodological differences.

Routine vs One-Off Analyses

Depending on the type of analytic project, the code may become a routine or a one-off analysis. Identifying whether the project is intended to become routine at the outset will help guide the development process with the end in mind.

Projects such as developing code for key performance indicators (KPIs) are routine analyses and calculated regularly. Projects such as evaluating new marketing campaigns are performed once and recreated as new campaigns are executed. If you align best practices for code development for each type of analysis, both will be more efficiently created.

Skill Alignment

Regardless of your organization’s analytics journey, you want analyst skills to align well with the project work. Proper analytic governance will provide guidance on the staff mix needed for different types of data projects. Although, your specific staffing mix will depend on your organization.

Higher-end data scientists will need more complex and engaging work to complete. In contrast, more junior data analysts will assist with data management and basic programming tasks. When poor analytic governance results in misaligned analytics teams, higher turnover is inevitable.

Two Components of Governance

Your organization will benefit from having both a data and analytic governance structure in place. Data governance focuses on the accuracy and security of data assets within the organization. Analytic governance focuses on the processes required to complete analytic projects. While planning for your analytics team, consider approaches to each component.

Analytic Processes

Before launching your analytics team, consider the analytic processes you want to use across projects. I do not mean the research designs and analytic methods when I mention analytic processes. Those will be unique to each project. Instead, analytic processes refer to your team’s tools and strategies to plan, execute, and archive each project.

Planning

During the project planning phase, both the business units and analytic teams need clarity on roles and responsibilities. This process focuses on how teams are expected to take a project from business problem to final deliverable. To create a solid process, you’ll want to consider the following types of questions:

• Who is responsible for overseeing the development of the plan?
• Who is on the analytic team?
• Who is the client/audience for the project?
• What is the timeline?
• Which pieces must be contributed by the business unit leads, and which by the analytics team?
• What is the business problem, and context for the problem?
• What are the analytic questions derived to help resolve the problem?
• What data will be used?
• What analytic methodology will be used?
• What type of deliverable will be created?
• What kind of reporting tables and figures will be created?
• Where will project files be located during development and execution?

Data Review

Once data is available to the analytic team, they must review it for completeness and accuracy. Sometimes analysts call this process data validation. The specific checks analytic teams use vary by the type of data and source, but generally include:

• Verify the correct number of rows and fields included to ensure receipt of the file as intended (confirmed with the data stewards providing the data)
• Confirmation of the data values in each field
• Assessment of implausible and missing values in each field
• Assessment of record uniqueness and agreement across data tables
• Assessment of the consistency of record volume and value distributions across subgroups within the data set.
• Comparison to historical data for comparability and agreement
• Comparison to external data for a sanity check against other known information

Code Development

A colleague of mine used to say, “There are 1,001 ways to get from point A to point B in code.” He was absolutely correct about that statement. It never ceases to amaze me how differently some analysts write their code from others. While you never want to stifle analytic creativity, you will want to provide guidelines on several minimum coding elements.

Code Structure

Start by working with your analysts to determine a general code structure. A general code structure allows analysts to transition across projects without learning a new framework.

For example, you might have all code begin with a header element containing important information for the programmer to understand. You might also want user-defined parameters contained in one code block to allow easy editing. Additionally, you might have all code blocks called by a main program run file, rather than having each calling the next program in the sequence.

Code structures may vary depending on the needs of the project. However, defining a general structure will help your analysts work more efficiently.

Commenting

Determine how many comments you will need in the programming code being written. If you’re not a programmer, comments are plain-language explanations of what is happening in a particular piece of code.

Programmers write comments inside code files to provide insights about what, why, and how things are being done. Comments are extremely useful to analysts when they review code they either didn’t write or haven’t looked at recently.

Most analysts learned programming in fields of study that are not pure computer programming. As a result, they often do not learn best practices for code development.

I have seen analysts include comments on every line of code. And I have seen analysts never include any comments in their code. The best practice is somewhere in between. I always recommend that each function and block of code with a single purpose have a comment that explains what it does.

Coding Conventions

While there are 1,001 paths between two points in code, sometimes you find processes that work well. Rather than reinventing the wheel each time, you will want your analysts to use the tried-and-true processes.

For example, it seems programmers are always introducing new functions to analytic software for exporting information into Microsoft Office^® products like Word^® and Excel^®.[1] Yet, tools like Dynamic Data Exchange (DDE), developed by Microsoft in 1987, remain a valuable approach to automating such data transfer.

Similarly, programmers must consider processing efficiency when reading and writing large data files. If the analyst’s code is inefficient, the result could be hours of wasted processing time. Therefore, organizations managing big data may impose conventions for efficiently accessing the data.

Work with your analytic teams to spell out these conventions. The benefit will be analysts with a better overall understanding of the code and quicker project transitions.

Analytic Validation

Data-driven decisions are only as good as the accuracy of the analysis used to make them. As a result, every organization has a vested interest in validating each analysis for accuracy.

Analytic validation, however, is not a single technique, but a family of approaches to ensuring accuracy. The effort applied to analytic validation should be commensurate with the accuracy needed from the results.

The simplest and least expensive validation is for a single analyst to review their code and results for any errors. This is also the most error-prone approach. At the other end of the spectrum, you might require two analysts to perform the analysis independently and reconcile their results. This is the most accurate, but also the most expensive approach. You can read more about analytic validation methods here.

Documentation

Finally, consider the documentation you will need for each project. Like all other analytic planning, I like to start with the end in mind. Think about what you, or your analysts, would need during a review 12 months after project completion.

At a bare minimum, I recommend maintaining seven pieces of documentation for each project.

• Analytic plan: The initial plan for the analysis. Questions, data sources, staffing, client requirements, output descriptions, and analytic strategy. Include enough details for competent analysts to use like instructions.
• Project Process Document: This document lays out an internal timeline for project execution. The timeline parallels the analytic plan and includes staff assignments. The document is updated as tasks are completed, and any challenges or alterations to the original plan are documented here.
• Raw Data: The original data used for the analysis before any transformations or manipulations.
• Analytic Data: The data set(s) created by analysts from the raw data to use for the analysis.
• Code: All programming code used to transform raw data into analytic data sets and perform the analysis.
• Log Files: The log files generated by the analytic software confirm the executed code and any warnings or errors.
• Results: The raw output created by the analysis, and any production formatted tables and figures.

With these seven sets of documents, you and your analysts can review any project long after completion. If you have ever had to recreate a project without these documents, then you know how important these are.

Five Components of Analytic Processes

Leaders building an analytics team must consider the internal analytic processes that analysts will use. Frequently, analysts have different ideas about how processes should be structured because of differences in their training.

To prevent your analytic team from becoming the Wild West, you should consider the five processes discussed here: planning, data review, code development, analytic validation, and documentation.

You may not develop your final process the first time, but it is far better to have one than not.

Cultural Change Management

The final key decision you must consider when building an analytics team is how you will approach cultural change management. When building an analytics team, there will be many firsts for everyone throughout the organization. How you manage the introduction and integration of analytics could largely determine the team’s ultimate success.

You will need to consider how you will prepare the organization for the introduction of a new functional unit. Will the changes in organizational structure and functional responsibility be clear to everyone?

You will also need to obtain buy-in from existing business units that will be impacted. Will those staff most closely involved with analytics perceive a loss of authority or a gain of an ally?

You must set expectations about how existing staff will collaborate with the analytic team once it is in place. Are there any risks of existing staff creating silos of data or business functions?

Importantly, if your organization doesn’t already have a data-driven culture, you must work to create one. Emphasize the expectations of using data to understand the business landscape and make informed decisions. You can read more about creating a data-driven culture here .

Conclusion

At the risk of sounding trivial about this two-part post, there you have it. One in-depth dive into the key decisions necessary to build an analytics team in your organization, from use cases to budget, organizational structure, and cultural change management. Use this article like a road map, and your new analytics team will have a solid foundation for success. I can’t wait to see how well this works for you. Email me at [email protected] if you have any questions or want to follow up with success stories.

If you found these posts helpful, be sure to sign up to receive my weekly email with the latest strategies and step-by-step instructions made simple. You can sign up in the form right below this post.

---

[1] Microsoft Office, Word, and Excel are trademarks of Microsoft Corporation.