Search This Blog

Saturday, July 31, 2010

Requirements in pictures not words

As I recall from Pysch 101 - taken in the 60s so my recollection may not be exact - human beings think in pictures and images rather than words. How the psychologists figured that out I do not know. Words, both verbal and written, are our attempts to describe those pictures in our heads. Using diagrams, drawings, models, etc. gets us even closer to the pictures in our heads. However, we also do not think statically. Our pictorial thoughts are in association with other images in our head, and tend to be more dynamic, that is moving. To accommodate this, we develop prototypes that show the data in conjunction with the interface in conjunction with the process of using both. Now our model gets really close to what we see in our heads. Working with information systems, however, the picture we have in our heads - at least in the users' heads - is somewhat foggy or vague since it deals with abstract and future reality, and really doesn't clear up until we see the prototype in action.
Now here's the kicker. The sufficiency bias says that we will be satisfied with something that satisfies our specific needs rather than to hold out for something better. This means that what we are looking at now becomes the picture of what we want in our heads. Later, we might see something else that changes the picture and expect the delivered system to have that something else. And round we go.
Isn't inexact science fun?

Thursday, July 22, 2010

Change and Transition

Many times we in IT discover as we are solving a business problem that the closer we get to implement the solution, the less enthusiastic the business community appears to be about the upcoming change. The same people who were anxious to get started and get the problem solved and remove the pain or extra work they were going through, now seem to erect roadblocks and obstacles to the incoming changes. It is very frustrating to spend time writing the software and preparing the system only to find the process workers resistant to the solution. The symptoms are late stage changes, reversals of choices, the sudden appearance of new authorities in the mix, an unexpected change in the guard, and a seemingly unending focus on minor details and testing.

Daryl Conner explains it this way, in Managing at the Speed of Change: “some of the strongest resistance occurs when we get exactly what we asked for – if what we asked for causes a significant departure from our expectations.” Clearly, coming into a new system or way of doing things is going to vary from a process worker’s expectations. The closer we get to the delivery, the more concerned and fearful of the change the process workers become. That’s when the business community, consciously or unconsciously, invents various strategies for slowing up the changes. Business analysts recognize the syndrome and work to make the transition easier for the business. Keep the focus on the benefits of the new system or enhancement, be honest about the risks and obstacles facing the changeover while being open about what is being done to overcome them to make a smooth transition. Primarily, business analysts keep the communication flowing among all parties removing as much of the mystery normally associated with technology as possible.

There will still be natural resistance. This resistance, however, can be made positive by listening to the opposing comments which may identify new obstacles that can be overcome. In the end, the change is inevitable, and the business analyst can do much to make it easier for those being changed.

The business analyst’s contribution

Perhaps the most important contribution a business analyst can make to the success of an IT project is to define the problem to be solved and determine what constitutes a successful solution to the problem. A simple question of the sponsor or customer or even users should accomplish the task. "What will you need to see or what will you need us to do to prove that we have solved your problem?" If they don't have an answer to that question, perhaps they don't really know what the problem is, or maybe they don't really have a problem, or at least one that you can solve. When we do get the answer to that question, we have the basic "why" of the project, and what our ultimate target is.

I believe business analysts are more than stepping stones, interpreters, translators, emissaries, documenters, or glorified administrative assistants. i believe business analysts are business problem solvers and the solutions do not necessarily have to be IT solutions (e.g. process improvement solutions). The outcome of a business analyst's work therefore is a solution document stating what the solution is - what the business needs to do to solve the problem, and it may or may not be a requirements document, or the total solution involving the change to business processes may include requirements.

Tuesday, July 20, 2010

Drowning in the waterfall

During a recent exchange on a business analyst forum, a poster complained that he was “drowning in the waterfall”. Much of the "drowning in the waterfall" is really drowning in paperwork not the process. The waterfall doesn't in itself call for a mass of documentation; the paperwork is the result of the way the waterfall is applied in many organizations. Much of the paperwork that accompanies a development life cycle is not designed to assist or enhance either communication or the development process. It is there solely for control: for management to be assured that certain activities have been accomplished and they have a document that proves it; as a measuring device to demonstrate that phases or milestones in the process have been achieved; as a verification artifact that someone can use to check up on the progress at points along the way; to provide disinterested parties a glimpse at what is happening with the development; to give the auditors proof that the process is being followed; and so forth. Where possible try to turn permanent, persistent documentation into transitory documentation that you can throw away once the document has served its purpose. Write designs on white boards. Do status reports verbally in stand up meetings of no more than ten minutes. Communicate face to face rather than via documents. It saves time. It saves trees. And it keeps your head above water.