Consulting can save you from building a bad tech

Estimated reading time: 11 minutes

Consulting can help eliminate the gap between business challenges, technical requirements and end customer experience, which is a huge step in building a successful product. With a well-defined scope, you can avoid scope creep and revisions that can potentially derail your project – We call this consulting phase a Discovery Phase

Discovery Phase is a process of research and analysis where teams work together to understand business models, operations, technical requirements, challenges and organizational goals, which is then converted into a well-defined plan of technical requirement documents, project strategy, user flows & journeys and prototypes.

This phase is critical as the information gathered will be utilized as a base for the System Requirements Specifications (SRS) document. The SRS will include a vision or mission statement of the company defining the overall objectives and business plans. You can also see this process as setting up the right expectations as business and vendor as it enables both parties to minimize risks and balance the task management within the required timeframe.

A process of discovery phase must always include key executives and stakeholders. An ideal business analyst must follow some techniques to get started. You can use some or all of these techniques below to get started with your action plan.

#1 Interview

Interview turns out to be one of the most effective techniques for requirement gathering. In this method, the business analyst talks to company employees at various roles such as directors or owners to understand the goals and objectives, operations head to understand the business processing, sales team to understand the sales process and marketing team to understand the marketing goals. This helps him to to give out detailed information as they are not aware of the system development and related functionalities.It is the responsibility of the business analyst to extract relevant information from them which can be achieved by interview. If you do not have a large team, then a single contact can also share relevant details and the rest can be covered under competitor and industry analysis.

#2 Survey

Survey is another effective method to collect information and requirements within a short frame of time. Under this technique, it is advisable to first ascertain the goal of the survey and thereafter draft the questionnaire. Once your questions list is ready, it should be delivered to stakeholder.

#3 Brainstorming

Once you have all your base requirements collected, its time to discuss it with your stakeholders. Stakeholders from both sides of the company and development team are responsible to conduct brainstorming sessions. They discuss and find out solutions to complex issues.They are further responsible for requirement prioritization post they collect all the requirements which are related to the software. Face to face meetings or video conferencing calls are highly recommended for these sessions.

#4 Joint Application Method

This method follows a prototyping method, under which all the stakeholders like developers, end users, SMEs, business analysts and software engineers come together and attend workshops for working on a system in greater detail. These stakeholders attend the workshops till the time the desired goal is accomplished.

#5 Observation

Under the observation method, the responsible person observes the team in working environment and gets ideas about the software and subsequently document the observation. Observation can be invisible, the person simply observes the working and does not interact or makes himself visible, and hence, the concerned person observes and asks relevant questions.

#6 Focus Group

In this method, the business analyst bases his/her requirement gathering process by interacting with the representative of the client and users.The representative here has a broad idea pertaining to the needs of the users and clients. Under focus group, the idea is to collect information from representatives to understand the software idea clearly.

#7 Interface Analysis

Interface analysis is a specialized technique in which specific requirements related to application development are determined and their interaction with other software components is measured.

#8 Prototyping

This is a technique of building a model of software which helps in uncovering and capturing software requirements from client. The output can be broad mockups or sketch formats of software.

#9 Use case diagrams

Use case diagram is a technique that shows how people interact with software. It shows what a system does.

#10 Problem Reports and Suggestion Analysis

Requirements analysis can also be done from change suggestions and user issues. A direct method to look for requirements is to see the suggestions and problems that are described in the document first. Some organizations have forms to report and record system problems; you can look through such reports and find the pain points.

To help you choose which of the above techniques to use, there are a few factors that need to be considered – Availability and location of the stakeholders, Client and development team’s knowledge on the problem, Client and development team’s knowledge of the development process and methods to resolve the same.

Gathering and managing requirements is a challenge in effective project management. It can be a matter of success or failure for for projects, if requirement gathering is ineffective and this can happen even if the project is midway. Web projects have a baseline that is continuously evolving throughout the timeline of the project which needs careful and effectual management. Project manager needs to duly assess and understand the novelty value of the requirement gathering process of individual project. Requirement risks are one of the most insidious risks that threaten IT project and their effectual management. Having unclear requirements, lack of client involvement in the process or faulty requirements; all these become the major perpetrators in the projects which are likely to go awry. Following agile practices can effectively help you in mitigating such risks to a large extent. Project teams can make a lot of difference by adopting and executing agile working practices. If implemented accurately, agile working can reduce the risks that are associated with requirements gathering in IT projects.

Soliciting and collecting business requirements is a critical step for any kind of project. Creating complete set of requirements at a preliminary stage can facilitates in better planning, precise cost estimates, shorter delivery timeline, enhanced client satisfaction and better response to the final product. Eliminating the gap between business and technical requirements is the responsibility of business analysts as they need to understand the business needs in the full context and align the same with the business objectives while communicating the same to the development team as well as other company stakeholders. For the said purpose, they need to ensure that the requirements are written in a form that is easily understandable by both the groups. Business analysts also need to stir between vague and sometimes differing views of the stakeholders in order to concur on what needs to be accomplished. There are times when the requirements gathering efforts are hindered by several kinds of pitfalls.

Let’s discuss some of the challenges that can grip requirements gathering process and discuss the potential approaches to deal with them.

#1 Lack of Clarity in Defining Criteria for Success

Stakeholders have a clear idea about the problems they are facing or exploring a particular opportunity; however, more often than not they are pretty clueless about exactly what they are looking to achieve. In order to address this concern, it is advisable to break the project into small bits and start from the section where the client has most clarity. There are collaborative modelling tools which allow the clients to have a high level vision of the end result which makes getting feedback early in the process simple enough. It is also advisable to ask questions from the client and identify current business practices and identify the pain points which can be improvised. In any case, the best thing to do is make the requirements quantifiable and testable so as to have a solid foundation against which the results can be later measured.

#2 Organizations Change their Minds Often

When the requirements are not clearly defined or understood/evolved over the course of the project, changes are bound to happen. The best approach to tackle it is to become adaptable and accept the changes. Although, it is important that the changes are prioritized and estimated and new time and budget allocations are communicated and confirmed with the client before modifications are taken care of.

#3 Lack of Communication between parties

Active communication and participation by organization stakeholders is critical to the success of the requirement gathering process. Getting the stakeholders to provide honest and open inputs requires establishing a rapport of trust. It is important to listen, learn and speak the client’s language for their project and the same implies that you are interested as well as have understood the client’s business challenges and are here to focus on resolving the issues.

#4 Getting stuck on solution offerings

Companies often get too stuck up on a particular technology or software which happens when they have limited knowledge in certain technical areas or when a particular technology has worked wonders for them in the past. The best thing to do here is to focus on the main problem and understand how their preferred tool or technology can help them here. Create comparison spreadsheet with features that matter, and rate each tool and technology based on it. This will give both parties a clear direction to work towards.

#5 Stakeholders can have conflicting priorities

Requirements gathering process needs to have a tough approach which includes asking open ended questions for the stakeholders to answer. All stakeholders involved must articulate their ideas and perspectives in a timely manner. Rushing through process may lead to proposed terms that are considered out of scope, or promoting individual agendas rather than the organization’s vision. A desirable thing to do is to have several interactive sessions with the client that has enough scope in between to digest the inputs collected, ensuring that the requirements gathering process gets on the right track delivering the right results.

Based on the brainstorming sessions, the business analyst will then analyze the requirements and draft an SRS (system requirement specification) document.This document would include basic objectives, functional as well as data description, system architecture, ACD (architecture context diagram), systems requirements and some suggested additional revenue streams and also the basic USP (unique selling point) of your web application etc. Teams also set up a creative designer who will be working on the design elements. Post the designs of the screens are made, a basic HTML prototype is made to ensure user flow and journey flow are inline with the use cases.

After the completion of discovery phase, you should have a clear roadmap along or project planning, requirements and scope of work with correct time, team and cost estimate.

In further detail an SRS document prepared should include the following component details:

In the end, here are some best practices to follow while you get your project discovery done.

#1 The primary important step in discovery phase is requirement gathering and identifying the problem along with the business users and defining in the most accurate manner. This definition must include:

Project issue and the advised solution

What are the benefits that are expected from this solution

#2 Accurate and detailed description of the project. The solution that has been planned should be adequately described at a high level along with the business requirements that it is centered on.

#3 It is imperative to address all the needs of stakeholders as well as users. This is a relevant part of requirements analysis and an important step which we should follow methodically before we freeze the requirements. This step helps in the deployment phase as well since the user gets adaptable to the new process/application.

#4 The solution offered must have its set of do’s and don’ts which should be captured in detail. This will be helpful in clarifying any doubts.

#5 The application should have its planned features captured in grave detail. The functional, as well as non-functional requirements should also be captured in much detail further including details on the project’s execution strategy.

To summarize what we have discussed so far – it is vital that the business analyst draws out a plan which is helpful for capturing the basic requirements of the client. When this plan is carefully researched and drafted, there is little room for rework which further helps in saving time. It is also necessary that all the stakeholders give their view with regard to the software being developed and kept in loop of the progress being made. Working as per the requirement gathering process ensures that the quality of the end product is superlative and makes it simpler at all stages of the SDLC. This phase gives a solid foundation to the rest of the processes and steps for design and development and hence ensures that the problem is resolved. The stronger the foundation and clearer the understanding for the project, smoother will be the course of things when development begins and we move onto the support and testing phases of the project. There might be a time when getting the perfect requirements gets difficult; however, better the understanding, more solid the end product would turn out to be.

This document is your trigger point for designing, documenting and developing and will be of immense help in all aspects of the project some time or the other. Try out these techniques with your business or your clients and let us know what you feel. If you have any questions on how to implement some of the points above, please leave a comment and I will get back to you.

Also check how we work with our clients