(Originally posted on Aug 24, 2008)

According to the Standish report, “User Involvement” has been ranked as the number-one factor in software projects success. The following is the complete list of factors found to significantly impact success:

1. User Involvement
2. Executive Management Support
3. Clear Business Objectives
4. Optimizing Scope
5. Agile Process
6. Project Manager Expertise
7. Financial Management
8. Skilled Resources
9. Formal Methodology
10. Standard Tools and Infrastructure

(Source http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)

How to achieve an optimal user involvement?

First off, we would need to define who the “user” is. The user is anybody who will benefit from the use of the system. This term is not to be confused with “Client”, the latter being a certain entity who wants the software to be built. The Client may or may not be the ultimate user of the system.

In any project, there should be a designated “Product Owner” (an Agile/Scrum term) who has detailed knowledge of the business domain and user needs. Often, technology companies are started by such a person, who has identified a clear business need and knows what the right product for it will be. However, this ideal situation is not always the case: sometimes, the initial idea needs to be developed in much more detail beyond the initial insight. In other cases, an existing company wants to develop new products about which it has an intuition, but not yet a complete understanding. Both of these scenarios provide challenges in which the product owner may not yet be knowledgeable enough about what needs to be built. One solution is to develop that knowledge through group studies and interviews with the target users, and to pair the Product Owner with other stakeholders.

Another challenge in building software products is distinguishing between end-user needsand wants. Roughly defined, we could say that a want is a feature that the user thinks the system should have. We define a need, on the other hand, as something that the system should definitely have, from the perspective of the software implementer.

Users will often demand certain features to be incorporated, because of the perception that they would make their life easier. However, it is exception rather than the norm that such a want SHOULD actually be translated into a feature. The reason is that individual users, from their own perspective, have only a limited view of the problem. It is the Product Owner who can have an integrated, “holistic” view of the needs across the entire spectrum, and who SHOULD decide what wants will be translated into needs. A common mistake is trying to add features for every want.

The Product Owner also needs to be aware of the difference between a function of the product, and the visual interface for that function. It may sound like common sense, but a great deal of products do not place enough emphasis on user friendliness because the product owner doesn’t have that skillset. In that case, it is vital that the Product Owner collaborate closely with a user experience specialist. Apple is an example of a company that understood it is not just about the feature, but also about the best way to interact and express that feature.

Finally, there is a need to understand the technical details of the implementation in the Product Ownership group. That idea is alien to traditional software approaches, but central in Agile. If the Product Owner doesn’t have the necessary technical skillset, a sharp separation is often imposed throughout the development cycle, which could be catastrophical for the project. The solution is to have the Product Owner in continuous collaboration with the technical team - such as by pairing them with a technical lead. At every step of the way, feature feasibility and prioritization should be considered together with the technical details - the result being much better choices, faster development time, and ultimately a better product.