THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Impossible Data Warehouse Situations: Management Issues

Published: July 1, 2002

Published in TDAN.com July 2002

This is an excerpt from "Impossible Data Warehouse Situations: Solutions from the Experts", scheduled to be published by Addison Wesley in the fall of 2002. This book has 91 impossible situations which are addressed by nine leading data warehouse experts.

Management Issues

“The IS manager of the future requires a different mind set.” Bill Wahl

“What is needed…is a new structure – one that allows knowledge and information to be manipulated, created, stored, and communicated both rapidly and inexpensively.” Richard L. Nolan

A sound management structure is one of the critical success factors of the data warehouse. A strong, positive attitude by management, both from the business and from IT, is critical to success and projects have come to a halt when the project’s sponsor has left. Projects have experienced sponsoring managers not staying long enough in their positions to see them through to completion, not due to incompetence but because of the dynamic nature of the organization. This will likely mean the loss of the sponsor before the project completes. A strong, dedicated sponsor is a critical success factor for the data warehouse.

Management often does not know what is going on with the data warehouse and does not understanding its value. Without this understanding, there won’t be funds to support existing data warehouse systems, nor will there be funds for future systems. Some organizations have a terrible track record collecting multiple data warehouse failures. These failures are usually the result of management not understanding, not caring, and not devoting the necessary resources to make the data warehouse successful. Success will require a change in the way management views data warehouse projects.

Data Sharing

Information is power and division heads are loath to give up any power they see leaking from their empire as a result of the data warehouse. When the norm is not to share data, it has implications for the entire organization and the ability to have a single version of the truth. Data is often not shared by users for a number of reasons. The users may genuinely believe that they are the only ones smart enough to receive, validate and interpret the results of a query or report. Some managers may believe that sharing their departmental data would give their bitter rivals ammunition to be critical. Sharing data may give supervisors the ability to micro manage; a management activity that is definitely not appreciated by their staff. Since data is power, by sharing data, managers may correctly believe they lose some of their power. And finally, managers may not want to share their data because, before it is released, they may want to adjust the results, sometimes called putting their own spin on the numbers. These managers may want enough time to be able to justify poor results or to actually change the numbers before the rest of the organization sees the results. We have seen situations where people in management, for reasons of power and politics or sometimes fear, have fought against the project from the beginning and continue to do so as the project is being developed. They may continue to sabotage the project or sabotage its reputation even after the project has been implemented.

Criteria for Success

Some data warehouses implementations are failures. It’s possible that many of those “failures” would be considered by some to be successes or at least be positioned some place in between, but not failures. The criteria for success are often determined after the fact. This is a dangerous practice since those involved with the project don’t really know their targets and will make poor decisions about where to put their energies and resources.

Users are instrumental in setting these criteria but they should be set with a reality filter. This filter must set realistic goals for performance, and address what data will be provided in each phase. This is a suggested set of criteria for success:

• The data warehouse is used and useful
• Acceptable return on investment (ROI)
• Business, performance-based benchmarks, e.g., customer satisfaction improvement
• New requirements are being generated by the users; there is more demand for data warehouse capabilities, new users want access, new data sources are being requested
• Acceptable performance – the user is satisfied with response time. This is not only a question of the system giving fast response; it is also a function of what the users expect. Setting their performance expectations should be done early and often (with complements to the late Mayor Richard Daley of Chicago).
• Satisfied users – satisfied users are willing to sing your praises. Be sure to ask.
• Goals and objectives met – this assumes that the goals and objectives for the data warehouse have been identified and accepted.
• Business problems solved – for example, the problem for a manufacturing company could be inadequate quality information.
• Business opportunity realized – for example, the opportunity could be securing large customers as they see your data warehouse giving them critical information unavailable from your competitors.
• The data warehouse has become an agent of change – for example, the data warehouse has made a fundamental change in the way the organization approaches decision-making resulting in more timely decisions based on higher quality information.

Data Warehouse has a Record of Failure

This is the third attempt at a data warehouse. The first two failed and the general feeling is that this one will also fail. What can a project manager do to dispel the negative conventional wisdom about the data warehouse?

Sid Adelman:

Talking up the data warehouse and telling everyone how good it’s going to be will be a wasted effort. The only thing that will convince this organization is a successful implementation. The project manager should deliver something of value and deliver it quickly. The project’s business sponsor should be asked to tout the success of the project and to point out specifics on where the data warehouse made a difference to his or her department.

Joyce Bischoff:

First, understand why the first two projects failed and address those issues in the project plan. Ensure that project members are well trained and that the organizational issues are addressed. It would probably be helpful to bring in a high-level data warehouse expert from a consulting firm to act in an advisory capacity to ensure that the project addresses critical issues.

Douglas Hackney:

The first step is to perform the due diligence necessary to fully understand the failure drivers for the prior efforts and to mitigate those drivers in the current initiative. The second step is very important and is related to branding. You must create a new brand name for the project that does not use the term data warehouse. Thirdly, you must focus specifically and exclusively on delivering incremental relief of life threatening business pain.

Chuck Kelley:

Well you know the old saying “Third time is a charm!” It would be nice to know why the first two failed. There are many reasons for failure, and most of them are not technical, but political/personal.

The data warehouse project manager’s critical role in this third attempt is to:

• define a clear business case, develop the consensus understanding of what the data warehouse will do and will not do,
• create the appropriate committees with the right people (both the business side and the technology side) on them to aid in the development of the data warehouse,
• keep a constant presence with business users letting them know what is happening, what will happen next,
• continue to capture feedback on what is going well and not so well.

The data warehouse project manager needs to find a senior management champion, someone who understands the need for the data warehouse and can articulate it to the other members of the senior management team. The data warehouse champion will be used to support the building of the data warehouse as well as acting as the arbitrator of the issues between the groups.

David Marco:

It is important to understand why the previous initiatives failed and to have a plan that will mitigate these issues for this third attempt. The project manager must be honest about why the previous attempts failed. Don’t gloss over the problems because they are likely to be the same problems that the project manager will face.

Larissa Moss:

Hopefully the project team conducted post-implementation reviews on the two prior data warehouse projects to learn from their mistakes. The project manager can use the review results and other sources of information about data warehouse development to show the users and management that the third attempt will be different. He should set up a meeting with all stakeholders and briefly cover the reasons for the prior failures, followed by a review of his different approach for the next project, showing how he will avoid the prior pitfalls. He should also set up a weekly communication channel (meetings, emails, or Intranet web site) to convey ongoing progress as well as roadblocks and resolutions on the project. The project manager should also engage the users and the sponsor to promote the data warehouse efforts and their progress. A bad reputation is not easy to overcome. But given good communications and enough time, a well-organized and well-managed project should produce positive results — and positive results are the best way to recover from a bad reputation.

Clay Rehm:

Instead of spending time talking, just do it. How? Every single project team member must work hard to produce deliverables each week, communicate every day, keep a positive attitude even when others around you are negative, and most importantly, don’t let up. Always have a smile on your face and tell yourself and everyone you meet that you we will succeed!

Okay, so maybe that sounds easy… so how do you motivate your team? It is up to the project manager to keep everyone excited about the data warehouse project. The disposition of the project manager will rub off on the team, good or bad. This means the body language, tone of voice, and expressions on the face of the project manager can do a lot for the morale of the team.

Staff the project with team members who have positive attitudes, who have experience with difficult projects and are willing and able to do what it takes to get the job done on time. This means staffing with people who are willing if asked to work 15 hour days or 7 day weeks.

Even if the team members do not have experience with a given tool or technology that the data warehouse will use, determine if the team member is willing to learn and is quick to learn a new tool under the most trying of circumstances.

Since there is a history of failure, consider retaining a consultant who has experience with data warehousing and have that consultant provide best practices, standards and templates.

The following are best practices to keep a project from failing:

1. Get close to the users and become their friend.
2. Get to know what the users need, and support those needs.
3. Take a personal interest in the project.
4. Communicate through the use of diagrams; everyone loves visuals.
5. Document current state, document desired future state and show the steps to get there over time.
6. Always have a positive attitude and be easy to get along with.
7. Tell yourself that failure is not an option.
8. Sit close to your users.

Moral of the Story: A team filled with pride and positive attitudes can go a long way.