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.

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)

Iteration Retrospective

Retrospective is an agile process which allows the team to stop and look at what they have been doing and ways to improve.

There are many types of retrospective depending upon when it is done; if you do a retrospective at the end of the iteration it is called iteration retrospective.

The main goal of the retrospective is to discuss with the team what went wrong, why and how can we prevent it in the future. The outcome of the retrospective may change the way you execute the next iterations.

There are 3 fundamental questions which the team should be asking

• What went well in the iteration, which we should continue doing?
• What should we stop doing?
• What should we start doing?

Please note the order of the question it is very important for the team morale to talk about success first before discussing the bag things.

By discussing the problem and suggestion the team can change the way they run the next iteration and eventually grow and be more responsive and productive. A retrospective should be plan for about 30-40 minutes, ensure the time and location used is convenient for every team member to attend, this meeting should not be optional. Shareholder, Business Unit, SME, BA, Developer, QA in fact anyone and everyone who was involved in the iteration should be attending the meeting, you may invite customer in the meeting depending upon their involvement.

Retrospective should not be a blame and shame session, it is not about who did wrong, it should be all about how can the team improve based on the team experiences. Team members should not be scared to speak up and admit the things which were done wrong.

Get feedback from the team members about the retrospective to make the retrospective better for them and finally don’t forget to thank the team to be open and honest.

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.

Agile Vs Waterfall

I am pretty sure this topic has been discussed many times and is there a clear winner ... I guess not.
I have been working with waterfall methods all my life and more recently with agile, if I have to summarise they both have their advantages and disadvantages.

I thoroughly enjoyed doing analysis in a water fall method, partly because you were given the opportunity to think and discuss solution upfront, so more time was spend doing the requirements gathering this works really well where project has limited resource (time or money) and clear objective.

On the other hand the disadvantage with the waterfall method (more so in the current era) is that it is not as versatile as agile. Business are growing (and some of them are shrinking), as day goes by there are new competition in the market, new legislations and other factors which affect the company and needs to be responded immediately, in this type of environment agile allows quick and timely changes.
Agile also allows team to delivery solution to the QA team and possible to the customer quicker than the waterfall method.