Understanding Requirements

Anyone who met me before I became a virtual assistant in 2014, will remember me as that lady who was all about IT and computers. Rightfully so, computers were (and are still really) my life! During that time in corporate following graduating from university, I got the opportunity to work on a number of technical projects. The most interesting thing about them was that, we didn’t just start by developing a solution in the restricted IT office. No. We were designing solutions for use by business people and therefore had to go through a process of understanding requirements and the business as a whole before we could start developing a solution.

Why was understanding requirements so necessary?

It was the only way to know what kind of solution we needed to develop lest we wasted time and energy working on something business did not need or want.

Often times, in any business setting using information systems, there is a process in place to manage any requests for new system developments. It usually involves submitting a request through filling out a form or via an online system then a series of back and forth communication to understand the request before any decision is made to start on a project.

However despite the existence of such systems and processes, most business users were not quite interested in documenting their requests. It was tempting to assume understanding of certain requests based on their spoken word but experience had taught us that it was always a recipe for disaster. Why? Well, because sometimes you would develop one solution and then hear it’s not what was required resulting in wasted resources.

So in any scenario where you’re trying to craft a solution, it’s necessary that you understand the client’s requirements before you start doing any work. This is something we practice here at Twenty47 Virtual before we start working with any client on a project. Besides going through a series of requirements gathering conversations and questionnaires, we document the points discussed during these meetings. After this, we will craft a proposal outlining the solution proposed. This gives the client an opportunity to see whether or not their problem has been understood. The client can also evaluate whether the proposed solution will address the client’s problem. It doesn’t matter the size of the project. Understanding requirements helps us develop the  best solutions for our clients.

How do you go about proposing solutions to your clients’ problems? Do you focus on providing the best solutions or you tend to be moved by the client writing down that cheque?

Leave a Reply

Your email address will not be published. Required fields are marked *