Oct 17, 2009 / Labels: , ,

Why I Like Being a Business Analyst?




Reading the last page of the book which has been lying on the table besides the bed for months is most fulfilling. I recently completed reading Outliers by Malcolm Gladwell. In this book Gladwell explores the reason why some people are so accomplished, so extraordinarily and more successful than others. Gladwell argues that some people are successful not because just because they are really smart, but success is a function of culture and community and family and generation the person belongs.


The book is a very good read and highly recommended. As you read through the book few things stick with you for  example the 10000 hour rule, the  trouble with geniuses, the Chris Lagan Story and the facts about airplane crashes.  But this one caught my attention the most, for a  job to  be satisfying, Gladwell says, it should have 3 qualities: Autonomy, Complexity and  Connection between effort and reward. This is how he describes: 


Those three things--autonomy, complexity, and a connection between effort and reward--are, most people agree, the three qualities that work has to have if it is to be satisfying.


Isn't this true? No matter how well you  are paid you can never continue and be 
satisfied with a job which is monotonous, non challenging under an autocratic(let’s say  non-democratic) management. This I like best about Business Analysis and being a Business Analyst.
Autonomy : Throughout the project lifecycle, process and requirements management is a highly autonomous job. Not to sound boastful but I have realized that I am never under pressure from managers or clients during the lifecycle (off course I make sure not screw up things) nobody interferes during the process or questions your approach, in fact there is less or no interference from the delivery teams during this period. All that I have to make sure that all stakeholders are well communicate and there expectation well mapped. It is indeed an autonomous task.
Complexity:  Well do  I need to  explain this point? We analyze the complex Business processes, liaison between various Business Units, work hard with the IT teams to  make sure that the solution is made right, negotiate requirements, help PMs in estimations...and what not and as Jeff Martin wrote in his post We help  the companies change .. Isn't it complex?
Connection between effort and reward:  Organizations have realized that experienced BAs are their most valuable resources. Their ability to communicate, facilitate and analyze makes them indispensable. Today companies need people who understand both business and technology well and BAs get amble exposure to both ...and yes they are one of the best paid professionals currently in market. 
I like my job. I am working with for an IT outsourcing company and have experienced this in my projects and with the pressure on optimization and cost I feel the BAs still enjoy more freedom then other roles in a project. Personally the most satisfying experience is the day when my role gets over, the requirement documents are signed off after a good review with stakeholders, when business user shows confidence in you because finally someone from IT understands their process, pains and needs, or when the sprint gets over and the stakeholders are satisfied after  sprint review. Or simple things like when the developers are confident about the requirement they are to write code for and the QA folks are clear about the testing scenarios or the PM is sure about the scope, effort and estimate. These things indeed make my job very satisfying and finally I am able to enjoy the inflight entertainment system on my  flight back  home.


comments (3) / Read More

Sep 27, 2009 / Labels: , ,

Business Analysis in COTS Environment- Part 2


Understanding COTS Products
Use of commercial off the self product is gaining popularity, specially where the Business needs matches those of one or more commercial IT market place segments like ECM, Collaboration, Enterprise Search, SCM, HRM, CRM, Business Intelligence etc. These components offer a promise of rapid delivery to end users, few organization can afford resources and time to replicate the market tested capabilities for these products.

For a Business Analyst, working in a COTS environment is different from a typical custom solution development projects primarily because the components are preexisting and are not designed to meet specific business needs. For BA it becomes important not only to know what the business needs are but to also understand the functionality of the COTS product how it is likely to change over the period of time. This understanding is vital as it help in doing a 'to-be' mapping of the business process and define more useful business and system requirements.

So how are these COTS products different? What are the key characteristics of these products and as Business Analyst what should I must know about COTS system in general? The SEI has identified following attributes of the COTS products and components:
  • The marketplace, not one system’s needs, drives COTS component development and evolution.
  • COTS components and the marketplace undergo frequent, almost continuous change.
  • Frequency and context of COTS component releases are determined at the discretion of the vendor.
  • COTS components are built based on unique architectural assumptions and are not constructed using a universal or consistent architectural paradigm.
  • There is at best limited visibility into COTS component internals and behavior.
  • COTS component assumptions about end-user processes may not match those of a specific organization.
  • "Vendor” is not a new name for subcontractor. Different relationships are required to have insight and to influence component changes.
  • COTS components often have unsuspected dependencies on other COTS components.
I have been working with COTS products ever since i started working as Business Analyst. I feel that it is must to understand the above mentioned features of an of the shelf product. It is not possible to know all the functionalities of a COTS product for a Business Analyst but the basic realization that these components are market driven and may not satisfy some of the project requirement prepared the BA for negotiation with business and IT.

References: EPIC: An Overview [ A must read]

Coming up:
  • BA in a familiar COTS environment i.e. when you know the product.
  • BA in unfamiliar COTS environement i.e. when you have no idea about the product's capabilities.

comments (4) / Read More

Sep 19, 2009 / Labels: , ,

Business Analysis in COTS Environment- Part 1

Summarizing the Process:

1. Ideally, the business process re-engineering(BPR) should happen and the business should be made aware of what the COTS tool can offer and changes that may be required in their current way of doing the business.
2. Ideally, the Business Analyst should be fully aware of the capabilities and functionalities of the COTS tool and help business identify the functionalities that the tool can offer.
3. Ideally, Agile methodologies should be adopted to built COTS based system to enable system development adapt as per business needs.
4. Ideally, the OOB features should be implemented with phased and with incremental releases.
5. Ideally 80-20 principle should be followed. 80% features coming OOB and 20% through custom development.

But system development is rarely Ideal. Often a COTS tools are chosen because some smart sales guy managed to influence the CIO or the manager in charge and now it has become a company standard. As a BA you were not involved early in the process and have little experience with the COTS tool and the dead line is too aggressive, now what do we do. We will get to that later. But there are some things to keep in mind:

1. There will always be a mismatch in business needs and what COTS can offer. It is good to know both.
2. There will be a constant negotiation between development teams and the business on what should be done OOB and how much custom code should be written, facilitate these discussions.
3. Ultimately both will have to mid somewhere in middle, a little between of custom code, a little bit of requirement changes and a lots of OOB.
... Stay tuned for more.

comments (2) / Read More

Jun 30, 2009 / Labels: , ,

Use Case Template

It's not too difficult to create a use case template as there are plenty available on the web and best practices to create an use case are well documented. Still I struggle to create one when it is needed. Utilizing the break between sprints in my current assignment, I have created a template which is consolidation of learning from various projects. The template is available in the downloads section or it can be downloaded by clicking here. Hope it would be useful.


comments (0) / Read More

Jun 10, 2009 / Labels: ,

Gathering Implicit Requirements

How do we define Implicit Requirements? While attempting to write this blog post I was thinking of defining 'Implicit Requirements' upfront before I proceed elaborating my thought process.Here is the best that I could come up with:
Implicit Requirements are inexplicit requirements that are not directly expressed or captured but are essential to meet System's goal. They are something that are assumed to be "there".

I can sight an example from my current assignment where not capturing implicit requirement had a major impact on our project.

Explicit requirement 1: A Publisher should be able to create an Article, send it for approval and finally publish the Article on the portal.
Explicit Requirement 2 : A Portal user should be able to search Articles published on the Portal.

After the sprint ended we realised that the System was developed to cater to both the requirements, So the publisher could create and publish an Article and the end user could search the Articles using the search functionality. But the search result displayed articles which were published, under approval and in draft state.

Call it a bug or badly defined requirements..whatever... but there was indeed an inexplicit requirement which said: The Articles in draft state and under approval should not be displayed in search result.

This was one example. There can be many more such cases especially related to User Experience (UX) which are mostly implicit. So how do we insure that they are captured at the right time?

1. Using Prototypes/Wireframes: Visual representations always work, while text/documentations can be interpreted in various ways a visual representation of an User Scenario helps you nail many unsaid requirements. Using wireframes for creating screen flows or HTML prototypes is one the best way to capture UX requirement. There is no way that an use case can define how a screen will look or how the screen flow will work and what option should be available to user while creating an Article.

2. Early feedback from the end user: Let the users see, touch, feel and use the system as it is developed. Involve and engage them very early in the development cycle , this will help in getting early feedback from the user and they will be excited about the product. Believe me surprising them with a system at the end is not a good idea.

3. Observing similar product/system available in the market: How is the competition doing? What features do they have in the system? What similar products have to offer? It is always good to know what they have so that you can build better systems.

4. Simply leveraging your experience as Business Analyst: Use your experience, now that i have learned form my present mistake I pretty much sure that in future projects draft Articles would not appear in search results. This is how you become better Business Analyst :)

comments (1) / Read More

May 31, 2009 / Labels: ,

Concise Requirements and More

I have been following a very interesting discussion of LinkedIn on whether restricting Requirements to 140 Characters is a Good Idea? See this Link; you might have to join the IIBA group to follow this discussion.

The discussion was started by Adam Feldman and what seems to be inspired by Twitter rapidly got attention of many Business Analyst professionals. It is interesting to see how the opinions changed (mine changed at least). If we don't see requirements in terms of models for capturing them like Use Cases and User Stories we can actually put together very good and concise requirement in less than 140 characters.

From my experience I have learned that we often tend to get verbose while documenting requirement which often leaves a lot of room for manipulations and interpretations. The Idea should be to keep them as simple and as concise as possible… why? Well because like any other thing in this world the best requirements are on which are simple and easy to understand and a good Business Analyst should always try to make requirements simplest not simpler(Isn't this what Einstein said!!).So if the use case is getting to lengthy with many alternated paths and extension, try to break it into simple ones. If the user story is taking more than few lines to write it has should be broken down into multiple stories.

I came across a very interesting article by Jeff Martin on defining the Business Analyst role, in his article he points out how to handle "So, What do you?" situations. It has happened many times when people ask me "So, What do you do?" and still being proud and confident about my profile I never had a perfect answer. Quoting Martin this is how the response should be:

If you are practicing activities that fall within the BABOK, then what you do is very simple and only takes three words! You "HELP COMPANIES CHANGE."

And this is what we exactly do, by bridging the gap between business and technology!

comments (0) / Read More

Apr 26, 2009 / Labels:

Business Analysis: It is more than Requirment Gathering

Business Analysts are still involved more during the initial phases of the project, this is indeed changing with acceptance of Agile Methodologies. But still the role primarily involves creating Business requirements, Functional detailing, documentation and creating  various artifacts related to  project requirements. So the focus they often keep is on 'What' has to be done, which is very good and should be maintained while they perform there roles. But the additional value comes when the involvement and understanding of ‘How’ and ‘Why’ increases. 
 This is what I mean while talking in terms of What/How/Why:
 What- 
 A Business Analyst should be clear about what has to be done… functionally off course. This is what we achieve when we create User Stories/Use Cases. 

 Why- 
A Business Analyst must be clear why the functionality is critical for business needs. This will help in defining the 
business objective and will complete the business requirement; it also helps in prioritizing requirements. 
 How- 
A Business Analyst must be able to understand how the requirements can/cannot be met by the underlying technology, the BA should be able to convey and negotiate with business the impact of technology on the requirements. The days of fresh development are long gone, now business systems are created around tools/products already  available in the market and its often desired to full fill maximum requirement with  'Out-of-the Box' available features. 
  • Understanding of the how technology behaves will help in connecting closely  with architects, designer and developers.  
  • You will be able to participate better in design and architecture brainstorming and interfacing with quality folks.
  • This will be help in understanding the system as it is developed and you will be confident while providing demos, walkthroughs and during UAT. 
  • While the high level business requirements will broadly remain unchanged but when the requirements are broken into functionalities they are impacted by limitation of the technology, understanding how technology serves requirements and what additional it can provide helps the Business Analyst during negotiation on what can be done with business stake holders. 
It is very important to remain focused on the bigger picture and keep a level abstraction with ‘What’ during the initial phases and... let’s say throughout but if you  want to get involved and  not just want to be waiter passing on the requirement to the kitchen it is always to good to understand how thing are done.

comments (0) / Read More

Mar 25, 2009 / Labels: ,

Use Cases and User Stories- When to use what?

I currently working in a very complex SCRUM project, a huge business problem is  divided among multiple teams and with Scrum masters and Business Analyst involved at various levels. In such  complex environment Practicing Agile is tough but one that comes really handy is writing both use cases and User stories. 


User Stories - I feel are excellent ways to capture high level  Business requirements. They may be enough when team are collocated and you actually have all stakeholders working  from same location and interaction is not limited.  

But the situation when you have multiple teams working and offshore  teams working in varied time zones it makes sense to further detail  out requirements using  Use Cases. The mapping can be  one to many- 
So when the user story  details out 'As an {User} I should be able to perform {task} so that is {Business objective} is achieved', the use case for the same user stories  will take the requirement to next level : 

  • [Description of Use Case] ->From User Story 
  • [Actors]  - >form User Story 
  • [Pre Condition] - >Not Covered in User Story 
  • [Post Condition]-> Not Covered in User Story 
  • [Basic and Alternate Flow] -> Not Covered in User Story 
  • [Assumptions] ->Not Covered in User Story
  • [Exception]->Not Covered in User Story
  • [Implementation  Notes]-> try writing this section where the discussion from Architect and dependencies  from other teams /system can be noted down 
This helps a lot in saving  a lot of communication time across team both at Onsite and Offshore. It also serves as a solid artifact to  create unit leve test cases and where the combination of user stories can be used to create higher level integeration test cases. 

The point I am trying  to make is that Use Case and Use Stories are not mutually  exclusive, they go pretty much hand in hand.  

comments (0) / Read More

Jan 22, 2009 / Labels: , ,

Business Analysis 'Scrumed'

While the debate continuous about  the role Business Analyst plays in an agile environment -it is interesting to note the Paradigm shift that it brings in the mindset of the team members and the way  their role changes. 

Interesting things to carry are: 
Customer becomes the part of your team. 
No matter how brilliant a PM you are,  in any other environment(read water fall inspired) you are always over the Fences with your customers; Over committing, Over billing and under delivering. 

I am  doing some basic study on Scrum  process which has to be followed in my next project.  Will keep posting stuff here. 

comments (0) / Read More

Dec 6, 2008 / Labels: ,

Has Requirement gathering actually evolved?

Technologies have evolved, Softwares have become smarter, the development  time is now minimal for IT applications. But the Software Development Life cycle has  still not Shortened. The amount of time consumed in requirements has increased over the period from 24% to  45%.

Here are the problems that I see : 

1. There isn't any defined set of methodologies for Business Analyst. The Best practices are not defined, the 'must haves' are not defined. 
2. There is no way to  validate requirements, code can be tested and many testing tools have evolved  to help in testing. But the  point is requirements that are elicited are often not validated.
3. The quality folks are often not involved from Day 1, the requirements are so  textual that the business imperatives are often lost in English. The use cases are either too  short or to descriptive and the business often has no clue that what this 100  page document is for. 
4. The use case best practices are for  designer and developers to understand  not for business stakeholders to  validate. 
5. New methodologies and best practices like design patterns have made software development  more robust and quick, but requirement Analysis  still remains  unchanged.
6. Though use case are good to capture detail  requirement, but methodologies to capture the business process/requirements have still not evolved. 
7. Parallel  Methodologies like agile are too much implementation oriented and pay less emphasis on requirements and companies find it difficult to use them for big projects.
8. Business Analyst are often not trained in handling difficult stakeholder, 'Business' accountability and availability is missing. 
9. And the worse, I have seen many companies where the  Business Analyst  is  not involved  through out the project and developers/designers keep on reinventing the wheel again and again. Blame is one the service provider for not able to convince the client, the project manager who often feels insecure  by BAs presence as SME and fears loosing control of the team .
Lack of collaboration, poor Project Management leads to more investment in rework rather than in innovation .

The Quality of your requirements  is a function of how good the Business Analyst is. Templates and Quality guideline will not help in making the sure that the requirements are up to the point but only to adhere to the quality checklist of your organization.
So how to  make sure that the Business Analysis as a field get some its own set of best practices ?
Let us all share our individual best practices that we have gained from our project experience.




comments (0) / Read More

Oct 15, 2008 / Labels: ,

What to do after Business Use Cases are written?

You have documented understood the Business Process and Documented the Business Use Cases. How to transition from here to System Use Cases?

The BA Mantra:-

Imagine the System


Simple and Obvious, but take my words this will sail you through :)

comments (1) / Read More

Sep 20, 2008 / Labels: ,

Business Analysis: Creating Storyboards and Prototypes

John: "Ranjan, do you know how to play chess?"
Ranjan: "Yes, a bit"
John: " You must plan your future moves.See things ahead. And that's the way systems should we made, today its E2(End-to-end) tomorrow it can be E3,E4 .. You must plan for E7. You have your limitations but keep one thing in mind: Make your systems Horizontally consistent. Symmetrical and modular. What I am trying to verbalize is that call each section as a 'thing' and that 'thing' should have similar properties. Later replace 'thing' by real names: Issues, meetings, Lists, product etc... follow this in UI also."
John is an architect and has extensive exp. of more than 150 systems for wall street companies. We are working together on my current assignments for one of the largest pharma companies. Here I have tried to capture my learning while prototyping the application in this presentation:

comments (0) / Read More

Subscribe to: Posts (Atom)