Published in TDAN.com July 2000
This article is excerpted from a book titled, Data Warehouse Project Management scheduled to be published by Addison Wesley Longman in August of 2000.
“If we could just get the user out of the way, we could get some serious work done.”
Understanding the Business
If you perceive yourself only as a technologist, your perception must change. You must understand the needs of the business, the direction of upper management and the strategic vision of the
enterprise. As much as possible, the data warehouse must support those needs, those directions and that vision. Without a solid understanding of the business, your project will surely fail. This
section suggests how to gain an understanding of the business.
Terminology
Whatever the language of the business, be it banking, retail, manufacturing, insurance, health care or education, it is imperative that you know the industry-specific terminology and feel
comfortable using it. Assuming you and your team are more technically knowledgeable than the users, this technical knowledge must never be flaunted. Users hate technobable. They normally see it as
a way technologists use to distance themselves. Never speak in a condescending fashion. If technology must be explained – it doesn’t always have to be explained – do it in a way
they will understand, and do it without talking down to them or boring them.
Learn what Drives the Business
You must know the concerns and problems of the users, their goals, their priorities and what keeps them up at night. If your organization is publicly traded, review the chairman’s letter to
the stockholders. Your CEO has probably made statements internally and to the press about your organization’s vision and where it is going. Follow the trade and business press on articles
about your company, your industry and national as well as global conditions that affect your organization.
Educate Yourself
It is important that you know your organization from the perspective of the users. There are classes, seminars, conferences, books and periodicals for your industry. Familiarizing yourself with
industry information is time and money well spent. If you are supporting the Marketing Department, hang out at their watering hole – you will hear their concerns, better understand the power
structure, learn what really drives them and what they care about. If you are supporting the Actuarial Department, attend their interdepartmental actuarial meetings.
Educate the Team
Some of the technical people on your team may balk at having to learn anything that is not specifically IT related. However, to be able to talk to the users, they must know the business, not to the
level the users do, but in enough depth so that the users will accept them. IT needs to understand that it is the business that ultimately pays the bills. They need to understand that, without user
support, their best efforts will be wasted. Their efforts would be like putting on a stage play to an empty theatre.
Types of Users
Not all users are created equal. There is no “average” user. They have different levels of skills, experience, desire to learn, degrees of comfort with technology and patience. Treating
them all the same is a mistake. You must understand each type of user and customize your approach, training, level and type of support. You must allow different amounts of time for different users
to become capable of using the system. This section describes different types of users.
Technophobe
This user has been dragged kicking and screaming into the technological 21st Century. He looks at any and all problems associated with the project as justification for his membership in
Luddites-R-Us.
You are going to have to make it very easy for him to use the system. He will prefer very simple over increased functionality and over additional information.
Tech Wienie
This user carries a cell phone, a Palm Pilot and a pager. The Internet is his primary source of information – about everything. He manages his life electronically, loves technology and
believes that all the opportunities and challenges in both professional and private life (much to the dismay of his spouse) are technical.
The tech wienie will choose the technologically elegant solution even though it is inappropriate for the business. This user will frequently want to get involved in making all the technical
decisions even though most should not concern him, and even though he is not qualified to make the decisions.
Hands-Off
This user wants all decisions to be made by someone else, usually IT. Even though this user defers to others on decisions, he is still willing to assign blame when a poor decision is made. While
most IT choices do not necessarily require input from the users, there are some choices, specifically the query/analysis tool where the users’ input is important. Most users will want to
participate to some extent. If they abdicate this responsibility, they must be willing to live with a system that may not be totally to their liking.
Control Freak
This user wants to control everything about the project, not just for the business but for everything IT does that relates to the project. He wants to be involved with every decision, big and
small, and to validate everything. If he is not invited to every meeting, he feels left out and will retaliate.
An understanding of the data warehouse roles is mandatory. This user needs to understand that his bandwidth could probably impact the schedule, and so should neither take on tasks beyond his area
of expertise, nor should he delay the project while everyone is waiting until he makes up his mind.
Communicating with the Users
The user sponsors are not there for your convenience. They are busy and you must respect their time and use their time efficiently.
Listen
User sponsors will inundate you with requirements. It’s very important to capture and document these requirements. The requirements should be validated with the sponsor for clarity,
specificity, priority and accuracy. The sponsor will want to know you heard what was said. It is also important that you ask your sponsor to prioritize the requirements in case the scope turns out
to be too large and you have to break out data and functionality into implementation increments.
Status Reports
Let’s face it; most of us hate writing status reports and those that do like to write them probably have some genetic deficiency. We need to change the way we look at status reports. Start to
view them as an excellent way of communicating with the users as well as communicating with your management and your sponsor. The status report will have “Accomplishments,” “Next
Period’s Planned Activities” and “Issues.”
The status report is not the place to exaggerate your accomplishments, but it does provide an opportunity to give credit to team members and others involved with the project. The status report is a
vehicle to give notification of problems, indication of the need for more resources and advanced warning of actions that must be taken to overcome roadblocks. Management hates surprises and hates
to not know what’s going on, especially when everyone else in the organization appears to know of impending doom. It makes them look bad.
On one project any “Issue” had to be explained to the CIO along with a complete plan on how the issue was to be resolved. Needless to say, this procedure was much too threatening, and
as a result very few issues were reported – that is, until it was too late for management to correct the problem. Management was kept in the dark as long as it was possible. In fact, project
managers were instructed not to put any issues in their status reports. The CIO’s objective of staying in touch with the problems did not succeed. This was clearly a case of upper management
“choosing” to cut off communication from below.
Meetings
Meetings can be a time-efficient means of communicating, discussing problems and options and getting resolution and concurrence to decisions. Meetings can also be an incredible waste of time. Be
sure that your meetings are in the first category. You will get a reputation for the types of meetings you run. There are some standard rules for good meetings:
- There is an agenda – preferably sent out ahead of time so that people can decide whether to attend, and be prepared for the topics on the agenda and for their assigned responsibilities.
- The meeting starts on time and ends on time.
- Time is not taken from the meeting to brief a tardy participant.
- The agenda is followed. Topics not relevant to the discussion are tabled for future meetings.
- There is only one person speaking at a time.
- Responsibilities for activities are assigned and those to whom they are assigned are called on to report on the progress of their activities.
- Minutes of the meeting are distributed as soon as possibly following the conclusion of the meeting.
- A person other than the person running the meeting should take minute notes during the meeting.
- The person who called the meeting controls unruly participants and brings the discussion back to the published agenda.
- Coffee and donuts are available – An informal study found that when people know there will be coffee and donuts, attendance improved by 22.638%. Knowing there will be donuts and that the
good ones are gone early also encourages people to be on time.
Validation and Concurrence
During project development, many decisions are purely technical and need no validation from the users. Examples might include the choice of a data modeling or ETL tool. Other decisions absolutely
need user validation. Examples include a specific business definition for a data element and the allowed access to the data from another department. In these latter cases, ask for validation and
provide a deadline for the validation. Appendix 5.2 has a template for User Validation.
In meetings and conversations, the user sponsor will often make statements, address issues and make decisions. It’s very important that those utterances be captured and validated. You may
have heard incorrectly or the importance of what was said may either be much more or much less significant than your perception. Document the sponsor’s statement, pass it back as a memo of
understanding and ask for the sponsor’s validation.
Informal Communication
This is the information received in the elevator, by the coffee maker and in the rest room. Informal communication comes from a spouse who works somewhere in the organization, from peers, from
people in your old department and from your well-established network. This is often how IT management or a business sponsor finds out that the project is in trouble. Sponsors and other management
don’t like bad news but, again, and more importantly, they really don’t like surprises.
Lining up Support
Before going in to a meeting where you are scheduled to make an important, and possibly controversial proposal, have discussions with the key players prior to the meeting, discuss your plans,
solicit their comments and ask for their support.
User as a Co-project Manager
The most effective means of communicating with the users is to have “one of them” do the communicating. Read Chapter 8 to get ideas for co-managing the project. If a user co-manages the
project, he or she will be able to talk and write to the user departments in their language and do so with unmatched credibility.
Summary
Satisfying the users is one of the Critical Success Factors of implementing a data warehouse. Regardless of how good a job you think you have done, if the user is not satisfied with either the
capabilities of the system, the quality of the data, the response time, the timeliness of the data or the availability, your project will be seen as a failure. You must understand the business. You
must be aware of and support different types of users and communicate well and often with them. A Project Agreement will keep you on track and help to prevent misunderstandings. You must be able to
sell the project to management to be able to get the budget and resources you will need to continue to enhance the data warehouse.