Being Business Analyst

Business Analysis in COTS environment: Evaluating COTS Products

2011-10-31T04:58:00.001-04:00

This is going to be a quick post, I was asked by a reader on best practices that Business Analyst can use to evaluate COTS products. Following was my response:

Business Analyst role in COTS analysis is often undermined and not given due importance. What I have seen is that, the days of fresh developments project, where an application or a business solution is build right from the scratch is over, IT managers look for tools which can "best fit" the business needs and have a warranty associated with it.
Having said that, here is what I think a BA need to do in order to evaluate COTS products:

Understand and gatherbusiness requirements very well. This is the first step. What business problem are we trying to solve? What the business is trying to achieve? What are the high level requrements or the desired funtionality? These kinds of questions..which will give an idea of the length and breath of the field that has to be covered.
Make sure that these requirements reflect the need rather than the solution .
Categories requirements based on the priority(first) and then on the similiar feature groups. Example: wokflow requirements can be categoriesed together... so can be admin and editing realted requirements.
The selected vedor(based on the prices, feature match, support etc.) can be asked to demo the product, do a pilot(implement top 5 features in a sandbox environment which has end user access) ...this will help in selecting the right vendor.
Prepare a evaluation sheet..for example features with their quantitative weights, mapped with the scores of the various vendors and their product. The final score can be used to judge the best fit product. Gartner publishes some really good evaluation matrix..check those to prepare the evaluation sheet. This is a critical excercise and will be crucial for building the final evaluation report.
Always, have a technical analyst, project manager and business users representative as stakeholders in your analysis. Communicate with them, make them the part of the demo..do the scoring with them and faciliate them with the decision making process.
The COTS tool will never be a complete fit there will be changes in the requirements to fit the tool and some change in the tool to fit the requirements. Ask how customizable is the tool, ideally, if the tool fits 80% of the requirements... it is good enough.
Don't encourage too much customization the vendor will always say that everything can be done OOB or can be coded, make the business understand that customization will only add to their administrative cost in the future.
Prepare an analysis approach which is best fit for your business need. :)

What do you think additionally a BA should keep in mind while evaluating COTS products?

CBAP Application- Few points to remember

2011-07-11T07:46:00.000-04:00

My CBAP application got approved some time back and I am really delighted. There are couple of reasons for my excitement. First, I have a total experience of just over 5 years and I was really nervous about the acceptance of my application form even though I had required hours. Second, now I can appear for the certification which I wanted to do since long time and was just waiting to get the necessary experience required. The application process is indeed a little lengthy and requires quite an effort from the candidate. I have some tips and pointers which might be useful in case your are applying or planning to do so in near future:

Few really good tips are mentioned on the B2T Training Website, check 8 Hints for Applying for CBAP. This is the place to start.
Capture high level business goal in the project description. There are restriction on number character for project description, make sure that the project description is written in language which is concise and understandable.
Don't miss on your consulting work. The projects where the outcome was not a software application can also be listed, for example I mentioned the the content management strategy work that I did for a pharma company. The outcome was a recommendation document but it involved a lot of business analysis activity which maps to the knowledge areas.
Pre-sales do not count as a Business Analysis experience. But if you have done some kind of solution assessment or enterprise analysis that may be counted. What may not count is responding to RFPs and RFIs.
It is not necessary to allocate some percentage to every knowledge area for every project. It is OK to have, for example, 0% allocation for solution assessment and validation for a particular project. It is again dependent on the work that you done. What is important in the end is that you have a minimum of 900 hours in at least four knowledge area at a minimum total of 7500 hours.
Avoid listing online recorded training for PDUs. You should list only those classes where there was instructor, you had an opportunity to interact with the instructor and it was related to business analysis work. Read this article by Laura Brandenburg to understand the PDUs concept better.
Start the reference process early, don't wait for the other sections to complete before asking for reference from your career managers. If the feedback is received late your application submission may be delayed.

It takes time to complete the form, a lot of information has to be entered and tracking the overall BA hours, total hours per knowledge area while your are entering information is not possible. IIBA should revise the form to make it more user friendly. I have created an spreadsheet to manage the application process, this is based on a presentation by Angelique Robateau & Michelle Gehrig. You can download the sheet here or by clicking on the image below:

Click on the image to download the sheet.

How to interview a Business Analyst?

2011-04-27T16:31:00.146-04:00

I had a chance to be on both the sides of the interview table on quite a few occasions. From what I have experienced, there aren't many companies which are good at interviewing business analyst. Often the interviewer is confused on whether to ask technology questions or the business questions? No one can be blamed for such confusion as often the job description itself is very confusing, for example "looking for a Sharepoint Business Analyst". Here the interviewer and interviewee they are confused on whether to focus on Sharepoint knowledge or the business analysis skills.. to be honest I often think if the BA has to be an expert in Sharepoint than what the other member on the project are suppose to do?

I would like to share my learning with the broader community having interest in this topic:

1. As Project manager or the HR manager make sure that the designated interviewer(s) understands clearly the role of the Business Analyst...in general and in the project. Ideally the interviewer should have the direct stake in the project or in the organization for which the BA is being hired.

2. Let the interview be case study oriented. I think it works better than asking standard questions which are published all over the web, case studies are unique and a very good way to evaluate analysis and problem skills. Take scenarios from your previous projects and ask how the candidate would have handled the situation. A case study can be a business problem which a company is trying to solve, a difficult requirement change situation in the middle of the project, a tough client handling situation, a unique business requirement etc.

3. It is important to ensure that the candidate has the right communication skills, whether he/she asks good follow up question to understand the scenario given in the cases study? Whether the responses are detailed enough and yet short? Whether the candidate answered the question you asked? Does the candidate take too much time to understand and answer the question? Or in general as interviewer are you able to enjoy the conversation?

4. Ask open ended questions, this is a good tool for a business analysis as well for interviewing a business analyst. Such questions open a platform for discussion, gives an opportunity to gauge domain knowledge and are foundation to get into specifics. For examples: Tell me about agile software development? What are the benefits of prototyping? How do you gather implicit requirements?

5. If the interview is face to face, give the candidate a situation where he/she can white board. It could be drawing a work flow through many decision points or mocking of a screen as per the given requirement. This will is a good way to evaluate diagramming and creative skills.

6. Schedule a round of interview with a team of professionals representing various skills in a typical project. For example let a team consisting of Tester, Developer, BA and PM interview the candidate, this is a good way to evaluate the candidates ability to communicate with different members of the team.

Here are some good links I found on the same topic, would love to hear back via comments on this post:

Follow the discussion on LinkedIn: How to interview a Business Analyst?

A good user story

2011-03-25T11:11:00.003-04:00

It is very important to templatize things and define some good practices when there are many Business Analysts involved in a project. We faced this problem. In my last project we had a global team of 10 BAs and everyone had their own way of writing requirement. We soon realized that there is an immediate need of harmonization between the BAs and to establish a common understanding on what a user story is and how they should be written. The outcome was a beautiful user story template and some of the best practices which helped a lot during the following sprints and subsequent releases of the project.

Here is what I learned about user stories, I would like to summarize it in Mindmap:

WIll be back soon

2010-07-28T16:03:00.000-04:00

Its been a long time since I have posted something here. Almost 8 months. The reason for inactivity is my laziness and a lot of action on personal and professional front.

But now I am back and have a lot to share, in past few months I had an opt. to work on various project and in different capabilities:
- Lead a team of Business Analyst across geographies to build an enterprise portal for a pharma major. I have a lots of learning to share.
- Handled a very politically charged project( I was drained out in 3 weeks!!) for a mobile company. We were buiding their support center application and I created the testing plan. I do have few learning to share... but the major learning is not to get involved .

Go by the Rules

2009-11-29T20:42:00.001-05:00

I have been reading a lot about Business Rules lately mostly by following blog of practitioners. Though I have been documenting rules during the analysis in someway or the other but not in the way recommended or the way 'Business Rules' should be treated and written.The major learning has been separating Rules from Business Process/Use Cases. Often they got mixed up in the Business Process Model or are hidden in the use cases(I could have saved a lot of pain if I separated rules from the diagrams).

For folks who are getting into the profession I would recommend treating and learning Business Rules as par with Use Cases, Process Modelling or any other technique. For Starters I would suggest the following text on the internet:

1. The Business Rule Manifesto- Clearly specifies the importance of Business Rules and various principle of rule independence.
2. RuleSpeak- Is a set of guidelines for expressing rules in concise and business friendly fashion. This site also two very good documents which are freely available for Download, they are
Basic RuleSpeak Do's and Don't and RuleSpeak Sentence Form.
3. Introduction to Business Rules By Scott Ambler -Provides a template for detailing Business Rules.
4. 'KISS' Process Modelling Technique by Kathy Long - Kathy gives a beautiful example on Separating Business rules from Business Process.
5. Business Rules Hidden In Use Cases by Scott Sehlhorst -A very interesting article on separating rules from requirements and how the rules are commonly hidden in the use cases.

Let me know if you come accoss more such articles, I would love to add them to the list :)

Why I Like Being a Business Analyst?

2009-10-17T23:28:00.010-04:00

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.

Business Analysis in COTS Environment- Part 2

2009-09-27T18:59:00.004-04:00

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.

Business Analysis in COTS Environment- Part 1

2009-09-19T18:12:00.006-04:00

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.

Use Case Template

2009-06-30T22:08:00.004-04:00

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.

Gathering Implicit Requirements

2009-06-10T21:46:00.007-04:00

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 :)

Concise Requirements and More

2009-05-31T17:39:00.005-04:00

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!

Business Analysis: It is more than Requirment Gathering

2009-04-26T20:06:00.017-04:00

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.

Use Cases and User Stories- When to use what?

2009-03-25T15:19:00.006-04:00

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.

Business Analysis 'Scrumed'

2009-01-22T11:13:00.004-05:00

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.

Has Requirement gathering actually evolved?

2008-12-06T02:09:00.002-05:00

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.

What to do after Business Use Cases are written?

2008-10-15T13:37:00.005-04:00

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 :)

Business Analysis: Creating Storyboards and Prototypes

2008-09-20T05:00:00.000-04:00

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:

View Upload your own

Requirements Lifecycle

2008-09-20T04:57:00.000-04:00

A Typical requirements LifeCycle(Click to enlarge)

I have been trying to put together some thing like this since long time. I think the above diagram summaries how a Business Analyst should typically engage in a project. There are very few projects where a BA gets to engage right from strategy to implementation. The crux is whatever the situation you are put in, if not being able to see the bigger picture troubles you..think that you are doing just right. If I am asked to summaries the value a Business Analyst brings in to a situation it will be - Converting and communication a business strategy into system requirements. The ability to see the big picture is imperative in such cases.

The great digital divide.

2008-09-20T04:56:00.000-04:00

Human being by nature are not racist, we normally like to mix with people who do not look or think like us. But at the same time we also have a general bias, we tend to prefer the company of people who are like us in some way or the other. People from a same community will live together, people speaking same language feel more at home with each other, people with same political view gel pretty well. Can you imagine a congress politician subscribing to BJP newsletter.
Like everything, In a overall neutral society we have small polarised sections. These formation happen gradually in a real world.

In 1971, economist Thomas Schelling performed a very simple experiment with a very strong result. He began his experiment by drawing a grid of squares on a piece of paper creating a pattern resembling an over sized checkerboard. Each square representing a house lot. He then randomly placed a black and white marker in some of these squares. Black and white representing Black and White people. Assuming the community to be fully integrated now, blacks and white living together with no preferences. He made one assumption now, if the percentage of the neighbors of the same color fell beyond 50% the family would move to nearest square to meet this need. Assuming this he started moving the squares and soon realised the board was totally segregated. All whites on one side and all blacks on the other.
He explained "small incentives, almost imperceptionable differentials, can lead to highly polarized results". Meaning, social realities are fashioned not only by the desires of people but by the action of blind or mechanical forces.

Though this kind of polarization takes a lot of time to happen in the real world where there are many hurdles to be crossed to reach this polarization. A family will look in to hundreds of thing before changing the neighbourhood.

Now, imagine a world where there are no such hurdles, where people can move around at will to there nearest neighbourhood, or even better, where people can create there own neighbourhood.
A world where there are no speed breakers: the web.
With lots of cool things around and Googles, yahoos, amazons, microsofts of the world providing, tracking and encashing on personal needs of the people. We live in communities, where we want to live in. We interact with people who talk like us, think like us...blog like us. The blogs/communities/sites/portals we visit link to places which are similar in nature. The web is moving towards Radical Personalization, and most of the time we don't have any control over the content that is fed to us. Somebody is tracking our behaviour by the clicks we have made in past. Our window is becoming narrower day by day.

Our online communities are polarized, we are able to find like minded people very easily on the web. It is well founded thought that deliberation between like minded people leads to ideological amplification. The more we interact with like minded people, the more radical our ideas become. With no critics around we see the world through a very limited window and through great confidence. The Web 2.o generation is a generation with radical ideas. It is affecting our lives.

We Indians were never radical in our nature, with nations living inside nation, it was always impossible to have polarized nation. We have always interacted with people with various communities and different ideologies and hence were never radical in nature. But things may not be same in future.Examples: What is happing in Maharastra is triggered by relatively young leadership. We are seeing avery radical face of religion and terrorism who hire and operate via web.

Learned form 'The Big Switch' by Nicholas Carr.

Dilbert On Software Requirements

2008-09-20T04:54:00.000-04:00

Every Analyst, Manager, developer must have been into these situations...
The most hilarious are the one that happen after these systems are developed.

In one of the projects,the client happened to be a Desi Guy..and we built a really nice rapo with him. So, after the requirements was done, the system was developed... during the acceptance he comes up and say " yaar, kuch maza nahin aaya".
When the manager promptly replied that all the requirements was covered and we have made the system as documented in the requirements document, and she sighted that every thing was approved and signed off by him, she forwarded all the approval emails that he had sent ( you know, we guys always keep these mails... client ko phek ke marne ke liye ).
In his typical marathi tone, he say " yaar, system easy to use nahin hai..ab dekho yeh to assumed hai naa.... bola tha..naa.. poocho....ranjan se poocho(knowing very well that I am not with project anymore)... use pata tha.. tumhe bataya nahin usne...ab document padhne ka time nahin hai naa... I trusted him..!!"

Business Analysis for Dummies- Feature Matrix

2008-09-20T04:52:00.001-04:00

Quoting IIBA:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

Building my thought on the above statement, I thought of building up a "Feature Matrix" for a Business Analyst. The above matrix was the outcome and is plotted against Criticality and Experience.

Here is the discussion for the same:

The four parameters 'Characteristics', 'Skill', 'Tools' and 'Domain' can be used to measure any professional in this world, the order in which they are placed in the graph may definitely differ. Talking about our profession I strongly feel that character and skill are high priority. The work is so much of comprehension, communication, analysis that it requires the above listed characteristics to justify the job. The outcome often is a requirements document( called as FRS,SRS,URS in CMMI companies), hence a lot of emphasis is on writing and communication. Domain Knowledge will come with experience and is very important for a Business Analyst, it helps you in relating to the business situation pretty quickly.However many people may feel that 'Domain' should be right there at the top, but my argument is, yes, it needs to be there at the top as highly critical feature but the passion and skills are still required to convert knowledge of business into a business usable system. A good domain knowledge is gained over a period of time by building systems and by being 'in the game'.
Knowledge of various tools and process will help in maintaining Quality. These techniques can be quickly learned and doesn't require expertise... to start. But personally I feel knowledge of product life cycle is imperative. It is good to learn writing use cases, a good use case leads to a good design. The expertise will come with experience and only if you have passion to learn and learn more.

Let me know your thoughts on the " Feature Matrix", does it makes any sense? Can we use it for defining other professions?

Reference:
1. My earlier post: Business Analysis for Dummies
2.'Characteristics' has been taken from Trials and Tribulation of Business System Analyst, a highly recommended blog.

Things I learned In past few weeks.

2008-09-20T04:48:00.002-04:00

In future, not companies but their Supply chain will compete.

This is true.I would have loved to discuss this over here but will rather put it in a separate post after exploring a bit more. Examples: WalMarts Vs Any other retailer in the world. But Walmarts is suffering a midlife crisis and its competitor Target is doing much better, what can be the reason? This will determine the future of IT industry. The companies with best delivery model will succeed.

During requirement gathering, pay a lot of emphasis of business process. A little haze in the process will bring thunderstorm during development.

This statement is said by the great ranjan jha :))
This is my personal exp, a little gap or the little voice that you ignored will get louder down the line. clarify each and everything, one thing will lead to another, its better to bring everything on the table right in front. Stakeholders do not like tough questions, but a BA bust asks ugly questions.

Companies with content oriented website and not so complicated requirement must consider Microsoft Office SharePoint Server 2007(MOSS 2007) to build there extranets

I have written a Case study on it... will love to share it with you guys...mail me :)

Analyzing the role of Business Analyst

2008-09-20T04:48:00.001-04:00

The need of having a Business Analyst for IT project might have came up when more and more business problems were addressed by the software companies. The outsourcing and offshore phenomenon may have made the need even more urgent.

Software Services organization still fail to understand the role of Business Analyst, or do they? Projects fail because the requirements are not done properly, the expectations are not set up right at the very start. Let me put it in different way, projects fail because the vendor or the services company is not able to understand the business of the client. A business analyst should not only do the requirements but should be involved through out the lifecycle of the project and should be the owner from the business side. More of a clients representative then a vendor's representative. As Babcock put his concern nicely:

Is the role of business analyst an IT role, a business role, or both? How can the BA role be used to the greatest benefit of the organization?

In his article Finding a home for Business Analysts he beautifully explains the roles a BA must play. He points out that the Business Analyst should be more involved in developing a Business Case then playing an IT role. This is so true. He further explains

Business stakeholders sometimes fail to realize (in part due to the BA or Project Management Organization’s failure to articulate) that the great value of a BA is not just in the ability to crank out documents translating business-speak to tech-speak, but to help business stakeholders through the processes of identifying and prioritizing true (not necessarily perceived) business need

I have experienced the above myself, pretending that they understand technology. The Stakeholders ofter define the technological platform they are going to use. These decisions are rarely taken after a thought process. The decisions are often taken because, the technology is "cool" or the competitor is using that, or Gartner has kept it on the top right corner of there magic quadrant. Not because its going to serve the business need, no body has time to do this. These decisions should ideally have taken place after the business case is developed by the Business Analyst, this not only gives a BA a lot of freedom to analyze without thinking about implementation when the technology is defined.

So what does the future hold? As Babcock opines:

I do feel that the role will continue to require business acumen and technical literacy, and I know that every company will continue innovate and build on past lessons to address their needs for the role as they see fit. In many smaller budget operations we’ll likely continue to see the systems analyst/business analyst hybrid. In other scenarios we’ll see the breakout.
As I indicated above, I think that organizations will realize the most value from the business analyst as he/she is included earlier and earlier in the business decision making process, and becomes more of a fixture within the business. Whatever the case, though, I trust that the market will properly guide the evolution of the business analyst role

.
Whatever the future holds a Business Analyst will play a very important role decision making process both on the client and the vendor side.

Related Articles: Business Analysts: SME’s or Generalists?

Another way of capturing Requirements

2008-09-20T04:46:00.000-04:00

Many times a situation comes in where the business requirements are to be captured but not any of the defined process seems to be the right way to do so.
The business problems where there aren't any complex process to be automated. For example, a company wants to migrate its commercial website to a better technological platform. There are definitely certain requirements that are to be captured. Mostly these requirements are on the look feel side. How will a business analyst capture requirements in this situation. Writing use cases certainly isn't the best Idea.

I am currently working on one of these website migration projects and this is how we captured the requirements:

1. Most of the time requirements are very clear, the technology is defined. But still a sign off is needed, so you need to capture requirements in some way.
2. The owner of the dotcom of any company is the marketting department and often the VPs and directors... who wont have much time to spare.
3. The important thing is to get the look and feel approved first, the templates and all.
4. Provide the entire site as wireframes...best to have a expert UI designer to work the new look of the site, frame by frame and get it approved by the business.
5. The next thing that is left is content and navigation.
6. We made PPTs...took the wire frame and provided the content editing areas on the slides and provided it to the business to edit.
7. This gives the business a good idea of how the new site is going to look like.
8. Next, get the sign-off on the requirements and without wasting much time get ahead with the design and development.

Actually these projects are very boring for an Analyst, I am doing one. I learned a new way to do requirements which helps in breaking the mindset that OOAD is not always the best way to do things.