Written by Gary Hastings.
Ever notice how gathering requirements for software solutions can feel like it should involve a crystal ball? By the time you analyze processes and discuss needs across all the stakeholders, then develop and test a solution, many, many months have likely passed. And who were those stakeholders anyway? Were they in a position to know, let alone predict, what the correct solution should look like by the time it’s implemented?
The resulting software solution usually confirms the fact that, indeed, no one had a crystal ball. Then once the software is finally implemented, it risks being shunned outright or secretly despised during hushed conversations in the shadowed recesses of the office. And then there’s the really bad outcome – the whole system and process was just so far off the mark that instead of using the solution that was “intended-to-be-an-improvement,” the end-users put all their creative juices into finding unique and interesting ways to “work” around it. Talk about a return-on-investment (ROI) buzz-kill.
Agile To The Software Implementation Rescue
Thank goodness for the advent of Agile development. We now have discovered the concept of handing over a lower-risk, lower-cost, base solution to the actual end-users early in the project. And in the case of Esker’s document automation software, we’re often talking in like 2-3 weeks from kickoff! They then have the opportunity to experience how the solution works before a whole bunch of requirements are defined and implemented. And really, what better way is there to implement a high-impact, process-altering solution? After all, the proof IS supposed to be in the pudding, right? So why not just give ‘em some “pudding,” see how they like it, and then adjust the “software recipe” from there?
Over the last couple years at Esker, I’ve actually gotten to experience this software implementation approach first-hand with our accounts payable automation and sales order processing automation customers. We’ve been implementing solutions in Professional Services with an Agile approach with continual success. After the obligatory demos, assurances, and legalities have been checked off the list, we get to move on to the fun part – implementing the solution. At Esker, that starts with delivering our base package with the necessary connections to allow meaningful interaction (you know, the “pudding”). From there we let the actual end-users (as many as possible) interact with it for a few weeks, followed by an in-depth and collaborative walk-thru of the solution (via an onsite workshop) to get their feedback on the functional and process-driven aspects of the solution. Essentially, we look to find out how they want their document automation solution to work for them—bringing them the best ROI.
What’s Your Automation Software Recipe?
It’s always interesting to see the user stories (a.k.a. software requirements) that come out of those onsite workshops. We’ve had the people who are living (and struggling) with the current processes, get a chance to live with ours for a bit. Once they have their hands on a real and functional system, they’re in a much better position to tell you what works and what doesn’t (how the “pudding” actually “tastes”). And that’s pretty powerful stuff! Granted, you won’t have a 100% perfect list of requirements after a couple weeks of interaction – but you’re off to a pretty darn good start. Add in “a dash” of incremental development and “a pinch” of continual testing, and you have a solid recipe for a project and solution success. SWEET!
And the cherry on top, the buy-in of the final solution is usually much higher since it was designed by the ones using it!