Continue in 2 seconds

Iterative Project Scoping

  • June 01 1999, 1:00am EDT

The major challenge of DSS project planning is to strike a balance between providing the end-user business community with usable solutions to their pressing business needs and delivering information that is feasible and reasonable from a technology perspective. All this must be achieved within a framework of small iterative project phases delivering incremental value to the business. In a previous DM Review article, "An Intelligible Approach to Enterprise Business Discovery and Information Deployment" (April, 1999), I outlined a broad business discovery process to follow. As part of phase two ­ micro business discovery ­ the scope and content for each planned project iteration must be documented and communicated to all interested parties. This is a key factor to successful expectation management when practicing the nontraditional, iterative delivery of business information systems. Managing expectations of senior executives, business end users and deployment technologists will greatly influence the resulting perceived success or failure of the ongoing data warehousing or data mart effort.

A picture is worth a thousand words, and the use of simple charts is always an effective and understandable way to communicate complex concepts or ideas. I have found that the charting approach presented here is easy and understandable for audiences of all levels within the organization.


The two competing realities that must be balanced are the need for critical business information and the ability to deliver that needed business information. Asking the end-user business community to prioritize their "needs" can be challenging. Often initial data warehousing efforts mistakenly try to provide all things to all business end users in the first iteration. If the end-user business community spans several different subject areas, this problem can be especially troublesome to resolve. Typically, when asked for business requirements without constraints, the end-user business community will commonly request "all of the data ­ now."

Attempting to deliver everything requested by the end-user business community is foolish at best. At the very least, trying to deliver all of the requested information takes considerable time and resources. By the time all of the requested information has been delivered, the business requirements may have changed and the information may be obsolete. Moreover, all information needs do not carry the same level of importance. It may not be surprising to discover that 20 percent of the business information requirements may satisfy 80 percent of the end-user business community's needs. In many cases, a little information goes a long way ­ if it's the right information. Unused data in the data warehouse is an unnecessary resource burden that will accumulate over time to unsustainable proportions. These issues are the basis for many underlying core principles of established data warehousing methodology ­ rapid, flexible, iterative, value-added deployment of small subsets of business information.

The key is to force the end-user business community to list all of the needed business information and agree upon the importance of each of these elements. Each of the end-user business requirement elements is evaluated and ranked according to current business needs. The effort to rank all of the business requirement elements may be somewhat unscientific and is often based more upon perception or politics. In the end, an agreed-upon, prioritized list of business requirement elements will be documented. This list represents all of the business information needed to eventually fully populate the data warehouse or data mart. However, simply knowing what the end-user business community wants and in what priority is not sufficient to effectively plan a series of iterative project phases ­ it is only half of the equation.

The other half of the equation is technical. It is not enough to know what the end-user business community wants; the technologists must know what can be delivered successfully. Remember, in an iterative deployment scheme, an intrinsic benefit of this approach is that "lessons learned" in preceding phases can be applied in succeeding phases. This logic suggests that it may be wiser to tackle the easier challenges before tackling the more difficult challenges, thereby minimizing risk by learning from small mistakes in order to avoid big mistakes. Therefore, it is the laborious task of the technologists to evaluate each of the end-user business requirements in order to rank each element in terms of technical difficulty to deliver.

For example, certain data may be readily available in an extracted and cleansed format from existing systems; in this case, the ETL (extract, transform, load) process is quite streamlined. This data may likely be ranked as "very easy to deliver." In other cases, data may not be readily available because it is derived from multiple disparate sources of inconsistent format and quality; in this case, the ETL process would be complex and quite an arduous undertaking requiring extensive data cleansing. This second example may be ranked as "very difficult to deliver." Still other data may be in varying states of "readiness" and span the gamut of technical deliverablity ­ from "easy" to "difficult."

When ranking the data as to its technical deliverability, the judgment criteria must be clear and well defined to eliminate subjective influences. There is plenty of subjectivity already in the priority ranking of the end-user business requirement elements ­ no more is encouraged here. A simple decision grid may be useful for determining and ranking the technical deliverability of the business requirement elements.


Armed with two agreed-upon ranked lists of the same business requirements, it's time to chart and evaluate the results. The first step is to plot the prioritized end-user business community requirements along the X-axis of a simple two-dimensional scatter chart. The X-axis is the "business need" dimension and should be labeled with "high priority" near the Y-axis intersection and the "low priority" label extended out at the end of the X-axis.

The second step is to plot the technical difficulty ranking along the Y-axis for each of the corresponding end-user business community requirements. The Y-axis is the "deployability" dimension and should be labeled with "easy" near the X-axis intersection and the "difficult" label extended out at the end of the Y-axis. The result should be a scatter plot depicting the relative priority and difficulty of each end-user business requirement element. (See Figure 1.)

Figure 1: Iterative Project Scoping Model ­ Initial Scatter Plot

Typically, the plotted points should be fairly well distributed; although, sometimes there may be clusters of plotted points. These clusters may be explained by certain data having few differentiated sources or having a poorly distributed priority ranking.

From this point, common sense can guide the analysis of the chart. Start by using a neutral, 45 degree "decision" line beginning at the intersection of both axes and slide the decision line along both axes until a targeted number of plotted points fall below the line. (See Figure 2.) The targeted number of business requirement elements must be determined much earlier in the business discovery process, for this number represents the relative scope for each project phase iteration. In an initial or small development effort three to five elements may be appropriate, in a moderately scaled project six to eight elements may be appropriate, and in a large development effort eight to 12 elements may be appropriate. Trying to deliver more than a dozen business requirement elements defeats the concept of rapid, flexible, iterative deployment of small subsets of business information. In this example, four project iterations have been scoped ­ each with five business requirement elements.

Figure 2: Iterative Project Scoping Model with Reasonable Amounts of Funding


The 45 degree orientation of the neutral decision line establishes a baseline for a reasonably funded development initiative. However, as the financial and political climate changes within an organization, the available project funding may increase or decrease accordingly. The changing availability of funding and resources will certainly impact the planning and scope for each project iteration in the overall deployment effort.

In the scenario of an increase in project funding, the angle of the decision line will shift vertically. The effect will be that more difficult business requirement elements will be selected earlier since more resources can be brought to bear on the project. As a result, more of the higher priority elements are tackled sooner rather than later. Those elements that are most important are addressed first with less regard to how difficult the task will be. Additionally, more funding implies that more project iterations can occur. This is shown in Figure 3.

Figure 3: Iterative Project Scoping Model with Abundant Amounts of Funding

Conversely, in the scenario where funding decreases, the angle of the decision line will shift more horizontally. The effect of this will be that the less difficult business requirement elements will be selected earlier since fewer resources can be brought to bear on the project. As a result, fewer of the higher priority elements are tackled, deferring to those elements that are important yet easily delivered rather than those that are most important but difficult to deliver. Likewise, less funding implies that fewer project iterations can occur. This is shown in Figure 4.

Figure 4: Iterative Project Scoping Model with Limited Amounts of Funding

In situations where executive enthusiasm shifts and project funding modulates, the angle of the decision line will change over time. If the decision line were to be tracked throughout the life of several project iterations, the lines would most likely not be parallel as shown in Figures 2 through 4. In cases where funding steadily increases, the lines would be fan-shaped stemming from the X-axis, since the more difficult and higher priority elements could be tackled sooner. This is shown in Figure 5. In cases where funding steadily decreases, the lines would be fan-shaped stemming from the Y-axis, since the more difficult elements would have to be postponed, yielding to the lower priority elements. This is shown in Figure 6. In cases where funding levels go up and down from project to project, the lines would be a patternless blend of Figures 5 and 6. In extreme examples of unpredictable funding, the lines may appear almost crosshatched.

Figure 5: Iterative Project Scoping Model with Increasing Amounts of Funding

Figure 6: Iterative Project Scoping Model with Decreasing Amounts of Funding

Lastly, those business requirement elements in the furthest upper right portion of the chart may never be addressed. These elements are both technically difficult and have low priority. These elements are on the end-user business community's wish list, but there is no urgent need for this information relative to the other information requirements. It is likely that after each project iteration, new and more important business requirements will emerge and perpetually push these orphaned elements to the back burner.

It is very important to be able to select viable business requirement elements in the planning of each iterative phase of data warehouse or data mart deployment. These selected elements define the scope of each project phase. Scope definition is the cornerstone of individual phased project plans. Once the scope is known for each individual project iteration, specific resources can be secured and time frames can be established with confidence in the detailed project plan.

There will be arguments by special interest groups for preferential selection of particular business requirements to be implemented sooner rather than later. Adequate defense of the unbiased evaluation of the business requirements as represented by this model can be conducted logically and fairly. If political influences favor particular business requirement elements, then this influence should be reflected in the priority ranking along the X-axis. After all, this dimension allows for subjective interpretation of the perceived business need as established by the end-user business community, including those influential political forces.

Alternatively, politically motivated arguments for preferential selection of particular business requirements can be accommodated in this model by allocating additional funds or resources to the project. The effect of this would be to shift the angle of the decision line within the chart to a more vertical orientation. This allows higher priority business requirements to be included in earlier project iterations even though they may be technically difficult elements to tackle.

Above all this model allows for concise yet flexible analysis and documentation of an otherwise unwieldy subject. Once project scope has been defined, the other pieces of project planning and execution can fall into place naturally.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access