6 ways to avoid scope creep in your next BI project

One of the greatest threats to a successful Data Warehouse/Business Intelligence project is scope creep, and the consequence is often a poor return on investment – or even failure, if not managed properly. We define “scope creep” simply as having a project scope that increases in size due to initially unintended or unanticipated changes to requirements and expectations. We propose six practical methods to handle the risk of scope creep in your next Data Warehouse and Business Intelligence project.

Let’s start with a small analogy to illustrate scope creep, using a situation most people can relate to: Grocery shopping at the supermarket. We have three scenarios:

First shopper has been busy all day and hasn’t planned dinner, and didn’t spend any time planning the shopping trip. But the shopper needs food and has a pretty good idea what is needed. The shopping trip is completed by memory, but while cooking, the unfortunate shopper realizes that ingredients are missing and needs to go back to the store to buy the rest.

Second shopper enters the store with a shopping list and knows exactly what is needed. While having a plan, the shopper still evaluates bargain items on sale and ends up making a few impulse purchases, resulting in a more expensive shopping trip than expected.

Third shopper spends considerable time on planning the trip and enters the store with a shopping list and only brought just enough money to fulfill the list. There is no room to deviate from the plan.

In the world of business, we often appreciate to reduce risk, thus most people would argue that “we want to be the third shopper” with a solid plan backed up by a solid budget. But one may find that planning a project down to the very detail may be unfeasible, or at least too costly. When it comes to planning a project, time and budget are not exact science. Too rigid planning may also include the cost of not taking advantage of unanticipated opportunities during the project. The first shopper represents the opposite extreme of having no sense of direction, and resources may be wasted on both unnecessary “ingredients” and a need for a larger scope to finish the “meal”. However, by not planning, the first shopper may still use less time compared to the third shopper, even with the extra shopping trip, and it becomes a matter of defining cost of time versus money. The second shopper represents the type of scope creep we see most frequently, the “forever-moving goalpost.” Any progress in the project spurs new additions, and we end up having a much larger and expensive project than initially anticipated…or even worse, the project gets stuck in the “sales aisle,” with the customer not being able to decide.

So how to avoid scope creep? We offer 6 methods that might save your next DW/BI project!

1. Fewer cooks in the kitchen

Narrow the channel between the business side and the BI development side, so that all requirements and scoping flow through the same people. You want to avoid business requirements being specified to the developers without having been weighed against the existing list of requirements. The downside of having just one person handling the scope is, obviously, that a lot of crucial information walks out the door should that person change careers. This risk can be mitigated with documentation.

2. Playing the “zero-sum game”

The zero-sum game is very simple: Every addition to the scope implies giving something else up in the scope. Consider the third shopper, who only can afford what was initially planned and would need to sacrifice items of equal value with any unplanned additions. Every request of “we also would want…” should be met with “okay…so what else don’t you want?” This is an extremely effective method in managing the size of the project. The downside to this method is that the business user requesting the change may not be able to evaluate the value of existing requirements, and/or does not have the political clout to make such decisions. This would risk great requirements being squashed.

3. Start a second project

Rather than try to fit in new requirements to an existing project, it can be better to simply start drafting a second project. Once the original project has met the defined expectations, the project team can engage in the new project and include the new requirements. The main benefit is that the project team can “worry about new stuff later” and focus on the project at hand. This method helps build a culture of continuous improvement, while keeping project scopes locked down. The downside is the risk of having a more valuable project waiting for the first project to finish.

4. Price the increase of scope

Recall that the second shopper brought home more than what was initially planned, which could be defined as “scope creep,” or it could be the result of poor planning. Either reason does not negate that every addition to a shopping basket must come with a price (our metaphors are law abiding). We recommend that any additions to a project should be estimated and priced. Similar to the zero-sum game, with the difference that you don’t insist on excluding something else, but align all stakeholders expectations to the reality of how much extra time and budget is required for the additions to the scope.

5. Start a backlog

Every additional request to an existing scope can in fact be treated as a request for improvement, which is a compelling alternative to the discussion of whether something is “in” or “out.” We recommend recording the requests on a prioritized list and/or visualized on a chart with difficulty vs. value axis. Have the list/chart available to the development team so they can decide what is possible to add within existing budget constraints. The key is managing the expectations, and the project team can evaluate when the backlog justifies starting a second project.

6. Say no

The simplest yet hardest way to avoid scope creep is simply to say no. Lock down the scope and refuse to accept any additional requests. Like the third shopper, realize that the project team has a plan and a budget with no room for change.