BA involvement in pre-sale support

As a BA you may be called upon to help the sales team with pre-sales support sometimes also called as Request for Proposal (RFP), although it is hard to generalise the content of the document they usually follow a standard format.

Sales people may not have the technical knowledge for the RPF and that is where the BA can be very handy, you may ask a question as to why not involve the technical people? The answer is very simple, most of the RFP are targeted to middle or senior manager and some may have the technical expertise but in my experience most don’t, so there is a need to represent the technical information in a business language.

BA will play a major role in designing and developing a prototype for the proposal, a good BA will spend reasonable time investigating customer’s business, trend and preferences to customize the demonstration that will make the customer more confident on your product/service.

Sales people are often stereotyped as commission hungry and income driven individuals , getting a BA involved in the sale gives customer the confident that your company is serious about the product/service and they are thinking of all the aspect of the sale like installation, implementation, training, support and maintenance.
There is one more advantage in this process, as a BA you experience firsthand the needs of a new customer this can be very handy to enhance the product and may lead to identify new opportunities and business sector.

Requirements Process - Three C Phase

Capture
Make sure you gather and capture as much requirements as possible, do not get too much worried about the format of the document or the structure, the focus should be more on completeness rather than tidiness or presentation. Involve the end-users or customers as much as possible during this phase. Make sure you record all the spoken and unspoken requirements, try to focus on what rather than how.

Clarify
In this phase make sure you clarify the requirement with the SME or users, developing prototype or test cases can help you clarify the requirements, make sure that the requirements are measurable, this phase is very important as it also determined the completeness of the requirement by formally inspecting the documents as a group.

Confirm
In this phase evaluate and agree which requirements will be done first, this phase will help you to remove those high cost but low value features. In this phase project scope will be identified and milestones will be defined.

BA as Innovator

The only way you can survive in today market is by innovating, innovation is not limited to technology and solution, innovation in strategies and business models are also very important, in fact innovation can be performed in any area.

Traditional thinking is that innovation is for creative mind and venture capitalists, I beg to differ, innovation can be performed by anyone and at anytime (in fact every time) in any role they are performing, all you need is the ability to dream.

Innovation is not only about creating new products; innovation is about reinventing business process, venturing into new market and meet untapped customer’s need. Innovation may be high in small size companies, partly because it is the only way to survive against the big companies, but I have seen innovation in large companies too like Google, it all comes down to company culture and how much do they promote innovation.
The first thing which pops in my mind about innovation is iPod, they were not the first player in the market, but they are popular because of the innovation in their business model, simple interface and the online music shop, they added the WOW factor to the MP3 player, they recognized and tapped the customer trend and fashion.

The first step to be innovative is to remove the fear of failure, take risks and embrace failure, don’t spend too much time taking decisions, all the good ideas seems meaningless and impossible initially. Try looking at other industry to get inspiration, there is nothing like bad ideas, there may be ideas which are not feasible but that’s life.

As a BA you are in a perfect environment to be innovative, most of us are responsible to implement an innovative idea but does that mean innovation stops there?, you can use innovation to implement the idea (which include software and process ). Be a bit more social, try and meet BAs from other industry talk to them to find out what they are working on, learn from their success (and their failures).

Try getting in the head of your target audience, try to see what customer sees (or expects) which you have missed, walk a mile with them, feel their pain and frustration, a small change in the way you do things can make a big difference in their life, the moment a customer thinks they are being heard, they will be more open with suggestion and criticism.

These days business are getting global in nature, do not restrict yourself to a particular region, sooner or later you will venture out and you need to think (NOW) about the opportunities you can tap in future. Sometime to be innovative you have to go to the opposite direction from where your industry is going, you'll redefine the rules of the game.

Thank you very much for reading and don’t forget to dream.

Vendor Assessment (Part 2 - Software Development)

In my previous post I spoke about how to assess vendor on company background criteria, this post I will continue the discussion

Software Development

Project Management

• Will a proper project manager is assigned to ensure smooth running of the project?
• Does your company recommended any project management methodology to be used?

Project Status Update

• Are regular project status update provided? Will it be targeted to shareholder and sponsor?

Development Methodology

• Are development methodology used is in accordance with your company's development methodology.
• Is the proposed methodology compatible with methodology used currently within your company?

Regular update and enhancement

• Are regular update and enhancement in the future if required?

Milestones

• What are the milestones, are the proposed milestones acceptable?

Issues/Bug Management

• Is there a proper process/tools proposed to handle bug and other issues raised during and after QA and UAT process.
• What is the proposed turnaround time to action/resolve the queries raised by business users? are those time frame acceptable?

SLA (Service Level Agreement)

• Is the SLA proposed by the development acceptable?

Functionality

• Is the functionality in the Requirements document included?
• If the software is extending current functionality, How will they ensure the current system functionality is retained?

In my next post I will continue talking about technology criteria.

Vendor Assessment (Part 1 - Company Background)

In your BA life every now and then you are faced with a decision whether to develop the product in-house or outsource it. I am not going to discuss the in-house- VS outsource in this blog, I am assuming you have come to conclusion with the stakeholders that you are going to outsource the development and that when the main question comes in as to who should we outsource to?.

Outsourcing development is a major investment for any company and requires careful and complete evaluation of the quotes received from the various software development companies.

Start by separating the “must have" criteria from the "would like" criteria. Proposals that do not meet all of the "must have" conditions should not be evaluated further. The final recommendation should be then made via a weighted assessment of the proposals.

Company Background

The first Impression

• Did the company get back to you on time?
• Were the people dealing with you were professional?
• Did the company’s representative asked any questions?
• Did the company’s representative understand the requirement

Total Employees

• These criteria will determine the resource available to execute and maintain the project.

Experience and References

• Experiences will determine if the company has developed a similar project, this is reducing the learning curve and increasing the quality of the product delivered.
• References will be used to determine if the earlier project they executed were delivered on time, as expected and within cost.

Stability

• How long has the company been in business
• Will the company be in business in five years?
• Good market standing

Customer service

• These criteria will ensure we are dealing with a professional company.

In my next post I will continue talking about software development criteria.

Planning Poker

I have been using planning poker in our planning meetings for a while now and I get many people asking what it is and how does it work so I thought to write my expericence with planning poker.

Planning Poker is a technique used in agile software development for estimation. There are various ways it can be done but the most effective way is to do it with a cross functional team.

Before you start the estimation make sure you create (or bring an existing one) a user story, user story should be very small (possible independent from other functionality) and self explanatory, we do not use any fancy system to record user stories, in fact we use one of the oldest method ... on cards. The goal of this planning meeting is to estimate that user story.

In our work environment we use a cross functional team, we do not start estimation if we do not have at least one person from QA, development and BA team. The advantage of this mixture of skills is to be able to see the user story from each angle. BA usually kicks of the estimating meeting by explaining the user stories, depending upon the story other teams members may have questions like, what technology it will be developed in? Will there be any automated test? Etc.

Each member in the planning meeting is given a series of cards; we use 0.5, 1, 1.5, 2, 3 and 5. You can use any units you want, the units can be related to days, hours or some fictional units (some agile practitioners like to call them relative units of work).

Once the BA has explained the user story and everyone has asked their question, each of the team member picks one card from his/her deck. They do not show the card until everyone has finished picking their number, on one go everyone then displays the card. Most of the time the estimates from all of them will be within a small margin let’s say 2.5-3.5 in this case you can safely assume the estimate to be 3.

If for whatever reason the estimates are very different like one person is 2 and other person is 5, both that person gets the opportunity to explain their estimate, it may happen that the person with estimate 2 has some insight on the problem, it may also happen that the person with estimate 5 raises a very valid problem, based on the argument presented by all the parties you may play the estimate game again.

Usability

What is Usability?

Usability is a term used to define the ease with which user can interact with the software or website in order to achieve a particular goal. Usability is very much measurable and should be used to assess the user interface during the entire SDLC.

Why usability is important?

Usability helps designers and developers (especially BAs) to improve the user experience with the software, some of the user benefits from usability are:

• Improve understanding the product and reduce learning curve
• Increases user satisfaction and trust in the product
• Improve speed and accuracy in recording information
• Improve rapid recovery from error and invalid data inputs
• Easy to remember

Define conventions and best practice to improve general usability for your organization; use this to evaluate every product shipped out of the door.
Investigate and define usability for every age group, demographic, ethnographic or any other category of your users, this is very important as every group of people interacts with software is different way, you can achieve this by running focus group meetings and in-depth interviews.

Tools
Usability is a concept and as such you don’t need any tools to implement it, but there are plenty of usability software which can be used to gather, collate and present information and resources about issues related to usability in software or website design. One tool I can recommend is Morae from TechSmith you can download a free trial from http://www.techsmith.com/morae.asp

Acceptance Testing

Acceptance testing is the final testing done on the software prior to its final delivery. Please note that acceptance testing is different from user acceptance testing which is normally done by the customer or representative of the customer within the company.

Acceptance testing is sometimes also referred as functional test because each acceptance testing is also testing the functionality of the software.

Acceptance testing should be defined and agreed during the requirement phase of the project and is normally defined by the business customer as the minimum test to be executed before the delivery of the software. Some customer is hesitant or not technical enough to write the acceptance testing, that is when the BA comes in action, every requirement gathered during the investigation phase should be converted into acceptance testing. Best acceptance test criteria will be created when customer, BA, developer and tester get together, this will also avoid certain test to be run multiple time during the delivery.

Acceptance testing in Agile

Traditionally acceptance testing is done at the end of the project but in an agile environment acceptance tests will be defined and agreed at the beginning of every iteration. Every user story becomes a test and the story is not complete until it passes these acceptance criteria.
Acceptance test helps developer to understand the functionality from the user story. Make sure all the scenario in the user story is covered by the acceptance test. Each acceptance test should define the environment, inputs, steps and outputs for each user story. Make sure each acceptance test is understood and verified by the customer (this is very important if someone else is writing these test on customer’s behalf)

Critical Appraisal

Critical appraisal is the done at the end of designing phase, the main purpose of this task is to do a final check between proposed solution and physical design, this task along with solution walkthrough gives the stakeholder and the team a common understanding and also the opportunity to identify any missing requirement and most importantly to validate the proposed solution.

The following people (or group) should be attending this meetings

• Business Analysts
• Stakeholders and SMEs
• Business Users
• Development Team

Some of the advantages of this process are

• Confirming the Business Requirement.
• Confirming the physical design.
• Improve stakeholder’s confidence in the project.
• Identify any people or organization problems.
• Identify any function or data problems.
• Identify any performance or workflow issues.

The main topic in this process is to match logical and physical design, if there are data models created, make sure the domain is complete, there are no duplication or redundant data, identify any relationship problems.

The final question BA should ask the team is ‘Does the proposed system meet the organization goals?’. Always remember it is easier to change the design and solution on paper than to change few hundred lines of code.

Preparing Business Case

Developing a new product or functionality involves ensuring the money is spent wisely and that there is proper ROI (Returns on the investment). A business case is a detailed report used by the stakeholder/sponsor to justify the need of the project. The report should provide all the relevant information in an easy to understand format. In some companies business case is a must to receive funding and go-ahead for the project.

A business case is used to support a particular course of action when there may be several different options; the most important aspect of the business case is the cost-benefit analysis.

Identify your audience early in the process; you will have to address each audience's need, concern, expectation and level of understanding in the document.

Cost Benefit Analysis should be broken down into two categories, 'Direct Costs' and 'Indirect Costs', list all the topics under each category. With my experience sponsor loves valuing in dollars, try to work out each of the cost and benefits in dollars.

Although there is no official format or one that works for everyone, I can suggest you to structure the document in the following section

• Background
• Effect/Risk of the problem
• Costs and Benefits
• Proposal
• Impact
• Conclusion/Recommendation

Other factors which should be considered in the business case are

• Financial (expense and revenue)
• Corporate commitment
• Quality
• Customer pressure/satisfaction
• Industry pressure
• Legal compliance

Finally these are some of the questions which should be answered in the business case document

• Why are we doing this project?
• What is the problem this project is trying to address?
• Are there any workarounds or alternates?
• What are business benefits?
• How are we going to solve the problem?
• How much it is going to cost and how long will it take?
• If we do this project, what are the risks?
• If we don’t do this project, what are the risks?
• If we need to measure success how will be measure it?

Try to answer the questions above in the document to create a good business case proposal. In the end of the document make sure you summarise the problem, costs and benefits of the proposed solution, the document should be structured to highlight that the benefits outweighs cost.

See you next time.

Crash Party

I know what springs to mind when you hear 'Crash Party', but I am not talking about gate crashing or going to a party you haven't been invited. I am talking about Crash party before the release of the software, so let me start by explaining what is a crash party and why there is a need for one?

Testing plays a crucial role in the successful delivery of today’s complex, heterogeneous, business-critical software systems, as software get more and more complicated, there is a need to improve quality which poses challenge to the QA team, crash party is yet another way to improve quality.

Crash party is another form of collaborative group testing when a group of people (Developers, BA, QA, Support) gets together for a limited amount of time and test the functionality of the product with the intention to find as many defects as possible, it works on a very simple principle that when multiple people are using the system in a non predictable way, they are bound to find workflows (along with defects) which hasn't been thought, documented and/or tested before. Some Crash party may use a predefined script (e.g. UAT ) for the testing. Crash party can also be used for load and stress testing.

Crash party is an excellent way to bring team members up to speed, get them familiar with the area they haven’t work before, and the most important thing is to make them feel a part of the entire product.

Each team member participating in the crash party may be given an area of the product to test. Give cards or paper to each team member to record the defects and the steps to reproduce it, I would highly recommend you to not introduce any electronic bug recording system during this process, the reason being it is easier to write it on a piece of paper and expand that later once the crash party is over.

One of key things to ensure in a crash party is to make sure that the test cases and/or areas are evenly distributed among the team members and to avoid repeated test steps. Also make sure you are not executing any steps which have already been tested by automated tools and regression testing. Always tell the team member the goal is to find what we haven’t found before, 'we don't know what we don't know'.

After the Crash Party is completed, compile a list of defects found during the process, there may be some defects reported due to incorrect data entry or workflow, make sure you discuss that with the BA to ensure the defect is still relevant. The next and the most important step is to prioritise the defects to be fixed before the release; the ones which can’t be fixed in the current release will be flagged for the next release.

Finally software testing is an art, testing practices have not changed since last few years, but the tools and techniques have, complete testing is infeasible, so try to implement quality at every stage of development.

Resolving Conflicts

As a BA you are constantly in a position where there are conflict whether the conflict is in requirement, conflict in design, conflict in implementation or just conflict in management, they are just everywhere, to be a successful BA, you will have to master the art of resolving conflict.

Conflict resolution can sometime take up 10-15% of my BA time but I find it very challenging and most of the time I am happy with the results after the conflict is resolved. Most of people think conflict is bad, unproductive and unhealthy in an organization, I would like to take a different approach, I believe conflict is natural and healthy it means people are thinking, as long as conflict are resolved on time, it can help make changes for good.

Everyone has to deal with difficult people from time to time, they want to be heard, and with the right strategy it is possible to reach an agreement with them. I will go through some of the strategies which I have used in past whenever I am in a conflict situation.

Stay calm no matter how heated the discussion gets, how angry the person gets, you should never lose your temper, try to stay calm and collected.

Let the other person do most of the talking, sometime all they want is to speak up and get it out, do not interrupt them or try to correct them when they are talking, after they finish acknowledge that you have heard what they have to say by saying something like “I see your point, if I understand it correctly what you are asking is ...”.

In a conflict situation people tend to bring in past experience, and imaginative facts and figures, do not try to defend and correct them, just think of them as red hearing and move on. Do not be the judge or try to take side, try to look for the cause of the conflict and not the symptoms of the conflict.

Silence is a very important strategy for reacting to conflicts. Acknowledge the possibility that you could be at fault even if you don’t think you are, on the other hand if you think you are at fault try to ask yourself as to where you are at fault.

Pay extra attention on your body language, you body gives messages when you think they are wrong or you don’t like what they are saying, relax your body and face.

If for whatever reason, the argument becomes verbally abusive, just calmly terminate the discussion and let them know that they are very angry and we will have to continue this discussion later, gracefully excuse yourself from the meeting .

I always believe that every conflict I came across provided me a means to learn and has made me more mature, conflict resolution is a skill you must learn for your own good, it is very crucial to become a successful BA (and as a person). That reminds me a quote from Carl Gustav “The greatest and most important problems of life are all fundamentally insoluble. They can never be solved but only outgrown.”. So true!

The Art Of Negotiation

While doing my Business Analysis I have found that negotiation skills are very important and very crucial part of your role. As a BA you need to master the art of negotiation, you will have to use that skill at various stage of the project, you negotiate with the sponsor with the scope and delivery dates of the project, you negotiate with the project manager to get appropriate resource and on time, you negotiate with the development team with the features to be development and if you are lucky to get this far, you now negotiate with the QA team to ship software with least number of defects.

One thing you have to learn and believe as a BA is that nothing is set in rock, you can and you should negotiate at every possible stage of the project to achieve the best outcome possible.

Some people are natural at negotiation whereas other people need to improve on it, most people see negotiation as negative and tend to avoid it, but it is not about doing the least possible or being difficult, it is about making sure all the party involve are happy, and everyone gets something out of it.

You should be very careful when negotiating, your body language, your tone and your approach is very important. Try to put yourself in other person's shoe that will help you to understand the other person's view, treat everyone as you would like to be treated.

Before you start negotiation sit down and list of following things

• Make a list of every single topic to be negotiated.
• Make a list of topics which should be avoided during the negotiation.
• What are your needs (and not your wants)?
• What is the minimum you want to settle for?
• How far are you prepared to go?
• What is available or possible?

Knowledge is power so make sure you know as much as possible about the thing you are about to negotiate, ask around if anyone else has done it before and what was the outcome, don’t let the other party blind you with technical details, stay focused.

Always remember 'Relationship before task', spend some time with other party to understand their need, always empathise with their problem, avoid and deal with conflict as soon as possible. Always explain to other party why and what are you negotiation for.

Negotiation is not about 'YOU' or 'ME', it is about 'US', be flexible, do not try to drive too hard, make everyone involved feel like a winner.

How do you know that your negotiation was successful?

Well there is no great answer for this but if both parties seem happy with the outcome, which fits into the project goals, I will say that’s good.

In the end don’t forget, negotiation is truly an art and not science, negotiation skill can be improved even in your day to day life activity (some time you are doing it without realising it) like negotiating for a mortgage, car or even insurance. All the best.

Technical details in a requirements document

The thought of writing about how much technical information should contain in a BRD (Business Requirements Document) came to me yesterday when I was working on a requirements for a new feature for our product.

I come from a technical background, but not all business analysts comes from programming or technical background, I feel both categories of BA have advantages and disadvantages, especially when you are working for a software company.

Let me stick to the topic and focus on BA with technical background, I feel when you start the requirements document it should be entirely based on business outcome and you should not think about the solution or any other technical details, this ensures that your document covers all the business needs and is not compromised by technical limitations.

If your company promotes and allows JAD (Joint Application Development), then you will have to talk to the technical team, I found it very handy if you are able to talk the technical language, but getting too much technical could risk the business focus. On the other hand based on my experience technical team are a bit reluctant to document technical details in that case documenting technical information can be very handy (QA team will thank you for that).

Personally I would rather focus on defining requirements clearly and free from ambiguity then worry about technical details, but BA needs to understand the design concept, in past I have experimented with semi technical document by adding Workflows, UI, Data Modelling and sometime ERD diagrams, that has worked in some cases some and some cases it did not, you will have to use your judgement as to how far you need to go on the technical side, it may also depend upon your audience, too much technical details makes it difficult for a business user to review,understand and verify the requirements.

There is also some overlapping between functional and technical, what is technical to BA is functional to the development team, BA usually have to write functional and non functional requirements so sometime there is no way out but to write technical details.

So in short depending on the willingness, skills and experience, BAs can choose to be more on the technical side or stay focused on the business side, a balance of both side is what I will recommend.

Walkthrough Process

Performing a walkthrough process is very critical during analyzing phase, it helps the stakeholder, business user and development team to understand the proposed solution and identify any potential shortfall.

Walkthrough should not be just conducted before the beginning of development; it should be done regularly (as and when needed) during the entire lifecycle of the project.

Some benefits of structured walkthrough are as follows

• Helps stakeholder to believe and take ownership of the project.
• Business users can visualize the solution and propose any changes or highlight any potential problems.
• Reduces ambiguities and identify missing functions earlier on the project.
• Helps the team agree on objectives of the proposed solution.
• Validates the current and complete understanding of the analyst(s).

Planning and Organizing Walkthrough

Make sure that relevant people (preferably one person from each department and/or level) attend the walkthrough meetings, keep the meetings short and distribute material to every participant before they attend the meetings.

Facilitating a Walkthrough

Rules observed during any business meeting should be followed during a walkthrough meeting, such as

• Make sure you book the meeting room well in advance.
• Setup the meeting room before the meeting starts.
• Arrive on time, and most importantly finish on time.

Below are some more tips when you are facilitating walkthrough meetings

• Give every participant a fair chance and time to speak.
• Do not interrupt when someone is talking and don’t let anyone else do that.
• Use terminologies which are familiar to the group and/or organization.
• Take notes of all the proposals, questions and problems identified during the meeting.
• Try to stay away from fixing any problem and/or bugs identified during the meeting.
• Nominate yourself or someone else to resolve any conflicts arises during the meeting.

Always remember the cost of fixing and/or changing anything after the development is complete is very expensive and time consuming when compared to identifying it early on the project. Please let me know if you have any questions and/or comments.

Critical Success Factor (CSF)

Critical Success Factor (CSF) are defined based on individual organization’s goal, objective and mission, a good CSF are the ones which can be measured, and when I mean measured I don’t mean by a score, there needs to be a baseline defined for each CSF to be measured against.

One of the CSF for a project I worked for in past was 'ease of use', immediately when I looked at the CSF I told them, that’s an interesting CSF and I posed them a question, how are you planning to measure that?, and guess what I did not get any tangible answer, the reason was that everyone agreed that we want to deliver a software which is easy to use but did not know how to measure it? that does not mean it is not a good CSF. The moral of this story is that if you cannot measure something how you will decide if it was successful or not, sometime we do not have to categorize a CSF as success or failure it could be how effective it was and that’s good enough (at least for me).

One another CSF I came across was 'increase in sales by 20%', which was later changed to 'increase sales by 20% from last year', now this can be measured, do you agree?

Identifying CSF (oops measurable CSF) at the begining of the project is very critical for project's success and for stakeholders confidence in the project.

Some of the typical CSF is as follows

• Solution will be delivered by so and so date.
• Solution needs be able to install via an installer.
• Software needs to be up and running with no (or absolute minimum) configuration.
• Sales order should be placed within X minutes.
• Quotation needs to be generated within X minutes.
• Implementing this solution needs to save X dollars in operational cost.

Sometime there could be different CSF for different team, but an experienced BA will ensure that every teams individual CSF can be used to measure organizational CSF.

It is very important to constantly keep an eye on CSF, the progress needs to be recorded correctly and more important timely, very recently I saw people in my organization using burn down graphs and backlogs, the tool was very simple to maintain and enabled the whole team to act in time and monitor progress, that’s what I like to see.

Bye for now…

Is Business Intelligence a threat to Business Analyst ?

In the past 5-6 years I have seen Business Intelligence (BI) getting very popular and powerful too. For those of you who are new to BI let me first explain in brief what BI is, the official definition according to Wikipedia is "Business intelligence (BI) refers to skills, technologies, applications and practices used to help a business acquire a better understanding of its commercial context. Business intelligence may also refer to the collected information itself."

Now you may think that this is some new cool technology but you will be surprise to hear that BI existed since late 1950s in one form or another.

BA are very integral part of creating BI, interacting with customer, identifying reports, analyzing data, this information can then be applied to the BI, it does not make sense to apply rules to data if you don’t understand the data.

There is one thing everyone needs to understand that BI are great for reading data, massaging data and applying decision and generally does all this very fast, but one thing they lack which is "thinking" (until they perfect artificial intelligence of course), for now BA will do the thinking.

Business Analyst Vs Project Manager

Well as much as the title suggest that I am going to talk about who is important over the other, let me settle this before I talk more, the answer is very simple (and you know it) "Both". Now that it is settled I can relax and continue, BA and PM and like two side of coins, depending upon which angle you are looking from, one may seem more important than other, but in reality the only way to guarantee success of any project (big or small) is to have a very experienced PM and experienced BA.

In a project BA manges business stakeholders and PM manages resources (hardware, people, cost), it is very crucial for the success of a project that both role are clearly defined and planned for (unfortunately sometime BA are expected to do both ... but that is a different story).

In the beginning of the project both roles will overlap to define and agree scope, mission, objective, risk (along with mitigation plan) of the project (sometime called "Terms of Reference"), but as the project moves on the roles gets it real shape and each focus on their particular responsibilities and tasks.

It is very crucial for the success of the project that both role are working towards an agreed goal and never lose in touch with the business stakeholders and business users.

Some of the tasks performed by BA are as follows

• Bridge between business users and technical teams.
• Knows (or in the process of) the business in and out.
• Regularly feeds progress back to business stakeholders.
• Resolve conflicts and implement change management process.

Some of the tasks performed by PM are as follows

• Manage resource (people, computer and much more)
• Create a proper (detailed) plan of the project.
• Motivate the team members and resolve any conflict as arises.
• Document change request.
• Keep an eye on the risk and take timely approach to resolve it.

Now as you must have guess that sometimes it seems that BA and PM have conflicting goals, for PM it’s more important to deliver project on time and within budget, for BA it is more important that the business outcomes are achieved, I personally like that kind of tension and that’s where experience comes in.

Bye for now...

Why Business Analyst ?

Over the last 10 years or so the technology focus has moved away from IT to business users, it is no more about product, software or hardware it is all about solution (not any solution - A business solution).
Business Analyst is a bridge between technology and business, the one who can see and understand both sides, to support business procedure which in turn increases revenue and decreases operating costs.

An experienced BA will involve business users and technical people from the very beginning of the project; this ensures that both side gets an opportunity to express their views and contribute ideas, this process is called JAD (Joint Application Development). There are various tools which can be used during the various stages of projects some of them are

• Process Mapping
• Data Modeling
• B5 Matrix
• Design Sessions

BA must also be skilled at system testing, user training and project management.I am going to leave you with a final closing statement that today companies need good BA more than ever if they really want a solution for their business users and to keep up with this fast moving global competition.

How Business Analyst fits in Agile Environment

There is a lot of information and talk these days on agile development, so I am not going to bore you with agile software development principals.

But one thing I hear a lot is that most (if not everyone) in agile environment thinks that there is no need for a BA. Well I am going to be up in their face and say "Mate you are wrong”, there is more need for an experienced BA than ever and I will try to explain why.

Most of the agile project (if not all) gets disconnected from the business stakeholder over its development course and BA forms a very important link to ensure this does not happen.

Since Agile development is very organic and does change its shape and form, BA has to be constantly on their toes to make sure all the changes are well document, discussed and agreed. Since BA has tremendous business knowledge they are in better position to evaluate every option in terms of their business benefit for the business users and in the best interest of the stakeholders.
Some of the questions you can expect from a BA are

• What about this, have you thought of another option?
• Why this option?
• Do we really need this option?
• How does this change the user experience?
• What is the advantage of this option to business users?

BA will also ensure the team is solving a business problem, keep them aligned with stakeholder's goals, with that thought I will take your leave ... see you next time.