Web & Technology Insights

According to the Standish report, “User Involvement” has been ranked as the number-one factor in software projects 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 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.

You need to designate a Product Owner 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. The 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 needs and 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 will 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 will 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.

Recruiting software professionals for a new technology is difficult. Coupled with a general job-seeker’s market and a region short on technical talent in general results in an even more serious problem. Such was our experience with one of our New York City-based clients; the particular technology in question was Ruby on Rails (RoR).

Ruby on Rails is no longer extremely new, but still considerably less popular than Java, .NET or PHP. And the reality is that most technical people would rather live on the West Coast than in the hustle of NYC.

As with every challenge, there are ways out, and it can be turned into a big opportunity. In fact, since most companies will face the same problem, the opportunity to solve it will be all the better.

Here are the approaches that proved successful for us.

1) Recruit people without explicit experience in the particular technology, but who are totally capable and eager to learn it

Almost all of the strong RoR developers around had a job or enough contracts. What to do, stall the project or change the technology? Not the smartest thing to do.  Our approach was to get promising people, with a background in related technologies - in this case, PHP and other Object Oriented Programming languages. These developers learned Rails quickly and were able to surpass our expectations.  Interestingly enough, this principle runs counter to some people’s advices advocating only hiring people with at least a Rails project in their portfolio.

2) If faced with a choice, get someone with a lot experience and skill in a similar technology, over someone with a little experience in the same technology.

Unfortunately, some of our offshore consultants were in the second category - that is, they had some Rails experience, but their overall web development experience was low. Fortunately, we made the opposite choice when we recruited the on-site people. A developer with significant background in PHP, CSS/Javascript and databases proved to be an exceptional Rails developer in a short period of time.

Which brings us to the next point:

3) Do not underestimate the teaching power of the web

A lot of technical problems have been already solved, and chances are someone out there posted a description of how to do it. A significant number of programming constructs (plugins, modules) have already been made. And for Rails, the web community is so good that often all it takes to uncover how to do it is a simple Google search. Therefore, knowledge of the specifics of a particular technical language has become even more irrelevant - and someone who has a strong understanding of the principles is the best asset.

4) Recruit people with communication skills. Encourage and grow communication skills.

It is common to assume as a given that IT professionals lack good communication skills, but that doesn’t need to be the case. In fact, particularly if the development methodology is intended to be Agile, the assumption is unacceptable. If there is a need, management can (and should) set up processes that will encourage better  communication. We were able to get people with both technical abilities and excellent communication skills at the same time and that was instrumental to the success of the projects.

5) Engage technology professionals in the hiring process

It is tempting to try to delegate the candidate search to recruiters, whose sole job is to look for people. Yet sometimes with new technologies it is the developers themselves who can be more successful at getting new hires. Through their memberships in various online communities, personal networks and knowledge of specific job boards, excellent referrals can be obtained.

Conclusion

In conclusion, not starting or stalling a project just because people with that particular skill set can’t seem to be found is not a solution. Lost opportunity can be a lot more costly. A good principle is to look for people showing the general traits of adaptability, passion for technology, general technical ability and work ethic.