Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Requirement Gathering Techniques - Part II - Choose your tools

I'm listing a few different methods that you can use to extract requirements from clients. In my previous post I talked about understanding the situation you are facing: the nature of the project, the urgency and the availability of knowledgeable resources. These factors will determine which methods are more suitable for your situation and what combination you will employ. By using your experience and factoring in the magnitude of your project, you will be able to estimate how many sessions you will need for each method.

Prototyping

Good for user interfaces.

Good for allowing visualization with clients.

Clients focus in on the details and look and feel. This is a good thing when creating functional specifications but not very good for getting high-level business requirements (i.e., understanding the general business purpose and objectives.)

Clients may develop expectations that final product can be developed quickly since the prototype was developed rapidly.

Observation

Good way to see and understand the existing workflow and processes that are used. Particulary helpful if the process is only known by the end-user.

End-users have a tendency not to behave how they normally would or feel that they may be being scrutinized.

Brainstorming

Good for faciliation and idea development.

Easy to lose focus and start going off on tangents.

Requires lots of different people.

Requires follow-up meetings to refine.

Interviewing

Short daily sessions are less distruptive to the lives of clients but take longer to reach end of job.

Inversely, longer half-day to full day sessions are very distruptive to clients day jobs but you can finish faster.

My next post will be concerned with setting expectations for your clients as to the production of requirement deliverables.

Requirement Gathering Techniques - Part I - Know the situation

My next set of posts will speak to the different types of techniques that can be employed to gather requirements for a project.

It is important to understand which methods are appropriate (or conversely which ones are not appropriate) for a given situation and to choose accordingly. The selection of an inappropriate tool will hinder your efforts.

I like to think that as I learn and experience more, I am refining my own approaches as well as learning new techniques. This allows me to have a larger repertoire of tools (in my "toolbox") that I can use to tackle future opportunities. At least, that's my personal philosophy on this subject.

One of the first things that you should understand is, "What is the situation?" Usually this is fairly self-evident, however, you should always make sure you are at least pointed in the right direction before you start running.

To understand the situation, criteria that you should consider are:

The nature of the project

• How much is known about the project (i.e., is there already a defined idea or are facilitative efforts needed?)
• Are there user interface requirements?
• Have similar efforts been done before (internally or externally) that can be leveraged?

The urgency of the project

• In a utopian society, we have lots of time. In the real world, sometimes we are already behind before we even start. Are you in that situation?
• Are there hard deadlines that cannot be moved (i.e., legislative mandates?)
• Is this an investigative or facilitative effort?

The availability of knowledgeable resources

• Who are the different people involved?
• What time commitment can the key clients, end-users and subject-matter experts provide?
• Are external resources, such as legal experts, needed?
• Is potentially useful information available on research sites like: Gartner, Forrester, or the Yankee Group?
• Are there user groups or independent communities that can be leveraged?
• How much knowledge does the business analyst have on the subject?