In the Field with our Experts

MDM and All That Jazz

By Rob Paller, Consultant

Recently, senior consultant Bob Wall mentioned building the team as one of four proven starting points for getting your MDM program rolling. By now, you have probably identified the C-level executive experiencing the most pain as a result of working with unmanageable data. You have even gone so far as to identify a small project that allows you to demonstrate the value that MDM will provide the company.

However, the success of your MDM pilot project and overall MDM strategy will come down to the team you assemble to support it. Interestingly enough, there are a few parallels that can be drawn from what makes up a good jazz ensemble that can be applied to building your MDM team. Every musician must possess a core set of competencies—just like employees possess in order to do their jobs. However, in order for a jazz musician to excel, he must possess an additional set of skills that is, for the most part, unteachable, but enables him to reach a level where his inspiration and creativity matches his ability to execute. 

• A jazz musician must be a virtuoso of his instrument in order to communicate what he visualizes in his mind instantly through his instrument. An MDM team member must be a subject matter expert with an innate technical understanding of the source system or a similar understanding of the business processes surrounding the subject matter.

• A jazz musician must possess a trained ear that is not only able to identify something being "in tune" or "out of tune," but hear the melodic structures and chord progressions. A soloist must be able to adapt to the piano player making chord substitutions underneath the soloist's performance. Any member of your MDM team needs to be able to find the nuances in the business when it comes to defining the core subject areas of your business. For example, defining what a "student" vs "alumni" vs "donor" means to your university.



• Many jazz musicians are able to recall hundreds of songs at a moment’s notice—not only the melody, but the chords as well. Your MDM team must understand how and be able to explain the countless business processes and policies surrounding your master data.


• A good jazz musician must be able to listen and interact with the group in the present moment and contribute to improving the overall quality of the performance. This is one of the most important skills that an MDM team member needs to possess. The MDM team must be willing to listen to the rest of the business and communicate effectively. There are no ivory towers in MDM or jazz. 


Keep in mind when assembling your MDM team that it must be a balance of members from both the business and IT—much like a jazz ensemble consists of a balance among percussion, brass, and/or woodwind instruments. If you are unable to find a balance, you risk discord in what you produce.


photo by Fillmore Photography 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.

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.

The Natural Order of Things

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.

The “Temporary” Building

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.

Ready, Shoot, Aim: Gaining Control of Your Data

By Carol Newcomb, Senior Consultant

You’re already familiar with the common symptoms: rapid heart rate, shallow breathing, sweaty palms and jumpy behavior.  When you are asked to identify the strategy for information management in your organization, your mind draws a blank.  “So, I’m not the CIO.  Go ask him!”  When asked about the most reliable source for master data on customers or contracts or sales force, you mumble, “Try the ERP system.  That’s where I found it last time.”  Or if an outside contractor were to ask about your 5-year plan for information management and BI strategy, you shrug, puzzled.  “What good is a 5-year plan when I don’t even have a 1-year plan?  Leave me alone.”  Treading water is the mode of survival.

The single most common problem organizations face these days is too much data.  It comes from all directions for all sorts of purposes.  It comes from dozens of applications designed to fulfill specific functions.  It has grown over the years until reluctantly, one of the organization’s leaders says “Enough already!”   Data is now costing more to manage than it is contributing to informed decisions.  Data is not an asset, it’s a liability!  How did this happen?  It’s like a teenager’s fantasy: wanting and having, wanting and having, bright shiny objects, more and more, until the sobering realization sinks in that the dream is no longer just a dream—it’s a full-fledged nightmare! 

Information management is all about control.  Stop.  Step back.  Get some perspective.  Assess the true situation. Itemize what’s good and what’s subpar.  Think about what the organization needs to achieve.  Think about how the data supports those objectives, not how the organization manages despite its data.  Data management is a deliberate, stepwise set of practices designed to ensure that value can be extracted from the data, and that the overhead associated with poor quality, inconsistent definitions, unaligned source systems and discontinuous data management practices are orchestrated to work as a whole.  The objective is to deliver information value.

So how do you go about changing from ‘Ready, Shoot, Aim’ to ‘Ready, Aim Shoot’?  First, get ready.  Admit that survival is not a strategy.  Survival is survival, and it is getting more difficult to maintain your organization’s survival, much less its competitive edge.  Next, invest the time and resources in drawing that big ugly spaghetti diagram, an inventory of ALL the source applications, software systems, ETL points, staging systems, landing points and delivery channels.  Then, take a true inventory of the end-users.  This is critical, because this is where data begins to result in business value.  Take time to really research who does what with certain pieces of data.  Do they further augment it with external data?  Do they merge it with other internal or external data?  Do they modify it to match other data sources?  How much time do they spend cleaning, standardizing or massaging data?  Start to build your ROI equation.  Data Sources X Time X People = Business Information Cost.  How much is this really costing?  Where is the value?

As you learn more about how the business uses data, start to lay out a business value matrix (the other side of the ROI equation).  This will help prioritize your data management roadmap.  Estimate the amount of effort required to integrate each source against the perceived business value, and chart a business value/implementation effort matrix.  Consider drafting more than one, as this reflects perceptions more than actual fixed units.  Share this information with end users to validate it and socialize a plan.  Then start to lay out a tactical roadmap.  Aim!

Now you’re getting somewhere!  Having faced the ugly reality (Ready) and incorporated real-life facts from business end-users (Aim), you can start to craft your strategy to streamline and rationalize the multiple data lifecycles supported by your organization.   Shoot!  Prioritize the data sources and systems to begin with, and estimate the expected value.  Launch your governance, metadata, quality and delivery resources, and engage your business users each step of the way.  Deliver value and repeat.  Evaluate the process, refine, and keep going.  It’s a deliberate, engaged, transparent and proactive approach, and it’s the only way you will ever conquer those adolescent nightmares!

photo by Erik Charlton (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.