As a consultant, one of the most critical components to a successful engagement is the requirements gathering process. While seemingly obvious, there is a lot of nuance within this process to support a successful outcome. With this in mind, check out INVISR’s tips for a successful project discovery:

10 Rules of Engagement for Gathering Requirements:

1. The strategic objective of the project must be defined upfront; think less ‘we need a CRM’ and more ‘we need a CRM so that W & X teams can improve their execution of Y & Z’ in ways that can be tracked and measured over time.
2. Every individual requirement must keep the overall objective of the project in focus, and not delve into other unrelated business units or peripheral use cases. In other words, don’t lose focus on the core objective with ‘nice to haves’.
3. Always define the persona, then the need, followed by the why - this keeps the overall format consistent and ensures there aren't any discrepancies between the functional requirement and the expected outcome, relative to the strategic objective of the project.
4. Do not be afraid to digress in conversation - it often times helps clarify the greater picture. But when it happens, be sure to 'anchor' the original point so that it can be brought back to core strategic objective. In other words, digressions can be helpful as long as it doesn’t completely derail the topic at hand.
5. Talk to everyone. The designated representative responsible for owning the solution on the customer side (i.e. Product Owner) can be mistaken, so be sure to test the validity of a request when you gather a requirement - whether it be the pain point or the need of a group of people or an executive stakeholder.
6. Merit should always win - a requirement isn't a must if there is a better way or better answer. Hold firm on this point; as consultants it is easy to relent to the loudest voice in the room at the expense of the overall success of the project.
7. Do not be hesitant to question a requirement; it's a means to strengthen your understanding of their business and to validate the requirement.
8. Know the lay of the land of your customer’s firm; understanding the political landscape of an organization (who’s a decision maker and/or influencer, whether or not their compensation is attached to the success of the project, any executive or board-level mandates, etc.) will enable you to be a more emphatic partner and effective communicator.
9. Requirements should give definition - not generalized statements. If there is a need, then the requirement needs to have substantial detail of what exactly it is (see examples below) and how it fits into the larger solution strategy.
10. Requirements should never reference the ‘meta’ of a project. They are within a vacuum of the project's scope so referencing things like timeline or external sources can only confuse a discovery process. NOTE: This is not to minimize the importance of the ‘meta’ to the success of a project: timeline, budget, and understanding source systems are all critical; just not necessarily as part of a business-oriented requirements discussion.

Clear Documentation of Requirements:

As mentioned above, requirements should be kept in a consistent format. It's 'three tiered approach' that keeps the requirement’s purpose clear:

• Persona - WHICH role is **using the requirement/functionality as?
• Need - WHAT does that user type need to be able to do within the system?
• Purpose - WHY do they need to do this in the system? What is the expected outcome/benefit?

****Note: Using "as the system" for persona is fine and implies automation***
****Another Note: Defining requirements this way REALLY helps with user acceptance testing (UAT) towards the end of the project***

Examples:

Ex. 1:
Ability to see deals in a pipeline for review. I want to click and be able to view that deal.

This is bad - gives no persona, no true definition and no reason behind why this is important. It also can be seen as two requirements in one.

Ex. 2:
As a Sales Manager, I need to view all Opportunities in one place so that I can management my teams pipeline effectively.

This is better. It defines a persona, the need and also the why. Its slightly loose on definition however. Workable with further refinement but could be better.

Ex.3:
As a Sales Manager, I need to view all Open Opportunities (status "Stage 1" & "Stage 2") owned by my team, within a list view, so that I can see a clear pipeline of open deals.

This is ideal. It gives all three attributes while also the luxury of definition. Although, this may not be definable at the time it still gives a true threshold of what you are looking to track, and in what form it should take in one statement.
It also gives definition without necessarily having to define the exact solution. We do not need to solve at this stage with specifics. No technical solution - just pure business driven definition.

Template Guide:

The way in which requirements are documented is important. It is important that they are stored in a way that supports digital collaboration to allow multiple people to work on it at once and to avoid versioning (e.g. don’t use an Excel file shared via email). Additionally, it should categorize the requirements by type and offer the ability for detailed requirement definitions beyond the top line description (i.e. specific user flows, fields, attached wireframes, etc.).

In Practice:

It is common for business stakeholders to see projects simplistically, not necessarily appreciating the potential complexities of creating a solution that meets their requirements. Therefore, it is important educate these stakeholders on the actual build process to properly set expectations and avoid any unnecessary misunderstandings.

Thank you for taking the time to check this out! If you’d like to learn more about INVISR’s approach to solution implementation or how our platform Polystack delivers value for our customers, contact us!