In the Field with our Experts

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.

What Makes Healthcare Data So Different

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

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:

• Highly Influential
• Visionary
• Mover and Shaker
• Supporter
• Naysayer
• Politically Necessary

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

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

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.