Building Successful Prototypes

Building a successful prototype starts with defining its purpose and setting its scope. The purpose and scope of a prototype can never be the implementation of a full-scale BI application, which is comprised of an ETL process, an access and analysis application, and a meta data repository. There are two main reasons why a prototype can never produce a complete BI application.

While portions of the ETL process and some functionality of the ETL tool can be tested in a prototype, the entire ETL process is too complicated and would take too long to be an appropriate scope for prototyping.
Similarly, the design and some functionality of the meta data repository can be tested in prototyping, but developing a robust, production-worthy, enterprise-wide meta data repository is outside the scope of prototyping.

Therefore, the most appropriate and the most common purpose and scope for prototyping is to demonstrate the overall usefulness of the access and analysis portion of a BI application by using a small subset of functionality and data. Consequently, prototyping is the best way for the project team members of the Application track to perform "systems analysis," which is systems-focused analysis of functional requirements that leads to application design. To take it a step further, if the BI project team chooses to build an operational prototype, it is conceivable that after several prototyping iterations the operational prototype can evolve into the final access and analysis application.

Once the prototyping activities are in progress, it is quite common to make new discoveries that lead to new requirements, which can affect not only the scope of the prototype but also the scope of the source data analysis activity, the ETL process, and the meta data repository. Be sure to review and renegotiate the project constraints when the scope changes, and be sure to communicate daily with the project team members of the ETL track and the Meta Data Repository track.

Prototype Charter

Prepare a prototype charter, which is similar to a project charter but much smaller and less formal. A prototype charter is an agreement between the business sponsor and the IT staff for developing a prototype. It should include the following sections:

The primary purpose of the prototype, for example, whether the focus is on testing queries for marketing analysis, demonstrating executive information, running a financial analysis report, or fulfilling another specific purpose.
The prototype objectives, including a statement of what type of prototype will be built. Each type of prototype takes a different amount of effort and produces different results. It must be clear to the business people what the limitations of the prototype will be.
A list of business people who will:

- Participate in building the prototype

- Sign off on the prototype

- Use (test) the prototype
The data, including information on the type of data, the amount of data, and the consolidation level of data that will initially be brought into the prototype
The hardware and software platforms on which the prototype will be constructed and the language in which it will be written.
The measures of success should be itemized for the prototype. How will you know whether it was worthwhile to prototype portions of your BI application?
An application interface agreement is also important to cover the following:

- Compliance with standards (or development of standards if none exist)

- Necessary level of understanding and skills required

- Ease of use (" user -friendliness")

Regardless of how much we use the term " user -friendly system," it is still an oxymoron, like a " simple programming change." In most cases, we seem to be looking for " system -friendly users" instead of developing " user -friendly systems."

Express the goals for ease of use in terms of quantifiable criteria for:

The minimum time it takes to learn the new application.
The speed of task accomplishment (e.g., time to analyze a market condition).
The retention rate of queries over a period of time.
Subjective satisfaction; business people like applications that are intuitive and forgiving .
The effectiveness of the help function (if included in the prototype). Is the help function really helping people resolve problems? Are the business people making use of the help function frequently? What is their feedback about the content of the help function?

Guidelines for Prototyping

Create prototyping guidelines and communicate them to all prototype participants . Table 6.7 lists some sample guidelines.

Additional considerations appear below.

With each prototype iteration, plan to expand the number of data types, and plan to increase the functionality and the volume of data.
Keep the type and placement of GUI components consistent among prototypes. If you are choosing a pull-down menu for certain types of displays, do not switch to radio buttons on another prototype. The business people may need to reach consensus on some basic standardization for the BI decision-support environment.

Table 6.7. Prototyping Guidelines

Do not deviate from the basic purpose for which the prototype is being developed.
Develop a working prototype quickly; therefore, keep the scope small.
Acknowledge that the first iteration will have problems.
Frequently demonstrate the prototype to stakeholders.
Solicit and document top-down as well as bottom-up feedback on the prototype.
Ask for ongoing validation of the prototype results.
Continue to cycle between demonstrating and revising the prototype until its functionality is satisfactory to all parties.
Review your prototyping approach and modify it if necessary before proceeding with the next prototype iteration.

Skills Survey

The business people who will participate in the prototype and will later use the BI application should be evaluated to determine their skill sets. What level of business knowledge do they have about the business functions addressed by the BI application? Are they experts in using computers but do not know much about the business functions? Or are they experts in the business functions but have not used a computer extensively before?

You may want to use a skills matrix, similar to Table 6.8, to assess the skill sets of the business people in order to determine how simple or how sophisticated the prototype and the final BI application need to be.

If the survey shows an overwhelming number of people with XX skill sets (expert in computer skills and expert in application knowledge), build as many shortcuts as possible. If the survey shows an overwhelming number of people with BB skill sets (beginner in computer skills and beginner in application knowledge), provide as much guidance and help functionality as possible. If the survey shows an overwhelming number of people with any other skill set combination, you need to take a hard look at your proposed solution and decide whether only one solution will be sufficient. If the BI application is designed for only one level of skills but has to satisfy everybody using the application, either it will be perfect for beginners but the experts will be bored and frustrated, or it will be perfect for experts but the beginners will be lost and frustrated.

Table 6.8. Skills Matrix

	Computer Skill
Business Functions Knowledge	Beginning (B)	Advanced (A)	Expert (X)
Beginning (B)	BB	BA	BX
Advanced (A)	AB	AA	AX
Expert (X)	XB	XA	XX