BeyeBLOGS | BeyeBLOGS Home | Get Your Own Blog

Main | March 2010 »

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
John@northstarbi.com
http://northstarbi.com

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:


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
NorthStarBI.com

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)