Archive for December 2007
A lot of projects, specially if they are Greenfield, require a Business Analyst to concentrate on the As-Is/To-Be world. Some people call it the Current Method and Proposed Method Analysis too. This is probably one of those workshops/session with the Business where, typically, the Analysts sweat the most. It is also the one that is difficult to start and sometime also the one where you never know until the end if you took the right approach. The reasons are many, with the biggest of them being the different views an Analyst can take to understand and model the process. You can either study what the different roles involved do (Role Centric) or you can study what the different processes in various departments (Process Centric) are in the current world. Usually, the As-Is has a very significant role in determining the To-Be world. This is what makes an Analyst nervous because if you start with the wrong approach, you risk ending up in a To-Be world that may not be the ideal solution to the problem. Now, a lot of times projects may not be greenfield - they can be conversion where an application is being converted from one technology to another. A lot of projects, in certain domains and specially large companies also include product swaps - replace a custom written application with a COTS product but customize and configure it to meet the needs. In these scenarios an application already exists. Example Imagine there's a bank that has an Internet presence where its customers can carry out their standard banking transactions online. This application was custom written in the late '90s where there were not many banking and payment technology solutions available out of the box. But now there are, and our bank wants to move on to this product because there are 100 other banks using it, amongst other reasons including better and robust technology, technical banking expertise that is not be maintained in-house, etc. As an Analyst you are task is now to roll out requirements for this new banking solution. The temptation in the above mentioned scenarios is to start going screen by screen in the current application, recording the existing functionality and writing requirements for the new one. Other than the fact that with experience this approach becomes less favorable, let me also introduce another mini-scenario. When this project was sold by the technical team to the business, it was pitched as an opportunity to throw away some existing functionality and introduce a slew of new e-services. Now, where do you start. Would you want to be Role Centric or Process Centric? Role Centric approach would be, at a higher level, be to identify the different roles that interact with the current systems, and their goals. e.g. New Customer > Wants to register or Existing Customer > Execute Electronics Funds Transfer (EFT). Process Centric approach would be to identify different areas of the business and the processes that can be done in the current application. e.g. Customer Service Center > Registration process or Core Banking > EFT process. So, which of these - Role Centric Vs. Process Centric is right? This is where the uncertainty creeps in and decision paralysis strikes you out. My answer - none of them is wrong. However, process centric is usually efficient to do. It avoids having to repeat almost similar processes for different roles. Roles can then be identified for each of those process steps and the exceptions can be recorded. If, on the other hand, we choose to go the Role Centric route, it is highly likely that for each role, similar processes with slight variations will induce repetitions. The role centric approach invariably leads to a workflow analysis. Same Stories Regardless of which approach you take, both of these As-Is and To-Be approaches result in stories that should not be very different. Some stories from the above examples will be:
- As a New Customer I want to register online on the bank site.
- As an Existing Customer I want to transfer funds electronically to external/internal accounts.
Picture take from: http://www.implementingscrum.com/blog/2006/09/11/the-classic-story-of-the-pig-and-chicken/
Isn't it really? That's not to say that people are talking less. It's just that there is very little conversation in all that talk. Listening, which is an extremely important component of any conversation, is a painfully hard skill to find. It is not just me who feels that. Today someone asked me about my educational background. When I told her that I am an engineer, her first reaction was, "Really? See, I have a few nephews and nieces that are engineers, but it is hard to strike a conversation with them." I asked her the reason(s) and she said it is most likely because they don't listen much. Isn't lack of listening abilities very common in the industry, specially software development? The more experienced we get the more we get disillusioned that we know it all - been there, done that. This leads to a verbal exchange of ideas that isn't a conversation at all, many times. Conversations, however, are the bread and butter for Consultants and Business Analysts. If conversation is a dying art then they should be concerned. So, if you ask me for one skill that is at present very important for a BA to have, it'd have to be listening.
Last week in my post on Information Radiators , the description of the term made it sound like as if it was coined 'by' ThoughtWorks. This is not the case, as per Alistair Cockburn himself. I apologize for the confusion. The term was coined in 2000 or 2001 by Alistair Cockburn while he was visiting ThoughtWorks (while staring out at the walls from Martin Fowler's office, describing the idea of "convection currents of information flow" to Martin Fowler and Ward Cunningham), and subsequently written up by Alistair in his books and articles.
One of the tools and techniques, which I have seen, being used by many highly functional teams is Information Radiators.
We have all come across them in some form or fashion at work or in public places that we often visit. The term "information radiator" was termed in Thoughtworks (source: http://alistair.cockburn.us/index.php/Category:Information_radiator) and refers to a publicly posted display that is large so that it is easy to see. When I first heard of the term I didn't get to see an example. That left me with no picture of how to implement information radiators, if I had to. Now, I have lots and here are some pictures that may give you some idea of the nature and size of information radiators. In the pictures on the right, there's different kinds of them:
- Large card walls or card tables that grab people's attention as they walk in into the workspace/team space.
- Blown-up progress charts, etc. that the team members can look at from far corners of the work-space.
- Flashing light that illuminates any time there's a failed build is yet another kind of information radiator. You can see one sitting on the top left corner, on a cubicle wall, in one of the pictures.