Lesson 2: – Gathering Requirements – Services – Part -1

Overview: –

Not only in field of technology but in any field you happen to work in, either as a designated Product Manager (PM) or you’re required to fulfill responsibilities of one, knowing what you intent or asked to build is the most crucial step in building a product. Gathering Requirements… Requirement Gathering call it what you may is the technique used to first know what needs to be built and further extend the understanding about it.

I’d like to discuss Gathering Requirements in a two part series which will be based on the type of organization or to be more specific, the business type of technology organization.

Technology based organizations broadly operate in two models, namely: –

1. Service Based or Consulting
2. Product Based

In this chapter, I’ll be discussing about the methods used to gather requirements while working in a service based organization

Disclaimer – While I talk about requirements being gathered in a service based firm, some of you who may be currently either working as either a designated Product Manager/Owner , Business Analyst or someone who’s responsible to possess expertise of one, you may find my view naive or even alien based on what you’ve been asked or baited for being a PM. I can already understand. But here, my intention is not be someone who’s absolutely right but more on giving a view and direction about the technique.

Role & Responsibility of a “Product” personnel in a Service Based Firm

To understand the requirement gathering techniques and to put them in practice requires one (you) to first thoroughly understand your role, the responsibilities bestowed upon you and your prerogative. Broadly, your role and your responsibility will first depend on the magnitude of your project. Magnitude in terms of scope, project cost, team size (always and always refrain from saying resources) and your location.

But more than anything, it depends on the most important stakeholder at your client’s end, the residing Product Manager. No matter what you’re designated in your organization, when it comes to the nature of your work in such an environment, the Product Manager on your client’s end will be calling the shots.

When does Requirement Gathering begin?

The most convenient answer I can give here is that, it depends.

1. It depends on when the SOW is signed, the client’s boarded and now the management team (product & project) sit down to carve out a true scope (not the oversold one from your presales or sales team).
2. It depends on what stage in the course of development has the client reached out to your firm for building the product.
   • Is it a product that needs to be built from scratch ?
   • Is this a modernization project?
   • Is it where the client has hired you(your firm) after sacking another vendor who’s half built the product, possibly incorrectly

The possibilities are endless. So before understanding the techniques and choosing the ones that’ll suite your project is an informed judgement you’ll need to make after thoroughly understanding the dynamics of your project.

Let’s discuss service/consulting specific requirement gathering techniques: –

Document Analysis: –

Document Analysis is the techniques where not only the product personnel is involved but other disciplines such as engineering and testing team as well. During Document Analysis, the client sends documents needed to understand what they envision in building. These documents can be PRDs (Product Requirement Document) or BRDs (Business Requirement Document) , Engineering Design, UI/UX designs (can be a prototype built on Figma) or even a presentation about the client’s business objective to be achieved by an idea. As a product, you need to thoroughly read, understand and if possible create an understanding document to be verified by the client to further disintegrate requirements before building them.

Walkthrough or Demonstration: –

Application of this technique is depends on what the client is bringing to the project at the start. It can be when: –

1. The client want to keep the brains behind the idea at their end and completely outsource product’s engineering. They bring in a non functioning prototype with a very clear intention to have it working the way it is seen.
2. A case where the client has a partially built product from another software vendor but both have parted ways for their own good reason

In this technique, stakeholders from client’s end give a walkthrough about their business, the product and what it’s expected to do to make an impact.

As an acting PM, it is your responsibility to thoroughly understand what’s been shown and carve out a foreseeable product roadmap which can be further worked out with the client

Shadowing: –

Shadowing is technique wherein you have to observe user’s behavior while performing task(s). The technique is used not only for gathering requirements but also for enhancing the product. It’s used for gathering requirements when the ask of the project is to streamline and possibly even automate an existing strenuous process or set of processes. This can be for an existing application currently in use or digitally uplifting an entire process. When using it for enhancing a product, consider this process like the most review of your product. If you find users working their way out, spending most of their energy to use or operate your product, shadowing will help you better your product. In this process one literally observes even sits besides users as they use the product.

Interviews: –

Interviewing is by far one of the most complicated technique in gathering requirements. It is a technique also commonly used in Product Based organization but with a different audience.

The definition is nothing but asking an identified stakeholder a right set of questions pertaining to the product and the project to understand the product in detail, validate your understanding and clarify assumptions. But as easy as it may sound, it is a more layered technique than one can think.

Firstly, it involves identifying the right stakeholder(s) who will be able to answer your questions. Second, you need come with perfectly tailored questions based on a thorough homework and understanding of the project you’re going to start and product that’s going to be built. The process of interviewing and the technique can be carried out in 3 phases.

Phase 1: –

• Here, you need to come with clean slate and no precursors about the project or the product. It is very important to have done thorough homework around the project which may involve understanding everything about the client and their motive to built the product. Be careful here when drafting questions as you should not lead the stakeholder intentionally, unintentionally or subliminally to get answers to the questions based on what you think the product should be.

Phase 2: –

• When there is adequate knowledge gained after first phase, a design is made, this is the phase where you along with the team should validate the design, get your assumptions cleared and eventually pave your way towards carving out concrete requirements.

Phase 3: –

• This should be treated as a recurring event with an agenda to have more clarity on what’s going to be built in the next iteration. In Agile terms, this can be a second part of review somewhere before or after the sprint planning as this is not a scrum event.
• The intention here should be about discussing things at very minute levels for implementation purposes.

With this, I’d like to conclude part 1 of gathering requirements. In the next part, I’ll be discussing techniques which are used commonly in product based firms although all the ones mentioned above are used in some or the other way there as well. The techniques we’ll see are: –

• Brainstorming
• Focus Groups
• Interviewing
• Prototyping
• Requirement Workshop
• Reverse Engineering
• Surveys