Lesson 2: An Examination of Project Management Approaches

Some industry authorities assert that data warehousing project management is unlike any other type of project management. Other experts state that data warehousing project management is similar to any other type of project management. So who is right? In a way, they both are. There are characteristics that differentiate data warehousing projects from other types of projects, and those characteristics affect some of the most critical aspects of a data warehousing project. Nevertheless, good analysis, planning, and project management techniques that have always worked in other environments are also effective at handling the challenges of managing a data warehouse project.

After this lesson, you will be able to:

  • Identify good project management techniques that are common to data warehousing projects and other type of development projects
  • Contrast data warehousing project issues with issues commonly associated with other project types
  • List the roles that can make up a successful data warehousing implementation team

Estimated lesson time: 40 minutes

A Golden Rule of Data Warehousing

Let s start with an important concept that will temper all of the suggestions that follow:

Data warehousing is a solution to a business problem. Business problems are identified by and solved by users.

In other words, data warehousing is not about a particular front-end query tool, storage type, database size, technology, or even vendor. These are by-products of a successful implementation that occurs through thorough research and user involvement. If the users (and therefore the organization) benefit from a data warehouse, that data warehouse can be deemed a success.

One of the best characteristics of the Microsoft Data Warehousing Framework is that it is open architecture that allows developers to select the best tool for the job, even when the tools come from different vendors.

Data Warehouse or Data Mart?

One of the first issues to resolve is the scope of the project: Will this be a data warehouse project or a data mart project? Even using these terms is potentially problematic because within the data warehousing industry there is little agreement about the exact nature of these terms. For our purposes, let us define the terms as follows:

Data Warehouse Project: A data warehouse project affects most of the enterprise. This type of project may have multiple source systems and subject areas. It is not uncommon for data warehouse projects to span years and be quite costly. The "big picture" benefits to the organization justify the risk and expense.

Data Mart Project: A data mart affects a single process or department within an organization. This type of project usually deals with a single subject area. It is common for data mart projects to be implemented in months rather than years.

It is useful to use these labels to discuss the differences in approaches, but it is also important to apply them with flexibility. The best solution is the one that fits the business need. The minute you start to say, "This is a data mart, so we can t do it that way," you have lost sight of the golden rule of data warehousing.

So how do you decide whether a data warehouse is the appropriate approach? You may want to consider a data warehouse if you agree with the following statements:

  • I am willing to invest time and money to achieve long-term benefits.
  • I am able to organize different areas of my IT department to work together to achieve a common goal.
  • The business measurements I consider important span operations or departments within my enterprise.
  • My competitors use data warehouses to achieve strategic advantages.

You may want to consider a data mart if you agree with the following statements:

  • I am interested in a particular area of my organization s operations.
  • I need a solution quickly.
  • I am not willing to embark on a longer-term project.

Data Warehousing Issues

Following are some of the most significant issues specific to data warehousing and some potential resolutions:

  • Because a data warehouse is likely to be dependent on data from many different operational sources, that dependency threatens the likelihood of project success. Possible solutions to such a problem are as follows:
    • Use metadata to facilitate use of heterogeneous data.
    • Document data sources and transformations.
    • Use a staging database or operational data store to retain control of copies of operational data.

  • Because the scope of a data warehouse is grander than smaller, more immediately productive projects, the data warehouse project can suffer from inertia or the phenomenon that it is never begun because the project seems too ponderous. Possible solutions to such a problem are as follows:
    • Use identifiable checkpoints to gauge progress.
    • Make sure the project is split into achievable tasks.
    • Delegate those tasks clearly, with clear deadlines.
    • Use tools that provide rapid results and allow prototyping to solicit immediate feedback.

  • Analysis must reach across the enterprise and harmonize facets of business operations that may not interact otherwise. Possible solutions to such a problem are as follows:
    • Use subject matter experts to identify important measures of success or key performance indicators in each area.
    • Verify your analysis with someone who has a high enough viewpoint of the enterprise.

Effective Development Practices

Unlike the above issues, which are unique to data warehousing projects, the following project management practices have a clearly defined scope.

Define Projects with Clear Beginnings and Endings

Something often overlooked is the importance of the beginning and ending. A project is a temporary endeavor. What marks the beginning of database design? When do you know database design is complete so that you can begin capacity estimation? These are all questions that must be answered in order to gauge progress.

Identify Project Deliverables

Often project descriptions are so general that they provide no insight as to when the project is considered complete. "The Northwind Sales data mart will provide better sales information to users" is not an example of a deliverable.

"The Northwind Sales data mart will include a Web-based query tool that allows users to pose ad hoc questions in English" is a better example of a deliverable.

Define Project Objectives

Project objectives are quantifiable criteria that must be met for a project to be deemed successful. Objectives clarify a project s purpose and help justify a project s existence. They may help to solicit participation from individuals, especially those who believe they may benefit from having the objectives met. For example, good analysis requires soliciting expertise from subject matter experts like marketing managers, who may be very busy with their own jobs. If marketing managers can see how accomplishing some of the project objectives will make their job easier or provide better information, you will have team members from marketing who provide excellent information and do so willingly and effectively.

Create Development Milestones

Because data warehousing projects tend to be long term, there is a danger that the deadlines seem so remote that they are not honored. For example, it is risky to say, "We must move all the data from the mainframe by year s end." Data warehouse project development should be broken down into a series of coordinated mini-projects. A better approach would be to say,"The transformations from the inventory system are to be implemented in four weeks." This approach results in a manageable, achievable series of tasks. It also provides visible results more quickly than if you consider the whole project. Lastly, it provides more immediate feedback should any technical problems affect project deadlines.

Building the Team

What are the roles that constitute an effective data warehouse development and deployment team? The following abbreviated list examines important roles in a data warehouse and development team. It is useful as a starting point and good food for thought as you embark on your project plan. On smaller data mart projects, multiple roles may be fulfilled by a single person; on larger data warehousing projects, the best approach is to convene a team of dedicated individuals and subject matter experts.

  • Executive sponsor—This individual may not actually use the data warehouse but should have the following characteristics:
    • Authority to coordinate resources, or willingness to delegate that authority
    • Enthusiasm for the data warehouse benefits and the desire to spread that enthusiasm
    • Enterprise—level perspective

  • Executive liaison This individual will have a conceptual grasp of data warehousing and its capabilities and will be able to:
    • Enunciate the benefits of data warehousing to executive staff in nontechnical terms
    • Be aware of the political implications of the data warehousing project within the organization
    • Know what the data warehousing project team is capable of

  • Project manager—This individual is responsible for:
    • Maintaining the deliverables schedule
    • Coordinating resources
    • Identifying problems before they compromise the timetable
    • Creating teams
    • Delegating tasks to teams or individuals

  • Business analyst—This person:
    • Is expert in an area of business operations, for example, sales
    • Knows key measurements of success within a business area
    • Can articulate questions that identify key performance indicators of success; for example, "How many more customers ordered Product X in the third quarter than in the second quarter, and what cities are they in?"

  • Data architect—This person will be able to:
    • Comprehend operational system entity relationship diagrams
    • Derive a star schema from a conceptual description of dimensions and measures
    • Estimate capacities required for a proposed data warehouse design
    • Implement indexes to support data warehouse operations

  • Database administrator—This person will:
    • Create the data warehouse database
    • Implement security on the data warehouse database

  • System administrator—This person will:
    • Configure the network to allow traffic between operational and data warehousing systems
    • Advise on bandwidth and storage considerations

  • Legacy systems specialist—This person will be able to
    • Assist in finding and deriving operational data.

  • Data transformation migration specialist—This person will:
    • Catalog and implement data migration routines

  • Quality assurance specialist. This person will:
    • Evaluate quality and integrity of data
    • Test query and analysis tools
    • Catalog anomalies

  • Users—These individuals will:
    • Provide test queries for evaluation
    • Provide sample reports for evaluation
    • Provide testing and feedback

  • Documentation specialist—This person documents procedures and applications.
  • Intranet administrator—This person configures Web servers to host Web-based query tools.
  • End-user tools expert—This person:
    • Evaluates querying and analysis tools
    • Assesses vendor tools
    • Manages vendor relationships

Lesson Summary

Certain unique characteristics differentiate data warehousing projects from other types of development projects. By identifying these unique attributes and having strategies in place to manage them, one can increase the probability of project s success. Because these characteristics present special challenges, it is all the more critical to understand the project management issues that go into a successful implementation.



Microsoft Corporation - Microsoft SQL Server 7 Data Warehousing Technical Support Training Kit
Microsoft SQL Server 7 Data Warehousing Technical Support Training Kit
ISBN: 0735606706
EAN: 2147483647
Year: 1999
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net