Gathering Effective Requirements
Effective requirements are a crucial part of creating an accurate product. They are the difference between instilling confidence in your client and causing frustration. Yet far too often, rushed discovery phases, result in limited and under detailed requirements.
How can you build from 1 to 10 if you only know 3, 4 and 7?
Why Discovery is Crucial to A Successful Product
The discovery period is an amount of time, at the beginning of the project, which is set out to meet stakeholders, understand your client’s business process and gather requirements, amongst other activities. Depending on your projects methodology, these requirements won’t come with delivery deadlines and will later be prioritised as part of a product backlog, such as in Agile, which is the development methodology this article will assume.
However, regardless of approach, what will come from this discovery period, is a set of requirements needed to begin building the final product.
It’s crucial that these requirements are well defined and broken up into manageable chunks, such as stories. These stories — will then be further broken down (sub-tasked), by developers, who will need to understand clearly, what is expected from the requirement, in order to get it right, first time around.
As time goes on, Business Analysts and Functional Consultants, will have worked on gathering requirements for a multitude of other stories and, naturally, granular knowledge fades and memory becomes vague. This is why it is crucial to adequately define requirements, first time round, removing the possibility of ambiguity creeping in.
Why is Discovery So Often Rushed?
The discovery period primarily produces documentation and requirements, rather than a product. This therefore means that early on, for every day discovery is running, development is typically not.
It is often this haste to ‘get on with it’, that causes ambiguous requirements, that can and will come back to haunt future development efforts.
Effects of Inadequately Defined Requirements
Poorly captured requirements are like boomerangs — they’ll keep coming back to you.
In the best case scenario, inadequately defined requirements will mean you never hear the end of a user story, from product owners refusing to sign it off, to developers asking questions upon questions until it is comprehensive.
In the worst case scenario, there’s a chance that an inadequately defined requirement actually makes it into build, risking something completely different to that of the intended requirement being built and causing a knock-on effect to the entire sprint or worse — entire build phase.
In addition to this, there’s the simple fact that clients, like all of us, don’t like repeating themselves multiple times. Once a requirement is captured and noted, it doesn’t reflect well to continue asking about it long after it was originally discussed — this shows a lack of understanding or a lack of listening, both of which will not instil your client with confidence.
Respect your Project Managers and they’ll respect you — capturing inadequate requirements means a duplication of work in asking for them again. This takes time, which will not have been factored in, skewing timelines and causing headache at the project management level as well as the project team level.
Getting it Right the First Time
Right People = Right Requirements
Making sure you have a combination of Subject Matter Experts (SME’s) and decision makers (Stakeholders, Product Owners etc.) in the room, is a recipe for a great set of accurate requirements.
The fact the group are empowered and invested, means they are the perfect set of individuals to extract detailed requirements from, as likely it will be themselves or their team using the system at the end of the day. This means that they are passionate about adding their builds to make the new-world product the best it can be.
Often, having the client be the organiser for the requirement gathering session is a productive way of ensuring you get the right people in the room. Naturally they know the key business contacts better than you and, in many cases have a stronger rapport, enabling them to be more approachable when it comes to hosting sessions that calls for the involvement of the business.
Show Me the Goods
The best way to visualise something is by seeing it. The same is true when thinking of requirements. If the client can see it, they can visualise it.
Using the system as a visual aid to drive out requirements and steer the conversation, is an effective way to make sure nothing is missed. It’s also a great way to teach the client as you go, demonstrating the capability of the system and showing them what goes where and what does what.
This is a great opportunity to be a good consultant, ‘showing off’ exactly what the system is capable of and advising on areas where legacy processes can be replaced with Out of The Box (OoTB) functionality. After all, a new system should be an improvement on the old and therefore it’s likely that the client will be coming into these sessions with a number of requirements that the new system is capable of as standard.
Fail to Prepare, Prepare to Fail
Having a pre-defined and thoroughly thought out agenda is another excellent way to ensure that both yours and your clients time is being used as effectively as possible.
Setting clear objectives of what is to be achieved in each session allows both parties to prepare and ensure the conversation remains on track, with the understanding that further requirements on related topics will be extracted during future sessions.
It is expected that requirement gathering will by its nature unearth areas that were previously unknown. Therefore it makes more sense to discuss there and then, as perhaps it is a pre-requisite or something that is needed to be understood for context. It’s important to account for this and take it in your stride — be flexible in your workshop scheduling and plan contingency for such occurrences.
Forward Thinking
No doubt you have worked on a project where you have at some time or another thought, ‘the people designing this current system really did not think about the future’.
It’s important not to continue that trait, and, while nobody knows what the future holds, especially not in a technology context, there are some principle rules we can all follow to help a solution stand the test of time.
Configuration over Customisation
This is the golden rule in our team and one we’re passionate about sharing.
Over-engineered solutions are often the ones that cause us to have the thought mentioned above. They are complicated to manage, difficult to understand, impossible to handover and highly unlikely able to be upgraded.
Yet, all too frequently, if there is a requirement for the system to perform a task that is somewhat obscure or unique — the first port of call is to customise.
Following a configuration first approach is becoming more and more popular and as business applications grow and gain more features, it is often the case that a business will choose a product because of it’s up-to-date practices, often different to the current running of their business, but more aligned to modern industry standard.
In many cases the client is expecting that there may be changes to internal processes and, are actually looking forward to such improvement. This is where it is crucial to best advise on how to take advantage of enhanced standard functionality the new system is capable of, demonstrating how existing business processes can be adapted to streamline efficiency.
Configuration over customisation has benefits at each stage of the product life-cycle, from the above, through to long after build completion. Should a system be customised, it needs two kind of upgrades when the time comes for patches/updates. The system will under-go it’s core update, but where does this leave the customisation? There is no guarantee that the customisation put in place during development will be compatible with the newly upgraded system. It is for this reason and more that customisation over configuration causes increased cost, maintenance, time and headache.
Tools
Once you have your requirements, it’s important they are stored in a place that is visible to all parties involved, in many cases, this includes stakeholders. This transparency ensures that all parties are kept on the same page and that any changes are reflected in real time.
Azure DevOps
DevOps is an excellent Microsoft-made tool which features support for requirement gathering and management, through to build, test and release.
It is an all-round project tracking and developer services collaboration tool that will already be widely used by many reading this post. Sticking to the theme of requirement gathering, DevOps allows you to load all of your project team, stakeholders and project management team into one central location, using their pre-existing Office 365 accounts (licensing considerations apply).
Containing templates for a number of existing project methodologies (incl. Agile), DevOps allows you to load and track all of your requirements, as well as effectively manage them throughout their life-cycle. In addition, your client also has visibility of this progression, allowing for a transparent view and further enabling collaborative working.
Visio
Although not necessarily in the same category as the above requirement management tools, Visio is certainly a cornerstone product in effective requirement definition.
It offers a chance to put together comprehensive Process Diagrams, enabling you to illustrate your understanding of the clients business process(es). This goes a long way in instilling the client with confidence that you have grasped their requirement and are on-board with what they are aiming to achieve.
Want to work in an environment where discovery is taken seriously and requirement gathering techniques are constantly evolving and improving? Take a look here and Join The Microsoft Team at Capgemini.
