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 3 - Technology and Commercial)

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

Technology

Platform

• Is the Software developed as per company hardware requirements?
• Software developed in accordance to company software requirements?

Coding Standards

• Coding standards followed based on company coding standards?

Comment in Code

• Will all classes, functions, procedures be documented ?
• Will comments be used to describe intentions, algorithmic overviews, and/or logical flows?

Documentation

• What code documentation and end user documentation is provided ?
• Data Model ?
• Class overview ?
• Architecture overview ?

Training / Handover

• Is there a proper procedure for handover and time allotted for training?

Commercial

Development Cost

• Is the proposed development cost acceptable?

Delivery time

• Is the proposed delivery time acceptable?

Support Cost (e.g. training, end user support if required, technical support)

• Is there any support cost involved?
• Is there a warranty period suggested?

Maintenance Cost (i.e. bug fixes)

• Is there any maintenance cost involved?
• Is there any warranty period suggested?

Terms of Payment

• Are the Terms of payment proposed agreed by the sponsor?

Penalty / Incentive

• Is there any penalty proposed if the milestones are not achieved on time?
• Is there any incentive available to achieve before time?

Ownership

• Is the company claiming any ownership on the software developed?
• Are the any licensing fees involved?
• Do they intend to use this product for any future development for their clients?

The list goes on, I do not intend to blog every criteria but the list above could be a good start, do not hesitate to contact me with your feedback.

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.