Need to Continue Remote Requirements Gathering and Analysis?

Read Skore’s guide on how to gather requirements, run workshops remotely and analyse key data online.

For any team embarking on a software change or implementation it’s essential to understand the requirements before you really get started. This key part to any project just got a whole lot harder as organisations are forced to make employees work from home. Fortunately it is totally possible to do this remotely. Our guide to remote requirements gathering will demonstrate exactly what you need to consider and how you can do it remotely. 

Firstly, consider that requirements can be gathered at different levels. Initial requirements will help early on when selecting technology. More in-depth requirements are required when it comes to configuring the system and training the team.

If you don’t understand and agree requirements all sorts of things can, and most likely will, go wrong with your project. Common problems include:

• Project runs over time and costs a lot more than expected.
• Users find that it doesn’t work the way they need it to. It doesn’t matter if the project is delivered late and over budget. When people aren’t using it then the whole investment is lost.
  

Incredibly, as important as requirements gathering is, many teams get this wrong. It’s hard work, and time consuming, and requires many people across the business to get involved. However don’t let this put you off as it will only cost you more in the long term. Here is a high level guide for how to capture requirements for your next software implementation and the best bit is you can do it all remotely: 

Start by Capturing the As-Is processes

Have some idea of where you are right now to clearly explain to anyone impacted by the project how things are going to change for them. More importantly, everyone should have a common understanding of the existing problems so they know why things are going to change.

Capturing as-is processes helps identify hidden problems and other improvement opportunities. You should quantify these if possible. Look at manual processes that could be automated. Question how long do they take, what do they cost, and what’s the risk of making mistakes in a manual process?

Once you have the initial process, and improvement opportunities, you can start to create your wishlist of requirements. The process will give you a central framework onto which you can hang the requirements. Requirements can be written as statements that can be tested later on. For example:

“We should have the ability to automatically send an email when the client requests help so that we can be seen to respond quickly.”

Try to include why the requirement is needed, for example here it’s to quickly acknowledge the client after a request has been made.

Finally, consider how important each requirement is. Is it a must have? Is it essential to continued business or could you live without it? Alternatively is it a nice-to-have requirement that would delight users but they wouldn’t notice it if it wasn’t possible? There are various frameworks available to help you categorise requirements such as https://en.wikipedia.org/wiki/MoSCoW_method and https://en.wikipedia.org/wiki/Kano_model

Prioritise the benefits

Use one of the above methods to help you prioritise the requirements. Make sure you are really clear about your must haves. Often teams list almost everything as a must have but this will only lengthen the project and the chances of it going wrong. Instead think of must haves as the things you need to have in order to do the work at least as well as you do today.

This means that at the very least you won’t have gone backwards after the implementation. Having more non-essential requirements gives you more flexibility when it comes to project length. If things take longer than expected you can drop the non-essential requirements!

Finally, question if the requirements be grouped into deliverables?  Consider whether part of the process can be implemented first, then the next and so on. This allows the project team to deliver smaller benefits more often and make the change easier.

Select the system

Once you have your initial list of requirements you have the information you need to select your software. In most cases there will be multiple vendors in the market all with their own speciality. Run a first pass market scan and create a shortlist of vendors.

Contact your shortlist and ask for a demo based on your requirements. You can provide a list of requirements from Skore by simply creating an attachment report and filter it by requirements. A key aspect here is that the vendors will often have worked in many businesses similar to yours so they may well bring new perspectives and ideas to help you.

You may need to ask for a small trial, or proof of concept, to demonstrate how the solution will work with your processes. Especially if you have a unique requirement, or something that needs more than the usual customisation.

Design the future state

Once you have selected a vendor consider how your processes are going to change and the impact that may have on teams. The best approach here is to run workshops with the same stakeholders as before. But this time you have the benefits of the new system articulated and you should invite the vendor along.

The vendor’s system will have best practices built in, and often it’s better for you to adopt these than to try and adapt them to how you used to work. At other points in the process you may have very specific requirements that need a lot of configuration. The vendor is going to need as much information as possible here. To make the implementation as smooth as possible work as closely as you can with the vendor and share all the processes.

The other important piece here is that, for some members of the team, what they do can change considerably. Use your new processes to understand which roles in the business are going to be impacted and how. Who will need training, how will their roles change, do you need any new skills? You should be able to answer, and act, on these using your future state processes.

Configure and test the system

At this point the technical team can get on with the technical implementation and configuration. Again ensure they have access to all the processes, requirements and any other related information. If done well this should provide them with all the information they need but make sure someone from the business is available to answer any additional questions. If not, the technical team will be forced to make decisions that could impact the success of your project.

Use the processes to run test scenarios through the new system before it goes live. Can a user complete key steps in the process, are you seeing the expected outcomes at the end of each process?

Train the team

Finally, once the system is ready, it’s time to train the team. Compare the original ‘as-is’ processes with the new future state ‘to-be’ processes. This tells you how things are going to change and helps to explain to the team.

Well designed processes should be easy to read and follow so can make excellent training and reference material. Let the team have access to these to help them in the early days and to train new team members in the coming months.

Remote Requirements Gathering can be a Success

Software implementation projects will almost always turn out to be more complicated and take longer than anticipated. However, you can set yourself up for success if you invest enough time in understanding the real problems in the business and the real needs. A little more time spent up front will save a lot more later on.

But one thing to remember, a software implementation is not finished at the end of the project. We now live in an ever changing world and the business is constantly in a state of change. Processes will change from day to day, if you’re not keeping an eye on how it changes and what that means for you new system you might find that months later it’s no longer fit for purpose. Keep your processes regularly up to date and use this to keep your software at the cutting edge.

Skore software is a Process Improvement platform. Use Skore to remotely run workshops, gather information, share insights online and create your Process Library.

If you’ve found this article useful then sign up to get even more resources to help you.

Get Your Free Resources