Power of Acknowledgment

I appreciate acknowledgment every now and then, a good acknowledgement in fact makes my day as long as it is real, sincere and heartfelt.

Now if that makes me happy I am sure that makes others happy too, but how often do we acknowledge people, not very often, it is difficult, we are so verbose when things go wrong but the same enthusiasm is lacking when things go right.

If you acknowledge someone you inspire and motivate them, it is also very crucial for a healthy relationship. Delivering an acknowledgement is an art and if done correctly can be very powerful else it may have an entire opposite effect.

Below are some of the tips on delivering effective acknowledgment

Tip 1: Communicate only when you are happy, your message will be heartfelt and will appear genuine.

Tip 2: Differentiate between Acknowledgement and Compliment. Acknowledgement is about recognizing their accomplishment and to show that what they did has made a great difference. Compliment is just being nice, kind of good manners.

Tip 3: Use facts and examples to support your acknowledgement rather than generic thank you statements.

Tip 4: Be honest, do not acknowledge when you don’t believe in it, most people can see right through and you can actually come across insincere or every phony.

Here are some myths about acknowledgement

Myth 1: Only positive people should be acknowledged. There are always people in team who bring positive criticism; even they need to be acknowledged.

Myth 2: Rare acknowledgement is more precious. In fact the more generous you are with your acknowledgment the better it is.

Myth 3: People are just doing their job. Most people want to go a great job and everyone does a great job but every acknowledgment makes them work harder and feel treasured.

Myth 4: Individuals should not be acknowledged, it is bad for team morale. I some time think the team concept has gone too far, as must as the team delivers but the members within the team are the one who makes it happen. The best strategy is to compliment the team and acknowledge the individuals.

I would like to mention a very recent incident, I was on a flight to Melbourne for a user conference when the air hostess was serving food, she gave me two choice Ham salad or spinach roll. I ordered spinach roll, just before serving me she said ‘Sir I know you ordered spinach roll but I feel I should mention that it has beef in it, will that be ok with you?’. I think she guess that I am a Hindu and don’t eat beef but that comment was so sincere that it touched my heart, I told her ‘Thank you very much for asking, I don’t mind eating beef but thank you for caring”. In fact also wrote a letter to the airline to acknowledge the great service I experienced. I am sure that the air hostess felt happy to receive an acknowledgement but I was happier to give one, in fact giving acknowledgment is a win – win situation.

Practice this skill on daily basis, try to acknowledge at least one person every day, you will see that you create so much positive energy and enthusiasm.

The five ‘P’ in a team formation

Here are the five areas to be discussed when forming a team.

People
I am sure you will agree that this is perhaps the most important area of the team, after all it is the people who makes the team. Success of any team depends upon getting the right balance of people in the team. In an agile environment it is very crucial to create a cross functional team, not just based on their roles and experience but also their personality.
Team is just not about picking the best people from the organization, it is a combination of people to form the best collaboration. Do not hesitate to pick someone who may not be very experienced but that person may be a good team player and will bring the best of people around him/her.

Purpose
No one can guarantee success if the team has no clear purpose. The entire team must be clear on what the purpose of the team are, it is also very important to align the purpose of the team to the vision and goals of the company, this way you always get buy in from the senior managers.

Place
Ensure that the team fits into the organization structure in such a way that it adds value to the company, draw people from various part of the organization to ensure that most of part of the organization are well represented.

Power
Discuss and agree with each team member their responsibility and authority, discuss what the boundaries of the team are?

Plan
Plan is all about the structure of the team, who will do what, when and how? Who is running the team? You may want the team member to decide amongst themselves the detail plan.

These above areas are important to address because they directly affect the team's ability to achieve its goals.

Writing Agile Requirements

Lots of people believe that in agile environment, requirements are not necessary, that is not true at least according to me.

The requirements in agile environment are represented as user stories, user stories helps the team to understand who the actual users are, what they want, what is to be developed and what should it look like when it is completed. The ability to write and understand user stories is the heart of agile development and everyone involve in this environment which includes developers, BA, testers and business users should have or learn this skill.

When writing an agile requirement try to answer the following questions “Who, Why, What and When”. Start with gathering high level user stories to describe the needs and goals of the stakeholders, this will help you to identify project goals and deliverables. Every user story created there onwards should one way or another add value to the high level user stories, the advantage of that process is that if you find any stories which do not contribute to the high level goal you should ask ‘Do we really need this?” or perhaps you have misinterpreted/misunderstood the user story.

For each user stories it is also very important to write the acceptance criteria which usually come from business users. This is very crucial during the QA and UAT phase, do not leave this for later, it is very important and the best time to do this is when user stories are created.

During gathering agile requirement focus more on ‘why’ and ‘what’, do not fall into the trap of ‘how’ which is very tempting especially if you have developers and architect in the meetings.

For each requirement define the scenario broken down by pre-condition, actions and expected behaviours.

All the user stories collected during various meetings will form your product backlog, later based on the prioritisation user stories will be added to the iteration backlog.

The biggest advantage of agile requirements is when you have product managers, business users and developers working together you get the best outcome in the shortest period of time.

Finally don’t be tempted to gather and define all the user stories in advance, all you need is the user stories for the current release, once you get to a stage of implementing a user story that is when more details are needed.

Feel free to contact me if you have any questions, good luck with requirements gathering.

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.

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