Tuesday, October 30, 2012

Does a Small Business need a Business Analyst?

Small business owners or business management won't think they require the service of a business analyst. They can be caught up in attempting to survive and overlook key elements of their success. The analyst can in truth are available in and apply his expertise to make out what the business is needed to expand. There's times when he sees the gigantic picture where the management only sees the base line

The business management can make the most from the analyst in quite a few ways. As an authority, he might be able to offer an unforeseen income-generating opportunity. The prevailing marketing techniques can be proving ineffective or not making the necessary income to justify the price of marketing. The analyst could possibly recommend yet another helpful marketing method. Would be the business could aim for specific clients in preference to a general population. The analyst might be able to recommend point of sale income not thought about by the business management. Other elements this expert could recommend will be repackaging in several sizes, where suitable. Offering complimenting sales items could have not occurred to the management. The business analyst is there to clarify a further perspective.

The business analyst would be clever enough to investigate the business and judge what business decisions ought to be made. She or he can educate the landlord of latest programs available. The analyst might be capable of suggest new technology the small owner isn't making the most of. Thus, an excellent business analyst can support the small business in lots of ways.

The business analyst is an inventive thinker. She or he can show the business owner find out how to put into practice progressive business techniques. These techniques won't have thought before by the business management. The business analyst can view the broad scope of factors to establish a necessity by the client. The landlord can have no concept that these areas of opportunity exist. That's as much as the analyst to provide an explanation for the landlord what's going to work and what is going to not work for his venture.

Generating profit and building customer relations are both key components that each business is concentrating. an even analyst is an expert in his field and may manage to combine these two key elements right into a course of action for the business. This expert can act because the liaison between the business and the client to set up that the business fulfill customer needs.

The business and its customers can enjoy the knowledge a business analyst brings to the table. Usually, the added expenditure of an analyst is justified by the rise in revenue generated by using his expertise.

Monday, October 29, 2012

How efficiently the Requirements can be prioritized

One key factor that may be often overlooked or underestimated during requirements elicitation is prioritizing requirements. If there are 25 documented itemized requirements, and 22 could be met by a software solution, you might imagine that could be an excellent percentage to have. But what if the three requirements that weren't/can not be met were the three most vital of the unique 25 - What once will have given the look of a good implementation now will become a questionable one.

Another example; let’s say there are 25 documented and itemized requirements, and only 10 of them can also be met by a software solution. Which can raise an alarm for an analyst, but upon closer examination the 10 requirements that aren't met are classified as low priority or “nice to haves”. The 25 requirements met are classified as critical priority. There's a different solution option that satisfies 15 of the necessities, but is missing 10 of the critical requirements. At the surface satisfying 15 of 25 requirements could seem just like the more sensible choice, but a deeper look under the covers will provide you with a clearer picture.

Given the time and resource pressures faced by all organizations in today’s economy, assigning a concern/weight to every requirement is a critical task that should be completed during requirements elicitation. Businesses must decide what's most necessary to them in an answer before you hit the drafting board.

Thursday, October 25, 2012

How to manage the Project Scope Succesfully for a Business Analyst

Why manage scope?

Successful scope management is necessary to the success of any project. Whether it is not closely controlled within the process a project, there are many issues which can arise:

  • The project overruns its timescale
  • The project goes beyond budget

In either of those cases, there's a risk that the project gets pulled either as the budget is fixed or it has a delivery deadline that's not negotiable. Even when there's some flexibility in budget or timescales, there's a much greater problem that is credibility.

The project loses credibility whether it is unable to manage budget or timescale and when it has lost credibility, folks that control the finances are more likely to drag the project to forestall further losses.



Techniques for successful scope management
  • In a project where the culture is open and consensual, it is usually effective to clarify the issue very clearly to the stakeholder proposing the requirement which contradicts the vision. Thus, the business analyst should explain how the requirement doesn't fit in the vision. He/she also needs to explain that it truly is always the case in any project that it's going to not be possible to deliver the whole requirements as it truly is inevitably the case with a finite budget.
  • The business analyst should invite the stakeholder to drop the requirement. It is advisable sweeten the pill by offering to incorporate it in a listing of necessities which are ‘nice to haves’ and may be considered in a future release or for a special project. The stakeholder cannot necessarily take in this ‘opportunity’. 
  • If the project is incredibly much management led and scope control is invoked very clearly by the project sponsor, it can be beneficial to give an explanation for this same view to the project sponsor rather than the stakeholder. To that end, the choice may be made more easily but it surely is significant that transparency is maintained the verdict and the justifications are explained to the stakeholder group. Some can be pleased with a less transparent approach but i think this works well to accumulate trust and makes for a more productive working environment. 
  •  Another approach is to play off one requirement against another in front of the stakeholders so they can decide the priorities. This is approached very using asking them to visualize the project was completed but requirement "Ex: Automating Sales Process" was not supported because there has been insufficient budget to deliver requirement "Customizing Sales force automation" and requirement "Integration with ERP".

    As a consequence, requirement "Automating Sales Process" should sit very clearly in the vision and requirement "Integration with ERP" must be the only you desire the stakeholders to drop.

    Again, this helps the stakeholders see for themselves the relative priority of necessities and to query which of them are really critical.
  • If none of those approaches work because stakeholders are being resistant then more formal requirements prioritization techniques must be pursued (see article). There's a strong argument that these ought to be undertaken anyway to support discussions later within the project regarding what appears in a release and even when it will be significant to attenuate the scope caused by unforeseen circumstances.
In summary, project success is solely possible when project scope is managed very carefully. The hazards to budget have to be managed to bypass the project losing credibility being cancelled. 




Friday, April 27, 2012

Requirements Elicitation

Requirements elicitation is the first phase of Requirements Engineering and it include all activities involved in discovering the requirements. Requirements Elicitation is also sometimes referred as Requirements gathering.

In Requirements Elicitation phase system developers and engineers work in close relationship with customer and end-users to
  • Find out more about the challenges to be solved
  • To describe the functionality of the system.
Not just a simple process about fishing for requirements, but a highly complex process:
  • Customer rarely have a clear picture of their requirements
  • Different people have conflicting requirements
Requirements_Engineering
Requirements Engineering

Most of the times the Business analyst can never be sure you that he gets all the required requirements from the customer by just asking them what the new system should do.

Challenges in Requirements Elicitation:
  • Inconsistency of the requirements collected from different end users of departments like Sales, Accounting, Stake holders etc. 
  • Some time, clients will assume few requirements are understood by the Business Analyst so he will not talk about those requirements in the meetings and even some times Business Analyst forget it and assume those are understand. But all the times, the assumptions don’t match between the client and business analyst. 
  • Most of the times the requirements will be given by the end users, as the stake holders will be busy. Once requirements gathering are completed, while showing the new developed system demo to the stake holders, they will raise new changes or tell this process is incorrect. These kind of issues will rise due to insufficient time of stakeholders while requirements gathering. 
To collect the entire, accurate and consistent requirements, the Requirements Elicitation process is very important.

Requirements elicitation practices include the following
  • Interviews: The most common technique of Requirements Elicitation. Asking more questions related to the requirements. For example: Who will create a Sales order, is it Sales man or Sales Manager? Should a Sales man have permissions to delete the sales order? There are two types of Interviews:
    • Structured: User/Stake holders answers with a predefined set of questions within the meeting of one hour.
    • Non-Structured: No Predefined agenda, generating new ideas, brain storming etc.
  • Questionnaires for different departments involved in the organization: Be prepare with questionnaire document which are relevant to the Process/industry. Most of the industry process is same in all companies, only few processes might differ which would involve additional steps. The standard questionnaire will help to get the most high priority requirements what the client are looking for. The same document can be used for other clients also. 
  • User observation: Most of the end users find it complicated to describe/communicate the requirements it is so usual to them. The best way to understand them is at work place, what they are doing?
  • Workshops: The Requirements Workshop is the most powerful technique for eliciting requirements. It gathers all key stakeholders together for a short but intensely focused period.
  • Brain storming: Brainstorming is the process of generation ideas/creative inputs from a number of participants like Subject matter experts, Business analyst etc. Participants must follow a process model in order to make the gathering of inputs more orderly and more efficiently.
  • Use cases: Use Cases identify the who, what, and how of system behavior. Use Cases describe the interactions between a user and a system, focusing on what the system “does” for the user.
  • Role playing: Role playing allows stakeholders to experience the user’s world from the user’s perspective. A scripted walk through may replace role playing in some situations, with the script becoming a live storyboard.
  • Prototyping: A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.
Requirements Elicitation is the cyclic process, the goal of this phase is a model representing the requirements of the system seen from the user‘s perspective.

Saturday, April 21, 2012

CRM Business Process

Most of us know what CRM, its Customer Relationship Management is, in layman language CRM is the model used by most of the organizations to manage their interactions with customers, and sales prospects. The main goals of CRM are:
  1. To gain new clients
  2. Retaining the current clients
Definition of CRM in business language: Customer Relationship Management is a comprehensive strategy and process of acquiring, retaining, and partnering with selective customers to create superior value for the company and the customer. It involves the integration of marketing, sales, customer service, and the supply-chain functions of the organization to achieve greater efficiencies and effectiveness in delivering customer value.

In this article let’s talk about the CRM business process from where the process starts and ends.

There are some important Roles, Groups in the CRM system, who will interact with leads, potentials, customers and perform few activities on them like scheduling meetings, follow up calls etc.

The CRM business process starts with a Lead.

CRM Business Process
CRM Business Process


Lead: Lead is the one who is the initial contact for a company. Leads can be generated from multiple resources, to list a few list building, e-newsletter list acquisition, email/web advertising which are paid sources, search engines results, web form (the visitor fill the form in the website, the same information will be created as a Lead in CRM system) referrals from existing customers etc. The major sources of lead generation are
  • Search engines
  • Ads
  • Web Form
Few companies start with the concept called Pre-Leads. Pre- leads are not the bulk contacts which would be ranging 10,000 – 20, 000 number. In few companies, the call center people will call all the 20, 000 contacts and it they are interested in a particular product/service, then the pre-lead is converted into a Lead.

When Lead is created in the CRM system, a Sales Man will be assigned to the Lead, it means he is the responsible person for the Lead. When Lead is created, CRM system will send auto responders to the Lead it means; once he is registered in the crm system one email will be send. After two/three days another email will be sent to him regarding the company products/services information. Like this few emails will be sent to the Lead, the time in days can be configured in the system with how many days difference the email to be sent to Lead.

The Sales man will call the Lead and explain about his company products, and perform few common activities like
  • Schedule follow ups calls
  • Schedule meetings,
  • Takes notes on the Follow up calls/Meetings
  • Schedule Events for Leads etc.
Potential: If Sales man feels, that the Lead will be interested to purchase product/service, then the sales man will convert the Lead into Potential with entering important information into the CRM system. The information like
  • Probability of the Lead – 100% (it means How much probability is there to convert that lead into customer based on his interest)
  • Estimated Amount (it means How much amount; the lead is willing to spend on the product or service.)
  • Phase: The potentials are sorted by different phases like Prospecting, Closed Won, Closed Lost, Priorities and criteria which depends on the organization.

The same activities which are performed to the Lead will be carried out for the Potential. When the Lead is converted into Potential, the data will not be available in the Lead; all the Lead history like scheduled calls, scheduled meetings, events etc will be moved/transferred to the Potential for reference purpose. The potential might be assigned to another Sales man.

Customer: If the Potential purchases the product/service, he will be converted into Customer. As soon as the Potential is converted into Customer, an Account also will be created on his name which tracks all the revenue generated by the Customer and User name and password will be sent to the customer where he can login and raise the tickets, upload information, upload documents etc.

Latest Promotions will be sent to the entire customer in the CRM system weekly/monthly with respective their products/services

Customer service: If there are any issues/defects with the Products/Service, the customer will login into his portal and raise a ticket with the ticket title and description about the issue. As soon as the ticket is raised it will be assigned to a support agent automatically/manually based on the CRM system. In few CRM systems SLA – Service Level Agreements will be implemented. The Support Agent will work on the ticket and update the status to the customer till the issues are resolved. Customer can also check the status of the ticket from the customer portal.

To simplify the CRM Process Lead is converted into Potential and Potential is converted into Customer.

The above CRM process is the basic industry standard, it might change based on the Organization, industry verticals like Telecom, Real Estate, Manufacturing etc.

Monday, April 16, 2012

Business Analyst Tools

Why Business Analyst should use tools?

The tools would be useful for the Business Analyst in project implementation, as the Business Analyst would be involved in so many activities like gathering business requirements, analyzing the requirements, categorizing the requirement, maintaining the requirements in the document for different versions etc.

The tools will help doing the activities with ease, maintaining them in different versions that will help the Business Analyst in making the project successful. The tools are designed based on the best practices so it’s strongly recommended for Business Analyst to use the tools.

It is not one tool, which the BA can use it for all the activities in Project implementation. BA has to learn few specific tools which are designed for specific purpose to do the job more efficiently. It is also not necessary to learn all the details, ins and outs, workings of the tool, but the BA should know what the tools is specifically designed form, it means the basics of tool, its main features which will give you an idea of what to do with that tool.

There are many tools available on the internet, but the Most popular Business Analyst tools used are:
  • Rational Rose – useful in Requirements Management
  • Microsoft Visio – Used as a diagram or modeling tool.
  • Microsoft Office.
Most of the Business Analysts (including meJ) use the Microsoft office and Visio.

Microsoft word: It is used in all the activities of the Business Analyst which are as below:
  • Preparing Proposals
  • Preparing Solution document
  • Preparing Communication plan
  • Preparing MOM (minutes of meeting)
  • Preparing SRS (System Requirements Specifications)
  • Preparing FS(Functional Specifications)
  • Preparing TS (Technical Specifications) and many more… (depends of organization)
  • Preparing weekly/monthly Project summary report
Some time BA’s use Microsoft word for creating UML Diagrams, flow charts and capturing screen shots.

Microsoft Excel: It is used in few of the activities of the Business Analyst which are as below:
  • Create Project Tracker (high level document which gives a complete picture on what’s happing in the project and its status, target dates, go live dates etc.)
  • Create Use cases documents
  • Used for tracking issues, new changes etc.
  • Used for analyzing trends
  • User for and generating bar charts etc 
 Organizations use Microsoft Excel to perform complex tasks.

Microsoft Power point: It is mainly used for creating visuals for presentations.

PowerPoint allows you to create slide show presentations using visuals that how the system is going to work, user interfaces designs, few diagrams which explain the flow of the processes.

The PPT creates a better understanding of the new system that will draw the attention of the customer in and create a better understanding of the new system.
Believe it or not, most of the Business Analyst will use the Microsoft office for their activities.