BI项目管理：合适的人与合适的规划

Most successful business intelligence (BI) projects are defined as delivering a solution that delivers trusted, meaningful and timely data.

To gain the most ROI from a successful enterprise BI initiative, it is critical each BI project be treated as an enterprise business project, not as an IT project, and not as a departmental project (for example: finance).

The power of BI is the delivery of enterprise data for making factually informed decisions in order to take deliberate action in a dynamic and uncertain economy.

Educating the organization’s executive team to win their sponsorship is of vital importance to achieving BI success.  The executive team at your organization should be the key benefactors of the BI solution.  The project manager should be able to explain BI benefits in executive language, get their attention by using the organization’s key performance indicators, secure executive advocacy and buy-in, and ensure BI as a strategic business initiative.  In doing so, this will improve the ease of project work by orders of magnitude.

The project manager should provide executives with statistical evidence for establishing an enterprise BI solution, and supply small data success stories with each major deliverable of a BI project to retain the momentum and commitment of the critical resources needed.

 Define Your BI Vision, Strategy, and Scope

It’s necessary to educate the executive team on the benefits of a BI solution before the conceptual stage.  If there’s no business appreciation for a BI initiative, then don’t even start one.  BI solutions are too expensive to do wrong, and without the right support, they’re a complete waste of valuable resources.

It’s essential to have an executive sponsor, ideally two sponsors for a BI project.  Their role in supporting and advocating the BI initiative, and its business strategy with other leaders within the organization, is the cornerstone to building a flagship BI enterprise solution.  Ongoing marketing of the BI benefits is necessary to obtain the greatest return on a BI strategic business initiative. 

Work with the executive sponsors to develop a BI vision.  The vision should rest on the fundamental importance of the BI initiative to the organization.  For example, our organization chose:  “The vision of this program is to deliver more meaningful, timely, complete, and trusted business information to those responsible for setting and measuring the direction of the organization.”

BI Strategy:  The BI strategy should include a foundational phase, a building blocks phase, an extensibility phase, and an expansionary phase.  The strategy should outline the journey from short to long-term BI needs (deliverables), the expected benefits, audience, and processing source systems involved. 

In our organization, we developed a strategic plan in the shape of a “pyramid” containing these multi-dimensional perspectives as a symbol of the initial 5-year BI plan.  Additionally, we named our BI plan the “Insurance Intelligence Program” in recognition of its chief purpose being for the business.  An “IIP Pyramid” was given to every executive in the enterprise as a reminder of the future we were building together.

Like the BI strategy, the phases can be different for every organization, depending on what is already in place from a data warehousing and decision support standpoint. 

• Foundation Phase:  The foundational phase typically includes confirming the executive sponsors and project managers, identifying the type of technical implementation (e.g. homegrown, custom, COTS), deciding the resource model (e.g. internally staffed, outsourced, or a combination of both), securing business solution partners, defining the architecture, selecting the software and hardware platform and vendors, establishing the initial project team, implementing the fundamental scope of the business and data deliverables, and most importantly, training the enterprise to use the BI tools for challenging their data, their business processes, and even the way they make decisions.
• Building Blocks Phase:  The building blocks phase generally includes time- phased projects involving additional data augmentation, more complex data solutions, enhanced security, data optimization, archiving and storing, and developing a wider range of customer oriented analytics.
• Extensibility Phase:  The extensibility phase involves sharing or exchanging BI data among external business partners, or building customized front end data applications for providing specific business or external customer services.
• Expansionary Phase:  The expansionary phase involves leveraging the existing BI solution for even greater analytic capabilities and opportunities, such as predictive analytics, enterprise risk management, or tapping into storehouses of external data without needing to store this data internal to an enterprise’s data warehouse.

Regardless of the phase or project, it is imperative for the project manager to define and closely manage the scope envisioned.  The goal should be to achieve a business relevant scope, not too big, not too small.  The scope must be centered on what brings the most informational value to the enterprise’s critical needs at that time.  Remember too much information too fast has no value…if the amount of information or data over saturates or overwhelms the BI audience, and they are furnished with no proper way to digest it, there is no value rendered to an organization. 

Additionally, when delivering too much data at once, there is not sufficient time to validate the data outcomes, and the most priceless BI characteristic of all is lost, trusted information.  BI is an unforgiving endeavor.  If the trust for the data is lost, it may never be recovered…. if poor business decisions are made based on bad BI data solutions, it’s a slow road back to redemption.

Keys to the Right People

The process for getting the right people starts with selling the value of BI to the executives from the very beginning…this is where the commitment to be given the right resources lies.

Business

• Getting the right people involved starts with the executive sponsor.  The executive sponsor must be a respected and credible leader in the organization.  They need to have a passion for data, be key to the operational success of the enterprise (have skin in the game), and be able to be the champion for the initiative.  If you don’t have the luxury of more than one executive sponsor, don’t let the executive sponsor be the CIO or CTO.  The golden rule of success is BI is a business initiative, not an IT initiative.  The ideal executive sponsorship is a combination of the CIO and the VP of Operations, or similar functions that may have different titles in other organizations.  By having this, the solution will bear a delicious fruit from the marriage of efficient technology and business relevance.
• The next most important selection for a BI initiative is the selection of the project manager.  If it is possible to select two project managers, one being the business project manager and the other the technology project manager from within an organization, this is preferred.  It will make a tremendous difference in the quality of the BI business outcomes.  The process or means of implementing BI solutions is highly disciplined requiring the structure of a technology project manager’s leadership, but the relevant deliverables only have value if sanctioned by business leadership.
• The business project manager commitment is generally 20  percent of the time, with 30 percent peaks during the requirements phase and the user acceptance testing phase.  For the technology project manager, if the BI solution includes implementing hardware, software, and data solutions, the time needed from the technology project manager will be 60-80 percent of the duration, and for strictly data solutions, generally only 40-50 percent of their time.

Business Project Team

• The selection of the business project team members is also very important.  The business project team members need to be the most data knowledgeable and process oriented business representatives in the organization (aka “knowledge workers” or “data gurus”).  They are typically the “thought leaders” of the organization who have a command of the business data, talk in terms of facts, and are analytical in nature.  They are also usually the highest in demand within an organization; thus, the importance for executive commitment for a BI initiative.  Ensure the project team members are a cross-functional mix of business experts, depending on the BI data being implemented.
• For example, in a worker’s compensation insurance implementation of policy and claims data, a good business project team mix could include an underwriter, a claims examiner, a policyholder customer service representative, an actuary, a safety management consultant, a finance specialist, and at least one operational team leader.  On the other hand, a medical and pharmacy billing data implementation might only have 2-3 medical and pharmacy claim specialists, a claims analyst, an actuary, and the operational medical team leader.
• The business project team members usually spend an average of 20 percent of their time for the duration of the project, with two 40 percent peaks during the requirements gathering and user acceptance testing phases of a BI project.  It is very important to have the business project team members dedicated to the BI implementation for the duration, and not change business team membership during the project.  It is too difficult for the business team members to catch up or ramp up with the analytical complexities in providing the necessary business value to the BI project.

Solution Partner

• Another critical aspect of the selection process is the external BI implementation partner(s).  Whether it is for customized or “cookie cutter” BI solutions, it is crucial to partner with a consulting team that has at least 10 years experience and expertise in your organization’s industry, in BI and data analytics, and in your organization’s platform and architecture.  If a solution partner cannot meet all of these criteria, the likelihood of BI success is decreased.  The more customized the solution, the more important it is for incorporating, exposing, and understanding your business rules within the BI data, and the greater the need for a BI partner with staff having expertise in your industry and type of business data.  Before choosing your solution partner, don’t forget to check the vendors’ references and arrange for site visits with clients having similar solutions to the one your organization envisions. 

Technical Team

• The final selection of the right people is the IT project team.  If an organization does not have these staff members internally, or doesn’t plan to have an internal implementation and support team for their BI solution, it is important to negotiate with the solution partner for these individuals. 
• It is strongly advised to have “right to terminate” and “long-term assignment” protection clauses for all consultants in the terms of the Statement of Work and/or contract.   Custom BI initiatives can often times have durations of many months, even multiple years, and when knowledgeable consultants are secured and develop a strong working knowledge of your data rules over time, it will be important to keep these same experts through the duration.
• If utilizing an external solution partner for your BI project work, it is recommended to include in the team lineup a part-time project manager from their team.  There are multiple benefits in doing so.  Meetings can be scheduled more quickly, incurred consulting costs can be monitored and managed more closely, and issues or misunderstandings resolved more efficiently.
• Also, with the oversight of an additional project manager, the external IT team members can easily be located off-site for the majority of the project duration saving a great deal in unnecessary travel costs.  Keep in mind this remote scenario warrants a reliable collaborative meeting communication tool for being able to bring together the entire project team.  These regular and ad hoc meetings may need to include consultants from the solution partner, staff from the IT team, and members of the business project team.  Surprisingly enough, this remote project paradigm can work very effectively for BI implementations staffed with the right people.

 What’s the IT Makeup? 

The IT team is usually made up of the following staff members: senior data analyst, business analyst, data modeler, extraction/transformation/loading (ETL) developers, metadata integration developers, presentation layer and enterprise report developers, processing source system developers, DBA, and a QA analyst.  If a BI solution involves hardware or software installation, it’s important to include an experienced BI architect and a senior systems administrator.

• Analysts:  The senior data analyst and business analyst are the lead staff for working with the business project team members to define and document the business and data requirements, assumptions, and business rules. 
• Processing Source System Expertise:  In addition to processing source system data mapping information, the processing source system developers (and processing source system business analysts if available) can provide incredible value to a BI project regarding the embedded business rules, business processes, and information on data history (e.g. explaining data patterns, data gaps, data anomalies, data conversion issues, etc.) for including in the requirements documentation.
• Designers:  For custom BI data solutions, the senior data analyst, data modeler, architect, DBA, and ETL developers are needed for ensuring proper BI design.
• BI Developers:  The ETL, presentation layer, metadata integration, and enterprise report developers are needed for business data extraction, transformation, loading, and integration development purposes, for ultimately producing the enterprise data warehouse, the enterprise reports, dashboards, and alerts, as well as the end user’s ad hoc query and report development environment.
• Testing & Data Validation Expertise:  While the development team provides a hefty amount of data analysis and data validation work from the processing source systems to the enterprise data warehouse and metadata repository, the senior data analyst, business analyst, and QA analyst are critical to leading the effort of data validation and performance testing with the business project team members during User Acceptance Testing for achieving business acceptance and signoff.
• BI Architect:  An experienced BI architect is extremely valuable to a BI initiative in technical planning and sizing, exercising optimization opportunities, establishing and ensuring ongoing compliance with architectural blueprints, technical roadmaps, and evolving development, security, and data testing standards.

For the most part, the IT project team members should be dedicated 90 percent of the time to the BI initiative.  The only exceptions would be the processing source system developers, the DBA, the system administrator, and the architect which could be reduced to 30 percent overall. 

If there is no hardware or software installation work involved in the BI project, there is little need for a system administrator.  If hardware or software installation work is involved, there could be peaks for the DBA, senior system administrator, and architect during the technical planning and installation phases upwards of 60-80 percent of their time.

It can’t be stressed enough that the selected BI project resources need to be patient and analytical in nature.  Without this defining characteristic, team members will find BI work difficult, tedious, and mundane.  They will give up easily and the project quality will suffer in the end.  With the right analytical minds, BI project work is exciting, challenging, and engaging!  When it comes to BI, pick the right people, or don’t bother.

 Not Your Ordinary Plan

For the technology project manager (TPM), a custom BI project is no ordinary system implementation.  It is unique because it requires more planning, more collaboration, and more facilitating.  The TPM should have an expert project management skill set, a history of high quality and timely implementations, and be well respected by the organization’s leadership.

To be an effective TPM on a custom BI project, it is necessary to plan continuously.  It requires a project manager to do more than keep score, cross tasks of a project list, and provide regular status reports.  BI project work is iterative, incremental, integrated and can have thousands of working parts.  BI initiatives demand highly disciplined project management skills, effective leadership capabilities, and a mastery of communication, collaboration and facilitation.

For the expert project manager, the most challenging role of being a TPM on a custom BI project is the work involved in being viewed by the business project team as a neutral facilitator.  It is very important that a TPM on a BI project understand that to obtain maximum quality outcomes they are highly dependent on the business team to provide the detail information and decisions needed for properly understanding and documenting the business rules and logic for translating the data from a machine language based structure to a human analytical construct.  Being an effective facilitator as the TPM takes a concerted effort (continuously reminding yourself this is not an IT project) and ongoing preparation to secure the expected BI deliverables needed by the enterprise (and not being sidetracked or tempted by elegant or overly sophisticated system solutions).

Although utilizing all the standard project management techniques and methodologies are critical to the TPM’s execution on a BI project, they won’t be covered in this paper.  Instead, included are points uniquely characteristic or specifically important to the project management of a BI implementation.

The heavy project management discipline is necessary due to typical BI implementations involving a variety of specialized skills combined with the management of usually more than 3, and often times upwards of 10 integrated technologies. 

Other uniquely important tactical planning suggestions include: 

A.  Require a data prototype from the vendors during the solution partner and/or software selection process:

• BI vendors should be able to complete a prototype of enterprise reports and ad hoc querying capabilities with your organization’s data.   If your organization already has existing BI software and hardware to be used in the implementation, require that the vendor use this same software and hardware in their prototype.  If your organization is shopping for software and/or hardware, require that the vendor prototype your organization’s data based on the software and/or hardware being reviewed for consideration. 
• Avoid costly delays by only selecting a BI solution partner that has experience with the software that is either already implemented, or with the software under consideration for selection.

B.  Interview vendor staff for BI and data experience.

• Get to know the vendor’s staff and their expertise. 
• Once the vendor becomes your solution partner, use this information to name the staff of choice in your BI implementation Statement of Work (or at least specify this caliber of expertise).

C.  Review a solution provider’s standard documentation and templates. 

• This review should include samples or templates for developing business & data requirements, the technical roadmap, ETL design documents, slowly changing dimension recommendations, the standard data model with definitions and diagrams, test plans, deployment plans, and milestone signoff documents.

D.  Data Quality Definition

• During the conceptual phase, the TPM should document the initial definition and criteria for data quality with the executive sponsor(s).  This is an ideal opportunity to educate them on the importance of data quality to a BI initiative, the dangers and costs to the utopia of infinite perfection, and to prepare them for allowing this definition to change over time. 
• As part of the requirements phase of a BI project, document for signoff the definition and criteria for acceptable data quality with the business project team, ensuring it is compatible with the executive sponsor definition, and reasonable enough to be achievable for the BI project team. 
• Five main factors that should be considered in an organization’s  data quality definition:  (a) business tolerance between perfection and acceptable use; (b) quality and usability of the raw data contained in the processing source systems; (c) cost to adhere to the definition of data acceptability—it is significantly more expensive to try to achieve perfection than general acceptability; (d) time needed to adhere to the definition of acceptability—takes more time to try to achieve perfection; (e) available resources—in some cases there may not be any resources available or knowledgeable enough to identify the existence of data issues, much less to address and resolve data quality issues (e.g. clean up dirty data). 
• As part of the lessons learned process, the TPM should review the data quality definition and criteria with the executive sponsors to ensure their expectations have not changed based on the reality of project time, cost, or quality constraints (aka the triple constraint).

E.  Issue Management

• Any BI contract should contain language for addressing issue management with specifics for handling escalation and change orders.  As the proverb goes, “good fences make good neighbors”.  If the parties in the contract are confident in their integrity and uprightness, they will embrace this concept.
• From your vendor base, select a solution partner that offers an executive sponsorship with the authority to make business decisions regarding the health and outcome of the BI initiative, especially in case issues are escalated to the level of contractual adherence.  Costly project delays and concessions can occur when an escalation event has to try and make its way through some of the monolithic BI vendor organizations.
• The majority of BI issues are rooted in data quality outcomes identified during data validation and reconciliation.  In these cases, the TPM should use the enterprise’s published definition and criteria to determine if the issue falls under the category of a contract (or SOW) escalation issue with the vendor, or if it falls into the category of requesting a change order from the vendor. 

F.  Expect Data Anomalies

• It is important for the TPM to expect data anomalies to be found during data validation and data reconciliation, and to plan for them to occur in the implementation schedule and in the project budget.    The schedule should allow for time spent by the TPM and the solution partner to develop change orders, and seek approval for them.  The schedule should have expansion options for incorporating change orders into the existing schedule, or exit strategy options if deemed necessary by the project sponsors.  The project budget should already have existing reserve funds in place for handling any approved change orders.  Addressing data anomalies needs to be a time sensitive process led by the TPM, or it will quickly and easily create budget and project schedule overruns.

G.  Training

• If the BI solution’s IT model is to have internal IT staff implement and/or support the BI solution, it is highly recommended to train the internal IT staff on the software in advance of their performing the work with the solution partner’s team.  It is also valuable to negotiate in the contract with the solution partner for knowledge transfer opportunities with their staff and the internal IT staff.  This might be more costly and time consuming during the implementation, but the cost will be justified when the internal IT team can support and enhance the BI solution, with minimal or no external consulting costs needed.
• Train the business team members on the software in advance of User Acceptance Testing.
• Demo the BI solution to the executive team during the User Acceptance Testing phase for their input to the project managers, and to continue the executive commitment for the strategic business initiative.
• The train-the-trainer approach works very well for BI.  Allow the BA and QA staff from IT to train the business testers, as the business testers should ultimately become the trainers to the BI end users.  Business representatives make the best BI end user trainers.  They speak their language, and can better answer their questions.  It also frees up the IT staff to focus on leading support change efforts, conduct BI enrichment workshops, participate in BI user or governance groups, assist the BI trainers, and participate on future projects to meet the strategic BI objectives of the organization.

H.  Data Governance and Stewardship

• The TPM should work with the BI sponsors during the deployment phase of the foundational project of a BI initiative to establish a data stewardship and/or BI governance team if one does not already exist.  Depending on the size of the organization, this team’s purpose could dovetail into the executive steering group of the organization regarding strategic business initiatives related to the BI solution. 
• The charter for this team should be established by the business.  Four important areas to consider as part of their charter are to:  (i) ensure the tactical plans of the group support the BI vision, (ii) govern and prioritize the future BI enhancements and change requests, (iii) make decisions about cleansing the data, and (iv) propose business process changes for correcting or adding data within the processing source systems. 

I.  Ongoing Marketing for Continuous Buy-In

• Because the nature of BI is continuous, incremental implementations, it is important to market the benefits of BI on a regular basis.  Success stories about the value of the data provided in the BI solution is important to publish in newsletters, or share during department, executive and board meetings.  It promotes the initiative and retains the ongoing support and commitment needed for the BI benefits to be realized and recognized by the enterprise.

J.  Transition Plan for Your Data Gurus

• The TPM should develop a transition plan for the data gurus in the organization before the BI initiative begins, and communicate it.
• Appropriate data gurus should be key business project team members.  They are usually the most influential individuals in the organization, and should be deemed as valuable business project team members. 
• They can sometimes make or break a BI project.  Their involvement can certainly improve the quality outcomes.  They can also be powerful change agents in converting others to the value of BI. 
• If not managed well, or if the data gurus feel their role of significance or influence in the organization is threatened, they can become project resistors or worse, sources of BI project failure.  
• It will pay off to request that they participate on BI projects, especially during the requirements gathering (they usually know the business rules best), data testing and reconciliation, and in developing business definitions for the data elements in the BI solution.  The data gurus should become the “power” users of the BI solution, and can make excellent trainers to the general BI end users.  If executed well, the TPM can ensure the data gurus’ role in the organization will be enhanced by a BI initiative, not limited.  The TPM should continue to encourage the data gurus’ positive influence by suggesting their names as BI governance leaders and team members.

 Summary 

Steer your BI project management ship towards achieving the benefits of trusted, meaningful, and timely data.

Project management of a BI initiative is not for the novice or faint of heart.  For the TPM, it takes a seasoned project manager, with strong technical and data knowledge, and processing source system or BI implementation experience.  Beyond adhering to standard project management methodologies and being an effective communicator, the TPM cannot underestimate the importance of being flexible and serving as a collaborator and a facilitator, rather than in the traditional driver or a delegator role. 

The TPM will have to be ready on a moment’s notice to schedule an ad hoc meeting with the appropriate participants to review a newly found data anomaly or discuss an innovative data design change.  Understanding a data scenario’s basis (or root cause if an anomaly), its relevance, its business impact, its history, its future, and securing business consensus and business decisions about it is necessary to addressing it in timely manner during a BI implementation.  The TPM needs to know what participants are needed and at what point to involve them in the problem solving or idea generation process.  Every necessary project team member needs to participate when the time is right and their feedback and input heard for the BI issue or idea to be fully flushed out, and the solution to be successful.

Collaboration and facilitation are precious instruments of the TPM leading a BI project.  The TPM will need to skillfully pick their battles wisely and must execute consensus building while securing timely business decisions. 

The TPM needs to be certain all business decisions are documented and archived for later review and reference (by project team members, IT support staff, or even auditors).  There are thousands of complex details at multiple levels that need to be accurately documented, tracked, and monitored.  However, the documented business decisions will be referenced many times during the implementation, as well as later during the post-live support state.

Don’t forget to be creative.  If the TPM is listening and paying attention, opportunities will present themselves.  For example, our organization’s vision had a clear expectation of trusted data.  In recognizing this, the TPM was able to persuade the organization to place a “certified” BI logo on the standard enterprise reports.  No enterprise BI report or dashboard could have this logo without BI Governance approval which only came after the results were successfully evaluated by a select group of data experts from both the business and IT department.

Timely and trusted BI project outcomes depend upon the TPM doing their job with excellence, being able to readily communicate or make presentations to a diverse set of stakeholders (from BI architects and software engineers to business executives and board members), and having the skill to ensure all project team members, project sponsorship, and stakeholders are continuously educated, informed, and committed to the value, benefits and vision of the enterprise BI solution.

Most successful business intelligence (BI) projects are defined as delivering a solution that delivers trusted, meaningful and timely data.

To gain the most ROI from a successful enterprise BI initiative, it is critical each BI project be treated as an enterprise business project, not as an IT project, and not as a departmental project (for example: finance).

The power of BI is the delivery of enterprise data for making factually informed decisions in order to take deliberate action in a dynamic and uncertain economy.

Educating the organization’s executive team to win their sponsorship is of vital importance to achieving BI success.  The executive team at your organization should be the key benefactors of the BI solution.  The project manager should be able to explain BI benefits in executive language, get their attention by using the organization’s key performance indicators, secure executive advocacy and buy-in, and ensure BI as a strategic business initiative.  In doing so, this will improve the ease of project work by orders of magnitude.

The project manager should provide executives with statistical evidence for establishing an enterprise BI solution, and supply small data success stories with each major deliverable of a BI project to retain the momentum and commitment of the critical resources needed.

 Define Your BI Vision, Strategy, and Scope

It’s necessary to educate the executive team on the benefits of a BI solution before the conceptual stage.  If there’s no business appreciation for a BI initiative, then don’t even start one.  BI solutions are too expensive to do wrong, and without the right support, they’re a complete waste of valuable resources.

It’s essential to have an executive sponsor, ideally two sponsors for a BI project.  Their role in supporting and advocating the BI initiative, and its business strategy with other leaders within the organization, is the cornerstone to building a flagship BI enterprise solution.  Ongoing marketing of the BI benefits is necessary to obtain the greatest return on a BI strategic business initiative. 

Work with the executive sponsors to develop a BI vision.  The vision should rest on the fundamental importance of the BI initiative to the organization.  For example, our organization chose:  “The vision of this program is to deliver more meaningful, timely, complete, and trusted business information to those responsible for setting and measuring the direction of the organization.”

BI Strategy:  The BI strategy should include a foundational phase, a building blocks phase, an extensibility phase, and an expansionary phase.  The strategy should outline the journey from short to long-term BI needs (deliverables), the expected benefits, audience, and processing source systems involved. 

In our organization, we developed a strategic plan in the shape of a “pyramid” containing these multi-dimensional perspectives as a symbol of the initial 5-year BI plan.  Additionally, we named our BI plan the “Insurance Intelligence Program” in recognition of its chief purpose being for the business.  An “IIP Pyramid” was given to every executive in the enterprise as a reminder of the future we were building together.

Like the BI strategy, the phases can be different for every organization, depending on what is already in place from a data warehousing and decision support standpoint. 

• Foundation Phase:  The foundational phase typically includes confirming the executive sponsors and project managers, identifying the type of technical implementation (e.g. homegrown, custom, COTS), deciding the resource model (e.g. internally staffed, outsourced, or a combination of both), securing business solution partners, defining the architecture, selecting the software and hardware platform and vendors, establishing the initial project team, implementing the fundamental scope of the business and data deliverables, and most importantly, training the enterprise to use the BI tools for challenging their data, their business processes, and even the way they make decisions.
• Building Blocks Phase:  The building blocks phase generally includes time- phased projects involving additional data augmentation, more complex data solutions, enhanced security, data optimization, archiving and storing, and developing a wider range of customer oriented analytics.
• Extensibility Phase:  The extensibility phase involves sharing or exchanging BI data among external business partners, or building customized front end data applications for providing specific business or external customer services.
• Expansionary Phase:  The expansionary phase involves leveraging the existing BI solution for even greater analytic capabilities and opportunities, such as predictive analytics, enterprise risk management, or tapping into storehouses of external data without needing to store this data internal to an enterprise’s data warehouse.

Regardless of the phase or project, it is imperative for the project manager to define and closely manage the scope envisioned.  The goal should be to achieve a business relevant scope, not too big, not too small.  The scope must be centered on what brings the most informational value to the enterprise’s critical needs at that time.  Remember too much information too fast has no value…if the amount of information or data over saturates or overwhelms the BI audience, and they are furnished with no proper way to digest it, there is no value rendered to an organization. 

Additionally, when delivering too much data at once, there is not sufficient time to validate the data outcomes, and the most priceless BI characteristic of all is lost, trusted information.  BI is an unforgiving endeavor.  If the trust for the data is lost, it may never be recovered…. if poor business decisions are made based on bad BI data solutions, it’s a slow road back to redemption.

Keys to the Right People

The process for getting the right people starts with selling the value of BI to the executives from the very beginning…this is where the commitment to be given the right resources lies.

Business

• Getting the right people involved starts with the executive sponsor.  The executive sponsor must be a respected and credible leader in the organization.  They need to have a passion for data, be key to the operational success of the enterprise (have skin in the game), and be able to be the champion for the initiative.  If you don’t have the luxury of more than one executive sponsor, don’t let the executive sponsor be the CIO or CTO.  The golden rule of success is BI is a business initiative, not an IT initiative.  The ideal executive sponsorship is a combination of the CIO and the VP of Operations, or similar functions that may have different titles in other organizations.  By having this, the solution will bear a delicious fruit from the marriage of efficient technology and business relevance.
• The next most important selection for a BI initiative is the selection of the project manager.  If it is possible to select two project managers, one being the business project manager and the other the technology project manager from within an organization, this is preferred.  It will make a tremendous difference in the quality of the BI business outcomes.  The process or means of implementing BI solutions is highly disciplined requiring the structure of a technology project manager’s leadership, but the relevant deliverables only have value if sanctioned by business leadership.
• The business project manager commitment is generally 20  percent of the time, with 30 percent peaks during the requirements phase and the user acceptance testing phase.  For the technology project manager, if the BI solution includes implementing hardware, software, and data solutions, the time needed from the technology project manager will be 60-80 percent of the duration, and for strictly data solutions, generally only 40-50 percent of their time.

Business Project Team

• The selection of the business project team members is also very important.  The business project team members need to be the most data knowledgeable and process oriented business representatives in the organization (aka “knowledge workers” or “data gurus”).  They are typically the “thought leaders” of the organization who have a command of the business data, talk in terms of facts, and are analytical in nature.  They are also usually the highest in demand within an organization; thus, the importance for executive commitment for a BI initiative.  Ensure the project team members are a cross-functional mix of business experts, depending on the BI data being implemented.
• For example, in a worker’s compensation insurance implementation of policy and claims data, a good business project team mix could include an underwriter, a claims examiner, a policyholder customer service representative, an actuary, a safety management consultant, a finance specialist, and at least one operational team leader.  On the other hand, a medical and pharmacy billing data implementation might only have 2-3 medical and pharmacy claim specialists, a claims analyst, an actuary, and the operational medical team leader.
• The business project team members usually spend an average of 20 percent of their time for the duration of the project, with two 40 percent peaks during the requirements gathering and user acceptance testing phases of a BI project.  It is very important to have the business project team members dedicated to the BI implementation for the duration, and not change business team membership during the project.  It is too difficult for the business team members to catch up or ramp up with the analytical complexities in providing the necessary business value to the BI project.

Solution Partner

• Another critical aspect of the selection process is the external BI implementation partner(s).  Whether it is for customized or “cookie cutter” BI solutions, it is crucial to partner with a consulting team that has at least 10 years experience and expertise in your organization’s industry, in BI and data analytics, and in your organization’s platform and architecture.  If a solution partner cannot meet all of these criteria, the likelihood of BI success is decreased.  The more customized the solution, the more important it is for incorporating, exposing, and understanding your business rules within the BI data, and the greater the need for a BI partner with staff having expertise in your industry and type of business data.  Before choosing your solution partner, don’t forget to check the vendors’ references and arrange for site visits with clients having similar solutions to the one your organization envisions. 

Technical Team

• The final selection of the right people is the IT project team.  If an organization does not have these staff members internally, or doesn’t plan to have an internal implementation and support team for their BI solution, it is important to negotiate with the solution partner for these individuals. 
• It is strongly advised to have “right to terminate” and “long-term assignment” protection clauses for all consultants in the terms of the Statement of Work and/or contract.   Custom BI initiatives can often times have durations of many months, even multiple years, and when knowledgeable consultants are secured and develop a strong working knowledge of your data rules over time, it will be important to keep these same experts through the duration.
• If utilizing an external solution partner for your BI project work, it is recommended to include in the team lineup a part-time project manager from their team.  There are multiple benefits in doing so.  Meetings can be scheduled more quickly, incurred consulting costs can be monitored and managed more closely, and issues or misunderstandings resolved more efficiently.
• Also, with the oversight of an additional project manager, the external IT team members can easily be located off-site for the majority of the project duration saving a great deal in unnecessary travel costs.  Keep in mind this remote scenario warrants a reliable collaborative meeting communication tool for being able to bring together the entire project team.  These regular and ad hoc meetings may need to include consultants from the solution partner, staff from the IT team, and members of the business project team.  Surprisingly enough, this remote project paradigm can work very effectively for BI implementations staffed with the right people.

 What’s the IT Makeup? 

The IT team is usually made up of the following staff members: senior data analyst, business analyst, data modeler, extraction/transformation/loading (ETL) developers, metadata integration developers, presentation layer and enterprise report developers, processing source system developers, DBA, and a QA analyst.  If a BI solution involves hardware or software installation, it’s important to include an experienced BI architect and a senior systems administrator.

• Analysts:  The senior data analyst and business analyst are the lead staff for working with the business project team members to define and document the business and data requirements, assumptions, and business rules. 
• Processing Source System Expertise:  In addition to processing source system data mapping information, the processing source system developers (and processing source system business analysts if available) can provide incredible value to a BI project regarding the embedded business rules, business processes, and information on data history (e.g. explaining data patterns, data gaps, data anomalies, data conversion issues, etc.) for including in the requirements documentation.
• Designers:  For custom BI data solutions, the senior data analyst, data modeler, architect, DBA, and ETL developers are needed for ensuring proper BI design.
• BI Developers:  The ETL, presentation layer, metadata integration, and enterprise report developers are needed for business data extraction, transformation, loading, and integration development purposes, for ultimately producing the enterprise data warehouse, the enterprise reports, dashboards, and alerts, as well as the end user’s ad hoc query and report development environment.
• Testing & Data Validation Expertise:  While the development team provides a hefty amount of data analysis and data validation work from the processing source systems to the enterprise data warehouse and metadata repository, the senior data analyst, business analyst, and QA analyst are critical to leading the effort of data validation and performance testing with the business project team members during User Acceptance Testing for achieving business acceptance and signoff.
• BI Architect:  An experienced BI architect is extremely valuable to a BI initiative in technical planning and sizing, exercising optimization opportunities, establishing and ensuring ongoing compliance with architectural blueprints, technical roadmaps, and evolving development, security, and data testing standards.

For the most part, the IT project team members should be dedicated 90 percent of the time to the BI initiative.  The only exceptions would be the processing source system developers, the DBA, the system administrator, and the architect which could be reduced to 30 percent overall. 

If there is no hardware or software installation work involved in the BI project, there is little need for a system administrator.  If hardware or software installation work is involved, there could be peaks for the DBA, senior system administrator, and architect during the technical planning and installation phases upwards of 60-80 percent of their time.

It can’t be stressed enough that the selected BI project resources need to be patient and analytical in nature.  Without this defining characteristic, team members will find BI work difficult, tedious, and mundane.  They will give up easily and the project quality will suffer in the end.  With the right analytical minds, BI project work is exciting, challenging, and engaging!  When it comes to BI, pick the right people, or don’t bother.

 Not Your Ordinary Plan

For the technology project manager (TPM), a custom BI project is no ordinary system implementation.  It is unique because it requires more planning, more collaboration, and more facilitating.  The TPM should have an expert project management skill set, a history of high quality and timely implementations, and be well respected by the organization’s leadership.

To be an effective TPM on a custom BI project, it is necessary to plan continuously.  It requires a project manager to do more than keep score, cross tasks of a project list, and provide regular status reports.  BI project work is iterative, incremental, integrated and can have thousands of working parts.  BI initiatives demand highly disciplined project management skills, effective leadership capabilities, and a mastery of communication, collaboration and facilitation.

For the expert project manager, the most challenging role of being a TPM on a custom BI project is the work involved in being viewed by the business project team as a neutral facilitator.  It is very important that a TPM on a BI project understand that to obtain maximum quality outcomes they are highly dependent on the business team to provide the detail information and decisions needed for properly understanding and documenting the business rules and logic for translating the data from a machine language based structure to a human analytical construct.  Being an effective facilitator as the TPM takes a concerted effort (continuously reminding yourself this is not an IT project) and ongoing preparation to secure the expected BI deliverables needed by the enterprise (and not being sidetracked or tempted by elegant or overly sophisticated system solutions).

Although utilizing all the standard project management techniques and methodologies are critical to the TPM’s execution on a BI project, they won’t be covered in this paper.  Instead, included are points uniquely characteristic or specifically important to the project management of a BI implementation.

The heavy project management discipline is necessary due to typical BI implementations involving a variety of specialized skills combined with the management of usually more than 3, and often times upwards of 10 integrated technologies. 

Other uniquely important tactical planning suggestions include: 

A.  Require a data prototype from the vendors during the solution partner and/or software selection process:

• BI vendors should be able to complete a prototype of enterprise reports and ad hoc querying capabilities with your organization’s data.   If your organization already has existing BI software and hardware to be used in the implementation, require that the vendor use this same software and hardware in their prototype.  If your organization is shopping for software and/or hardware, require that the vendor prototype your organization’s data based on the software and/or hardware being reviewed for consideration. 
• Avoid costly delays by only selecting a BI solution partner that has experience with the software that is either already implemented, or with the software under consideration for selection.

B.  Interview vendor staff for BI and data experience.

• Get to know the vendor’s staff and their expertise. 
• Once the vendor becomes your solution partner, use this information to name the staff of choice in your BI implementation Statement of Work (or at least specify this caliber of expertise).

C.  Review a solution provider’s standard documentation and templates. 

• This review should include samples or templates for developing business & data requirements, the technical roadmap, ETL design documents, slowly changing dimension recommendations, the standard data model with definitions and diagrams, test plans, deployment plans, and milestone signoff documents.

D.  Data Quality Definition

• During the conceptual phase, the TPM should document the initial definition and criteria for data quality with the executive sponsor(s).  This is an ideal opportunity to educate them on the importance of data quality to a BI initiative, the dangers and costs to the utopia of infinite perfection, and to prepare them for allowing this definition to change over time. 
• As part of the requirements phase of a BI project, document for signoff the definition and criteria for acceptable data quality with the business project team, ensuring it is compatible with the executive sponsor definition, and reasonable enough to be achievable for the BI project team. 
• Five main factors that should be considered in an organization’s  data quality definition:  (a) business tolerance between perfection and acceptable use; (b) quality and usability of the raw data contained in the processing source systems; (c) cost to adhere to the definition of data acceptability—it is significantly more expensive to try to achieve perfection than general acceptability; (d) time needed to adhere to the definition of acceptability—takes more time to try to achieve perfection; (e) available resources—in some cases there may not be any resources available or knowledgeable enough to identify the existence of data issues, much less to address and resolve data quality issues (e.g. clean up dirty data). 
• As part of the lessons learned process, the TPM should review the data quality definition and criteria with the executive sponsors to ensure their expectations have not changed based on the reality of project time, cost, or quality constraints (aka the triple constraint).

E.  Issue Management

• Any BI contract should contain language for addressing issue management with specifics for handling escalation and change orders.  As the proverb goes, “good fences make good neighbors”.  If the parties in the contract are confident in their integrity and uprightness, they will embrace this concept.
• From your vendor base, select a solution partner that offers an executive sponsorship with the authority to make business decisions regarding the health and outcome of the BI initiative, especially in case issues are escalated to the level of contractual adherence.  Costly project delays and concessions can occur when an escalation event has to try and make its way through some of the monolithic BI vendor organizations.
• The majority of BI issues are rooted in data quality outcomes identified during data validation and reconciliation.  In these cases, the TPM should use the enterprise’s published definition and criteria to determine if the issue falls under the category of a contract (or SOW) escalation issue with the vendor, or if it falls into the category of requesting a change order from the vendor. 

F.  Expect Data Anomalies

• It is important for the TPM to expect data anomalies to be found during data validation and data reconciliation, and to plan for them to occur in the implementation schedule and in the project budget.    The schedule should allow for time spent by the TPM and the solution partner to develop change orders, and seek approval for them.  The schedule should have expansion options for incorporating change orders into the existing schedule, or exit strategy options if deemed necessary by the project sponsors.  The project budget should already have existing reserve funds in place for handling any approved change orders.  Addressing data anomalies needs to be a time sensitive process led by the TPM, or it will quickly and easily create budget and project schedule overruns.

G.  Training

• If the BI solution’s IT model is to have internal IT staff implement and/or support the BI solution, it is highly recommended to train the internal IT staff on the software in advance of their performing the work with the solution partner’s team.  It is also valuable to negotiate in the contract with the solution partner for knowledge transfer opportunities with their staff and the internal IT staff.  This might be more costly and time consuming during the implementation, but the cost will be justified when the internal IT team can support and enhance the BI solution, with minimal or no external consulting costs needed.
• Train the business team members on the software in advance of User Acceptance Testing.
• Demo the BI solution to the executive team during the User Acceptance Testing phase for their input to the project managers, and to continue the executive commitment for the strategic business initiative.
• The train-the-trainer approach works very well for BI.  Allow the BA and QA staff from IT to train the business testers, as the business testers should ultimately become the trainers to the BI end users.  Business representatives make the best BI end user trainers.  They speak their language, and can better answer their questions.  It also frees up the IT staff to focus on leading support change efforts, conduct BI enrichment workshops, participate in BI user or governance groups, assist the BI trainers, and participate on future projects to meet the strategic BI objectives of the organization.

H.  Data Governance and Stewardship

• The TPM should work with the BI sponsors during the deployment phase of the foundational project of a BI initiative to establish a data stewardship and/or BI governance team if one does not already exist.  Depending on the size of the organization, this team’s purpose could dovetail into the executive steering group of the organization regarding strategic business initiatives related to the BI solution. 
• The charter for this team should be established by the business.  Four important areas to consider as part of their charter are to:  (i) ensure the tactical plans of the group support the BI vision, (ii) govern and prioritize the future BI enhancements and change requests, (iii) make decisions about cleansing the data, and (iv) propose business process changes for correcting or adding data within the processing source systems. 

I.  Ongoing Marketing for Continuous Buy-In

• Because the nature of BI is continuous, incremental implementations, it is important to market the benefits of BI on a regular basis.  Success stories about the value of the data provided in the BI solution is important to publish in newsletters, or share during department, executive and board meetings.  It promotes the initiative and retains the ongoing support and commitment needed for the BI benefits to be realized and recognized by the enterprise.

J.  Transition Plan for Your Data Gurus

• The TPM should develop a transition plan for the data gurus in the organization before the BI initiative begins, and communicate it.
• Appropriate data gurus should be key business project team members.  They are usually the most influential individuals in the organization, and should be deemed as valuable business project team members. 
• They can sometimes make or break a BI project.  Their involvement can certainly improve the quality outcomes.  They can also be powerful change agents in converting others to the value of BI. 
• If not managed well, or if the data gurus feel their role of significance or influence in the organization is threatened, they can become project resistors or worse, sources of BI project failure.  
• It will pay off to request that they participate on BI projects, especially during the requirements gathering (they usually know the business rules best), data testing and reconciliation, and in developing business definitions for the data elements in the BI solution.  The data gurus should become the “power” users of the BI solution, and can make excellent trainers to the general BI end users.  If executed well, the TPM can ensure the data gurus’ role in the organization will be enhanced by a BI initiative, not limited.  The TPM should continue to encourage the data gurus’ positive influence by suggesting their names as BI governance leaders and team members.

 Summary 

Steer your BI project management ship towards achieving the benefits of trusted, meaningful, and timely data.

Project management of a BI initiative is not for the novice or faint of heart.  For the TPM, it takes a seasoned project manager, with strong technical and data knowledge, and processing source system or BI implementation experience.  Beyond adhering to standard project management methodologies and being an effective communicator, the TPM cannot underestimate the importance of being flexible and serving as a collaborator and a facilitator, rather than in the traditional driver or a delegator role. 

The TPM will have to be ready on a moment’s notice to schedule an ad hoc meeting with the appropriate participants to review a newly found data anomaly or discuss an innovative data design change.  Understanding a data scenario’s basis (or root cause if an anomaly), its relevance, its business impact, its history, its future, and securing business consensus and business decisions about it is necessary to addressing it in timely manner during a BI implementation.  The TPM needs to know what participants are needed and at what point to involve them in the problem solving or idea generation process.  Every necessary project team member needs to participate when the time is right and their feedback and input heard for the BI issue or idea to be fully flushed out, and the solution to be successful.

Collaboration and facilitation are precious instruments of the TPM leading a BI project.  The TPM will need to skillfully pick their battles wisely and must execute consensus building while securing timely business decisions. 

The TPM needs to be certain all business decisions are documented and archived for later review and reference (by project team members, IT support staff, or even auditors).  There are thousands of complex details at multiple levels that need to be accurately documented, tracked, and monitored.  However, the documented business decisions will be referenced many times during the implementation, as well as later during the post-live support state.

Don’t forget to be creative.  If the TPM is listening and paying attention, opportunities will present themselves.  For example, our organization’s vision had a clear expectation of trusted data.  In recognizing this, the TPM was able to persuade the organization to place a “certified” BI logo on the standard enterprise reports.  No enterprise BI report or dashboard could have this logo without BI Governance approval which only came after the results were successfully evaluated by a select group of data experts from both the business and IT department.

Timely and trusted BI project outcomes depend upon the TPM doing their job with excellence, being able to readily communicate or make presentations to a diverse set of stakeholders (from BI architects and software engineers to business executives and board members), and having the skill to ensure all project team members, project sponsorship, and stakeholders are continuously educated, informed, and committed to the value, benefits and vision of the enterprise BI solution.

Most successful business intelligence (BI) projects are defined as delivering a solution that delivers trusted, meaningful and timely data.

To gain the most ROI from a successful enterprise BI initiative, it is critical each BI project be treated as an enterprise business project, not as an IT project, and not as a departmental project (for example: finance).

The power of BI is the delivery of enterprise data for making factually informed decisions in order to take deliberate action in a dynamic and uncertain economy.

Educating the organization’s executive team to win their sponsorship is of vital importance to achieving BI success.  The executive team at your organization should be the key benefactors of the BI solution.  The project manager should be able to explain BI benefits in executive language, get their attention by using the organization’s key performance indicators, secure executive advocacy and buy-in, and ensure BI as a strategic business initiative.  In doing so, this will improve the ease of project work by orders of magnitude.

The project manager should provide executives with statistical evidence for establishing an enterprise BI solution, and supply small data success stories with each major deliverable of a BI project to retain the momentum and commitment of the critical resources needed.

 Define Your BI Vision, Strategy, and Scope

It’s necessary to educate the executive team on the benefits of a BI solution before the conceptual stage.  If there’s no business appreciation for a BI initiative, then don’t even start one.  BI solutions are too expensive to do wrong, and without the right support, they’re a complete waste of valuable resources.

It’s essential to have an executive sponsor, ideally two sponsors for a BI project.  Their role in supporting and advocating the BI initiative, and its business strategy with other leaders within the organization, is the cornerstone to building a flagship BI enterprise solution.  Ongoing marketing of the BI benefits is necessary to obtain the greatest return on a BI strategic business initiative. 

Work with the executive sponsors to develop a BI vision.  The vision should rest on the fundamental importance of the BI initiative to the organization.  For example, our organization chose:  “The vision of this program is to deliver more meaningful, timely, complete, and trusted business information to those responsible for setting and measuring the direction of the organization.”

BI Strategy:  The BI strategy should include a foundational phase, a building blocks phase, an extensibility phase, and an expansionary phase.  The strategy should outline the journey from short to long-term BI needs (deliverables), the expected benefits, audience, and processing source systems involved. 

In our organization, we developed a strategic plan in the shape of a “pyramid” containing these multi-dimensional perspectives as a symbol of the initial 5-year BI plan.  Additionally, we named our BI plan the “Insurance Intelligence Program” in recognition of its chief purpose being for the business.  An “IIP Pyramid” was given to every executive in the enterprise as a reminder of the future we were building together.

Like the BI strategy, the phases can be different for every organization, depending on what is already in place from a data warehousing and decision support standpoint. 

• Foundation Phase:  The foundational phase typically includes confirming the executive sponsors and project managers, identifying the type of technical implementation (e.g. homegrown, custom, COTS), deciding the resource model (e.g. internally staffed, outsourced, or a combination of both), securing business solution partners, defining the architecture, selecting the software and hardware platform and vendors, establishing the initial project team, implementing the fundamental scope of the business and data deliverables, and most importantly, training the enterprise to use the BI tools for challenging their data, their business processes, and even the way they make decisions.
• Building Blocks Phase:  The building blocks phase generally includes time- phased projects involving additional data augmentation, more complex data solutions, enhanced security, data optimization, archiving and storing, and developing a wider range of customer oriented analytics.
• Extensibility Phase:  The extensibility phase involves sharing or exchanging BI data among external business partners, or building customized front end data applications for providing specific business or external customer services.
• Expansionary Phase:  The expansionary phase involves leveraging the existing BI solution for even greater analytic capabilities and opportunities, such as predictive analytics, enterprise risk management, or tapping into storehouses of external data without needing to store this data internal to an enterprise’s data warehouse.

Regardless of the phase or project, it is imperative for the project manager to define and closely manage the scope envisioned.  The goal should be to achieve a business relevant scope, not too big, not too small.  The scope must be centered on what brings the most informational value to the enterprise’s critical needs at that time.  Remember too much information too fast has no value…if the amount of information or data over saturates or overwhelms the BI audience, and they are furnished with no proper way to digest it, there is no value rendered to an organization. 

Additionally, when delivering too much data at once, there is not sufficient time to validate the data outcomes, and the most priceless BI characteristic of all is lost, trusted information.  BI is an unforgiving endeavor.  If the trust for the data is lost, it may never be recovered…. if poor business decisions are made based on bad BI data solutions, it’s a slow road back to redemption.

Keys to the Right People

The process for getting the right people starts with selling the value of BI to the executives from the very beginning…this is where the commitment to be given the right resources lies.

Business

• Getting the right people involved starts with the executive sponsor.  The executive sponsor must be a respected and credible leader in the organization.  They need to have a passion for data, be key to the operational success of the enterprise (have skin in the game), and be able to be the champion for the initiative.  If you don’t have the luxury of more than one executive sponsor, don’t let the executive sponsor be the CIO or CTO.  The golden rule of success is BI is a business initiative, not an IT initiative.  The ideal executive sponsorship is a combination of the CIO and the VP of Operations, or similar functions that may have different titles in other organizations.  By having this, the solution will bear a delicious fruit from the marriage of efficient technology and business relevance.
• The next most important selection for a BI initiative is the selection of the project manager.  If it is possible to select two project managers, one being the business project manager and the other the technology project manager from within an organization, this is preferred.  It will make a tremendous difference in the quality of the BI business outcomes.  The process or means of implementing BI solutions is highly disciplined requiring the structure of a technology project manager’s leadership, but the relevant deliverables only have value if sanctioned by business leadership.
• The business project manager commitment is generally 20  percent of the time, with 30 percent peaks during the requirements phase and the user acceptance testing phase.  For the technology project manager, if the BI solution includes implementing hardware, software, and data solutions, the time needed from the technology project manager will be 60-80 percent of the duration, and for strictly data solutions, generally only 40-50 percent of their time.

Business Project Team

• The selection of the business project team members is also very important.  The business project team members need to be the most data knowledgeable and process oriented business representatives in the organization (aka “knowledge workers” or “data gurus”).  They are typically the “thought leaders” of the organization who have a command of the business data, talk in terms of facts, and are analytical in nature.  They are also usually the highest in demand within an organization; thus, the importance for executive commitment for a BI initiative.  Ensure the project team members are a cross-functional mix of business experts, depending on the BI data being implemented.
• For example, in a worker’s compensation insurance implementation of policy and claims data, a good business project team mix could include an underwriter, a claims examiner, a policyholder customer service representative, an actuary, a safety management consultant, a finance specialist, and at least one operational team leader.  On the other hand, a medical and pharmacy billing data implementation might only have 2-3 medical and pharmacy claim specialists, a claims analyst, an actuary, and the operational medical team leader.
• The business project team members usually spend an average of 20 percent of their time for the duration of the project, with two 40 percent peaks during the requirements gathering and user acceptance testing phases of a BI project.  It is very important to have the business project team members dedicated to the BI implementation for the duration, and not change business team membership during the project.  It is too difficult for the business team members to catch up or ramp up with the analytical complexities in providing the necessary business value to the BI project.

Solution Partner

• Another critical aspect of the selection process is the external BI implementation partner(s).  Whether it is for customized or “cookie cutter” BI solutions, it is crucial to partner with a consulting team that has at least 10 years experience and expertise in your organization’s industry, in BI and data analytics, and in your organization’s platform and architecture.  If a solution partner cannot meet all of these criteria, the likelihood of BI success is decreased.  The more customized the solution, the more important it is for incorporating, exposing, and understanding your business rules within the BI data, and the greater the need for a BI partner with staff having expertise in your industry and type of business data.  Before choosing your solution partner, don’t forget to check the vendors’ references and arrange for site visits with clients having similar solutions to the one your organization envisions. 

Technical Team

• The final selection of the right people is the IT project team.  If an organization does not have these staff members internally, or doesn’t plan to have an internal implementation and support team for their BI solution, it is important to negotiate with the solution partner for these individuals. 
• It is strongly advised to have “right to terminate” and “long-term assignment” protection clauses for all consultants in the terms of the Statement of Work and/or contract.   Custom BI initiatives can often times have durations of many months, even multiple years, and when knowledgeable consultants are secured and develop a strong working knowledge of your data rules over time, it will be important to keep these same experts through the duration.
• If utilizing an external solution partner for your BI project work, it is recommended to include in the team lineup a part-time project manager from their team.  There are multiple benefits in doing so.  Meetings can be scheduled more quickly, incurred consulting costs can be monitored and managed more closely, and issues or misunderstandings resolved more efficiently.
• Also, with the oversight of an additional project manager, the external IT team members can easily be located off-site for the majority of the project duration saving a great deal in unnecessary travel costs.  Keep in mind this remote scenario warrants a reliable collaborative meeting communication tool for being able to bring together the entire project team.  These regular and ad hoc meetings may need to include consultants from the solution partner, staff from the IT team, and members of the business project team.  Surprisingly enough, this remote project paradigm can work very effectively for BI implementations staffed with the right people.

 What’s the IT Makeup? 

The IT team is usually made up of the following staff members: senior data analyst, business analyst, data modeler, extraction/transformation/loading (ETL) developers, metadata integration developers, presentation layer and enterprise report developers, processing source system developers, DBA, and a QA analyst.  If a BI solution involves hardware or software installation, it’s important to include an experienced BI architect and a senior systems administrator.

• Analysts:  The senior data analyst and business analyst are the lead staff for working with the business project team members to define and document the business and data requirements, assumptions, and business rules. 
• Processing Source System Expertise:  In addition to processing source system data mapping information, the processing source system developers (and processing source system business analysts if available) can provide incredible value to a BI project regarding the embedded business rules, business processes, and information on data history (e.g. explaining data patterns, data gaps, data anomalies, data conversion issues, etc.) for including in the requirements documentation.
• Designers:  For custom BI data solutions, the senior data analyst, data modeler, architect, DBA, and ETL developers are needed for ensuring proper BI design.
• BI Developers:  The ETL, presentation layer, metadata integration, and enterprise report developers are needed for business data extraction, transformation, loading, and integration development purposes, for ultimately producing the enterprise data warehouse, the enterprise reports, dashboards, and alerts, as well as the end user’s ad hoc query and report development environment.
• Testing & Data Validation Expertise:  While the development team provides a hefty amount of data analysis and data validation work from the processing source systems to the enterprise data warehouse and metadata repository, the senior data analyst, business analyst, and QA analyst are critical to leading the effort of data validation and performance testing with the business project team members during User Acceptance Testing for achieving business acceptance and signoff.
• BI Architect:  An experienced BI architect is extremely valuable to a BI initiative in technical planning and sizing, exercising optimization opportunities, establishing and ensuring ongoing compliance with architectural blueprints, technical roadmaps, and evolving development, security, and data testing standards.

For the most part, the IT project team members should be dedicated 90 percent of the time to the BI initiative.  The only exceptions would be the processing source system developers, the DBA, the system administrator, and the architect which could be reduced to 30 percent overall. 

If there is no hardware or software installation work involved in the BI project, there is little need for a system administrator.  If hardware or software installation work is involved, there could be peaks for the DBA, senior system administrator, and architect during the technical planning and installation phases upwards of 60-80 percent of their time.

It can’t be stressed enough that the selected BI project resources need to be patient and analytical in nature.  Without this defining characteristic, team members will find BI work difficult, tedious, and mundane.  They will give up easily and the project quality will suffer in the end.  With the right analytical minds, BI project work is exciting, challenging, and engaging!  When it comes to BI, pick the right people, or don’t bother.

 Not Your Ordinary Plan

For the technology project manager (TPM), a custom BI project is no ordinary system implementation.  It is unique because it requires more planning, more collaboration, and more facilitating.  The TPM should have an expert project management skill set, a history of high quality and timely implementations, and be well respected by the organization’s leadership.

To be an effective TPM on a custom BI project, it is necessary to plan continuously.  It requires a project manager to do more than keep score, cross tasks of a project list, and provide regular status reports.  BI project work is iterative, incremental, integrated and can have thousands of working parts.  BI initiatives demand highly disciplined project management skills, effective leadership capabilities, and a mastery of communication, collaboration and facilitation.

For the expert project manager, the most challenging role of being a TPM on a custom BI project is the work involved in being viewed by the business project team as a neutral facilitator.  It is very important that a TPM on a BI project understand that to obtain maximum quality outcomes they are highly dependent on the business team to provide the detail information and decisions needed for properly understanding and documenting the business rules and logic for translating the data from a machine language based structure to a human analytical construct.  Being an effective facilitator as the TPM takes a concerted effort (continuously reminding yourself this is not an IT project) and ongoing preparation to secure the expected BI deliverables needed by the enterprise (and not being sidetracked or tempted by elegant or overly sophisticated system solutions).

Although utilizing all the standard project management techniques and methodologies are critical to the TPM’s execution on a BI project, they won’t be covered in this paper.  Instead, included are points uniquely characteristic or specifically important to the project management of a BI implementation.

The heavy project management discipline is necessary due to typical BI implementations involving a variety of specialized skills combined with the management of usually more than 3, and often times upwards of 10 integrated technologies. 

Other uniquely important tactical planning suggestions include: 

A.  Require a data prototype from the vendors during the solution partner and/or software selection process:

• BI vendors should be able to complete a prototype of enterprise reports and ad hoc querying capabilities with your organization’s data.   If your organization already has existing BI software and hardware to be used in the implementation, require that the vendor use this same software and hardware in their prototype.  If your organization is shopping for software and/or hardware, require that the vendor prototype your organization’s data based on the software and/or hardware being reviewed for consideration. 
• Avoid costly delays by only selecting a BI solution partner that has experience with the software that is either already implemented, or with the software under consideration for selection.

B.  Interview vendor staff for BI and data experience.

• Get to know the vendor’s staff and their expertise. 
• Once the vendor becomes your solution partner, use this information to name the staff of choice in your BI implementation Statement of Work (or at least specify this caliber of expertise).

C.  Review a solution provider’s standard documentation and templates. 

• This review should include samples or templates for developing business & data requirements, the technical roadmap, ETL design documents, slowly changing dimension recommendations, the standard data model with definitions and diagrams, test plans, deployment plans, and milestone signoff documents.

D.  Data Quality Definition

• During the conceptual phase, the TPM should document the initial definition and criteria for data quality with the executive sponsor(s).  This is an ideal opportunity to educate them on the importance of data quality to a BI initiative, the dangers and costs to the utopia of infinite perfection, and to prepare them for allowing this definition to change over time. 
• As part of the requirements phase of a BI project, document for signoff the definition and criteria for acceptable data quality with the business project team, ensuring it is compatible with the executive sponsor definition, and reasonable enough to be achievable for the BI project team. 
• Five main factors that should be considered in an organization’s  data quality definition:  (a) business tolerance between perfection and acceptable use; (b) quality and usability of the raw data contained in the processing source systems; (c) cost to adhere to the definition of data acceptability—it is significantly more expensive to try to achieve perfection than general acceptability; (d) time needed to adhere to the definition of acceptability—takes more time to try to achieve perfection; (e) available resources—in some cases there may not be any resources available or knowledgeable enough to identify the existence of data issues, much less to address and resolve data quality issues (e.g. clean up dirty data). 
• As part of the lessons learned process, the TPM should review the data quality definition and criteria with the executive sponsors to ensure their expectations have not changed based on the reality of project time, cost, or quality constraints (aka the triple constraint).

E.  Issue Management

• Any BI contract should contain language for addressing issue management with specifics for handling escalation and change orders.  As the proverb goes, “good fences make good neighbors”.  If the parties in the contract are confident in their integrity and uprightness, they will embrace this concept.
• From your vendor base, select a solution partner that offers an executive sponsorship with the authority to make business decisions regarding the health and outcome of the BI initiative, especially in case issues are escalated to the level of contractual adherence.  Costly project delays and concessions can occur when an escalation event has to try and make its way through some of the monolithic BI vendor organizations.
• The majority of BI issues are rooted in data quality outcomes identified during data validation and reconciliation.  In these cases, the TPM should use the enterprise’s published definition and criteria to determine if the issue falls under the category of a contract (or SOW) escalation issue with the vendor, or if it falls into the category of requesting a change order from the vendor. 

F.  Expect Data Anomalies

• It is important for the TPM to expect data anomalies to be found during data validation and data reconciliation, and to plan for them to occur in the implementation schedule and in the project budget.    The schedule should allow for time spent by the TPM and the solution partner to develop change orders, and seek approval for them.  The schedule should have expansion options for incorporating change orders into the existing schedule, or exit strategy options if deemed necessary by the project sponsors.  The project budget should already have existing reserve funds in place for handling any approved change orders.  Addressing data anomalies needs to be a time sensitive process led by the TPM, or it will quickly and easily create budget and project schedule overruns.

G.  Training

• If the BI solution’s IT model is to have internal IT staff implement and/or support the BI solution, it is highly recommended to train the internal IT staff on the software in advance of their performing the work with the solution partner’s team.  It is also valuable to negotiate in the contract with the solution partner for knowledge transfer opportunities with their staff and the internal IT staff.  This might be more costly and time consuming during the implementation, but the cost will be justified when the internal IT team can support and enhance the BI solution, with minimal or no external consulting costs needed.
• Train the business team members on the software in advance of User Acceptance Testing.
• Demo the BI solution to the executive team during the User Acceptance Testing phase for their input to the project managers, and to continue the executive commitment for the strategic business initiative.
• The train-the-trainer approach works very well for BI.  Allow the BA and QA staff from IT to train the business testers, as the business testers should ultimately become the trainers to the BI end users.  Business representatives make the best BI end user trainers.  They speak their language, and can better answer their questions.  It also frees up the IT staff to focus on leading support change efforts, conduct BI enrichment workshops, participate in BI user or governance groups, assist the BI trainers, and participate on future projects to meet the strategic BI objectives of the organization.

H.  Data Governance and Stewardship

• The TPM should work with the BI sponsors during the deployment phase of the foundational project of a BI initiative to establish a data stewardship and/or BI governance team if one does not already exist.  Depending on the size of the organization, this team’s purpose could dovetail into the executive steering group of the organization regarding strategic business initiatives related to the BI solution. 
• The charter for this team should be established by the business.  Four important areas to consider as part of their charter are to:  (i) ensure the tactical plans of the group support the BI vision, (ii) govern and prioritize the future BI enhancements and change requests, (iii) make decisions about cleansing the data, and (iv) propose business process changes for correcting or adding data within the processing source systems. 

I.  Ongoing Marketing for Continuous Buy-In

• Because the nature of BI is continuous, incremental implementations, it is important to market the benefits of BI on a regular basis.  Success stories about the value of the data provided in the BI solution is important to publish in newsletters, or share during department, executive and board meetings.  It promotes the initiative and retains the ongoing support and commitment needed for the BI benefits to be realized and recognized by the enterprise.

J.  Transition Plan for Your Data Gurus

• The TPM should develop a transition plan for the data gurus in the organization before the BI initiative begins, and communicate it.
• Appropriate data gurus should be key business project team members.  They are usually the most influential individuals in the organization, and should be deemed as valuable business project team members. 
• They can sometimes make or break a BI project.  Their involvement can certainly improve the quality outcomes.  They can also be powerful change agents in converting others to the value of BI. 
• If not managed well, or if the data gurus feel their role of significance or influence in the organization is threatened, they can become project resistors or worse, sources of BI project failure.  
• It will pay off to request that they participate on BI projects, especially during the requirements gathering (they usually know the business rules best), data testing and reconciliation, and in developing business definitions for the data elements in the BI solution.  The data gurus should become the “power” users of the BI solution, and can make excellent trainers to the general BI end users.  If executed well, the TPM can ensure the data gurus’ role in the organization will be enhanced by a BI initiative, not limited.  The TPM should continue to encourage the data gurus’ positive influence by suggesting their names as BI governance leaders and team members.

 Summary 

Steer your BI project management ship towards achieving the benefits of trusted, meaningful, and timely data.

Project management of a BI initiative is not for the novice or faint of heart.  For the TPM, it takes a seasoned project manager, with strong technical and data knowledge, and processing source system or BI implementation experience.  Beyond adhering to standard project management methodologies and being an effective communicator, the TPM cannot underestimate the importance of being flexible and serving as a collaborator and a facilitator, rather than in the traditional driver or a delegator role. 

The TPM will have to be ready on a moment’s notice to schedule an ad hoc meeting with the appropriate participants to review a newly found data anomaly or discuss an innovative data design change.  Understanding a data scenario’s basis (or root cause if an anomaly), its relevance, its business impact, its history, its future, and securing business consensus and business decisions about it is necessary to addressing it in timely manner during a BI implementation.  The TPM needs to know what participants are needed and at what point to involve them in the problem solving or idea generation process.  Every necessary project team member needs to participate when the time is right and their feedback and input heard for the BI issue or idea to be fully flushed out, and the solution to be successful.

Collaboration and facilitation are precious instruments of the TPM leading a BI project.  The TPM will need to skillfully pick their battles wisely and must execute consensus building while securing timely business decisions. 

The TPM needs to be certain all business decisions are documented and archived for later review and reference (by project team members, IT support staff, or even auditors).  There are thousands of complex details at multiple levels that need to be accurately documented, tracked, and monitored.  However, the documented business decisions will be referenced many times during the implementation, as well as later during the post-live support state.

Don’t forget to be creative.  If the TPM is listening and paying attention, opportunities will present themselves.  For example, our organization’s vision had a clear expectation of trusted data.  In recognizing this, the TPM was able to persuade the organization to place a “certified” BI logo on the standard enterprise reports.  No enterprise BI report or dashboard could have this logo without BI Governance approval which only came after the results were successfully evaluated by a select group of data experts from both the business and IT department.

Timely and trusted BI project outcomes depend upon the TPM doing their job with excellence, being able to readily communicate or make presentations to a diverse set of stakeholders (from BI architects and software engineers to business executives and board members), and having the skill to ensure all project team members, project sponsorship, and stakeholders are continuously educated, informed, and committed to the value, benefits and vision of the enterprise BI solution.