In the Field with our Experts

Every Story Has a Beginning, a Middle, and an End

By Mary Anne Hopper, Senior Consultant

When not at work, I enjoy racing sailboats - sometimes day racing and sometimes offshore racing.  Last year while racing from San Diego, CA to Puerto Vallarta, Mexico, we spent a considerable amount of time drifting off of Cabo San Lucas in absolutely no wind.   In the middle of the night with no wind, conversation tends to drift to stories amongst the team on watch.  Call it a lack of sleep but some of my stories made complete sense to me but not to my two watch-mates.  So they told me, “Mary Anne, every story has a beginning, a middle, and an end – now why don’t you start over from the beginning?” 

That line has become somewhat of a joke since that day and night spent off Cabo.   But, one of the interesting places it plays in my mind is the BI Requirements process.   That process can be broken down into three steps – business, data, and functional requirements.  A beginning, a middle, and an end.   Starting at the beginning with business requirements sets the stage for what business questions need to be answered ensuring value is delivered.  Data requirements can be gathered to support those business questions.  In the end, that functional requirements can detail how to access that data. 

Oftentimes, I see clients start with a set of functional requirements with no idea of whether or not they can be delivered with available data or what business questions they will answer.   This approach can take the project down one of two paths.  The first is back-tracking back through the requirements process that inevitably takes the project team longer to deliver because they start over with each step backwards.   The other path delivers the functional requirement but only with work-arounds (logic built into reporting, extra spreadsheets, new desktop applications, and so on), also a costly alternative when others try to support or extend functionality.  Neither of these approaches deliver the needed business value with the agility required.So when you’re planning your next BI deliverable, remember that every story has a beginning, middle and an end.  Start at the beginning with the business requirement, work forward to the middle data requirements and then the functional requirement at the end and you’ll enjoy the success of a story well told.

photo by Gabriel Villena via Flickr Creative Commons License

---

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.

Portfolio Management and BI

Below is an excerpt from the white paper Planning Your BI Program: A Portfolio Management Approach by senior consultant, Kimberly Nevala. In this white paper, Kimberly discusses ways in which your BI Program is, in many ways, very similar to your personal financial portfolio, and how, by applying some of the same principles you apply to your own finances, you can create a sustainable approach to optimize and capitalize on your corporate information. You can download the full paper here.

Portfolio Management and BI

In a very real sense, your BI program is an investment akin to your corporate or personal financial portfolio. It is multifaceted, dynamic, and subject to sometimes unpredictable internal and external pressures. Just like a financial portfolio, BI represents a significant, strategic investment and requires a similar level of discipline relative to its ongoing, deliberate management and control.

Figure 1: Balancing BI Investments

As seen in Figure 1, taking a portfolio management approach to BI implies we must continuously:

• Understand business strategies and objectives
• Monitor internal business performance, as well as external industry and economic trends
• Identify business opportunities and needs
• Balance opportunities against available capital, enterprise resources and risk/reward ratios (aka ROI)
• Deploy appropriate business intelligence capabilities to confirm and/or capitalize upon selected opportunities

In the investment parlance, portfolio management can be active or passive. Immature BI programs tend to focus on passive—or reactive—capabilities. They are focused on basic reporting about events that have occurred and simple analytic extrapolations. They are usually based on ad hoc requests and lack of user prowess with toolsets. Mature BI programs include (pro)active capabilities such as forecasting, predictive analysis and data mining. In addition, these capabilities—or outputs thereof—are integrated into the business’s decision-making and management processes.

Continue reading here.

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

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.