In the Field with our Experts

Did You Forget Something? Gaps in Execution in Data Governance Programs

2009-11-05T06:00:00-08:00

By Carol Newcomb, Senior Consultant

Somewhere along the way to understanding the whole data governance thing, someone forgot to mention that data management really is central. Did I say Mention? I really meant Emphasize. Urgently Emphasize. Data management processes are critical to the establishment and maintenance of a data governance program.

The thing is, data governance is quite impossible without a fundamental data management process that provides tactical direction. For example, if you have a bunch of people running around acting as data stewards, asking people questions about metadata, source systems, definitions, use of data and implications of sharing it, what happens when they have to write a policy? And when data stewards meet as a group, how can they describe the magnitude of issues to discuss with their users? How do issues get prioritized? How can anybody decide who is accountable if due diligence hasn’t been paid to the fundamental source data issues, and how can decisions about governance enforcement be made?

Data governance should never be undertaken as a project. It is a long term program that needs to start with a foothold in core data problems, like the inability to use or share data. To get that foothold, stewards need to identify data quality and consistency issues that resonate with end-users. Find some tangible pain. This requires a sound set of data quality profiling activities to prove where conflicts or inconsistencies are most problematic, and a quantifiable statement of what the impact is. The problem needs to be quantifiable to get people’s attention, as well as to compare one set of problems against another. The data management program should have the capacity to routinely analyze and reveal data quality issues,and keep bringing them back to end-users to build a sense of urgency towards taking restorative and preventive action.

Data governance is all about People, Processes, Decision Rights and Controls. But before you can even begin, you will need to have identified the problems through hardcore data management practices. This involves understanding the data architecture, examining privacy and compliance mandates around data visibility and sharing, exploring metadata definitions and having the ability to make changes through sound data administration practices. Without these systems and roles in place, data governance is just a hollow shell.

photo by limaoscarjuliet (via Flickr)

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.

The Natural Order of Things

2009-10-29T06:00:00-07:00

By Dave Gilbert, Vice President of Field Services

Recently, it seems that every conversation with prospective clients at some point degenerates into an exploration of how much things can be “parallelized.” I suspect that this is being driven by two primary opposing phenomena: (1) a backlog of BI needs caused by the economic stall, along with monumental budget pressures; and (2) the hyper-speed of new competitive business pressures. While I am a huge proponent of iterative and parallel development efforts, forcing unnatural acts in planning a BI initiative can be a slippery slope when taken too far.

I am an extremely amateur woodworker in my spare time, and this discussion reminds me of a lesson that I learned the hard way – more than once. A few years ago, I decided to build some bookshelves for my home office. Being a planner by nature, I spent sufficient time drawing and designing how I wanted my bookshelves to look. I measured books, knickknacks, and various other things that I wanted either functionally or on display (I suppose you could call those non-functional requirements). I drove to my local lumber yard and picked out some really nice hardwoods and hauled them into my shop. I then spent many delightful hours cutting, sanding, shaping, and staining the various components of my shelves. Because I had to build some jigs to gain the effects I wanted for my shelves, it was much more efficient to cut and route them all in succession before moving on to other components of my design.

Somewhere along the way, my wife (perhaps the most important requirements stakeholder) poked her head into my shop and noticed that the elaborate hardware I bought was functional -- but “ugly” -- and she would much prefer recessed hardware that would be hidden from view. Being all about user satisfaction, off to the lumber yard I went. Unfortunately, this seemingly minor requirements change left my shelves an inch shorter than required and sent me into a redesign cycle which never really translated from paper plan to end product.

The lesson that I learned the hard way – other than the obvious one about gathering all my requirements upfront and getting signoff –- was that by attempting to gain efficiencies in my cutting, shaping, and finishing process, I lost the opportunity for learning through practical experience with my end product, ended up expending more energy, and had considerable cost overruns. Similarly, attempting to put unnatural parallel paths too early in a BI planning exercise can eliminate valuable learning opportunities for the design and development teams, and forces rework on multiple work products - instead of just fully rationalizing your design patterns, making sure they are complete, and then using those to componentize and parallelize your work. It often takes a BI development team one or two cycles of development and testing to get their design patterns fully fleshed out and capture some of the more subtle requirements. Parallel efforts prior to the opportunity for this bottom-up learning only open the door for multiple rework paths, cost overruns and project risks.

As one client has described to me, they are in a continual prototyping mode, but they never get to the “sausage factory.” What they mean by that is that every project is handled as a one-off, and iteratively developed until it is ready for production. But they never capitalize on the benefit of their experiences by operationalizing their processes and then componentizing the workstreams into parallel efforts. Every organization is looking for the magic of the sausage factory, but this requires the discipline to put repeatable processes in place and not to force unnatural evolution prior to its time.

Photo by antwerpenR via Flickr.

Dave Gilbert is responsible for managing Baseline’s consulting teams and ensuring consistent high quality project execution to support our clients’ business needs. Dave brings over 20 years of IT system and data warehouse project management experience, deploying systems for both global 1000 and smaller e-business clients domestically and abroad. He has assembled and led multi-national development teams to deliver complex, scalable, analytic solutions that have assisted clients in establishing competitive superiority.

What Makes Healthcare Data So Different

2009-10-22T06:00:00-07:00

Below is an excerpt from the white paper Implementing Data Governance in Complex Healthcare Organizations: Challenges and Strategies by senior consultant, Carol Newcomb. The more complex the healthcare organization, the greater the need for enterprise data governance. The paper suggests building a data governance program within the context of a unified framework and explains how. You can download the full paper here.

Use of data in healthcare organizations over the past two centuries has changed dramatically, and the sheer amount of data available has grown exponentially. The emerging number of specialized applications under one roof that inform clinical and administrative decisions keeps increasing. Advancements in scientific understanding and technological developments in diagnostic techniques, surgical options and pharmaceutical sophistication, as well as the overriding need to share information between provider organizations, regulators and insurer networks have put data management issues high on the radar of healthcare executives. Given the tight payer environment for cost control and increasingly competitive pressures to demonstrate quality while also maintaining privacy, the need for data governance in healthcare organizations has become acute.

What Makes Healthcare Data So Different

The very nature of healthcare business requirements makes the collection, storage and organization of the data highly complex. Requirements that guide data availability, for example, include:

Data should be available at the point of care, upon demand, to support clinical decision making regardless of the care setting (hospital ER, ICU, office setting, long term care, lab or radiology department, etc.);

Data should include patient-specific, longitudinal diagnostic and procedural information coded using standard classifications, terminology and modifiers;

Reference data (billing codes, diagnostic codes, lab and medication catalogues, etc.) need to refer to patient encounter dates, as these classifications change over time;

Data should include patient-specific family and social histories collected from the patient or through practitioner observation;

Data should include orders for tests and procedures as well as corresponding results, which may include specific values, images or written notes;

Data should be collected across different practice settings, practitioners and geographic locations;

All data should tie back to a unique patient regardless of the practitioner, care setting or location;

Data should be secure, auditable and available to practitioners, billing organizations and oversight bodies based on HIPAA confidentiality requirements;

De-identification of data should not remove the ability to link specific diagnoses, procedures, results and demographic characteristics to an individual patient;

Data should be aggregated at multiple levels, including encounter date, provider, provider type, facility, department, disease, procedure, result, outcome, geography, demographics, insurance group, and many others;

Clinical data should be linked to demographic data about the patient and family;

Financial payment and billing data should be supported through clear clinical documentation;

Staffing and facility operations data (inventory, equipment, rooms) should be available for analysis relative to patient encounter dates and provider data.

Given this subset of data requirements, consider all the transactional sources of data within a healthcare organization. Such a complex interaction system usually results in a “spaghetti diagram”—like the one in Figure 3 (below) that fully illustrates the pain of sorting through different clinical and administrative applications, and designing standards to link data from one system to other relevant systems for analytical purposes.

Continue reading here.

Managing the Informal Leader in your Project

2009-10-15T06:00:00-07:00

By Steven Bebout, Senior Consultant

As a former Officer in the US Army, I know the importance of leading a team, creating esprit de corps, and providing communications (upward and downward). Whether in a training exercise, in a forward area, or back in garrison, leadership and understanding are vital to achieve success and prevent dissension among the ranks (regardless of the mission).

You may ask, ‘what does this have to do with business intelligence’, I would say a lot. The project team is composed of many different players: Project Manager, Technical Lead, Lead Architect, Lead Business Analyst, along with many others. As in the military, these leaders set and manage expectations, create alignment with other leadership within their own company (or for consultants with the client). Working in a vacuum is not an option.

One player may emerge during your project is the 'informal leader'. The informal leader holds perceived or real power over rank and file and potentially higher level stakeholders in an organization. This persuasive and typically respected individual can derail a mission, project or change success criteria. This individual’s agenda and their influence with the rank and file can put a fork in the road to success in a military or a project in corporate America.

How do you prevent the emergence of an informal leader in your BI Project? You can’t; you can only manage them and bring them on board immediately! How do you do this? Prior to the project kick-off you are provided a list of interviewees; this list comprises individuals for a multitude of reasons. The project sponsors and leadership have identified the list; I assure you, the ‘informal leader’ is part of the list. Interviewees can be:

Under one of the interviewee types lies your informal leader; typically a naysayer. Manage their expectations, incorporate them within the decision-making process, and empower them. Remember to apply the adage of Sun-Tzu’s to "keep your friends close, and your enemies closer."

How have you dealt with informal leaders in your projects? Are there key triggers to identify this individual? If so, what are they and have you ever found there to be multiple informal leaders?

photo by The US Army 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.

Just Like Your Investments, Manage Your Portfolio for Better BI

2009-10-08T06:00:00-07:00

By Kimberly Nevala, Senior Consultant

Given today’s economy, companies and individuals alike are reevaluating their investments. Like many, I did the research when establishing my own investment portfolio. And things ran pretty smoothly for a while. And then we all know what came next. Market volatility aside, I realized something vital: Truth be told, I wasn’t actively managing all aspects of my portfolio. My bottom line paid the price.

And so it is with many BI programs. After an initial concerted effort, many clients find their BI investments faltering. Some start with basic enterprise or financial reporting solutions that fail to evolve. Some find initial data warehousing investments deliver a mountain of data, but a dearth of actionable information. Often, the BI team falters in the face of an increasing avalanche of requests. Worst case, they never get off the ground. Too many needs. And no method to vet and prioritize them.

The answer: Manage your BI program like a portfolio. Wikipedia defines portfolio management as the process of “organizing both projects and programs into a single portfolio to ensure they are kept aligned with corporate strategy”. Underscore “kept.” To be successful, you must first define strategic and tactical business objectives, identify associated BI opportunities or needs, and lay out a roadmap for execution. Equally important is an ongoing process to both evaluate the effectiveness and relevancy of existing BI investments (a.k.a. reports and/or analytic applications) and proactively identify and prioritize new opportunities against evolving business strategies. The formation of a BI Portfolio, when done right, ultimately informs your BI development pipeline.

Today my investment portfolio looks vastly different from six months ago, let alone a year. It is more dynamic, requiring active management.

Your company’s BI portfolio is no less strategic or dynamic. Are you managing it accordingly?

Kimberly Nevala is a senior consultant specializing in MDM and CDI program planning, design, and governance at Baseline Consulting, a technology and management consulting firm specializing in data integration and business analytics.

The Value of a BI Scorecard Assessment

2009-10-01T06:00:00-07:00

By Robert Stone, Senior Consultant

A beacon in the night. A BI Scorecard is just that. And more.

Your team works hard. You have meetings. You go to the trade shows. Yet your business intelligence is not driving the business as it should. It’s lagging and it’s telling you what the history of the business was—and not guiding the business to better decisions. After many years of development and a lot of investment, you have the same reports you had five years ago, just nicer looking. What you need is a beacon to guide you, a scorecard on your business intelligence environment that points you to key leverage points that may be limiting the flexibility of your business intelligence.

Awhile back, I was part of a team to do a BI Scorecard for an insurance company. Business was dissatisfied with the quality and agility of the business analysis reporting. IT was swamped with report requests and changes to the data warehouse and had little bandwidth to step back and take a fresh look at their BI environment. It’s the ol’ can’t see the forest for the trees adage. Nobody’s to blame, but it happens all the time and it often takes an outsider to see the root issues.

Business and IT both agreed to bring us in to interview business users and IT staff. We focused on six core areas and did a comprehensive set of interviews—plus we did an analysis of their documentation and reports to verify that what we were told matched their actions. In practice, Baseline’s BI Scorecard is all about measuring the right things in the real world—not what it should be if the world was perfect. That is why we take into account the maturity level of the organization and develop an action plan for moving forward that matches the client’s abilities.

In the end, we met with everyone involved to present our findings. These meetings are not meant to be a blame game; they’re a learning experience. Each person, at some point during the meeting, was surprised by the findings, but all were told often that they were doing a great job under the current conditions. We worked out a series of next steps and milestones with them. It was a win-win for business and IT, and a year later, they had reached a new level in their business intelligence reporting.

photo by Tony The Misfit via Flickr

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.

Where’s Your Stuff? The Importance of BI Program Artifacts

2009-09-30T06:00:00-07:00

By Mary Anne Hopper, Senior Consultant

Do you have young kids with toys with little pieces all thrown together? Do you have boxes of organized holiday decorations but every year the hangers or replacement bulbs are missing? Do you have a Tupperware cabinet that is a constant juggle matching containers and lids? Is your toolbox organized but the smallest screw driver lives in the kitchen junk drawer?

Now let me ask the same types of questions a different way: Do you have a repository for your BI Program documentation? Is it complete? Can you find what you’re looking for? Or, do important artifacts needed to support and grow the application exist in many different places?

Oftentimes, I see important BI documents buried in project folders. This can be everything from database design to ETL design to source-to-target to data load scheduling. Case in point, at a recent client, I asked to see a complete source-to-target artifact so I could add on to it for a second phase of a BI initiative. I was given a link to a spreadsheet in a document repository and then two additional links. The entire source-to-target picture of the environment was already stored in three places with the intent to create yet another one. The client’s reasoning? They didn’t have access to the right tools and all project artifacts had to exist in a certain place in their taxonomy for the project to be complete.

While many BI vendors offer knowledge management tools for BI projects, most of our clients are stuck with spreadsheets in the short-term. My recommendation to the client was to merge the various spreadsheets together and put them along with the accompanying program level documentation in a centralized location. That way, one artifact could be utilized by future projects, resulting in reduced time and effort for next imitative. And if they didn’t, important documents would continue to spread through their directory structure and future project teams would spend more and more time with each new project—as they tried to piece together what the application looks like and where their project needs fit, resulting in longer implementation timelines.

Next time you’re kicking off a BI initiative, take some time to think about what others need to know and what they need to find. Be deliberate about creating—and annotating—your knowledge management system for BI. Some organization, process, and consolidation upfront will save you time the next time around.

photo by e0nn via Flickr

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs. She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

The “Temporary” Building

2009-09-24T06:00:00-07:00

By Stephen Putman, Senior Consultant

I was walking my dog on a sunny morning recently when we cut a path through my daughter’s middle school. I saw a group of temporary buildings attached to the main wings of the school, operating as additional classrooms. These new buildings were made to appear to be integrated with the existing classrooms, but it was obvious that they didn’t quite fit.

I thought back to my own years in middle school in the 1970s. My school was a recently-converted elementary school, and there were several temporary buildings constructed to provide facilities appropriate to a middle school, just like at my daughter’s school. I went back to that school a couple of years ago, and those temporary buildings were still there, 35 years later. I thought, “Aren’t these building called temporary for a reason?”

I believe that these buildings are still being used well past their original lives because of short-term, tactical thinking - it’s easier to keep things going as they are than to endure short-term disruption to build more long-lasting, integrated structures. Years of this tactical decision-making extend the lives of these buildings, even though it is likely that it is more expensive to maintain these buildings than the cost of erecting solid and permanent structures.

This reminds me of some data warehouses I’ve seen at our clients. Their enterprise reporting capabilities are built like these temporary buildings, with mismatched parts that are not integrated and often maintained at a higher cost than a solid, foundational system. I have seen many instances of reporting systems that are maintained constantly, manually, and reactively, nursed along over the years in the mistaken belief that maintaining these systems are less costly than building a permanent, integrated system, ignoring the cost and synergy benefits.

Don’t spend your time, effort, and money maintaining temporary structures--they may stay around much longer than you intend, and cost you much more in the long run.

photo by teofilo via Flickr.

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.

MDM and the Psychology of Data Management Maturity

2009-09-17T06:00:00-07:00

By Bob Wall, Senior Consultant

I recently read an interesting article on the web entitled “Ascending the Data Infrastructure Hierarchy: The Five Stages of Data Infrastructure Maturity."¹

In it the author discusses Maslow’s self-actualization psychology² and the Hierarchy of Needs (further information here) and creating an enduring Data Management Infrastructure. I believe it has implications to achieving data management maturity, which is a fundamental ingredient for MDM success.

As Baseline partner Evan Levy has explained in his MDM presentations, MDM is comprised of both “(Master Data) Management—capabilities to support master subject areas such as Customer, Product or Account—and Master (Data Management), in other words sustaining data management via standards, guidelines, and procedures. This includes the following Data Management functions:

Data stewardship
Data architecture, analysis and design
Database administration
Data security management
Data quality improvement
Reference/master data management
Metadata management

In trying to better manage these data management functions, reach an optimal level of data management maturity, and support a successful MDM implementation, Maslow’s hierarchy of needs and self-actualization psychology provides some helpful insight. In his epic psychology writing, Maslow organized human need into three broad levels: first, the physiological - air, food and water; then the psychological - safety, love, self-esteem; and finally, self-actualization. His insight was that the higher needs were as much a part of our nature as the lower, indeed were instinctive and biological. Maslow's greatness was in re-imagining what a human being could be.

The following schematic shows Maslow’s Hierarchy of Needs and an analogous Data Management Hierarchy.

Maslow’s Hierarchy of Needs and an analogous representation of a Data Management Hierarchy

We can see the 5 areas of the Data Management Hierarchy, mimicking Maslow’s Hierarchy of Needs, as follows:

Level 1: Tribal – Basic Needs (survival)  
At this level, an organization functions from day to day, but without any formal processes or systematic management. Instead, data management is left to the decisions of knowledgeable and skilled individuals.

Level 2: Enforced – Safety Needs (comfort) 
As a company advances to the next level of the Data Management Hierarchy, the Enforced stage, it begins to adopt some semblance of governance, which includes documented standard operating procedures and putting in place change controls to better manage workflow within its data environment.

Level 3: Standardized – Psychological Needs 
As organizations advance from the Enforced stage to the next level, they reach the Standardized stage, in which, as the name suggests, processes are established to handle various aspects of data management and less importance is placed on individual decision making.

Level 4: Actualized – Self-Actualization
 In the Actualized stage, organizations are able to start getting more creative with their data. Data can be extracted from across the enterprise - as well as from outside sources - and combined to create useful information and made actionable to create new knowledge and value added business propositions.

Level 5: Peak Performance Peak Experiences 
At last, the organization reaches the height of data management development, where it can devote all its resources to high-level strategic initiatives, rather than administrative issues.

MDM success is directly proportional to how well an organization integrates data management principles and reaches a peak performance/experiences maturity level. Hence we can see the possibilities of the gradual application of Maslow’s Psychology of the Hierarchy of Needs, leading to the ascendance of data management maturity and re-imagining what a successful MDM project could be.

¹ John Bostic, Ascending the Data Infrastructure Hierarchy: The Five Stages of Data Infrastructure Management Maturity (Auerbach Publishing, 2007).
² Abraham Maslow, A Theory of Human Motivation (Psychosomatic Medicine, 1943).

Bob Wall is a senior consultant with Baseline Consulting. He is an information technology specialist with 30 years experience in all areas of data warehouse administration, data architecture, data resource management, training, and applications systems development, as well as in corporate management.

BI and Data Warehousing, and the Role of Business Analyst

2009-08-27T06:00:00-07:00

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)