The secret to success for any programme of work is to get the key stakeholders' ideas flushed out and documented early in the process. This is even more important as we move forward in this modern Agile world. But, ironically, the uptake of Agile methodologies has given rise to the idea that we don't need traditional scoping exercises anymore, and therein lies the danger. Learn how to fight it, here!
Don't bury your head in the sand when it comes to stakeholder needs
Stakeholders in a software project can mean anyone from the CEO to a customer. They might have zero understanding of what it takes to build a piece of software.They may have no conception of what 'end-to-end encryption' means or never heard of a 'petaflop'. But they do know something you should never ignore, and that is what is important to them about this product.
Here's a scenario:
A.N. Other Letting Agents, a UK Wide franchise, wants to update their inventory system.
Random Webdesign Ltd has had a briefing from A.N. Other's head of IT. They've had a look at the old system and spoken at length to the inhouse developers and can suggest plenty of improvements. They are awarded the contract and get straight to work. They're using Agile, so they can keep flexible and cope with any changes, right? Their biggest aim is to update the ugly old interface with a new and aesthetically pleasing version!
In the meantime, Carol the CFO's problem is that she wants to cut the amount of time it takes for each customer appointment time in branches. She doesn't really know why they're taking so long, but they're costing A.N. Other a lot. Whereas, Eddie the branch end user just wants to be able to save a search against a customer profile to prevent him having to retype all the information every time the same people come back to enquire.
Random Webdesign Ltd got to the testing phase fast, and were feeling confident, but UAT wasn't going so well. People like Eddie were complaining bitterly that it was rubbish, and Carol the CFO was finding appointment times going up, not coming down! The project was eventually pulled as being unsuitable, to great loss of time, money, and morale.
So what went wrong? Although the head of IT was very thorough with the technical side, Carol and Eddie's issues hadn't turned up since there had been poor requirements elicitation procedures from non-technical stakeholders. There was no way to save enquiries or profiles at the click of a button, so people like Eddie would have been stuck using an inefficient, annoying piece of software, which -- even worse -- wasn't as familiar as the old one.
This is a facile example, of course. Most project problems are much more nuanced and hard to spot. But if the elicitation process is insufficient, they are pretty much guaranteed to happen. You've got to make sure you've got both those ends of the spectrum from Carol to Eddie (plus everyone in between) taken into consideration. You need to listen to them.
Requirements elicitation by Centrocol
So what now? You need to get these perspectives recorded. You need to ask the right questions. One way to do this is in scoping workshops. As part of our Managed Software Services, we can provide fun, interactive sessions that speak the language of the participants. For example, end users will find easy to understand, plain English spoken. But we can also wrangle the tech teams and help them roadmap the product without forgetting stakeholder needs. Our years of experience in both business and IT help us see the perfect balance between technical and non-technical requirements, and our energy and enthusiasm help draw out the best from your stakeholders.
Remember that most errors or faults found in final software or application solutions are introduced during the requirements gathering stage. Statistically, these activities are allocated less than 12% of the total project time with the majority of the rest allocated for development and testing solutions.
