Your business relies on a number of processes to run smoothly and it’s likely that, in turn, you rely on software applications in some form to manage these. Whether it’s logging tasks for a team, managing stock, or collecting and processing data for use; you need robust tools in place to backup your business process.
So, assuming that your needs can’t be met by off-the-shelf products, how do you write a good specification for business process software and tools, and more importantly, how do you wrangle that terrifyingly nerdy software development team into building them for you?
Start with the end goal and work backwards
It can be way too easy to get caught up in the details during specification. The majority of specs I am handed will tell me how a user should get from A to B, but often they may not have considered what happens when A is actually G, or B has had too much to drink and fallen over.
Ideally, it should just start with the end goal - “I need to get to B”.
Consider taking a step back, and leaving the solutions architecture and the user experience to those in the know (like us plug plug!), so you can focus more exclusively on what you need from your tool and why you need it. If you overthink on the detail around how something should work, without objectively considering the architecture and experience as a whole, you can risk missing out on the best solution.
If you start at the end, you’ll also start with a clearly defined objective and it becomes much easier at the close of a project to tell if you’ve been handed something that works or not. By asking yourself “What” do I need, and “Why” do I need it, you have the start of a great spec. With a great spec, you’ll reduce the risk of investing in a complex tool that tells you what the weather is doing outside, when what you really needed was a window.
Speak to the people who actually use it
When you assume...you know the rest!
It’s easy to make assumptions about what users in your organisation need, but this can be risky. Make the time to ask them through focus groups and surveys, and review the specification with them to make sure it meets all of their requirements before you hand anything over for production.
A lot of people make the mistake of only including their users once user testing starts, or worse, when a new system is rolled out. You are then met with a barrage of feedback which your production team will deem to be new features, and all of a sudden you have to find more budget or risk a user uprising. It’s a small measure to keep project costs down and your users content, by including them in your specification and testing process.
Keep control of your developers
If you jump straight in and let your development team work out the detail during the build, you will get a system that works beautifully, no doubt - but it probably won’t do what you wanted it to.
By completing requirements analysis and solutions architecture, your requirements can be transformed into a working model that doesn’t just meet your brief, but provides efficiencies and process improvements you might not have even considered. By allowing planning time to work out how a platform should be built, you will even save time in build and bring down your overall project cost, compared to having no plan and ending up completing multiple iterations in code later on.
In summary, by creating a clear and concise initial specification, and referring to the expertise of solutions architects and user experience specialists, you can custom build business process tools that get the job done and help your business to become more efficient and cost effective. Surely that’s worth an extra few hours of planning?