What is the relevance of a work breakdown structure in a data warehouse project? Can you give me an example?


Tom Haughey's Answer: It is often said that warehouses are different. In some ways, they are. Requirements are less tangible and predictable than in OLTP (online transactional processing). Queries are very data intensive, involving few or many tables, but with many, many rows. In OLTP, transactions are data selective, involving few or many tables and comparatively few rows. Metadata is always important, but in OLTP the meaning of fields is predetermined on a screen or report. In a warehouse, metadata (in some way, shape or form) becomes critical because you can ask any question. However, warehouse projects are real projects and, like all development projects, must be managed. To manage them, they need to follow a clear plan. In my experience, warehouse managers often have a more difficult job than those managing OLTP projects because there are so many pieces and sources to manage. Managers that don't follow a good plan typically have major problems, such as lots of rework before delivery, lots of surprises or even eventual failure. Two purposes of the work breakdown structure are to manage work and to ensure success. This is the same as in any project.

However, warehouse projects are unlike typical waterfall projects in that they are based on a RAD (rapid application development) approach. Three of the main principles of RAD are as follows:

  • Iteration: Division of work into small increments.
  • Timeboxing: Delivery of capability in short intervals. The first release typically around three to nine months (depending on complexity) and quarterly releases thereafter.
  • Prototyping: Early delivery of a prototype. Deliver working database one-third of the way through.

(Incidentally, most RAD projects I have observed follow an essentially waterfall process within a given increment. It's sort of like a bunch of smaller waterfalls!)
These three principles are very important because even the best of warehouse plans will invite failure if you ignore them. An example of a failure waiting to happen, even with a fully detailed plan, is a large data warehouse that will gather all requirements upfront and where the warehouse will be delivered all-at-once in three years. It is not the "large" that is the problem, but the "all requirements upfront" and the "all-at-once in three years." Even enterprise data warehouses are delivered piece-by-piece using these three (and other) principles. The feedback you can gather from increment to increment is critical to the success of the future increments. There are many examples of successful enterprise warehouses, but they have all adhered to such principles. [See my answer this month to " An Insurance System Data Warehouse" for an example of a work breakdown structure.]

Danette McGilvray's Answer: A work breakdown structure (WBS) is relevant for any type of project, and a data warehousing project is no exception. A work breakdown structure is a list of project tasks along with deliverables and owners responsible for ensuring the tasks are completed. (The owner may or may not be the person actually executing the task.) The WBS is sometimes known as a project plan, a workplan or a task list.

The work breakdown structure provides a foundation for a realistic project schedule and helps the project team breakdown the deliverables into manageable tasks that can be tracked. By identifying the tasks upfront, it helps reduce surprises about activities, time and resources needed for the project. An additional benefit comes in the form of greater commitment when team members are included in creating the work breakdown structure.

The goal of the task estimation process is to determine the tasks needed to complete the project, estimate effort and create a draft schedule for completion.

When developing the initial task list and timeline with a project team, it is helpful to use a facilitator. The facilitator expedites the process so the project manager and team members are free to focus on determining the actual tasks and effort needed. Depending on the size and scope of the project, you may have more than one project team creating their own project plan for their specific deliverables. The overall project manager then brings together the plans into a master plan. The approach below works whether you have one team or several teams.

Caution: Do not expect this plan to be set in stone. The plan will continue to change as the project progresses; new information is available; scope, resources and priorities change; deliverables are (or are not) completed on time, etc. The process of estimating and modifying your plan should be repeated many times throughout the project. Even the initial plan could take several iterations before you have gathered enough information to create a useable plan.

I will briefly explain a process I have used successfully for many projects.

Determine the general approach, high-level phases and the methodology to be used in the project.

  • This is usually done by the project manager and team leads. You may be using a methodology provided by a vendor, other experts or creating it yourself.
  • For example, high-level phases might include plan project; gather data requirements; develop data model; design and develop physical database; source, profile and map data; extract transform, load data; etc.

Gather the project team.

Manual technique:

  • For each high-level phase in the project, follow the steps below to develop your plan.
  • One technique is to use large sticky notes or index cards and masking tape. Have team members write tasks on the sticky notes and place on the wall or white board. Use one sticky note per task. It is easy to move the notes as you organize the order. Each sticky note will include as much information as you have at the time: task, owner, time estimates and dependencies.
  • Once the manual work is done, transfer the information to your project tracking software (such as Microsoft Project).

Automated technique:

  • If you already have a fairly detailed methodology, you can enter the tasks into your project tracking software prior to the planning meeting. Breakdown or create additional tasks by entering the information directly into the software.
  • Caution: It is easier for the team to understand the project as they see it develop visually using the manual process. It is more difficult when creating tasks and estimating times using only the software.

Benefits from creating the timeline manually first with the project team include: 1) tasks, effort and dependencies are visible to all team members, 2) team has a greater understanding of and commitment to the project, 3) team members have an opportunity to get to know each other and set the foundation for working together. This is particularly important if the team is dispersed geographically and will not be face-to-face throughout much of the project.
Develop task list and description.

  • Review the project and business objectives, constraints and the high-level phases.
  • Determine tasks needed to complete each phase.
  • Keep the description simple. A verb-noun form works well (e.g., interview users, document requirements).
  • Continue to decompose the tasks until they have rough durations of two to 20 days.
  • Break down the tasks only to the level of detail that you are willing to track.
  • Include key checkpoints or milestones as tasks to be completed. A noun-verb form works well for milestones (e.g., requirements completed, data model completed).

Identify owner for each task.

  • For each task, identify a single owner who will be responsible for the task deliverable.
  • Other people may help with the task, but the owner is the one accountable for ensuring the task is completed on time.

Estimate times.

  • Time can be estimated as effort and/or duration. Effort is the time needed to complete the task. Duration is the elapsed time in number of workdays before the task will be completed. For example, it may take 20 hours of effort over a duration of two weeks to complete a task.
  • Determine which type of time estimate to use. It may be useful to capture what you know about both types while building the initial timeline.
  • Some techniques for estimating time include using historical data, actual experience, experts, rules of thumb, known formulas, segment tasks into more detail or actually do part of the task, keep track of the time and extrapolate your estimate.

Note any dependencies.

  • Describe any constraints or dependencies that impact starting or completing a task (e.g., data model must be completed before physical database is developed).

Organize the tasks.

  • Place the tasks on the wall into a rough order of dependence. Group associated tasks into major categories of work.
  • Filter the tasks for any duplicates.
  • Number the tasks. The high-level phases could be 1, 2, 3, etc. Tasks under each phase would be sequenced as 1.2, 1.3, or 2.1, 2.2, 2.3, etc.

Create a timeline.


  • Write time periods across the white board.
  • Use the task time estimates to determine the earliest start and finish dates for each project task.
  • Arrange tasks according to time needed and dependencies.
  • Link the sticky notes on the board by drawing in the dependencies.
  • Transfer the information into your project software.


  • Transfer tasks, time, and dependencies into your project planning tool. The software will help you create a timeline with due dates factoring in resource availability.

Use your project plan to track progress. Review and modify your estimates and keep your project plan updated throughout the project.
Larissa Moss' Answer: A WBS is a list of all potential tasks that may be relevant to a DW project. Having access to a WBS, the project manager does not have to start with a blank page and recall from memory what tasks to perform on his/her DW project, but can refer to the list of tasks on the WBS. The book Business Intelligence Roadmap (a DW methodology, ISBN 0-201-78420-3) has a CD in the back with such a WBS (920 tasks in MS Project).

Joe Oates' Answer: The work breakdown structure (WBS) reflects the hierarchy of tasks that must be done in a data warehouse implementation project plan. In my opinion, a good project plan is critical to the success of a data warehouse (or any other software) project. It provides the crucial planning and estimation answers to: 1) what tasks must be done, 2) who is going to do a task, 3) when is the task going to start and when will it finish, 4) how many person hours will the task take, 5) dependencies on tasks that must be finished before a task can start, 6) the sequencing of the tasks and 7) how much is the project estimated to cost.

A good project plan is a very important management tool, because once you do a project plan, you don't just put it on a shelf and forget about it. You use the initial complete version of the project plan as a baseline to see how close your original estimates were. As each task is completed, the project manager should update the project plan with the actual start and end date, who worked on the task, how many person hours it actually took and how much did it actually cost.

Additionally, most project management software will initially provide the project manager with a critical path. The critical path is the sequence of tasks that determine how long the project will take to complete. Unfortunately, it is very rare that the initial critical path holds through a project. As problems come up and individual tasks are delayed, the critical path will change.

Unless the project manager provides tasks at a sufficient level of detail, the critical path will not be accurate. The reason that it is important for the critical path to be accurate is that these are the tasks that should receive management and resource priority. If the tasks are in sufficient detail and are sequenced properly, it is possible to keep a task on the critical path from taking longer than it should.

A properly prepared and maintained project plan provides critical feedback to help management adjust resources to complete the project efficiently. A project plan can also help to manage expectations for customers and management sponsors.

Clay Rehm's Answer: A work breakdown structure (known as WBS) is essential for any kind of project. It describes the work to be done; that is, it defines the scope of the project or phase. It does not describe who is doing it, when it will be done or what dependencies are required.

This is a deliverable that can be shared with every member of the team because it explains the work that is to be completed to meet an agreed-upon goal.

The beauty of it is that it can be as high-level or detailed as you want it. Obviously, the more detailed the better, but you may not have all of the details when the project starts. You will refine this as the project gets underway, and then you will need to freeze it at some point so you can manage change control.

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