Monthly Archive for: ‘February, 2009’

Can you use Agile development for BI projects? 0

I wanted to summarize Tuesday morning’s session at the TDWI BI Executive Summit.

Larissa Moss (President of Method Focus) presented “Agile Development: What is it and will it work for BI?” where she explained that after failing at a DW project she was working on using the waterfall approach, she stumbled into Agile in the mid ’90s. After explaining what Agile actually is and how it differs from a traditional waterfall approach, she asked the “$64,000 question“, “Can Agile work for BI?” to which she answered “It depends what you call BI“.

Larissa argues that Agile BI works well for companies that don’t have to deal with the complexity of the data (i.e. don’t deal with building an underlying data warehouse). As such, she explained that using an Agile BI approach to do a data warehouse project where the development team has to deal with end-to-end solution including data standardization, data modeling and ETL cannot work due to the complexity and the un-known associated with the underlying data.

Larissa finished her presentation by proposing a solution to address this situation – Extreme ProgrammingTM which is a 16 steps Agile methodology she developed to address the pitfalls of the traditional waterfall approach. Her book called Extreme ProgrammingTM is scheduled to be released shortly.

Jim Hill (Director of Data Management at 1-800-contacts) then presented “Applying Agile Techniques to BI” and how his organization has been successful for the past 4 years in using Agile Development “for all software development projects and BI activities“.

Jim explained the process used by his business users to log their requests (user stories) which are then prioritized weekly and included in weekly iterations. He gave an example of 1-800-contacts’ Call Center BI which is deployed to over 400 agents’ desktops and for which the data is refreshed every 15 minutes.

Following Jim was Wyatt Weeks (Group Manager Business Intelligence at Sport Authority) who presented “Agile Data Warehousing at Sports Authority”. Wyatt told the audience that his team had chosen to use Agile Development for the first time on a “Large, high risk project with short time lines” and following their success, the team has continued to use Agile to deal with changing priorities.

Wyatt’s Scrum team consists of 7 to 9 members and all phases of their BI projects (architecturee, data modeling, ETL, and report development) are delivered through monthly sprints. He highlighted the benefits of Scrum: team collaboration, enforces communication and visibility, and clear definition of priorities. 

The 3 speakers gave good presentations and agreed that indeed Agile Development can be used for BI projects as long as it is adapted to the reality and constraints of the organization.

Posted on: 02-26-2009
Posted in: Agile, Agile Business Intelligence

How to determine the value of KPIs? 0

This question is frequently asked but the answer isn’t so obvious. In many (if not most) BI projects much effort is spent in calculating the cost of the overall project and sometimes more specifically the cost associated with specific KPIs but a lot less time is spent in determining the value or benefit of the required information.

It is frequently recommended to calculate the ROI of your BI project in order to properly evaluate if it can be considered a success (or not). Unfortunately, the ROI calculation has to factor in both side of the equation – costs and benefits.

Since business requirements always exceed capacity, organizations need to implement mechanisms to properly prioritize their product backlog. Unfortunately, the approach where “the business user who screams the loudest wins” doesn’t serve the organization. Despite the fact that this approach seems to be used more often than not, such prioritization process helps promote departmental agendas as opposed to an overall corporate perspective.

As such, determining the value of the required KPIs forces the organization to get into an alignment exercise and creates a great opportunity for dialog. It is critical to keep in mind that the benefits of the assessment exercise is not on determining the right value but to agree on an acceptable quantitative value.

I suggest 2 high levels approaches to help determine the value of the KPIs.

  1. Determine the real value: with this approach, the team tries to determine the actual incremental revenue or cost savings the additional KPI will bring to the organization. When using this approach, it is critical to spend enough efforts to determine a good-enough estimates as opposed to determining the exact dollars and cents.
  2. Estimate the relative value: this approach works well in the context where people can compare various KPIs to each others as opposed to evaluating them in an absolute perspective. With this approach, the team can use pre-allocated amounts of points or virtual money to rate/vote on the various KPIs allowing the group to determine which KPIs receive the most votes. Although this approach doesn’t help with ROI calculation, it does help move the process forward by helping the team select and agree on the priorities which will in turn help the project team.

Whatever approach is used, the objective remains to agree on common (corporate) priorities as opposed to departmental preferences while determining the value of the KPIs.

PS. I had completed this post prior to attending the panel presentation (Strategies for Business Alignment) at the TDWI BI Executive Summit this morning where David Hsiao (Corporate Quality Metrics and Benchmarking at Cisco) mentioned that prioritizing requirements is much like comparing apples and oranges since most requirements do not have the same value for the organization.

Although he didn’t explain which method was being used at Cisco, he mentioned the fact that each stakeholder gets “requirements” equivalent to the percentage of total budget they fund. In my opinion, this represents a good preliminary step to slice the total pie prior to agreeing on the value of the KPIs.

Posted on: 02-23-2009
Posted in: Leadership

Explaining the business value of iterative development 2

A few people wonder how changing the software development approach can impact business results, namely costs and ROI.

We often use a diagram similar to the one presented below to explain the relations between various decisions and outcomes.

Iterative Software Development Applied to Business Intelligence

Iterative Software Development Applied to Business Intelligence

Starting with the decision of using an iterative development approach as opposed to a traditional waterfall approach for the development of a BI solution results in 4 immediate outcomes:

  • Improvement in requirements gathering by quickly developing on the initial requirements to deliver a prototype. After a few hours of discussion with a business user, there is usually enough information to start developing a first key performance indicator (KPI). At this point, the development team will select based on perceived value (see below) and low complexity a first KPI that they will develop and present to the business user. The business user will then re-assess his needs and initiate a new iteration to either add more KPIs or develop the first one further.
  • Reduce long term planning by avoiding a long term perspective. It is obvious that focusing on the long term forces the team to plan, architect, and model accordingly since it is unlikely they would have many attempts at doing this right. Reducing the long term perspective to the current iteration forces the development team to plan, architect, and model for the context of the current iteration. This does not mean the team should not think about future impacts. On the contrary, while the team needs to keep in mind the future overall BI application they should remained focus on the current iteration – focus being the key word.
  • Determine ROI of additional features by assigning business value to each additional request. Since the development team has a small time frame to deliver (current iteration), they cannot attempt to deliver everything and as a consequence the business users need to select which KPI should be handled during the iteration. Using a “business value factor” helps the business users and the development team understand and agree on the components that need to be build to deliver value quickly. Although simple, the prioritization exercise forces business users to make decisions and realize that it is not possible to deliver everything. Using long term iteration typically delays those hard decision and leads people to believe they can include everything and that everything will indeed be delivered.
  • Quickly responding to market changes by not committing the development team to long development cycles. In a traditional approach where the project is planned at the beginning and rarely re-assessed, using small iteration cycles allows a change in priority when the business context needs it. Knowing the development team is committed to a 3 to 4 weeks development cycle allows business users to change the content of the next iteration if the business landscape forces them to do so.

These 4 consequences of an iterative approach to a BI development then bring 2 important benefits to the organization.

  • The overall development time to deliver on the requirements is greatly reduced since the team worked with the business users to better understand and define their requirements through the use of a prototype. As such, development efforts were invested in well-known and understood requirements as opposed to speculations based on a limited understanding.
  • In addition, by focusing on the KPI that delivered the highest value – and not those who have low business value – while allowing for changes in the development priorities when the market conditions dictate such changes allow the development team to deliver value to the business users much faster than in a traditional approach where the users would only have visibility to the results at the end of the development project.

These 2 intermediate outcomes lead to 2 critical business value: reduced costs and improved ROI.

In light of the fact that a staggering 64% of systems functionalities are rarely or never used (Standish Group Study Reported at XP2002 by Jim Johnson), focusing on the requirements that were derived through the use of prototyping reduces waisted development efforts. As such, using a traditional development approach would have led to spend almost 3 times more time, efforts, and money on the real requirements.

In addition by having the development team select the real requirements with the highest business value ensures that efforts are spent on the tasks that will help the organization and possibly end the BI project once the cost of the remaining KPI exceed their estimated value.

Experience has showed us that changing the development approach to an iterative one does bring value to the organization. Hopefully, using such a diagram will make it easier to have such a conversation with the business community as opposed to within the IT department.

Posted on: 02-18-2009
Posted in: Leadership

An iterative and incremental approach for BI projects 0

The un-impressive track record in the development of BI applications led us to conceive an improved approach to reduce the initial investment required to launch a BI project in order to deliver key performance indicators (KPIs) much more quickly and at lower cost.

The incremental development approach we came up with is aligned with the business priorities while allowing business users to further develop the knowledge of their business and better define their expectations.

As opposed to the traditional waterfall approach to building a BI application which is: plan the project, define the requirements, prepare the architecture, develop, test, move to production in a sequential manner, we propose to use an iterative approach during which we build layers of the entire data warehouse through iterations.

For example, instead of spending time in defining in a high level requirements, work with the end users to understand their business and the indicators they use to successfully manage it. Using an iterative approach, the objective of our process is to work backward starting with the required performance indicators back to the source systems.

An Iterative and Incremental Approach for BI Projects

An Iterative and Incremental Approach for BI Projects

As can be seen in the diagram, the intent is not to divide the project into phases where data is extracted from the source systems first, then move to a centralized repository and so forth. Instead of the traditional approach, we use a layer approach where each indicator is developed from source system to the presentation layer.

Although our approach requires a substantial paradigm shift for most people having experienced a traditional waterfall approach for BI
projects, the notions we propose are simple, logical and straightforward. This approach relies on AGILE principles and
more specifically on SCRUM practices that have been demonstrated to be successful in other types of initiatives. Our objective is to present them in a very concise manner in this post.

Our proposed approach to BI development can be summarized by the following principles:

  • Segment the development of components into small iterations of 3 to 4 weeks and frequently deliver key performance indicators at the end of each iterations;
  • Repeat the iterative process and use increments to add components to the BI architecture and infrastructure;
  • Prioritize the development of the key performance indicators that will deliver the highest value to the organization first;
  • Using a top-down approach going from aggregation to granularity, develop each KPI from end-to-end or from source systems to presentation layer;
  • Avoid “analysis-paralysis” forces by using a “good enough” approach in documentation, architecture, modeling, project management
    and other overhead activities;
  • Learn from each of the iteration and adapt the process appropriately to increase efficiency.

Our approach promotes a process that encourages frequent inspection and adaptation, a set of engineering best practices that allow for
rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. With this
approach, the project delivers in small increments with minimal planning, rather than long-term planning.

Posted on: 02-17-2009
Posted in: Agile Business Intelligence

Analytical Mind has moved 1

As of today (February 15th), I will stop maintaining this blog. You can read my candid observations on collaboration and intelligence in a business context.

Posted on: 02-15-2009
Posted in: Leadership

You are not doing SCRUM if you don't have a ScrumMaster 1

I heard that comment a few days ago coming from a bright colleague of mine who was questioning why a product development team I am involved with didn’t have an official Scrum Master.

I fully support the role of the Scrum Master in a development team but this question led me to wonder if people don’t get a false sense of success in their implementation of SCRUM?

I believe that the objective of SCRUM is to ensure the team delivers quality software within the agreed upon time lines and budget. Whatever method that truly supports that objective should be considered, even if it is not SCRUM.

Going back to the comment, would the opposite be true – you are doing SCRUM if you have a Scrum Master. Although partly accurate, I believe this statement highlights what is wrong with the current popularity of SCRUM. “You are facing so many issues with your development team because you don’t have a Scrum Master. Simply hire a Scrum Master and all your problems will be resolved”.

The silver bullet doesn’t exist but at the same time, not having a Scrum Master doesn’t mean your project will fail.

In the context I was referring to earlier, the development team is small and composed of 3 fairly senior developers. The team works very well together and is totally self-organized. In addition, the team has successfully delivered on its commitments to date. Do they really need a Scrum Master?

The same way you can do project management without a certified project manager or do accounting without a certified accountant, you can embrace SCRUM without having a dedicated Scrum Master. As long as your team is successful in the eye of your customers and follows the principles of SCRUM, I am confident you can survive without a Scrum Master even if some people don’t like the idea.

Posted on: 02-14-2009
Posted in: Scrum

Are you using scare tactics to sell you product or service? 0

If you have decision making authority in your organization and receive emails promoting BI products or services, don’t you wonder how those companies performed before the crisis that is currently affecting the economy?

I have stopped counting the number of emails (aka SPAM) I receive that starts with “In this current economic climate…”. Nonetheless, I wonder why so many organizations put so much emphasis on the challenging economy to promote their offering. Aren’t their product/service solid enough to stand the competitive pressures? Do they need a crisis to stand out of the crowd? How bad is the product/service if they needed a downturn in the economy to get people to pay attention to their organization?

In the world of Business Intelligence, the value of a BI application should be visible on a daily basis, not only when there is a severe crisis. I believe business users need constant access to reliable information to optimize their decision making process, not only when there are troubles.
Do you know many drivers who look at their car dashboard only after they get into an accident? It would be no wonder they get into problems.

The value of BI applications is undeniable. Organizations should focus on providing continuous value instead of finding gimmicks to promote their product/service.

Posted on: 02-12-2009
Posted in: Leadership

Pyxis Technologies – Business Intelligence Blog 0

You may also be interested in my blog post on Pyxis Technologies‘ official blog (French).

Posted on: 02-11-2009
Posted in: Leadership

Want to get results sooner? 0

In an attempt to demonstrate that an iterative and incremental development process produces results faster, I came up with a quick comparison. Although simplified, I am using some fairly straight forward assumptions to demonstrate my point.


The following graph compares the cumulative costs-benefits of each approach used for a Business Intelligence (BI) project. BI projects notoriously require a lot of time up front to plan, architect, and design the solution. Once these initial steps are completed, up to 70% of the development team is spent on the development of the ETL. All these efforts are usually required prior to delivering key performance indicators (KPIs) to the business users.

As can be seen, both approaches require an initial investment in the development of the solution but after the third iteration (month 3), some value is already being delivered to the business user when using an iterative and incremental approach.

Using a project management view, the waterfall approach typically requires that activities get completed before moving to the next one. As such, the development team needs to progress through each step before the BI application can be deployed in production and the business users gets to see his first KPIs. This is in the best case scenario where the initial requirements were accurate and the business context didn’t change for the duration of the project.

By comparison, short iterations (typically between 20 and 30 business days) that focus on end-to-end solutions quickly provide results to business users.

Some planning needs to take place prior to launching an iterative and incremental project (which will be discussed in another post) but the obvious value is in delivering results sooner.

Do you know a business user who wouldn’t be interested in such an approach?

Posted on: 02-10-2009
Posted in: ROI