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. 

Change leaders or Lead Change

Change could be led by current leaders who are inspired by new ideas (which may come from someone or something else) or who realize (or are shown) that the current direction or the existing state of things just is not right or is not working. 

I think it is somewhat disingenuous to assert that the situation can change but those who are leading the situation cannot. To suggest that change only comes through  revolution (replacing current leadership with new and different leaders) does not allow for the Eureka! moments or the "oh, my God, what have I done?" moments. We have plenty of evidence historically of leaders changing their politics, position, beliefs and so forth, and in many cases that is exactly what makes them leaders, as opposed to those who are intransigent or stubborn and go down with the ship instead of finding a new way to save it.

And there are plenty of examples of leadership changing, but nothing else does.

Career path of the business analyst

My thoughts about the career path of the Business Analyst may be considered a bit extreme by some, and on the other hand may be embraced immediately by others. I believe the career path for the Business Analyst is the Executive Suite.  After a career in various levels of business analysis, playing various roles, applying the inherent skills of business analysis, the natural next step from the position of business analyst is at the strategic and leadership levels of the organization.  Why? 

The current crop of CEOs, as has been the case for decades, come from sales or marketing for the most part.  The kind of outgoing charismatic person usually associated with the sales and marketing position is the kind of person that is noticed and elevated as  CEOs and Presidents.  The charisma that helps a person be a great salesperson is the same as that which is typically possessed by  those considered as leaders. However, in today's world it is necessary to only know the organization's product and customers and market position and competition. Those evolving the strategy for the organization need to know technology (computer and otherwise), systems, business processes, and how all the various parts of the organization fit together.  It will not be enough to be a figurehead, plot a direction to increase sales or add new products or buy companies and make speeches at college commencements.

And who in the organization has the experience with both the technical and business sides of the organization? Who is trained with the skills of facilitation, negotiation, mediation, investigation, elicitation, applying influence, and resolving conflict? Who spends their time defining business problems, applying critical thinking to situations, coming up with solutions to business problems, viewing the situation from a systems thinking perspective?  Who is the organization's Chief Problem Solver? 

It is of course the Business Analyst. 

The Value of Observation

Observation is an information gathering or elicitation technique that is often overlooked by business analysts.  Sometimes it is impossible to observe the workers doing their jobs. There may be security issues, concerns about interfering with the work process, or simply physical limitations in the environment.  However, wherever possible the business analyst should seek out ways of observing the people as they perform the tasks and activities in the problem domain.  . 

The observation provides four beneficial things to the information gathering process:

1.    Observation lets you get an immediate view of, and feeling for, the overall problem domain, especially when you follow the business process from end to end.

2.    Observation gets you closer (and in participation you get all the way) to a shared experience with the people you are going to talk to

3.    Identifies questions that you need to ask

4.    Identifies actions, activities, decision points and processes that are so automatic that the process workers are not aware that they are doing it and would not mention it in an interview or meeting.

There are four types of observation:

·         Passive observation is when you walk through the business unit observing what is going on without any interaction with the workers.  Later you ask questions to clarify what you have observed

·         Active observation is walking through the business unit, but with the ability or permission to ask questions of the workers as you go. 

·         Participative observation is when you actually do the job – take the place of a worker or work side by side with them, taking notes along the way, and asking questions

·         Simulation occurs when there is no other way of observing. The business analyst enters a simulation of the business process.  Examples of simulations include the well-known Flight Simulator and other similar computer renditions.  But also there are usually training materials for new hires that can introduce the business analyst to the business process and some organizations have computer simulations of various user interfaces in the business process for use in training and process improvement that the business analyst can use to become familiar with the business process environment.  

Consider including the practice of observation as one of the elicitation techniques you use regularly in your business analysis process.

Type cast Business Analyst

It is sad that the business analyst has been typecast as solely a definer of requirements and to run interference with the business community. I tend to buy into the business analysts name - someone who analyzes the business to solve business problems.

There are two approaches depending on the business analyst's stance. A deductive or tactical business analyst responds to stated problems from the business. From that perspective, the business analyst would not be involved until someone identifies a problem - the difference between the current situation and what that someone perceives the current situation should be. Then the business analyst steps in to solve the problem and might in the course of defining the solution document some requirements for change.

In the second approach, the business analyst reviews the business process and identifies improvements or problems that could be solved to improve the process without being told there is a business problem to solve. For example, in the situation of a mechanic using a web site to help diagnose a problem with a vehicle (actual situation), the business analyst might suggest reorganizing the web site so that it reflects the natural way the mechanic uses the information instead of the logical flow of data that would be normally defined by a systems analyst or data base designer. The business analyst  observes the way the mechanic uses the website and suggest improvements not in the mechanic's process but in the way the computer system on the web site supports that process. Once the inductive business analyst's suggestion for improvement is adopted, the deductive business analyst (same guy, different hat) steps in to define the solution in a set of requirements that are implemented to improve the process.

Both business analysis approaches are valid and necessary to add value to the organization.