Defining Goals

The business analyst is often associated with goal making, the definition of a goal. While the project manager is the role primarily responsible for the goal of the project, the business analyst is the one who defines the goal of the product, what does the organization intend for the product to do for it. Is the goal of a new product to increase revenue, stay competitive, move into new markets, complete a product line?

Clearly the goal associated with solving the particular business problem has a great effect on how the project is done and how success is determined.

To assist the organization in defining an achievable goal business analyst needs to understand what a goal is.

A goal according to the dictionary: "the result or achievement toward which effort is directed; aim; end."  Being the result, it must state something to be achieved. However, saying "our goal is greater safety for our workers (using Georgy's last item)" does not help us.  How high? Will one defect less than before be considered 'higher quality'? It satisfies the goal. 

So we need to apply a measure to the goal for it to have meaning: "Our goal is to have ten percent fewer worker injuries."  The goal now has more meaning in terms of achievability, but the results are still questionable. Ten percent fewer injuries over the next day? the next month? the next century? 

For the goal to be effective - and what is the purpose of stating a goal if we don't care whether it achieves the results? - we need a time frame for achievement. "Our goal is to have ten percent fewer worker injuries this fiscal year than last fiscal year." 

Three elements of a functional goal (functional means the results are achieved and not just stated): a statement of achievability, a measurement that prove it has been achieved, and a time frame by which it should be achieved. Then we can state the goal (what results we expect) and achieve those results - and most importantly for everyone, know that we have done so. 

Prototyping and the Busienss Analyst

A prototype is "the original or model on which something is based or formed" according to the dictionary.  Prototyping is the act of creating such a prototype.

There is no part of the definition that suggests prototypes are done a certain way.

Therefore storyboards can certainly be considered prototypes as can wire frames.  Each should be done iteratively with increasing layers of understanding and refinement between the person creating the prototype and the person for whom the prototype is being developed. Use cases can also be considered a prototype. Anything that allows others to see the picture that is in your mind of the final solution is a prototype.

I have come to the understanding of the term 'prototyping' as the iterative actions and interchanges between developer or business analyst and the business person to create the model on which the software for a system is based. As early as the 1970s working on minicomputers with businesses that were new to automation, we found it easier to mock up the interfaces and operations rather than try to explain the concepts. Prior to that we used paper prototypes to show users what their reports would look like when the system was completed. In those days there was no user interface to prototype.  

There are issues and concerns with dynamic prototyping which describes animated, usually computerized prototypes.  I have found the viewers of a dynamic prototype using low tech tools such as white board or flip chart are much more likely to request changes and are more willing to experiment until they find the metaphor that works for them than they are with the dynamic prototypes (such as iRise).  I think it’s a cognitive thing. Viewing anything on the computer has the imprimatur of being permanent and having taken a lot of work to create. The viewer, usually a user of the system being modified, is hesitant to suggest changes. When the same screen is shown on a piece of paper, the viewer will make all sorts of changes without concern. 

Yes, in some ways a Requirements Document might be considered a prototype, but the review sessions tend to be more wordsmithing than productive. The prototype concept would have you create prototypes, either static or dynamic, and keep iterating them until they fairly accurately represent what the final solution will be, and then document the prototype in the Requirements Document.