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.

Consulting Terms of Engagement: a Readiness Checklist

By Carol Newcomb, Senior Consultant

Having worked at least half of my professional life either with consultants or as a consultant myself, I need to offer some practical advice on increasing the probability of success on a consulting engagement.

Remember, a consultant is just another tool in your management toolbox that provides either the leverage (expertise/experience) or the hard skills that you and your staff are missing today.

There are three main reasons to hire consultants:  1) you want coaching from expert advisors to mentor your existing team and provide tactical advice; 2) you don’t have the skill-sets that you need (ETL programmers, software/hardware experts, etc.); or 3) to provide frameworks and processes to build and sustain ongoing programs (like business intelligence or data governance).

Regardless of the type of consulting engagement, your staff need to be on board with the presence of consultants in their midst.  Ask yourself, as the sponsor, some basic questions:

• Have you explained to your team what the purpose of the consulting engagement is intended to achieve and their role in making it successful?
• Are you as a sponsor willing and able to provide authority for the consultants on the ground?
• Are you willing to spend time with your team and the consultants in the same room, to work out issues, questions, strategy and tactics as they evolve over time?  Don’t think you can just punt and run.
• Do you have committed resources on your team to help with knowledge transfer?  This is not an “all other duties as assigned” task for your staff.
• If consultants will replace or supplement existing staff, is your staff aware and comfortable with this?  This will inevitably become a problem if the expectations are not managed upfront.
• Are IT and Business ready to start working together?
• Do you have true business users and are they ‘on board’ with your project?
• Is there a way to prioritize issues as they come up?  One thing all consulting engagements do is bring to light an unsightly set of issues that become obstacles to progress.
• Can you be honest about your culture? Are their repeated patterns or behaviors that could sabotage a key project?
• Can you comfortably “park” issues that are not showstoppers in order to move ahead despite them?

There are probably many more items I could include on this “preparedness checklist.”  The point is that consultants can often be perceived as disrupting the natural order of things.  Either you, as their sponsor, will need to introduce them and guide them through the organization to ensure they are effective, or you need to clearly delegate to your staff what the expectations are for them to do the same.  If technical knowledge transfer needs to occur, don’t just assume it will happen.  I have seen too many consultants spend the first few weeks twiddling their thumbs either because they don’t have access to key systems, or they don’t understand the environment and haven’t been provided any documentation to work with in the meantime.  How much time will you allow for consultants to become proficient?

If the consulting engagement is to collect facts, conduct interviews, summarize findings, provide best practices, roadmaps or assessments then make sure they have a political lay-of-the-land upfront.  Otherwise, they will attend meetings they have no context for, they will assume things that may be incorrect, and they will be off-target in their recommendations. Also, many consulting firms sell their methodologies as separate and packaged products. If you expect your consulting firm to transfer its intellectual property as part of the engagement then your consulting contract should stipulate that. If you have secured the funding to bring consultants into your organization, you need to ensure that the project is a win-win.  The risks to you are probably larger than to the consultant group, because at the end of their engagement, they go away.  A good consulting firm will have ensured knowledge transfer along the way, but your staff carries some of the responsibility for that, too. 

If you’re considering or starting a consultant engagement, here are a few things to consider:

• Is your department/division receptive to advice or change?
• Are department heads, directors and managers on board with the engagement?
• If ‘best practices’ are recommended, does the department have the appropriate technical tools and agility to put them into practice?
• Have you done everything within your control to ensure the success of this engagement?

If the answer to any of the above is NO, then reconsider your readiness, regroup with your staff, and discuss alternative strategies with the consulting group you are working with.

If you have an opportunity to change and improve your department, leverage the effort to instill that change.   You may not get more than one chance.

photo by mykpwedding via Flickr (Creative Commons License)

---

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.

A Plea to the Engineers

By Stephen Putman, Senior Consultant

I am a computer engineer. I have been a computer engineer for over twenty years. I know a lot of other computer engineers. I have seen many techniques for implementing Business Intelligence systems, with varying degrees of effectiveness.

I have a simple request of my fellow engineers:

Please stop designing functions into your analytical applications without input from your business users.

It is a simple request, one that should be easy to understand and implement. Unfortunately, I have seen many companies where this idea is central to the fabric of the IT organization. Non-business managers are confident that they know what the business needs, either through hubris or a soured relationship with their users. Functionality is designed and developed that bears little relationship to how data is consumed and used in the business organization, usually without regard for the cost of development and maintenance of the resultant structures.

It’s easy to determine that this is happening in your organization - you attend meetings where the following phrases are used with increasing frequency:

“I think this is done...”
“They will need this eventually...”
“We didn’t think of that...”

We live in an age where the Business Intelligence projects that are completed are frequently over budget, late, and do not serve the needs of business users (too many projects are cancelled or abandoned as well). Much of this failure can be attributed to communication issues between the business users and the system implementation team. The system team means well by trying to fill in the gaps, but this often leads to frustration, uncertainty, and design based on hearsay. They really should try to resist that temptation.

How much more effective will your system be if you ask your users what they want, instead of guessing or assuming you know better?

photo by Wonderlane via Flickr (Creative Commons License)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at information-management.com.

The Change Paradox

By Carol Newcomb, Senior Consultant

Change is hard.  How does your company manage change?  How do you personally respond to change?  Why does it seem like everything changes at the same time, or that it’s never-ending?  How can you possibly do your daily job while incorporating all the NEW ideas and NEW technologies and NEW demands on your time?  When are you supposed to get a chance to actually think about the purpose of changes, and figure out how to put them all together into a manageable pattern?  Sometimes it just seems like all too much!

I recently worked for a few years studying patient safety in hospitals, and collecting a lot of data from across the country on types of errors.  Humans, it turns out, are very adaptable, but also very entrenched in our learned patterns of behavior and physical agility.  By this I mean that things like driving a car, while initially quite challenging (remember how to slip the clutch while starting from a dead stop on a snowy uphill slope?) become simple with repetition.  After a while, you don’t even think about all the little steps involved, and you just quickly let out the clutch, gage the slipperiness of the slope, and adjust the gas.  No problem.  And when some smarty-pants (like your husband) tells you you’re doing it all wrong, the response is undoubtedly scornful.  Such is most people’s response to change.  “I can handle this myself, thank you very much.”  Remember your first response to having to use a mouse or a keyboard?  Several doctors I know were not too tickled.

And yet humans are also very adaptable.   The literature on patient safety, and use of other technologies for that matter, document how once the brain stops consciously THINKING about how to do something, the subconscious brain kicks in and takes over, instinctively executing each step of a process without needing to affirm the need for each particular step.  It becomes part of a repeatable pattern—like lifting a beer mug without spilling a drop—or speaking a different language—that you can do without conscious or deliberate parsing of each micro-step.  With enough time and practice, humans can adapt pretty well.

As consultants, what we work on with clients ALWAYS entails change.   And here lies the paradox.  While most clients look for consultants to make recommendations—to help them  with things they are challenged with, to provide expert advice, to design a new way of managing their business, to recommend new technology, to train staff on new ways of collecting information, etc.—the ability to consume that advice or to incorporate new practices is tempered by the organization’s sensitivity to the impact such changes will have on their environment.

How many times have you heard, “That’ll never work here; our culture just isn’t like that” or “That may be a ‘best practice’ but who has time for all the extra work?”  New ways of doing things may be good ideas, but deliberate attention needs to be spent on incorporating them, digesting them—so to speak—so that they are not only accepted, but willingly practiced and even improved on over time.  The biggest risk, when we leave a consulting engagement, is that the organization will simply ignore or reject our suggestions, and go back to business as usual.

This is the Change Paradox: Change is good, but change is bad. Change is hard when there is too much change at the same time.  Change is necessary, but it can be overwhelming and destabilizing, especially if it compromises the work at hand.   Change can be refreshing if the purpose and the steps are broadly understood and accepted, otherwise it can be a needless waste of energy that ultimately accomplishes nothing.  Change can introduce new ways of thinking about the business and smarter ways to achieve business goals, but if can feel like chaos if not managed in digestible increments.

As you embark on a new project or a new set of practices, take the time to enlist the understanding and acceptance of those who will be most impacted by the proposed changes.  Provide the time, the training, the leadership vision and purpose, and the support resources to ensure that all the ‘newness’ can be incorporated, repeated and rewarded.  Change is simple, but it’s also complex.

Image by Rafa Garcés via Flickr (Creative Commons License)

---

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 and Business Alignment Begins with Listening

By Robert Stone, Managing Consultant

A lot has been written about the topic of IT –business alignment. We see it in action at our clients all the time. Baseline even offers a course on the topic.  I’ve made certain observations about it in my client work over the years that I’d like to share in this blog post.

We find that business intelligence projects are often the optimum way for companies to achieve tighter IT-business alignment. That’s because IT - business alignment will succeed only if you’re solving a business problem.  IT should not show up at a meeting with business users and recite a laundry list of everything they can do.  They should also avoid discussions of technology or existing reports. Instead, they should ask the business what their problems are.  Stakeholders actually enjoy describing what is preventing them from achieving their strategic goals or, at an individual level, what is preventing them from being more productive in their daily work.  IT should listen to the concerns of the business stakeholders and then determine how they can help in an effective manner.   Successful projects will become more frequent because IT already knows the business problems in detail before the project ever begins.

photo by Orange_Beard

Alignment is really all about building a relationship of trust.  If you constantly help business find reasonable and effective solutions then they will trust you.  Trust is also doing what you say—much easier with a set of articulated business requirements in place—and this requires good data management and business intelligence capabilities.

Alignment is not about pitching the business on a new project, the latest BI tool, or the latest methodology. It’s about establishing rules of engagement that can only be followed after earning the stakeholders’ trust.

---

Robert Stone has been with Baseline Consulting over 9 years and is a Managing Consultant responsible for leading and managing large and small projects.  He has over 25 years of IT experience with a diverse knowledge and skill base, and he's focused his skills on using technology to empower business users in many industries.

BI Development: Wrong Processes and Best Practices

By Bob Newell, Senior Consultant

One phenomenon I’m seeing with clients’ business intelligence development groups is IT relying on a one-size fits all development method. And the end results never seem to satisfy the business users, who are likely funding the project in the first place.

Any experienced developer asks the questions: “Who is my customer, and what’s the end product I’m expected to deliver to that customer?”

For a Software Development Life Cycle (SDLC), you’re trying to support a business process or a business operation. Whether it’s an application for data entry, a call center, or a network application that’s moving data from one part of the company to another, it’s all about the business processes and operations.

In the case of BI, you’re really trying to build an analytical environment. You need to understand what business initiatives need analytics, what questions your business users are asking, and what data is needed to support the answers to those questions. These types of issues are very different than those in standard application development, where the resulting functionality is much more straightforward and easy to articulate.

At a simple level, developers of both operational and analytical systems should understand the same concept when choosing a development method. Are you automating a business process? Then perhaps a standard SDLC is fitting. But if you’re building an analytical environment, a specific BI development lifecycle is the likely ticket to success.

---

Bob Newell is a senior consultant at Baseline. He has spent his career bridging technical and business disciplines, focusing on the effective utilization of data to advance strategic business objectives. This includes domain expertise in many technical disciplines such as database architecture, data presentation, CDI and ETL strategies, and enterprise architecture. Bob also manages the development of BI Application Portfolios and Business Requirements.

The Truth About Business – IT Alignment

By Robert Stone, Managing Consultant

Business and IT alignment is unquestionably important. But there are systemic reasons why it is seldom easy or consistent.  Alignment may occur for a period of time but the natural forces that push and pull on Business and IT cause drift.   Business wants flexibility, low cost, low risk, lots of little projects now, and at the same time big projects soon.  IT will often agree that it should be aligned with the business but the reality is that IT requires stability and mature processes, which often work against the business needs.   The simplest project often lasts from 3 to 6 months, costs hundreds of thousands of dollars, and requires many people.  IT is faced with maintaining and supporting the existing technology infrastructure with no downtime and risk to the business but also in quickly meeting the constant demands from all over the business for changes to existing systems or new systems.

In our client work, we’ve observed that the key to a tighter working relationship between the business and IT involves two practices. The first is a well-understood and easy to communicate program plan—for instance, a BI application portfolio that is sanctioned by the business, and drives the BI development pipeline. The second is a formal and regular requirements gathering process that allows IT and the business side to consistently and predictably engage one another in an ongoing conversation of problems and solutions.

Each of these is not only a predictor of business-IT alignment, it’s also a precursor to project success.

---

Robert Stone has been with Baseline Consulting over 9 years and is a Managing Consultant responsible for leading and managing large and small projects.  He has over 25 years of IT experience with a diverse knowledge and skill base, and he's focused his skills on using technology to empower business users in many industries.