Keeping tight control over the scope of your data warehouse/business intelligence (DW/BI) program is an important ingredient for success. Surprisingly, in some organizations it’s equally important to ensure that the program doesn’t suffer the theft of its scope after an otherwise good plan has been developed.
It’s nearly impossible to tackle everything at once in a DW/BI program. The DW/BI team should identify subsets of effort based on the organization’s business processes (see Design Tip #69) to phase the overall design, development and deployment effort. Each phase or iteration should be meaningful and manageable. That is, the scope of effort should be large enough to result in a deliverable that provides meaningful business value, yet the scope should be small enough that the size of the team, the amount of data involved, and the communications requirements are “reasonable,” especially given the resources allocated. It’s important to avoid a large galactic scope that requires an army of resources and years of effort.
Once the scope for the project is established, there will inevitably be pressures to increase the scope. The most disruptive kind of scope creep is adding a new data source. Such a small incremental change in scope seems innocuous enough. “We are just adding a new cost element” or “We are just adding a weather source to the sales data.” However, these so-called small changes add up over time. Often the DW/BI project team is at fault. Most DW/BI teams are very focused on serving the requirements of their business partners and sponsors. But you need to be careful in your enthusiasm to serve not to succumb to scope creep that negatively impacts your ability to meet expectations. While it’s important to be flexible, it’s necessary to say “no” to maintain scope, especially after the project is underway.
Scope creep also results from overzealous business partners and sponsors. Once they’ve thrown their support behind the DW/BI initiative, they’re eager for quick progress and immediate results. They clamor for a greater scope (more business processes, more history, complex business rules and so on) delivered more quickly than originally agreed upon. Clearly, the business’s enthusiasm and support is positive, but so is sticking to the game plan and delivering the meaningful and manageable scope. The main business sponsor in a DW/BI project needs to be a sophisticated observer of the technical development, as well as being a good manager.
A strong program/project manager is critical for successfully managing scope creep. The program manager’s job will be made easier with a supportive business sponsor, a solid IT/business partnership, and a project team committed to meeting expectations. Frequent frank discussions between the program manager and business sponsor regarding the scope, challenges, progress, timing and expectations will ensure everyone remains on the same page.
A second concern regarding project scope is scope theft. Scope theft occurs when proponents of other projects/programs within the organization try to attach their agenda to the DW/BI program. Often these efforts support important enterprise needs, however, when they become attached to the DW/BI program, it’s usually the DW/BI program that suffers. These other efforts often lack business sponsorship, payback, and most importantly, funding. Supporters of these initiatives want to attach their agendas to the DW/BI program to leverage (i.e., steal) the momentum, senior management visibility, business sponsorship, staffing and/or funding of the DW/BI initiative. These efforts are often repackaged as prerequisites, companion and/or complementary efforts to the DW/BI initiative; suddenly the agreed scope of the DW/BI initiative has been usurped to focus on other initiatives.
There are a wide variety of enterprise initiatives that might potentially attach themselves to a DW/BI program. Some common examples include:
- Data quality initiatives focused on the replacement of aging operational systems
- Efforts to solve ongoing operational data integration challenges resulting from ineffective source system integration
- Master data management efforts
- IT projects focused on infrastructure re-platforming
- Implementation of a new role-based security infrastructure
- First deployment of a publish-subscribe style service oriented architecture (SOA)
- Utilization of off-premises cloud based storage for the DW/BI initiative
There is little argument that these initiatives may be in the best interest of the enterprise (as is the DW/BI program); it’s hard to dispute them conceptually. But, be wary. The reason the proponents of these initiatives want to leverage the DW/BI program is because their initiatives are complex, challenging, and expensive – they have likely been unable to secure the funding and sponsorship required to launch as a separate viable initiative. Since the DW/BI program has strong business support and funding, these competing initiatives look to cloak themselves as prerequisites or architectural requirements for the DW/BI program to move under its program umbrella.
The key question is whether these other initiatives become part and parcel of the DW/BI program? Typically not; it is likely best for both initiatives if they stand on their own merits. Otherwise the DW/BI program risks becoming a more IT-driven, galactic effort that delays the planned DW/BI capabilities and fails to meet the business’ expectations. These other efforts are almost always clearly distinct from the DW/BI program and should be scoped, funded, sponsored, and governed independently. The DW/BI program manager and business sponsor need to be politically astute, cautious, and fight to ensure the DW/BI program remains independent. The DW/BI business sponsor must typically work through these challenges given the organizational politics are often beyond the DW/BI program manager’s control.
