BeyeBLOGS | BeyeBLOGS Home | Get Your Own Blog

November 22, 2010

Five thoughts for approaching DQ with a level head

1. Unless there is clear value (as defined by tangible outcomes that can be measured against stated business goals), there is no need for a massive DQ software solution. In fact, do not assume a specific solution of any sort. You DO need DQ measures (in order to assess size and impact of issues AND to monitor improvements over time), but this can be done using manual or semi-automated data profiling techniques. Data profiling tools are much cheaper to purchase (some are free) and carry little to no ongoing management overhead while enterprise DQ tools are very expensive. Follow the value. Move from profiling (to identify scope and location of most valuable issues to address) to these larger tools IF necessary.

2. Create data stewardship (ownership) from the audience. That is, get the business people involved up-front and then have a clear set of accountabilities that do not take an exorbitant amount of time. Have the interested people who use the data responsible for keeping an eye on the DQ. Then have a simple process for prioritizing any initiatives that come out of issues that arise so that the business defines DQ projects.

3. Do not initiate any DQ improvement projects without a context. This is not the same as attaching all DQ to a project and ignoring all other DQ (to bite you in the behind later). But the question of value should always drive DQ priority and the amount of time and effort to be expended. What specific business outcome or goal is going to be advanced if we improve this or that DQ issue?

4. Resolve any new or ongoing DQ issues in the most simple, cheap and effective manner. Is the best solution even an IT solution or can the issue be resolved through process changes? Are the people involved in the process clear on the value to them of making the change? Will process changes actually create better long-term DQ improvements than an IT approach would? If there needs to be an IT solution, be sure there is a clear method in place for communicating needs from business to IT.

5. Keep it simple! Do not create unnecessary process, software, documentation or meeting overhead where there is no clear added value! Drive all your activities from the goals and intended outcomes. Try to create a solution that is practical, doable and for which the participants can see the value for themselves.

Expertise required:
For improving and maintaining DQ for the purposes of valuable BI you need an understanding of the business goals, an understanding of the business processes, and an understanding of the way data can be used to drive business outcomes.

The IT skill sets required are much less critical and will be determined from the business requirements. It may be quite simple profiling skills (which is more about analytics than IT). On the other hand, especially in large enterprises, there may be a need for someone who can set up and maintain a full-scale DQ software system and related processes. But mainly, the management of the business data stewards, the DQ monitoring (by business), the project prioritization, and the assessment of solution are the key zones of expertise required.

Kelly Lautt North Star Business Intelligence Listen to our Advocates of Value podcast on iTunes

Posted by Kelly Lautt and John E West at 1:30 PM | Comments (0)

April 21, 2010

Successful BI Requires Data Readiness

The first area of risk in BI is that of poor data quality, availability and readiness. Too often this risk is ignored, under-managed or addressed indirectly with enterprise-wide data modeling. It seems that business users usually believe that "the data is good" in their system and BI project teams want that to be true. Perhaps this is why the risks around data readiness are ignored.

But data readiness from the perspective of supporting BI that has true business value is not the same as data quality. For example, one of the first things that needs to be tested is whether or not the data actually contains the answers to the questions being asked by the BI project. A few SQL statements cannot guarantee that this is the case.

Another common example is that disagreements about data definitions or simply data with similar names meaning different things in different systems can cause the illusion of bad or wrong data.

Many other more traditional forms of data quality issues can also be problematic. Historical reach may not be long enough; the data may be incorrect, missing or incomplete; the data you need may not be collected at all; data from different source systems may not be conformable, etc.

Having a a clear understanding of what questions need to be answered (BI goals) and profiling specific data to determine "data readiness" for a specific BI objective is a great approach. Knowing the reality of actual data readiness helps to focus attention on the things that are possible and avoid wasting time on things that are not.

If data readiness is ignored, your BI project spends time designing models that can't be filled, reports that can't be built, KPIs that can't be trusted and outcomes that don't provide value.

Kelly Lautt North Star Business Intelligence Listen to our Advocates of Value podcast on iTunes

Posted by Kelly Lautt and John E West at 4:45 PM | Comments (0)

March 21, 2010

Delivering Data Is Not Enough

The history and often conflicting definitions of Business Intelligence are such that many organizations still hold on to one or more dangerous fallacies concerning everything from who should run BI initiatives to what real value BI can actually offer and how.

BI has largely emerged from IT-driven work of extracting data from source systems and building data warehouses. There are still many organizations in which BI is run by IT. IT's goal is to get the data out to the business but their focus is on the technical solution development and the software. This focus often leads to general unhappiness: business feels that the data is irrelevant or difficult to understand; IT feels frustrated that business is unsatisfied. This scenarios tends to produce a lot of confusion and results in significant adoption problems with managers wondering why people aren't using their expensive BI or reporting solutions.

It was a huge step forward when organizations began to understand the importance of involving business in the initial goal-setting, requirements collection and data presentation design. This approach helps to involve business users and sometimes creates a better solution design (better in its ability to get the right info to the right people to support decisions). However, the "BI solution" is still a set of reports, usually emailed to users with little additional context or guidance.

The problem is that seeing the goal of BI as simply delivering data to people (the laziest version of "decision support") ignores the human and process factors that will move BI past an initial project success into a program that guarantees ongoing and business-driven expansion, adoption, support, evolution and value. Real success and value in BI will be realized through:

  • strategic planning and goal alignment

  • common data definitions

  • data quality optimization

  • actionable data presentation design (to drive behaviour)

  • data integrated into processes

  • training, change management and communications

  • ongoing value optimization through collection, prioritization and management of requirements.

Only recently is this point becoming clear to even very experienced BI professionals and industry analysts such as Gartner: see article here.

In order to speak intelligently about immediate and ongoing Business Intelligence (BI) value, BI must be seen and spoken of in a holistic manner rather than as a set of technical and end-user solutions. A holistic view is like saying that Customer Service is not just the CRM technology, which is clearly obvious and universally accepted. By understanding BI in a holistic manner as a set of ongoing strategies, systems and processes designed to optimize the value of your critical data in pursuit of business goals, we can gain clarity around how to organize, plan and run successful initiatives as well as how to assure and measure success over time.

Kelly Lautt
North Star Business Intelligence
Listen to our Advocates of Value podcast

Posted by Kelly Lautt and John E West at 2:30 PM | Comments (0)

March 10, 2010

Iterate, Prototype, Deliver Value

The standard "Rigid" model

Business Intelligence projects are complex endeavours with far-reaching goals. BI projects include myriad themes from corporate strategy down to intricate technical details and include users from different business areas with unique needs from data of inconsistent quality. With this level of complication many organizations choose to approach BI projects with an enterprise-wide focus and long planning cycles to avoid mistakes, missteps and costly diversions.

Unfortunately, many BI projects with extensive scope and long cycles of planning deliver limited value, take longer than expected, cost more than budgeted and are less likely to be adopted by users. A better alternative is to adopt an agile approach to delivering BI value.

Rapid iterations
Agility in BI delivery (for which the actual "Agile" project type is only one valid approach) means dividing efforts into manageable chunks that deliver material value on a regular and iterative basis (i.e. every 3-5 weeks). This iterative approach helps to address:

  • Changes in Business priorities
  • Limited attention span of business users
  • Opportunity cost of time spent planning
  • Course corrections due to unforeseen circumstances

    Value realization begins after each incremental release usually in less time than standard planning cycles would have been completed. Within a month, users can access data and prototypes to provide feedback and more detailed requirements, increasing adoption, fostering a feeling of ownership and increasing usability. Short cycles with visible value also help sponsors manage budgets and get users to "good enough" quickly.

    Project Momentum

    Enterprise-wide BI plans are usually conducted to reduce the risk of making a mistake and to give the project sponsor an idea of what the total project cost will be. Yet, actual mistakes discovered early in Agile iteration are often less costly then the guaranteed costs and efforts of enterprise planning. As well, enterprise-wide planning projects don't seem to increase the accuracy of cost estimates. In fact, Agile breaks programs of work into smaller, measurable, more tangible chunks.

    An iterative approach has the ability to make a few cheap test runs to determine if the project is possible. Each iteration should select a few data elements and deliver something of useful value with that slice of data to the end users. Start small and deliver in prototype form, so that users can give their feedback quickly. Most importantly, don't be discouraged if the data is not valuable, this is what you are trying to determine as cheaply as possible.

    With an iterative approach, the first value is produced in the first month with most of the team members starting work on day 1. This not only establishes the team with can-do credibility, but also reduces the need and likelihood of requiring a full ROI evaluation before the project can begin producing value. From a funding perspective, working with users using early prototypes builds excitement and understanding of value throughout the organization, supporting budgets for each subsequent iteration.

    Objections to rapid prototyping and quick iterations

    Often, people think that an approach comprising a series of quick, small-scope iterations ignores some of the key elements of proper planning and jumps too rapidly into implementation. It is absolutely true that delivering BI without an approved roadmap (and budget) is risky, but removing long planning doesn't mean ignoring proper strategy and BI goal alignment to corporate goals. Understanding and communicating corporate strategies and goals can be done while other critical start-up efforts such as reviewing existing architectures and assessing data readiness are underway.

    An approach that moves quickly to a first prototype and proceeds in very rapid, tight iterations is rarely used in the field. BI projects tend to be organized in phases with full data marts that support the needs of an entire department. Sometimes this is the only way to deliver BI, due to complex interdependencies or "layering" of solution elements (i.e. calculations built on other calculations). In many other cases quick prototyping or even formal "Agile" could be used but is not understood by the project team. Iteration planning is the art of goal decomposition into iterations, and BI teams may not have the skills to understand how goals relate to the strategy or the business processes. For iterative BI to work, the BI team must have an understanding of how the business will derive value from the solution in each rapid phase.

    Kelly Lautt

    North Star Business Intelligence

    Listen to our Advocates of Value podcast

    Posted by Kelly Lautt and John E West at 3:30 PM | Comments (2)

    February 24, 2010

    Mistaking Milestones for Value in BI Projects

    Milestones are important for project managers and sponsors to verify that the project is progressing at plan. Unfortunately, verifying the progress of the project delivers no long term value.
    Structure the project to deliver something of interim value that business users can work with and examine at each milestone. Including business users gives progress visibility and encourages valuable input and rapid feedback.
    If the data quality is good, build a prototype cube directly against source systems, load it once and send it to users. If the data is bad, create data quality reports for careful business examination. If transformations are difficult, prototype ETL and populate reports so people can verify the calculations against existing systems and reports.
    Always use milestones to encourage user involvement, address difficult issues quickly and build temporary components to be reused in the final solution.
    John West

    Posted by Kelly Lautt and John E West at 12:15 PM | Comments (0)

    February 18, 2010

    The Many faces of Data Profiling

    Something quite funny happened to me today. An article reminded me that data profiling can be seen as a completely IT issue with purely IT value in areas such as performance, conformance and database integrity.

    For a long time now, I have been focused on using data profiling to asses and strengthen data quality and its readiness to provide business value within a BI solution. That means that while I profile in much the same ways (among others) listed in Matt Austin's article, I have an entirely different focus and purpose. Business requirements and questions rather than the IT issues pursued by Austin drive my profiling efforts. For example:

    • Austin looks at the percentage of zeros, nulls and blanks to "help database and ETL architects set up appropriate [and allowed] default values." I investigate these values to determine whether important business data exists to answer the questions the BI solution needs to answer.
    • Austin looks at numerical ranges (highest and lowest numerical values) to "help database and ETL architects set up appropriate default values." I look at numerical ranges to identify important outliers that might suggest data errors or exceptional business cases of interest (like having 10 clients out of 1000 who purchase double what the next highest accounts do).
    • Austin performs date range analysis to discover conversion issues that might arise from moving from one database platform to another (ex: Oracle to SQL). I use date range analysis to make sure the data can provide the historical reach required by the business to support valuable trend analysis or comparisons from one time period to another (such as year-over-year sales figures).

    In Austin's work, data profiling supports architects and developers in their efforts to construct an efficient and robust structure for data storage. In my work, data profiling illuminates 1) the readiness (availability and quality) of the data to provide answers to business questions; and 2) areas in which data may provide unexpected business value.

    Posted by Kelly Lautt and John E West at 1:45 PM | Comments (6)

    February 16, 2010

    Scoping the project too small or too big

    Often BI projects are either too small to deliver anything of value or the scope is so large that project implementation never begins (or never ends).
    Scope being too small can come from a sponsor that inherited the project or doesn’t see value. Other times it is caused by a project manager who has lost sight of value and reduced scope to the point where the project is not worth completing. Projects suffering from either disorder need to be examined by management to include value or be shutdown.
    Scope being too large can stem from wanting to be thorough and expedite subsequent implementation with a detailed plan. Unfortunately, long planning cycles often create over-generalized, over-reaching and stale plans with little remaining value. At worst, long-term road maps might be signaling a lack of implementation experience and that people don’t know where to start.
    Scope should be described in terms of very specific and tangible business goals. The size of the scope should be no larger or smaller than is required to achieve each specific business goal. The skill is in describing goals in a manner that creates a series of manageable, complementary and targeted projects whose outcomes deliver accumulating value over time.
    Kelly Lautt and John West

    Posted by Kelly Lautt and John E West at 12:15 PM | Comments (0)

    February 12, 2010

    Moving forward without strategy, goals and tactical planning

    Lack of a clear strategy describing how BI will be used to achieve business goals and what that means in designing a solution is common value killer for BI projects.
    A BI solution that is not aligned with organizational strategies is doomed to be just another database serving reports to people that don’t care about and won’t use them. Avoid this fate by knowing the business goal and finding the business user(s) able to advance the goal. Determining what data is needed, how often and in what format is an iterative process of working with these business users.
    Save valuable time by redirecting the time business people spend attending software demos and use it to understand the goals, strategies and tactics for the organization. The organizational strategy should identify the business user that is able to advance each goal. Work with that business user to determine how the right information delivered at the right time in the right format will help to advance the goal. This approach will ensure positive value of the BI solution.

    Posted by Kelly Lautt and John E West at 1:00 PM | Comments (0)

    February 11, 2010

    Thinking that technology (really) matters

    Looking at the amount of time that business people spend choosing the “right” BI technology, you would think that BI platform selection must have a significant bearing on the ultimate success of BI.
    In practice, BI software platforms have little impact on the project’s ability to deliver value. Clearly defined goals, knowing who and how to affect these goals and the desire of the business to succeed are the key elements of a successful project.
    BI projects are business projects, not software projects. Installing BI platform software doesn’t deliver value or a BI solution. Unless you have a uniquely complex or specific issue clearly addressed by a niche software tool, you won’t be able to recover the time spent on assessing and comparing BI platforms against each other or a list of vague expected business requirements.
    Another timewaster to be avoided is theoretical and detailed dialogues regarding performance and scalability when nobody knows “how big this thing will get”. Scalability and performance are architecture and configuration issues that have little to do with product selection and nothing to do with business value. Count the users, size the data, buy the hardware, hire someone competent to configure it and move on. If you are lucky enough to have a rapidly expanding BI solution that is delivering value, then adding hardware or even moving to a new platform will be justified. Don’t waste time, or allow software venders to waste time with hypothetical or general “future proofing” discussions that do little more than inflate software costs and cause delay to value creation.

    Posted by Kelly Lautt and John E West at 1:00 PM | Comments (0)

    February 10, 2010

    Quitting before we start

    Why does ROI only seem to matter during the budgeting phase?
    Everyone considering a BI project is concerned with delivering value or ROI (Return on Investment) back to the business. Much time is spent creating business cases and ROI calculations to justify the project and gain support within the organization. Unfortunately, this focus on value rarely extends beyond the budgeting process. Perhaps this is because we all enjoy looking forward more than looking backward or, maybe we worry that the investment is returning less than we projected.
    Too often project completion is mistaken for the end goal. Success lies in thinking beyond the goal of completing the BI system and striving to apply BI to achieve business goals and real value.
    Extend the project plan to include value realization efforts required after the BI system is operational, spanning the entire timeframe of the corporate goal you aim to affect. Be sure to include processes for determining if the existing BI system is driving value and still aligns with current strategies; if not, modify focus of the project or retire the solution.

    Posted by Kelly Lautt and John E West at 1:45 PM | Comments (0)