Process engages business users early and often.
by Sid Adelman
A major problem in data warehouse development has been the disconnection
between what the business side needs and what IT delivers. Business users have
a difficult time articulating their requirements, especially business metrics,
the types of analyses they expect to perform and the key performance indicators
on which they operate.
The traditional approach has been to gather requirements up front, then wait
until the testing phase to re-engage end users. Unfortunately, they are often
unhappy with the outcome. The resulting shortcomings might include:
 |
A lack of the necessary data or metadata
|
|
An inappropriate level of detail
|
|
Cubes that are hard to negotiate
|
|
A business intelligence (BI) tool that is too difficult to use
|
|
A mode of delivery that is ugly or unusable
|
Any of these issues will make for an unhappy business user and a lightly used data warehouse.
Prototyping helps ensure that end users get what they asked for.
Get business more involved
The business users of an organization must be closely involved in the development of
any BI application; however, the challenge is getting them interested. BI developers
are constantly complaining about businesspeople who are invited to meetings but do
not show up, or those who send underlings who are ill-equipped in their understanding
of business requirements or unauthorized to make decisions. As a result, the project
will either be delayed or go forward with an erroneous understanding of what users need.
Prototyping, however, offers a means to pique end users' interest. As they see an
evolving set of deliverables with their data and a solving of their informational
needs, they will choose to be involved. Then they will need little prompting to
attend meetings or participate in demonstrations of the prototypes that will become
the final product.
Involving only the power users or a select group from the user community is a mistake.
A broad sampling of users is necessary to ensure that all users receive the information
they need. An additional advantage of such diversity is that those involved will help
sell and champion the project to their respective groups.
How prototyping can be used
Prototyping in the data warehouse world is a representation of the ultimate solution.
A smart prototyping process presents users with representations of what they will
get with continuous refinements until they sign off. A prototype that workers
dislike should not be considered a failure. Rather, it is a source of information
to correct a problem that could have caused a real failure if the original design
made it into final production. The primary idea of a prototype is to uncover potential
problems and then correct them.
Prototyping has the added benefit of keeping IT and business management
involved and interested in the undertaking. This means management will be less
likely to pull resources from the project. There is less chance that key people will
be lost to other priorities and a greater chance that the enterprise will get the
budget and resources needed to make the project a success.
Producing better results
Prototyping is a powerful capability that, if executed properly, can markedly
reduce the time to deliver, minimize effort wasted on the wrong deliverables and
greatly improve user satisfaction. By promoting communication between IT and end
users, prototyping creates a clear, common vision for all. The organization's IT
professionals will better understand the needs of the business users, and the users
will know the capabilities and limitations of the final product. The results are a
better process and a better solution.
T
| Prototyping dos and don'ts |
|
DO
| > |
Introduce the goals and objectives of the prototype and make sure
the business and IT communities understand them.
|
| > |
Set user expectations early and often. If extensive work is required for data cleansing,
testing, tuning, user training and anything else that will take time and effort, users
should know they will not get a production version of the prototype until those
activities are completed. Give users a realistic estimate of the completion date.
Set expectations for what they will not be getting.
|
| > |
Choose a prototype lead who is experienced and has an easy
and open way of communicating with the users.
|
| > |
Understand the difference between what users want and what they must have.
|
| > |
Make metadata a key component of the prototype so users will see and
understand the sources, the transformation and the business definitions of the data.
|
| > |
Let users know that their involvement in the prototype process is critical to the
project's success, and the scope agreement should include their participation in the
prototype activities. Users should also know that the project schedule is
based on their active participation.
|
| > |
Record the sessions or have someone take notes on the users' reactions to the demo.
That way you will know what was actually said and be able to make appropriate changes.
|
| > |
Develop a slide presentation that evolves during the prototype to keep all stakeholders apprised
of what's happening. It should include the prototype progression, the results, the names of
those involved, issues and next steps.
|
DON'T
| > |
Use technical language or IT acronyms in demonstrating the prototype.
Instead, use business terminology.
|
| > |
Put the focus on the business intelligence (BI) tool, but rather on the delivery of information.
|
| > |
Bring in business users too early; wait until you have something of interest to them.
|
| > |
Show off the system's bells and whistles or your technical skills. Users are likely to find the
intricacies of the extract, transform and load process boring, so focus on the business solution.
|
| > |
Employ old or incomplete data. It will raise questions and concerns,
and users will not be properly focused. Be sure to use current and complete data.
|
| > |
Bring users in for minor corrections or changes. Be sensitive to the appropriate use of
their time as well as their level of interest. Some might want to see every minor change,
while others are looking only for major milestones.
|
| > |
Succumb to scope creep. Users must understand that increasing the scope will delay the project's
implementation. Everyone should consider the phasing capabilities of BI.
|
| > |
Expect the prototype to solve all of your issues, especially the data quality problems
associated with the operational source data.
|
—S.A.
|
|
Sid Adelman is a principal in Sid Adelman & Associates, which specializes in
planning and implementing data warehouses.
Photography by Brad Hines
Teradata Magazine-September 2008
|