Challenge the requirements. Design the service.
We’ve probably all heard about how technology can transform, in fact we’ve probably experienced or benefited from it directly. Remember the good old days of popping out to the video rental store in the rain and trying to return your movie on time? The likes of Netflix, Uber and Airbnb wouldn’t exist if it wasn’t for the technology that underpins them.
A lot of hope is put on the digital solution that being brought in to make improvement, and as much disappoint can exist when the technology fails to deliver. There are a whole host of reasons that this could be the case, from project management failures to just selecting or building a poor product, but one aspect that often
Building or buying software ultimately comes down to knowing the requirements. In some cases there may be legislative or technical constraints that form requirements, but there are no-doubt other more functional requirements that are identified regardless of whether the solution is being arrived at through an agile approach or not. It’s these functional type of requirements that are often the ones to challenge.
It’s common when trying to improve services with the introduction of technology to implement in line with existing business process. This is because the requirements gathered document the current process rather than a new process capitalising on technology. Here’s a simple example of what to look out for:
John has a requirement to send a list of names to Sue who works in a different department to review. John communicates this requirement for a new system by mentioning he wants a process to provide an excel export of a list of names in order for them to be sent.
It seems a reasonable request and the easy option is to implement it, but without challenging the requirement only marginal service improvements are likely to be made in delivery this functionality. In the case above it’s worth exploring what the Sue does when reviewing the list. There may be another system that Sue is using when reviewing the list that John provided. Linking the two may save Sue the job of reviewing, mean John doesn’t need to send a list in the first place and therefore not wait for a response, freeing up John and Sue from this activity and speeding up this aspect of the process.
While this example is pretty simplistic, it’s actually quite common. In many cases though a few extra questions and stakeholder mapping can help highlight where service improvements can be made.