Skip to content

Archive for

Who benefits from the traditional consulting approach?

Traditional Sale Person

Traditional Sale Person *

You have done your research. You need to hire external consultants to help you deliver a critical project within very tight time lines. You have contacted reputable organizations and they agreed to come meet you at your office.

Each consulting firm you have met with tells you they are different (i.e. better) and only they understand your issues. Each organization has sent in well dressed and good looking individuals who have all left behind glossy brochures and great hourly rates. They all seemed knowledgeable and competent but you can’t make up your mind.

Now what?

Start by asking yourself these 2 questions.

How many of the sales people were practitionners – people with real life experience – as opposed to professionally trained sales people?

How many consulting firms priced their offering based on a successful outcome – the completion of your project on time and within budget – as opposed to billing for efforts?

The first question is related to understanding your business needs as opposed to pushing their services (i.e. selling). Does the consulting firm have to hire trained sales people to make you buy their services or do they send in their technical experts to meet with you to better understand your needs?

The second question is more complex. Most consulting organizations do not care to take on some of your risks, they are interested in placing resources on your project for which you will pay them an hourly rate. In all honesty, what is the incentive to quickly help you with your project when they will make more money as the project drags on. This approach is controversial as it changes they way people and organizations pay for services.

Do you want to pay for the efforts or for the outcome?

Paying for outcome is a better way of getting what you pay for, so next time you look to hire external help, why don’t you ask the consultants to price their services based on the successful results of your project as opposed to the number of hours they spent on the project?

* Picture by swgrlimited used under the Creative Commons (CC) agreement. The view expressed in the blog post is the one of the author. The photographer does not endorse in any way the content of this blog post or the work of the author.

8 Challenges To Address For A Successful Transition To Agile

We all know that getting the right information (meaningful and accurate) to the right people in the most timely fashion so they can make the best business decision is the ultimate objective of a business intelligence projet. Using an Agile approach aims to address these requirements but transitioning to an improved approach does generate some challenges.

Below is what we believe are the “8 challenges to address for a successful transition to Agile” for your BI projects. Although some of these challenges may seem overwelming at first, addressing them early in the process will greatly increase the chances of success in the long run.

  1. Educating your users so they understand their new role  – showing up only at the beginning and at the end of the project is no longer an option
  2. Training your architects and software developers on flexibility – not everything has to be binary
  3. Teaching your users the need to invest in invisible components – underlying technical architecture and infrastructure may not be visible to the users but they are a critical part of a BI project
  4. Making the users accept to divide large deliverables into smaller components – flexibility outweights the risk of not having the small components all at once
  5. Multi-years monolithic projects do not work – an incremental and iterative approach combined to timely budget allocation has proven to be a better strategy
  6. Informing everyone that refactoring is a success criteria and not an indication of failure – time saved from advanced detailed planning more than makes up for the time invested in refactoring later in the process
  7. Needing specialists with specific roles on the team is not a constraint – team members need to recognize they have a role to play on the team and should not stick to their defined job description
  8. Agile is a well documented methodology where all the answers are readily available – Agile is an approach based on key principles and relies on people’s ability to “do the right thing” in order to deliver quality output on time

Scrum Role: The Scrum Team

The Scrum Team

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Scrum Team.


The Scrum Team is a self-organized group of up-to 7 individuals with no pre-defined roles who work in collaboration to deliver upon their commitments. The Scrum Team is often comprised of cross-functional individuals who work to successfully complete the activities identified as part of the sprint backlog.

What the Scrum Team does

The Scrum Team is responsible for the following activities:

  • Following a negotiation with the Product Owner, selects the goal of the sprint;
  • Organizes itself and its work;
  • Plans and executes the tasks identified during the Sprint Planning Meeting;
  • Determines the appropriate methods of delivering on their commitments;
  • Presents the resulting work to the Product Owner.

Other interesting blog posts (June 23/2009)

Andy Painter presents the Top 10 tips to make better use of business intelligence . As a spin-off to his blog post, I thought I would associate some Agile practices to help support a better use of BI.

  1. Know what you want to get out of it -> Close collaboration with you business users to properly understand their needs (and be able to deliver on them)
  2. Make it relevant -> Present the results to the business users frequently so they can tie them to the business strategy
  3. Share the knowledge you have -> Increase communication within your development team to share technical and business knowledge and improve the expertise
  4. Start small -> Use an incremental development approach
  5. Work out what you’re already doing -> Do a retrospection of the work done to learn what is working well and what isn’t – what needs to be kept and what needs to be improved
  6. Don’t baffle the users -> Once again, work closely with the business users and frequently present the outcome of your work – avoid surprises
  7. Keep it clean -> Continuous integration testing to ensure quality of the data delivered
  8. Share your knowledge
  9. Open up to others
  10. Keep your eye on use

Ted Malone’s post (Cross-Domain Business Intelligence) re-emphasizes the point that “BI project must be able to adapt to changing requirements” and that “If an organization is rigidly structured, with well-defined “silos” of information, any attempt to develop cross-domain BI will likely end up in several BI silos that ultimately become useless when combined“. To this day, there are still more BI-people interested in architecting and modeling that there are BI-people interested in actually delivering value. It’s a shame.

Preface (Agile BI Book)

This blog post presents a preliminary version of the Preface of the collaborative Agile BI book. You can access the various sections currently available and you may register to join this collaborative effort to start contributing. I also invite you to comment this content at the bottom of the blog post.

Business intelligence (BI) applications are increasingly popular and organizations of all sizes are seeing the benefits. As a consequence, BI applications are no longer limited to senior executive but are increasingly deployed throughout departments and levels. The timely completion and successful implementation of BI projects provides a competitive advantage to the adopting organizations. Unfortunately, there are more failures and disappointments than successes.

There was a running gag in an organization we were working with that every Business Intelligence (BI) project required 3 years to complete and would cost over $3 Million. This running gag demonstrated an unfortunate situation – most BI projects are expensive, time and resource consuming and have a low rate of success. Along these lines, very few people would debate that traditional BI projects require heavy investments and result in long delays before providing value to the organization.

Much has already been said about the importance of BI applications in organizations. One of the most obvious and frequently repeated benefits of BI applications is the ability to increase the quality and timeliness of the business decisions being made. This is increasingly true as BI applications are being democratized and are now embedded in the decision making process at every level of the organization and across multiple departments.

In addition, decision makers constantly need an in-depth understanding of their business’ strengths and weaknesses and this is especially true during difficult economic times. The availability of timely and accurate information can help business leaders make the right decisions. Along these lines, the survey of over 1,500 CIOs[1] shows that despite predicted flat IT budget growth in 2009, BI projects remain their number one technology priority.

There isn’t much need to emphasize further the value of early diagnosis and the implementation of timely solutions but in a changing business environment the business needs evolve too quickly for sequential waterfall development methodologies.

Case in point, it is estimated that 60%[2] of BI projects end in abandonment or failure and market data confirms that out of the 3 standard project dimensions – time, resources, and scope – time lines and resources typically exceed the initial plan while scope consistently fall short of the original expectations and requirements. As such, an approach that delivers value early in the project while remaining aligned with the business priorities is recommended.

In addition, estimates show that no more than 20%[3] of business users actually use their BI applications proactively and that a staggering 64%[4] of systems functionalities are rarely or never used. This regrettable situation compelled us to look for an alternate and improved approach to ensure BI projects have greater success rate. More specifically that BI projects deliver the features required by business users (scope) in a timely fashion (time) while controlling expenses (budget).

Our intent is neither to rehash the unfortunate track record of BI projects nor to highlight the most dramatic failures but to propose a different approach to the development of BI projects.

This is a tall order but with the increasing popularity of AGILE iterative and incremental approaches and with repeated success in other specialities; we know using such an approach in the development of BI projects leads to much better outcomes.

The AGILE approach heavily relies on business involvement within the project team and throughout the duration of the BI project. Having direct contact with the business team, the development team will more easily understand the expectations and will increase its knowledge of the business which will make a more knowledgeable and productive team altogether.

In order to achieve our objectives to: reduce the initial investment, accelerate the availability of the information, deliver the right solution to the business users and constantly deliver value to the organization we explained that an AGILE approach is the right solution. Through iterations and increments, we use a “slicing approach” to develop from source systems to presentation layer in order to deliver on the business users’ requirements.

The benefits of an AGILE approach to a BI project are substantial. From our perspective, the most important one for the organization is that it forces the project team to focus on ROI and deliver high value by spending efforts on activities that will bring the highest value.

By reducing the duration of the development cycles the business and development team can modify their release strategy and focus on new priorities that may arise as a consequence of a changing business environment.

[1] Business Intelligence Summit by Gartner, 2008

[2] Standish Group Study Reported at XP2002 by Jim Johnson

[3] Within the context of this white paper and for simplicity, we combine Data Warehouse (DW) projects with Business Intelligence (BI) projects.


Other interesting blog posts (June 19/2009)

Mike Cottmeyer asks “are you more concerned about adopting specific agile practices or doing what it takes to build well functioning teams?“. In a world where consulting organizations sell tools and services to help you become Agile, Mike’s underlying question brings to the surface the real reason and the benefits of going Agile. Make sure to focus on the real desired outcome and not on the intermediary steps. The latter will get you “Agile-certified” but will not get you the benefits you are looking for.

Olga Kouzina has an interesting post (Do You Really Need a Deadline?) on a topic I already covered: time boxing software development. Although she raises a good question, I felt she is confusing the need for deadlines (time box) with the inability to properly plan.

Dean Leffingwell added a 5th post on the Agile Product Manager in the Enterprise.

Scrum Role: Scrum Master

The Scrum Master

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Team.


As an Agile Project Manager, the Scrum Master is the person responsible to ensure the adoption and adherence to the Scrum process. With no formal authority over the Team, the Scrum Master facilitates the various activities and maintains the Burn Down Chart.

What the Scrum Master does

As a liaison between the Product Owner and the Team, the Scrum Master is responsible for the following activities:

  • Helps the team maintain their productivity by removing barriers and preventing interferences;
  • Supports the Product Owner in achieving the project’s goals;
  • Facilitates communication between the Product Owner and the Team;
  • Updates the Burn Down charts and other artifacts to make team progress visible;
  • Organizes and facilitates the key meetings: definition, planning, building, demonstration, and retro-spection.


Top 10 indications that you are ready for a successful transition to Agile

With the challenging economic times, very few organizations are ready and willing to allocate large budgets and extended time lines before they get to leverage their investment. As such, transitioning to an approach that provides more flexibility and faster results seems like a logical choice.

Below is what we believe are the “Top 10 indications that you are ready for a successful transition to Agile” for your BI projects. It is obvious that an organization can begin a successful transition to Agile without having all 10 conditions but it is important to remember that the chances of success and the duration of the transtion will decrease as the number of conditions available increases.

  1. Your business users are already heavily involved in the development activities
  2. Your development team is successful in developing within defined time boxes
  3. Face-to-face and open communications are preferred to paper documentation and email communications
  4. Your organization has already had success implementing an Agile approach for other projects
  5. You are comfortable letting your customers take full control of the development process (requirements definition, answering questions during development, specify the required tests, ensure the results meet the expectations, and sign-off on the completed work) while maintaining flexibility on their priorities
  6. Your project team is used to prioritizing their needs and is able to determine which items are more critical (and which ones can wait)
  7. Management recognizes that adapting to the situation at hand is far better than spending countless hours in defining a detailed project plan
  8. The business sponsor, end users, and the development team are comfortable with iterative and incremental development and delivery
  9. Your organization has already invested into a data warehouse on which to build
  10. Your management team and the company culture can tolerate that people make mistake as long as they can learn from them (and that the mistakes aren’t huge and irreparable)

Chapter 03 (Agile BI Book)

This blog post presents a preliminary version of Chapter 3 of the collaborative Agile BI book. You can access the various sections currently available and you may register to join this collaborative effort to start contributing. I also invite you to comment this content at the bottom of the blog post. 




It was 2:15 pm on the Friday afternoon and Jordan and the development team were gathered in the meeting room making sure everything was in place for the presentation. Everyone was fairly relaxed with a sense of accomplishment. A few of the developers were making jokes in preparation for the demonstration that was about to take place.

Jordan had facilitated many demonstrations in the last 18 months and he was always impressed to see how pleased the developers were to present their work to their client. The product demonstration gave the developer the opportunity to present their work and get a sense of accomplishment. Over the years, Jordan had been happy to see that most teams he had worked with gelled quickly and their commitment to getting the job done was greatly increased when the team self-organized, as was the case again for this project.

Catherine walked in with a few of her employees. Immediately people from the marketing team initiated discussion with the software development team. Catherine looked at Jordan and said, “Do you remember when our teams sat silently at opposite end of the table waiting for the first person the open fire toward the other group?”

Jordan burst laughing, “Was it that bad? You make it sound as if Marketing and IT were enemies!”

“Weren’t we?” asked Catherine half-jokingly. “When you took over this project, things had slightly improved but with the previous project manager, this project was a disaster”.

“I know and they trapped me into this project. I wonder what I did to deserve this treatment?” said Jordan smiling. “All I can say is, the team and I are really enjoying working on the project. These end of sprints demo are a great way to get together and look at the great work that has been done to date”.

“I agree.”, said Catherine. “Are we going for beers after the presentation?”

Before Jordan could answer, Scott walked in with Alessia.

“We have important people joining us today” joked Catherine.

“That’s because I keep hearing good things about your project” replied Alessia.

“I’d like to ask everyone to take a seat” said Jordan. “We are just about ready to begin”.

“Kim, did you bring the cards so the team can demonstration he features that have been implemented” asked Catherine.

“Yes. Yes, I did” answered Kim. “I’ll sit next to Brian so he can demo them for everyone”.

The room was configured like other training room with a desk in the front of the room where Brian was sitting. His mouse and keyboard were linked to the main monitor that was used to project against the wall. next to Brian was a chair where Kim could sit and read the index cards on which were written the product features. Everyone else took a seat facing in the direction of the projector. Alessia and Scott took two seats available in the first row.

“OK, it’s 2:30 pm. Let’s begin” said Jordan.

“As a customer, I want to be able to add an item to my shopping so I can initiate the checkout process”, said Kim.

With a few click of the mouse and the relevant content, Brian demonstrated the feature to the audience.

“That’s great” said Kim. “I don’t really like the icon you selected for the shopping cart but I know, we’re not going to discuss this now. I’ll take a note for when we discuss the design and graphical interface”.

“Next. As a customer, I want to be able to specify my billing address so I can pay for the product I am purchasing” said Kim.

Once again, Brian clicked on a field, entered some text and press the submit button.

“Exactly” said Kim.

Alessia jumped in. “Why aren’t you also demonstrating the shipping feature at the same time”

“I’m sorry Alessia. Chickens are not allowed to participate in the product demonstration” said Jordan. “I can stay at the end of the meeting to explain our process. Let us continue the demonstration so we can stick to our time box”.

Alessia was shocked. In most meetings, people can interject and ask questions. Remembering how helpful Jordan had been earlier in the week with the coffee machine, she decided not to say anything for the time being but she wondered if being called a chicken was as bad as it sounded.

The product demonstration lasted over 90 minutes with most features being accepted as presented. Despite the fact the her question hadn’t been answered, she felt the presentation had been successful especially based on the constructive team dynamics she had witnessed. Once the meeting was over, she excused herself and walked back to her office.

On her way to her office, Alessia stopped for a coffee. Although it was past 4 pm, she wanted to get a jolt of caffeine to wrap up the week before leaving for the week-end. As she was pouring milk into her cup, Jordan walked in. “I thought I would find you here” he said. “You left before I could answer your question. I hope you didn’t take it the wrong way when I asked for you to wait until the end of the meeting to answer your question”.

“That part, I was fine with. What’s the issue with the chicken” asked Alessia.

“If you have a few minutes I can tell you about that” replied Jordan.

“Sure, come to my office. I have a few questions for you” said Alessia.

As the two walked toward her office, Alessia started “I am impressed with the team dynamic I saw this afternoon. A few months ago, all I heard were complains from marketing and from our team how catastrophic this project was and now, it sounds like everyone is pushing in the same direction. What happened?”

“The short answer is that we started doing things differently. The longer answer a friend of mine had tried a new approach in his organization with a lot of success and after I heard about it I asked Scott to attend a training. I started to apply my learning to this project. It was a disaster anyway when I took it over so I thought I couldn’t make it worst but trying a new approach. So I did.” said Jordan.

“How do you call this approach and most importantly can we send more people to this training?” quickly asked Alessia.

“Yes you can send more people but before you do, would you mind if I asked you a few questions?” asked Jordan.

“Sure” replied Alessia.

“The project management approach I’m using is called SCRUM and it is part of an Agile approach to software development.” said Jordan as they entered Alessia’s office.

“Have a seat” she said.

“Thank you. So what problems are you trying to address?” asked Jordan.

Alessia pointed toward the white board she had used earlier in the week.

“You have a lot of issues” said Jordan “Can I help?”

“Tell me something I don’t already know… Yes, maybe you can help” replied Alessia. “Can we apply your project management approach to our BI project?”

“I don’t know for sure but off the top of my head, I would be tempted to say, yes. Would you like me to look into it?” asked Jordan.

“If you don’t mind, give it some thoughts and maybe we can discuss your ideas next week?” said Alessia.

“Wow, it’s already passed 5 pm! Sure, give me a few days and I’ll schedule a meeting with you next week” said Jordan. “Have a good week-end”.

Other interesting blog posts (June 11/2009)

In Applying the 80-20 rule, Luu Duong presents a good correlation between the law of Pareto (80 – 20 rule) and the prioritization of the backlog.

A good introduction to the concept of Scrum of Scrums.

A somewhat lengthy blog post by Peter Thomas counter-arguing Why Business Intelligence Projects Fail.