O User, Where Art Thou?

In my previous article (http://www.batimes.com/articles/are-we-there-yet.html), I referenced the Standish Group’s CHAOS Report, which stated that the biggest issue leading to project pain is lack of user input.  Anyone reading this blog should know that user participation is a vital part of the software development lifecycle (SDLC).  Therefore, you should interview customers for requirements early and as often as possible in the SDLC.  Since you can’t get input from every user, you will need to place users into groups of user classes, which are based on the features and functions that are most utilized by each class.  Each of these user classes will have its own prioritized set of user, functional and non-functional requirements.  Once you have identified the different user classes, you will need to name the product champion within each user class.  This is a person who has expert understanding and decision-making power to formulate requirements on behalf of the user class they are representing. Even if you can locate this spokesperson, they will have other tasks in their day-to-day life that will compete with the time you need to spend with them.  For this reason, you should make a request to the champion’s management, letting them know that the champion’s involvement is a priority.

Since most projects have several user classes and each person knows something different from the others, you will need a small number of these product champions.  During requirements elicitation, each of these champions will get involved often and at different times depending on the function/feature/process being detailed.  You should look for one representative per user class, and sometimes you can get lucky by finding someone who can represent several user classes.  This product champion should be able to communicate requirements, suggest ideas, reconcile between contradictory information and help you arrive at a cohesive set of requirements for their user class.  This person also needs to make key decisions, which means they need to be informed, respected and be an effective communicator within their user class.  In a model situation, product champions are located with the analysts, testers and developers, and can devote their entire time to answering questions and providing all the necessary details during requirements elicitation.  In reality, few champions are located with the analysts, testers and developers.  Also, you are fortunate if you can get a couple of hours a day of the champion’s time due to other tasks they need to perform within the organization.  Therefore, when selecting project champions, look for the following traits and factors:

• They must be knowledgeable and respected within their user class.
• They need to understand and be committed to their tasks as product champions.
• They should have the time to commit and their management should encourage their involvement.
• They should have the power to make key decisions.  If product champions do not have the power or the willingness to make the necessary decisions, then the developers will make them for them.  This is not a good idea because developers usually do not have the right point of view to make the best decisions for the business.

There are situations where the analyst has very little or no access to the real users.  This happens quite a bit when developing commercial software products for a new or emerging market.  In these cases, you need to use surrogate users versus real user champions.  This can be a product manager or a subject matter expert (SME) in the field.  There are a couple of groups to stay away from if you are going to choose surrogate users.  Avoid the manager of the real users as a surrogate champion.  Usually, managers don’t use the product like the real users use the product.  Secondly, managers don’t have the time to fully dedicate themselves during requirements elicitation.  Another group to avoid as a surrogate champion is the software developer.  Unless the developers themselves are using the product, they do not make good surrogates because developers have a different point of view of the product than the actual users.

If your stakeholders do not put a priority on allowing product champions to work with analysts then tell them this: you’re going to need to get user input now if you want to spend less time, money and cause less frustrations during user acceptance testing.  Your projects will be less “challenged” when you get user input early and often during requirements elicitation versus waiting until the system is in testing or in production.  If the stakeholders can’t get users or surrogates during requirements elicitation then this indicates that there is little assurance of the success of your project.

Don’t forget to leave your comments below.

---

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.