Resources for usability testing

Previous articles covered some details about usability testing. I hope by now I have been able to cover some details of what usability testing is, why it is important, and some tips / issues that one needs to cover. However, there is always more that you can explore, read about, and hence you should have an idea of some of the secrets to having a good usability testing program.
Infodesign.com.au (link)
Accessibility forum (link)
Userfocus.co.uk (link)
Web Site Usability (link)
Web usability (link)
Usability.gov (link)
Doug Ward's website (link)
Usability testing (link)
deyalexander.com (link)
Column by Jakob Nielsen (link)

An example of unrealistic expectations in the service industry

This is a true example from around 6 years back when I was working for an IT software solutions provider (the firm did software projects for different customers). This was a decent sized company that had something like 12000 people on the rolls, doing everything from development to testing to requirements analysis, and so on. I was more into the area of a business analyst, translating the requirements document into a form that the developers working on the project would understand.
This was a new project with a new medium sized bank in the Midwest, and the hope was that we would be able to do this project well enough and give them a system that would work so well for them that they would continue with the company and be the start of a long and serious (and profitable) relationship. Sounds good, right ? Well, read on.
Around this time, our company, that was a publicly listed company was getting on just like the other service companies of that time, doing okay, but not generating great figures. Management was getting hit by analysts, and passed on a directive that every project needs to meet the company defined margin. Exceptions only when pleaded before the executive committee, and not otherwise. Implicit was the expectation that anybody who does a project that does not promise enough margin would need to explain the project.
Now, since our project was with a new customer with whom we had high hopes for the future, we could not charge our expected rates; after all, why would the customer then select us ? So, our account manager along with the Vice-President of the unit went ahead and quoted a rate that was atleast 20% lower (getting fewer people assigned to the project than necessary). Guess what ? Pretty soon, the strains and missing people started to show.
Ego also plays a part. For a Vice-President to go before the committee and plead for more money (a reduction in margin) would reflect adversely. The members of the committee, who might be expected to provide an experience of being able to handle these kind of situations and offer some latitude did not do so since they were never offered this project for review. Pretty soon, somebody senior in the team had the bright idea that weekends could be converted into work hours (maybe 1 weekend in 3 could be off), and this idea was implemented with gusto.
You can guess the rest. People from outside the project did not want to join, quality reviews of the project were hesitant because of the many exceptions, and eventually the customer could make out that the quality was not as desired. Project over, account over, and pretty soon the project manager and other senior team members quit and went to other companies.
This was a disaster caused by the management reacting adversely to poor numbers, and unwilling to exercise the due diligence in doing a project (after all, the first criteria for a project should be to make it successful).

How many of you have similar experiences ?

Hiring a consultant for generating your requirements: Part 2 of an external article

The previous article presented the DragonPoint.com article outlining 5 essential steps that you need to take when you have people hired to do requirements analysis for a project. Well, here is the link to the part 2 of this article that outlines tips 6 - 10 for the requirements gathering process (link). These next 5 tips are:
6. Make resources available: You need to budget for making sure that the requirements capturing team can access the current system and employees.
7. Include the employees who actually use the system: It is critical that the requirements gathering team get access to actual users who use the system, not only to the management people who drive the project.
8. Let your employees know their input is important: Make sure that the employees working with the requirements team understand that they need to help the team. At the same time, employees who are working with the team can provide an impression of the competence of the requirements team (are they asking the right questions, are they focused on the current processes, etc)
9. Remember why you hired the consultant: Do not take anything for granted. Explain your process in full detail.
10. Take ownership of the project: Hopefully not necessary to explain this. The project is important, and you need to make sure that it gets full importance.

Requirements gathering: DragonPoint Article (#1)

Requirements gathering for a software project (that you really need to expand or maintain your business) is a tough job; the toughness is because it is not an exact science. It depends on the type of project, depends on the nature of the people who will enumerate the requirements, and it depends on the capability of the team that does the actual requirements gathering. In such a scenario, it makes sense to read as much as possible about the requirements process so that one is aware of the best practices, about different use cases in which the process has worked, and so on.
A lot of companies that want to get hire consultants for this critical stage, and here is a great first part of an article at Dragon Point that talks about 5 steps (out of a total of 10) to become better at requirements gathering:

Any needs not identified during the requirements capture stage will result in scope creep. According to Suzie DeBusk, President of DragonPoint, the most effective way to minimize scope creep is to allocate 30% of the time spent on a project to requirements capture, design, and review. How does requirements capture reduce scope creep?
The requirements capture stage is similar to the planning phase of a construction project. If the client and architect do not communicate effectively, the blueprints will not meet the client's needs. And, depending on the size and scope of the discrepancies, this error in communication can result in costly rework as the project evolves.

As per the article, the following are the main points:
1. Be prepared for the initial consultation.
2. Remember your current system
3. Communicate.
4. Look for listening.
5. Listen for insightful questions that demonstrate you and your consultant share common goals.