Gather 'information' from users, not 'requirements'

Users do not have requirements

Users do not have requirements for the final solution. Nor do stakeholders. Nor does anyone else in the business . The job of the user is not to create requirements for us.

Many organizations attempt to make defining requirements the job of the business. Listed below are some of the reasons why this approach doesn’t necessarily work.

Users see the business, problem and solution from their part of their business process

Users are more focused on their jobs. They look at the business, problem and the solution from their part of the business process. In this project, some of the users were keen to see a few additional functionalities in the new application that would give them more flexibility in rate calculations. However they were not sure how the new application would interface with other quoting and rating solutions or how the application would facilitate more streamlined processing of the overall business.

Users may not know what IT wants

Users may not know what IT wants. They may be keen on discussing the business problem with us, or how they would like to see it being resolved.

For instance, they may not know what requirements mean to us; or what functional and non-functional requirements are and/or how to express them. Like many other projects, in this project too, we found a lot of users who were not sure about the non-functional requirements including performance issues such as application response times or capacity and scalability issues. They were keen on adding features in the new application which could solve some of their business problems such as flexibility in rate calculations etc., besides other problems.

Users may not know what is available technologically

Users may not know what is available technologically. For instance, in this project, we found users who were not sure about the latest versions of .NET which were commercially available or the advantages of using a particular version of .NET for developing the tool.

Users may not be able to visualize the solution

Users, may not be able to visualize how the end product would look like. Although our client was using a rating tool which was built in Visual Basic for Access, most users were not able to visualize the new solution which would rebuilt in .NET 2.0 and which would contain a lot of additional features to address their business problem . Also, some of the functionalities in the existing system were obsolete or unnecessary. This was one of the primary reasons why  we  build a proof of concept solution of the rating tool , for the clients. The proof  of concept solution also provided us with a lot of other benefits including a very  clear understanding of requirements ; understanding of the capabilities and limitations of .NET 2.0 technologies and MVP design pattern; ability to assess  design decisions early in the process; ability for the customer to visualize early  on, the look-and-feel of the solution; and reduction in the overall risk of project  failure .

Users may not aware of the overall implications of what they ask for and are likely to specify requirements that conflict

Users may not be aware of the overall implications of what they ask for and are likely to specify the requirements that are in conflict with each other. One of the classic cases of conflicting requirements in most projects that I have managed was between the requirements for security and usability. Methods of enhancing security came at a price of reducing usability and vice-versa.

If we don't gather requirements from users, what do we gather then?

Users are usually keen to talk about the details of their job such as the business problems that they face in their existing applications, their perception of the business problem and the solution, who else will be impacted by the problem or solution, so on and so forth.

So, what do we gather from the users? We gather information and not requirements.

It is this skillfully elicited information which is analyzed, to derive and define the solution to the business problem . The solution is written as a clear set of requirements which is used to state completely and accurately , what needs to be done to solve the business problem . The goal is to gather information and not requirements.

'Whoever gathers most information wins the game!'

Changing our expectations…understanding the domain view of the problem

There is more to it than just changing the language. It is a paradigm shift in our mindset and our expectations from users. When we expect to elicit information from users, we assume that users don’t know what they want and it is our job to determine the solution to their business problem.

An important aspect of this change in our expectations is that we focus more on our skill sets in eliciting pertinent information, information that will lead us to the proper solution to the business problem.

When we expect users to give us the 'requirements ' we are compelled to ask them questions such as "What do you want (need ? )".

But when we assume that users do not have requirements and it is our responsibility to define the requirements , we begin to realize that what we need is a bigger and better vie, a domain view of the problem. This allows us to gain more business insight and more knowledge about what’s happening around in the business.

At this point, our line of questioning changes to How do you do what you do? How do you perform your daily tasks? What information do you need to do your job? Where do you get it? What do you do with it? What are the business problems that you are facing now? etc.

Users are also more likely to talk about their jobs, their business problems, the solutions their existing tools, etc. During the proof of concept development, I had coordinated with our business users and had arranged for a few product demos for the offshore development teams. We were quite surprised to find that users weren't really tired of answering our questions regarding the rating tool and their daily jobs.

When we change our expectations, we may also want to spend more time observing the business processes to further understand the changes that are required to solve the business problem.

But why should project managers be bothered about requirement gathering and analysis ? Isn’t that a Business Analyst's job?

Well, by diversifying our knowledge and wearing both hats, we will not only be able to increase our marketability, we will also be able to acquire project success.

There are many organizations where the roles of a project manager and a business analyst are two distinct roles. But organizations are now increasingly seeking to hire professionals who are knowledgeable and competent in both these roles; for various reasons including the need to reduce project costs.

Since the requirements are the primary means of understanding and managing stakeholder expectations, they have a significant impact on the success of the project. Schedule, budget, quality specifications, risk factors and resource planning, all tie back to these requirements. To avoid cost overruns, dissatisfied users, or even project cancellations, it is vitally important to build the project on well-formed, testable, and verifiable user requirements.

Also, did you know that according to Carnegie Mellon, 25% - 40% of all spending on projects is wasted as a result of reworks . And that, 70% - 85% of all project rework costs are due to errors in requirements.

During the proof of concept development, one of primary responsibilities of the team was to extract business rules from the existing tool in Visual Basic for Access. These business rules which were extracted by the development team were then used by the business analyst team to define the final set of requirements. The final set of requirements was what we needed to enable the implementation of and compliance with the business rules.

While extracting the business rules, some of the team members missed out on the extraction of some rules which were crucial to the business, due to the lack of proper understanding of the business rules extraction process. This resulted in a lot of unexpected reworks ; and schedule and cost overruns in the project . However, by coaching the team on the processes involved in extracting the business rules and by explaining to them the significance of the entire business rules extraction process, I could help my team in properly extracting those rules and bring the project back on track.

I also arranged for a few product demos of the existing tool with the users, for the development team so that they knew how the existing rating tool worked. This also helped the team in gaining a better understanding of the requirements which were defined for the proof of concept and for the final solution.

Therefor , if we can wear both hats, not only can we ensure that the project is delivered on time and within budget, but we can also bridge the requirements gap between the business line and IT.

Conclusion

Users do not have requirements and it is also not a part of their job to give us the requirements. It is our responsibility to define the requirements. Users can give us information that could be analyzed in deriving the solution to the business problem. The solution is written as a clear set of requirements which is used to accurately describe the solution to the business problem.

In this approach, it is assumed that users do not know what they want. It is our responsibility to determine the solution to the business problem . We should focus on the bigger domain view of the business problem while gathering information from users. This will help us to focus on gathering pertinent information, information that will lead us to the solution for business problem.

Therefore, we should focus on enhancing our skill sets in eliciting information from the users that could lead us to the solution for the business problem.

By enhancing our skill sets in requirement gathering and analysis; and by diversifying our knowledge in this area, we can not only improve our marketability, we can also manage our projects successfully.