In the Field with our Experts

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.

The Role of Logical Data Models

By Caryn Maresic, Senior Consultant

Logical Data Models (LDMs) were the standard means of recording business rules and data definitions back in the ‘80s and ‘90s.  Business and IT partnered to learn the art of data modeling and 3rd normal form in hopes of finding a common ground to record requirements.  Over time, it became evident that in today’s fast-paced development environment the business doesn’t have the time to digest all the nuances in a data model.  It is IT’s job to gather information via interviews.  Many times, we skip the LDM task because we don’t have time and LDMs are too academic and we find ourselves asking…

Are Logical Data Models really necessary?  Yes!

LDMs drive BI design by defining business rules independent of physical implementation.  There are many tools (CA ERwin Data Modeling, Embarcadero Technologies), and techniques (UML, IDEF, Bachman) in use today. To illustrate the difference between the benefits of a PDM and an LDM, let’s look at an example:  Customer/Address relationships.

The PDM above (created using) supports many Customer/Address business rules, but it does not tell me the Customer/Address relationships as defined by the business.

In contrast, the following LDM is more rigorous and definitive:

What does the LDM above tell me that the PDM did not? 

• There are two types of Addresses – Physical and Mailing.
• The Customer Bill To Address can be either a Physical or Mailing Address
• Customer Ship To Addresses must be Physical Addresses.
• Every customer must have a Bill To Address.
• A Customer has zero, one or many Ship To Addresses.

All of these relationships can be implemented using the PDM, but they aren’t dictated by the PDM.  The LDM explicitly defines each relationship and prompts us to ask better questions of the business, such as:

• Are there any Customers who do not have a Bill To Address?
• Are there any Customers who do not have a Ship To Address?
• When there are multiple Ship To Addresses, how do you know which one to use?
• Are there any Customers who have more than one Bill To Address?
• Do you know of any upcoming business initiatives that might change these rules?
• Was there ever a time when the business rules were different?

The answers to these questions may require changes to the model, but without the LDM, we may not have asked the right questions!  The best part about the LDM is how valuable it is to the rest of the development process.  It will be used in production of training materials, test plans and test cases, data profiling and migration efforts and, finally, physical database design.

---

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.

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.

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.

BI and Data Warehousing, and the Role of Business Analyst

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)

---

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. 

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.

Facilitating BI Requirements Workshops

By Fernando Martinez-Campos

 
photo by faster panda kill kill

In this post we will explore ideas for facilitating BI requirements workshops with a group of users. The main goal of requirements discovery workshops is to identify initial BI requirements with key business stakeholders. These sessions start with open ended questions which evolve into detailed requirements. As a facilitator your responsibility is to keep the process on track so business value is derived from the discussions.

The earliest preparatory steps require that you identify the audience participants, create an agenda that will spark interest and schedule the meetings. You will also need to appoint a scribe, who will record the proceedings and capture the output (the facilitator can rarely do both jobs well). I find it useful to also have an initial set of prepared examples that show the progression of an idea into actual requirements. By showing these examples early during the first meeting, you will show stakeholders what the desired outcome of requirements gathering looks like.

Some common steps  in a BI requirements discovery session are:

• Brainstorming ideas – This is the open ended part of the discussion
• Categorizing ideas into business function – This step organizes ideas into groups
• Associating business functions - The groups are related together
• Defining business questions – Initial business questions are chained with follow on questions
• Refining detail requirements - This step translates the questions into detailed requirements
• Prioritizing requirements – Ranks the requirements in order of importance

Let’s use these steps with an example of how these facilitated meetings were conducted at our electronics manufacturer client. The main objective was improving the repair process using BI analytics. The initial session had about eight stakeholders in attendance.

Several categories were developed that had business requirements:  products returned, centers where repairs took place, tests performed, and repair actions. We developed the categories into associated business functions: for example, the Test category had related tests to test results which were associated to the Repair category with repair actions. We continued chaining more questions if the repair action yielded defect trends. By looking at how these business processes were linked, we could track the progress of the workflows in the repair process.

We published the requirements of these workflow activities along with the required data that was needed. On the next session we reviewed, adjusted and agreed on the requirements. Then it was time to prioritize which requirements needed to be implemented and created a roadmap of BI projects.

The BI requirements workshop reaped the following benefits:

• Established solid alignment between the business stakeholders and BI developers
• Documented requirements of the repair process and its analytics
• Reached early stakeholder consensus of the requirements
• Provided visibility on the agreed priorities to set the right expectations
• Provided a forum to communicate feedback and potential risks

As the BI stakeholders gained confidence in the combined effort, follow on sessions became easier. In fact, follow on BI requirements sessions  managed themselves!

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.