In the Field with our Experts

A Data Governance Primer (Part 1 of 3)

By Carol Newcomb, Senior Consultant

They say that Data Governance is about People, Process and Organization.  Much of the design work in planning for data governance is around people’s roles and responsibilities, then designing the organizational structure that will provide authority for decisions to be made and enforced.  The processes, however, are not new.  They are probably already being practiced within your organization, just in a decentralized, informal way.  In this blog series, I discuss the processes for 1) investigating and isolating the data quality issues—Root Cause Analysis—, 2) starting to collect complete Metadata Definitions, and 3) performing Data Quality Analysis.  Only when your governance group has worked through each step, in order, will you be more likely to design the appropriate solution.

Root Cause Analysis

The process of data governance is fundamentally very simple.

1. Identify the data quality issues to address
2. Prioritize the portfolio of issues to isolate/tackle the most important
3. Perform Root Cause Analysis to determine the true source of the data issue
4. Design the corrective action
5. Formalize the correction through consideration & approval by the Data Governance organization
6. Implement the fix
7. Monitor the results

It seems like when we start to map out the discrete steps involved in the data governance process, much of the work is already being done in informal ways throughout the organization.  What some folks don’t realize is that data governance is often nothing more than formalizing a whole bunch of informal processes that either don’t get communicated, or aren’t accepted as a data standard.

Root Cause Analysis is the process of identifying probable causes of a data issue, and isolating the contributing factors.  In order to resolve any particular issue, root cause analysis involves fact-finding, drilling into details of the problem, talking to the right people, and separating out other associated (but not contributing) factors.

A standard tool for supporting the detailed findings is the Ishikawa Diagram, below.  

To conduct a thorough Root Cause Analysis, use the following checklist:

• Diagnose the problem as if you are a physician or a detective. Consider all possible sources of the symptom. Don’t rule anything out yet!
• Boil the ocean—be exhaustive and creative.
• Don't practice problem solving before collecting all possible causes.
• Practice the “5 Why’s”—don’t stop asking “Why” until you have exhausted every conceivable potential reason.
• Rank the factors if possible.  Identify the Primary causes versus the Secondary or associated factors.
• Rule out each possible factor one at a time.  Justify why (you may need to come back to this later).
• Find all potential business process and data owners to involve them in your understanding of the possible sources of the problem.
• Share the findings with everyone involved in troubleshooting. They could rule out certain factors with their knowledge.
• Test your hypotheses with actual data.   
• Fix the problem and test again.
• Publish/share your findings and fixes.  Communicating your findings may reveal additional factors you hadn’t considered.

After a thorough Root Cause Analysis has been completed, Data Stewards should proceed to Metadata Analysis and Data Quality Analysis.  These two techniques will be discussed in my next blogs.

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

IT-Business Alignment: Let The Business Drive

By Caryn Maresic, Senior Consultant

Julia’s parents were planning a vacation.  Her mother thought Pensacola would be a great destination—she’s heard so much about the wildlife, especially the dolphins!  Her father wants to see the National Naval Aviation Museum and the Blue Angels.  Since Julia’s traveled extensively, her parents asked her to make all the arrangements.  While having dinner with them to discuss plans, she jotted down the following notes:

• Location:  Moderately-priced hotel close to water/sights.
• Budget: $3,000 for transportation and accommodations.
• Activities:  Beach and nature activities (Mom), science/historic sights (Dad)
• Duration: 10 days.

Julia felt honored that her parents trusted her to get the job done.  After doing some online research, she made all the reservations and met with her parents to review the reservations.  She eagerly awaited the look on her parents’ faces as they scanned the vacation itinerary and read through the glossy brochures.

“Hawaii?”, they said in unison.  “We didn’t want to go to Hawaii!"

"Honey, we chose Florida because we can drive there.  I don’t want to fly anymore.  Flying is such a pain,” Dad grumbled.

“I appreciate what you’ve done, Julia, but an old friend of mine lives near Pensacola and I was hoping to visit while we were there.” said Mom.

“But, Mom!”, exclaimed Julia, “You said you wanted beaches, dolphins, sunny weather.  Dad, you like science and history—what about Pearl Harbor?  You two can’t go to the gulf coast—what about the oil spill?”

What happened here is typical of what happens to IT projects all the time.  It’s easy to say that we wouldn’t do what Julia did.  Would we?  Don’t we oftentimes:

• Interview the business and record the requirements in an abstract way.
• Believe that the we can deliver something better than what the business asked for.
• Assume that the business lacks the capability to understand the technology.
• Fail to get all of the requirements.  Not exactly our fault, but still a problem.
• Neglect to keep the business involved in the process.

There has been a lot of buzz on IT-Business alignment of late, including this article on some specific companies that are going the extra mile: Beyond Alignment—as well as this one on lack of user involvement: Why IT Projects Fail: Lack of User Involvement.  Most companies aren’t as progressive.  The willingness to work together has to occur at all levels. Only when we let them drive can we deliver, if not what they asked for, then at least something useful.

photo by stevendepolo via Flickr (Creative Commons license)

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

Agile Analytics: Put Your SaaS in the Sand

By Rob Paller, Consultant

Recently at a client, the data warehouse administrator was asked to define a sandbox environment in the production data warehouse for  analysts and developers working on a small project. The idea behind this sandbox was to allow the team a working area for collaboration and intermediate storage of results while working with the data in a purely ad hoc capacity. Instantly it was recognized this could be the start of something bigger within the organization—something that could not currently be provided by the incumbent business intelligence tools. The response had to be formulated quickly in order to avoid stifling the creativity of the analysts—or worse, the progress of the project—but care had to be taken as well; if managed incorrectly it could get out of hand and become a waste of system resources and a drain on human resources that had already been spread thin.  The business unit in question is looking to move from the confines the current business intelligence environment and push the edges.

This was a group of analysts that wanted to get their hands dirty and weren’t afraid to fail. They wanted to mash data together that previously could not be done by the business intelligence tools in their controlled ad hoc environments. This was data mining for the next set of KPIs that would shape the way business moves forward.

The concept of agile analytics is not new, eBay presented on and blogged about this concept in 2008. The idea at this client was simple. By leveraging the existing enterprise data warehouse system to house their sandbox environment the duplication of data is all but eliminated. Groups interested in sharing data between their sandbox environments are strongly discouraged until the data has been properly integrated into the production environment. The sandbox environments would also be given a short life expectancy at their inception to prevent the prototypes from becoming production and data ending up in a wasteland. This all sounded great on paper.

In the midst of a development architecture overview, a brief conversation among a few enterprise architects uncovered the potential Screw-Me Scenario that could bring the concept of agile analytics to an untimely demise. “The users of the data warehouse are not permitted to write ad hoc queries outside of a controlled business intelligence tool. They might write a bad query.” Thanks for the warning, we’ll be sure to refine our pitch to the enterprise architects to diffuse this scenario before it turns ugly.

In Oliver Ratzesberger’s presentation for eBay’s Analytics as a Service, he acknowledges that the metrics we already know are cheap and the unknown metrics are expensive. But the known metrics are not pushing the edges. Known metrics are found in the middle of the box. Agile analytics is about pushing the edges about how your enterprise data warehouse is used to improve response to the needs of the business. It is about the evolution of the user community from one who plays in controlled ad hoc environments to encouraging them to experiment with new ideas and not to fear failing along the way. Agile analytics is about encouraging your users reach out for the edges and P U S H. Only once the edges are stretched can the middle of the box redefined.

photo by edenpictures via Flickr (Creative Commons License)

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system.

BI and Data Warehousing, and the Role of Business Analyst

By Steven Bebout, Senior Consultant

When I tell people what I do for a living, their eyes typically glaze over.  I am a business analyst with an area of expertise in the DW/BI warehouse space.  When asked to elaborate, my story changes depending upon the industry, current state of the client, politics, budget, priorities within an organization, the client’s history with past data warehousing efforts, etc…

Fundamental responsibilities include: liaison between the business and technology team.  I gather data analytic specific  business requirements; making sure that the data is there to support the requirements, ensure that the preliminary conceptual data models  validate business scenarios, and work closely with testing teams to make sure that the requirements are met.  Gathering thorough business and data requirements leaves the DW more robust and flexible as users further define their needs (especially reporting needs).

I’d like to provide the analogy of building a foundation for a house; a house needs a foundation to shoulder its considerable weight, provide a flat and level base for construction and separate wood-based materials from contact with the ground, which would otherwise cause rot and allow termite infestation.  This analogy aligns itself well to a data warehousing project.

The business analyst provides the foundation for the data warehousing project.  They shoulder the weight of understanding and identifying data and process deficiencies as you are doing the DW/BI analysis; serving as a business-oriented project resource.  In some instances, they may have a systems orientation but this is not an expectation of the business analyst’s knowledge set.

The business needs of the organization are identified by interviewing the key stakeholders.  You interview IT to determine technical feasibility, not business needs.  IT doesn’t define business needs; they only tell you if it can be done and what it will cost.  You take that information back to the business and let them decide if they want to pay for it. Identifying these business needs helps to develop the design needs of the data warehouse; missing or misinterpreting the needs creates ‘infestations’ as described in the housing analogy. 

It has been my experience that the business analyst is the right hand and often assists the project manager throughout the project.  Knowing the foundation of the project and utilizing their client facing skills provides the project manager confidence that in their absence, the business analyst can attend meetings and speak knowledgably on their behalf.

The most successful DW/BI projects I have been involved in are ones where the business analyst is gleaning the user's wants and needs for the business requirements and the data architect/modeler is analyzing the data sources, underlying processes and data quality aspects.  Together they work to construct a business-driven and data-driven conceptual and logical model (and also a dimensional and star-schema model if appropriate).  A broader combination of efforts includes working with the development team to discern the functional and non-functional requirements for the reporting or analytic deliverables and the physical model (normalized or multi-dimensional as appropriate).

I realize that some people are capable of fulfilling both roles (business analyst and data modeler), and certainly on smaller project might be called upon to perform both roles. However, due to the business complexity, the need for quick success, the economic pressures, etc., I don't personally subscribe to the ‘jack of all trades’ model.

Certainly being knowledgeable in both areas makes sense, but realistically I think it is more prudent to focus on the task at hand and collaborate together.  What is your opinion of a business analyst fulfilling both roles?  Do you see fulfilling both roles as a value-add or as a potential pitfall in resourcing?

photo by Martin Pettitt (via Flickr)

---

Steve Bebout is a consultant with over 15 years of experience in information technology in the areas of application development, business requirements, data analysis, and project management.  He has experience in the Communications Media and Entertainment, Financial Services, Life Sciences, and Insurance vertical markets; spending the majority of his efforts on customer data integration initiatives. 

Facilitating BI Requirements Workshops

By Fernando Martinez-Campos

 
photo by faster panda kill kill

In this post we will explore ideas for facilitating BI requirements workshops with a group of users. The main goal of requirements discovery workshops is to identify initial BI requirements with key business stakeholders. These sessions start with open ended questions which evolve into detailed requirements. As a facilitator your responsibility is to keep the process on track so business value is derived from the discussions.

The earliest preparatory steps require that you identify the audience participants, create an agenda that will spark interest and schedule the meetings. You will also need to appoint a scribe, who will record the proceedings and capture the output (the facilitator can rarely do both jobs well). I find it useful to also have an initial set of prepared examples that show the progression of an idea into actual requirements. By showing these examples early during the first meeting, you will show stakeholders what the desired outcome of requirements gathering looks like.

Some common steps  in a BI requirements discovery session are:

• Brainstorming ideas – This is the open ended part of the discussion
• Categorizing ideas into business function – This step organizes ideas into groups
• Associating business functions - The groups are related together
• Defining business questions – Initial business questions are chained with follow on questions
• Refining detail requirements - This step translates the questions into detailed requirements
• Prioritizing requirements – Ranks the requirements in order of importance

Let’s use these steps with an example of how these facilitated meetings were conducted at our electronics manufacturer client. The main objective was improving the repair process using BI analytics. The initial session had about eight stakeholders in attendance.

Several categories were developed that had business requirements:  products returned, centers where repairs took place, tests performed, and repair actions. We developed the categories into associated business functions: for example, the Test category had related tests to test results which were associated to the Repair category with repair actions. We continued chaining more questions if the repair action yielded defect trends. By looking at how these business processes were linked, we could track the progress of the workflows in the repair process.

We published the requirements of these workflow activities along with the required data that was needed. On the next session we reviewed, adjusted and agreed on the requirements. Then it was time to prioritize which requirements needed to be implemented and created a roadmap of BI projects.

The BI requirements workshop reaped the following benefits:

• Established solid alignment between the business stakeholders and BI developers
• Documented requirements of the repair process and its analytics
• Reached early stakeholder consensus of the requirements
• Provided visibility on the agreed priorities to set the right expectations
• Provided a forum to communicate feedback and potential risks

As the BI stakeholders gained confidence in the combined effort, follow on sessions became easier. In fact, follow on BI requirements sessions  managed themselves!

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.