We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Jim Gallo Subscribe to this blog's RSS feed!

Jim Gallo

Hello, again! Hopefully, this blog will be where the rubber meets the road. This is our opportunity to create an interactive dialogue about the subject of Agile BI and to learn from each other's experiences. The focus is on Agile methods as they relate to delivering BI solutions. If you would like to suggest a discussion topic, an article or link, feel free to send me an email at jgallo@iccohio.com.

About the author >

Jim isá National Director, Vice President, Business Analytics at Information Control Corporation (ICC), a firm focused on reducing the cost of developing BI solutions. Jim and the ICC team have enabled companies to increase the velocity of their development by adopting Agile methods for BI, with a particular focus on turning theory into reality.

Jim is a recognized expert and has published a number of articles on the practical realities of business intelligence and data warehousing. He is a regular speaker at conferences and industry-related events. He has led a number of large, complex BI projects for Fortune 1000 companies in addition to delivering value to federal and state governments and international clients. For two years in a row, Jim has been named IBM Champion for Information Integration and Federation. He can be reached at jgallo@iccohio.com.

Editor's Note:áMore articles and resources are available ináJim's BeyeNETWORK Expert Channel and blog. Be sure to visit today!

In her book, Sudden Death, Rita Mae Brown wrote, "The definition of insanity is doing the same thing over and over again and expecting different results."[1]  Think about this quote for a second and ask yourself, does this quote apply to the way you deliver BI solutions?  Have you been doing the same thing over and over again expecting different results?  If so, then you might want to keep on reading.

I've been in the consulting business for most of my career and have seen too many organizations blame technology for project failures.  In the past couple of years, especially, I've seen scads of companies spending ungodly amounts of money to do nothing more than replace one BI tool with another.  I liken the decision to blame BI tools for lack of user adoption and downright project failure to Brown's quote.  I really have to laugh every time I hear an organization blame a project failure on the BI tool.  When the BI team (too often synonymous with the IT group) finds itself squarely in the middle of major business dissatisfaction and low adoption rates, there seems to be a tendency to place the blame squarely where it doesn't belong, namely the BI tools.

But is it really the tool?  How can these very same tools be in wide use across the globe and be an integral part of some very successful BI deployments?  If it were truly the tools' fault, the vendors selling them would have gone out of business a long time ago and one would expect that hundreds to thousands of successful deployments with a "bad tool" wouldn't be possible.

Psst!  Stop and take a moment to listen to what's really being said:

Company 1 - "We're going to replace Tool A with Tool B because Tool A can't deliver what we need."

Company 2 - "We're going to replace  Tool B with Tool A because our users aren't using Tool B."

Company 3 - "We're going to replace A and Tool B with Tool C because neither A nor B are cutting it."

Oy vey!

In my opinion, most BI tools available today provide much the same functionality - query, reporting, analysis, dashboard and scorecards.  Some are certainly better than others at any point in time, as like most products, they continue to leapfrog each other in features and functions. And for the record, I'm talking about the real BI tools, not basic reporting tools pretending to be BI capable.  So if the tools provide similar functionality and have been successfully deployed many times over, what's really going on?

I liken these "Tool Wars" to another manifestation of poorly executed BI programs - speadmarts.  To me, they're symptoms of the same disease - IT's failure to truly engage with the business to deliver impactful, insightful, meaningful and intuitive solutions.  Seriously, if the BI team were building solutions using business-driven techniques, the solutions couldn't help but be successful.

So, before blaming tools and looking for a replacement, I'd encourage BI groups (IT groups) to first conduct a self assessment.  Reach out to the business community for whom the solution was supposedly built and seek to understand what the real objections are.  I'd be willing to bet donuts to dollars that the solution is suffering from one or more of the following woes:

  • A warehouse was built by IT and "thrown over the fence" to the business community with the expectation that they'll find value in the raw data tables.
  • The "BI" implementation is nothing more than a glorified report building environment rather than a metrics- or objectives-based solution that can be leveraged to drive revenue, improve customer satisfaction, reduce costs and maintain strong financial controls. (see "A Business Context for Agile Business Intelligence")
  • Time to value is measured in quarters and years rather than in weeks and months because existing delivery processes are mired in traditional waterfall methods.
  • Adequate end-user training has not been provided.

In a nutshell, "good" and "bad" have very little to do with the BI tools and lots to do with providing true business value in a reasonable timeframe and at a reasonable cost.  When BI solutions are anchored in and aligned with business objectives, the front-end tool really shouldn't matter.  If you don't agree, try replacing your BI tool while holding everything else constant.  When you deliver the "new and improved" version, don't be surprised when the business looks at you like you're insane!

[1] Rita Mae Brown, Sudden Death (Bantam Books, New York, 1983), p. 68.  Author's note:  I found that this quote has also been attributed to Albert Einstein and Ben Franklin.  However, the earliest published reference I could find was Sudden Death.

Posted January 7, 2011 7:24 AM
Permalink | No Comments |
Please let me know what you think about my 3rd myth article: Agile BI Methods Do Not Support Sound BI/DW Architecture Principles.

Posted November 9, 2010 12:34 PM
Permalink | No Comments |
I hope you enjoy my latest article that addresses the 2nd myth: There is No Need to Produce Documentation When Using Agile BI Methods.

Posted November 9, 2010 12:30 PM
Permalink | No Comments |

I hope you don't mind, but I've opted to create articles rather than blog posts about the 12 myths.  As I began writing about the first two myths I finally had to admit to myself that the word "terse" in no way reflects my writing style.

My goal is to address each myth in a bi-weekly article starting with today's edition - Myth 1:  Agile BI is radical and new.  Whether you're interested in operational business intelligence, business intelligence for banking, business intelligence for retail, or any other type of business intelligence reporting, I remain convinced that Agile BI is the way to deliver the solution.  Let me know what you think.

Posted October 12, 2010 5:21 PM
Permalink | No Comments |

Agile development has been applied to software development projects for quite some time. In a white paper that was first published by Robert Holler in the May 2006 issue of Better Software Magazine, entitled "Five Myths of Agile Development," Mr. Holler addressed the following myths with respect to software development projects.

  1. Agile Development is Undisciplined
  2. Agile Teams Do Not Plan
  3. Agile Development is Not Predictable
  4. Agile Development Does Not Scale
  5. Agile Development is Just Another Fad

In the past couple of years, we've begun to apply agile methods to business intelligence and data warehousing (BI/DW) projects.  Without a doubt, I've heard many of the same things addressed in Holler's white paper said about Agile BI from a number of sources.  Interestingly, when speaking with folks who are both familiar and unfamiliar with Agile BI, yet another set of misconceptions has arisen.  As a contributing architect in the development of Agile BI methods, I've compiled a list of Agile BI myths. As I sit here writing this blog post I'm not sure if I'll end up with ten, twelve or fifteen.  I encourage you to post your "Myths" here on my blog so we can discuss their validity. Who knows what I'll hear next!  At least for now, my list includes:

  1. Agile BI is radical and new
  2. There is no need to produce documentation when using Agile BI methods
  3. Agile BI methods do not support sound BI/DW architecture principles
  4. Agile BI displaces the software development lifecycle (SDLC) in its entirety
  5. Agile software development methods can be applied without modification to BI/DW projects
  6. When working as a part of an agile BI/DW team, anyone can work on anything, without consideration for roles and skills
  7. Agile BI only works for small teams
  8. Improvement in team velocity is all that matters
  9. Agile BI methods only work well with seasoned, highly talented and experienced team members
  10. All BI/DW tasks can start simultaneously because waterfall methods are no longer used
  11. The BI/DW team must be collocated in order for agile methods to be successful
  12. There is little to no correlation between story point estimating and project management estimating and budgeting

Look for future posts as I dispel each of these myths as we head down "The Path to Agility."

Posted September 30, 2010 9:38 AM
Permalink | 1 Comment |
PREV 1 2