Agile Montage

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.

If you look closely, Role Centric and Process Centric approaches are really not that different at all. It baffles me anytime I see Analysts struggling to start or not feeling comfortable with the approach they have chosen.