In this article you will better understand the role of the Business Intelligence and Analytics (BIA) sponsor and you will be ready with a five step approach to recruiting a person to fill that role. The role of the sponsor is critical to the success of the BIA project or initiative. This individual is a senior management person who takes overall responsibility for the effort.
Seek out a BIA sponsor who has a large stake in the project outcome as well as authority over the resources needed for the project. Look for someone with enough authority throughout the organization to manage competing priorities. It will help if there is organization wide recognition that put business intelligence and analytics as high priority and worthy of sponsorship.
The BIA sponsor fills a number of roles including:
- Definer of the BIA vision
- Owner of the business case
- Harvester of benefits
- Overseer of the project and chair of the BIA steering committee
- Ambassador of the BIA effort to upper management.
BIA champions complement the work of the project sponsor. Look for people who will promote data warehousing efforts across the organization. They make sure that the project is aligned with enterprise goals and help sell the project to the rest of the organization.
The scope of a BIA effort is also highly dependent on the level of authority of the project sponsor. If the sponsor is the CEO or CFO, then the scope can be enterprise wide. If the sponsor is a business unit head, then the scope is likely the business unit. If the sponsor is a department head, then the scope is likely limited to a single department.
Conversely, an Enterprise BIA or Data Warehouse project requires a higher level executive sponsor with more authority and resources than is required for a Departmental Data Mart project.
Five Steps to Recruiting the BIA Project Sponsor
Recruiting the BIA project sponsor is too important to leave to chance. Follow this step by step approach to recruiting your BIA project sponsor and champions:
1. Define the Requirements
- Start by identifying the characteristics that are needed in the BIA sponsor. Consider the scope of the project. What you need the sponsor to do? Who needs to be influenced? What needs to be signed off> What personality type needed? Do you need to motivate an enterprise wide team or a departmental unit? Put the requirements and their weighted priority in a spreadsheet.
2. Identifiy the Best Candidates
- Build a list of candidates for the role and narrow it down to a short list based on the identified requirements. This means scoring each of the candidates based on the prioritized requirements. Remove any candidate from the list who score poorly on the most critical requirements.
3. Analyze Candiate Capacity
- Perform an analysis of the short listed candidates to make sure that they have the time available to support the BIA effort. It is critical that the selected person on the list is devote enough time to your project and not be a sponsor in name only.
4. Plan your Marketing Approach
- Problem identification
- Proposed solution
- Value proposition
- Competition reference – what competitors are doing
- Team identification
- Resource needs
- Selling the BIA effort to the BIA sponsor and other critical stakeholders requires building a short “elevator pitch” which summarizes the benefits of the BIA program in 10 to 20 seconds. You will use the elevator pitch to gain initial interest so that you can provide greater detail and “close the sale”. Components of the elevator pitch may include:
The BIA sponsor is more likely to respond to a value proposition that addresses organization pain points and strategies rather than technical features. Put in business benefit terms and then package that into the “elevator speech”.
Integrated customer data
Effective use of marketing dollars
Improved customer experience
Visibility of enterprise performance
Data warehouse cubes
Advanced hardware platform
Capacity to enable business growth
Faster time to market and lower cost of ownership
5. Present the Pitch
- The presentation of the elevator speech to the candidate sponsor definitely should be done in person. First, rehearse – be ready for a smooth presentation followed by questions from the prospective sponsor. Second, if you do not have a direct connection with the sponsor, find a connection with a mutual contact who can introduce you to the sponsor. This is better than trying to corner by the water cooler or literally by the elevator. You should ask the sponsor to meet for an executive briefing rather than immediately asking the sponsor to be a sponsor.
- The executive briefing will enable you to better understand the candidate sponsor and build toward the close when the candidate sponsor is asked to commit to the BIA program.
Partnering with the BIA Sponsor
You have gained a better understanding of the BIA sponsor role and you cam use the five step approach to recruiting a person to fill that role. Recruting the BIA sponsor is just the beginning. Now it is time to work with the BIA sponsor to launch and implement the BIA effort. Be sure to keep him or her in the loop:
- Provide regular status reports
- Request help in dealing with roadblocks, especially those requiring cooperating across the organization
- Align BIA effort with organization goals
The choice of where and how to store the data for the data warehousing system is a critical architectural question. Part of the issue is the data warehousing architecture pattern, which is explained in Table 1. Data warehousing patterns include:
- Independent Data Marts
- Coordinated Data Marts
- Centralized Data Warehouse
- Hub and Spoke
- Federated / Logical Data Warehouse
- Big Data / Data Lake.
Table 1 DW Architecture Patterns
|Independent Data Marts||Multiple databases containing analytic data are created and maintained by different organizational units. The databases tend to be inconsistent with each other, having different dimensions, measures and semantics. There is “no single version of the truth” and it is a challenge to perform cross data mart analysis. These weaknesses make the independent data mart the least desirable of the architecture patterns.|
|Coordinated Data Marts||Data is harmonized across multiple analytic databases or areas of databases. Each database meets a specific need such as customer segmentation or product analysis. There are shared dimensions and semantics between the databases. For example, customer and product dimensions are consistent across the databases. Consistent dimensions and semantics support a logical enterprise view.|
|Centralized Data Warehouse||An Enterprise Data Warehouse (EDW) contains atomic data, summarized data and dimensional data. This is provided through a single database. Logical data marts are built from this database to support specific business requirements. Analysis between subject areas is facilitated by data being stored in a single database.|
|Hub and Spoke||The hub and spoke architecture is similar to the centralized data warehouse architecture except that there are physical data marts instead of logical data marts. A cost and complexity element is added due the need to copy data from the central data warehouse to the distributed data marts.|
|Federated / Logical Data Warehouse||The federated/logical data warehouse makes data that is distributed across multiple databases look to users like a single data source. Data may be stored in traditional relational databases as well as Hadoop or NoSQL formats. Data Virtualization software is used to create a logical view of the data and to optimize query of data across databases.
Common keys such as customer and product identifiers are used to tie the data together. This approach reduces the expense and time needed for data movement. The approach may have a high overhead and slow response time because queries between data sources in multiple locations can be inefficient.
|Big Data / Data Lake||The big data/data lake architecture stores data in the Hadoop environment which is an economical and flexible way to store large volumes of data including unstructured data.
Some organizations are shifting away from traditional relational databases and moving to big data environments.
Data Model Patterns for Data Warehousing
A data model is a graphical view of data created for analysis and design purposes. While architecture does not include designing data warehouse databases in detail, it does include defining principles and patterns for modeling specialized parts of the data warehouse system.
Areas that require specialized patterns are:
- Staging / landing area – looks like source systems
- Atomic Data Warehouse – uses normalized ERD (Entity Relationship Diagram)
- Data mart – uses dimensional modeling – the star schema, the snowflake schema or the cube.
In addition to these specialized patterns, the architecture should include other pattern descriptions for:
- Naming of tables and columns
- Assignment of keys
- Relational Integrity (RI)
- Audit history.
- Defining Scope and Objectives
- Finding the Right Sponsor
- Producing the Project Roadmap and Plans
- Organizing the Team
- Executing the Plan
- Finishing the Project
- Avoiding Major Data Warehouse Mistakes.
Scope specifies the boundaries of the project. It tells what is in and what is out. The scope definition started in the business case will be expanded, if needed, when the project is underway. This effort includes:
- Overview of the project (Mission, Scope, Goals, Objectives, Benefits)
- Scope plan
- Scope definition
- Alternative development.
Defining the correct scope and setting realistic objectives are critical to any project’s success, and a data warehouse project is no exception. Scope defines project boundaries including:
- Business requirements addressed
- Anticipated/planned users
- Subject Areas such as inventory transactions or customer service interactions
- Project success criteria, including quantified planned benefits.
Defining an overly large project scope and letting scope grow in an uncontrolled fashion (scope creep) are certain to cause project failure. Remember you cannot please everyone:
I cannot give you a formula for success,
but I can give you a formula for failure: try to please everybody.
Herbert Bayard Swope
The choice of Enterprise Data Warehouse vs. Departmental Data Mart is critical to the success of data warehousing projects. This choice is a major component of project scope. Examples of factors that arise with each focus, based on my experience, are shown in Table 1.
Table 1: Enterprise vs. Departmental Focus
|Factor||Enterprise Focus||Department / Functional Focus|
|Organizational Scope||Enterprise Wide||Business Unit or Business Process Focused|
|Time to Build||Multi-year phased effort||Single Year effort|
|Sponsorship Required||Executive Sponsor||Management Sponsor|
|Typical Cost||Often a multimillion dollar effort||Often less than $1 million effort|
The project may require both an Enterprise Data Warehouse and one or more Data Marts. The future Technical Architecture blog article will explain more about this choice.