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.