"Sabyasachi , we are gearing up for a new project which is lined up for our competency. We may have to develop a Proof of Concept to help the client in visualizing the potential solution to their business problem. This could also be an opportunity for us to highlight our capability in delivering the desired solution to our client, in .NET technologies. Let me know if you would like to lead this project for us “, Bijoy said to me.
Bijoy was our senior manager who was heading the competency for one of our healthcare clients. I had just joined the competency and was gradually adjusting myself to the new environment around me . The competency had a lot of well-defined processes in place and team members were really enjoying their work in such an environment. But what I really liked the most about this competency was its core asset - the teams. Most team members in this competency were quite skilled in the technologies in which they were developing software solutions for our client, besides possessing sound domain knowledge in various healthcare segments such as payers, healthcare providers, Government and public health programs and pharmacy benefit managers.
To say the least, I was quite excited to lead this project when Bijoy spoke to me about it.
The client was one of our leading healthcare clients in the domain. A lot of its business was supported by legacy systems and underwriting developed tools.The client also faced a stiff competition from some of its key competitors in the healthcare business. Moreover, brokers felt that the tools used by the client were taking longer time to install cases and provide quotations in comparison to the existing competition in the market.
They therefore felt the need to rebuild some of their existing pricing tools in .NET technologies; and integrate them with other quoting and rating applications which were already built on .NET technologies .This would give them a lot of competitive advantage including more flexibility in rate calculations; reduction in the turnaround time for quotations and case installations; and an improvement in the accuracy of quotations.
One of these pricing tools used by the client was built in Visual Basic for Access and the users were keen to see a proof of concept of the same tool, being built in .NET 2.0 technologies.
Therefore, the new project involved the development of i.e. Proof of Concept (POC ) for the pricing tool which helped the users in visualizing the final solution and understand how it is going to interface with other quoting and rating applications which were already developed in .NET technologies. In this POC, we covered a few key features of the project, especially parts of the project which had many unknowns or represented increased risk. Out of about 40-50 forms that the existing rating application contained, the POC was carried out for about 4-5 forms which covered some critical functionalities of the rating tool. Therefore, the POC also allowed the user to understand how the final application would work since we had created a POC where the user could actually try out some critical functionalities of the rating tool.
Besides many other tasks in this project, I and my team extracted business rules from the existing application, built use cases, helped the business analyst team in preparing requirement documentation and developed a proof of concept in .NET 2.0.
While working on this project, I realized that one of the factors which helped us in developing the proof of concept for the client was that we focused on gathering as much information from the users as possible and translated them into requirements for the proof of concept. This was a paradigm shift from the usual approach we had earlier, where we expected to find the requirements for the solution ,with the users or the stakeholders. But, users and stakeholders generally do not have these requirements. It is our job to gather information from users, and flesh out the requirements from them.
In this article, we will explore the reasons due to which users may not be able to give us the 'requirements' for the solution and why it is beneficial for us to focus on gathering as much 'information' as possible , from the users.
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.
