Developing reliable, high-quality software which solves real problems is already a tough hill to climb. Map that onto procurement and it feels like trying to summit Everest.
Unlike a crossword puzzle, there’s no neat list of clues upfront and no single solution to every problem we’re presented with. The challenge is also never won, with the landscape and requirements evolving just as quickly as the solutions can.
A mixture of high complexity, uncertainty and change sounds dangerous. A set of clear guiding principles are the best way to stay focused on delivering what matters. In order to come out on top, what you might want and expect can be different to what you need though.
What you want
Here’s the list of requirements
“I know what is needed for this feature and I can describe it in one sentence.”
In reality, that sentence was optimistic but naive.
There’s often a ton of complexity bundled into a feature request that no one could imagine upfront. And everyone who reads it will interpret it slightly differently.
Many assumptions will be made in the attempt to unpack and understand a requirement and at least some of them will be wrong.
Plus, the first idea which comes to mind (or is copied from a competitor) may not be the most effective or cheapest solution for every circumstance.
If all of this sounds like a bad basis for building software, that’s because it is.
Design it. Cost it. Build it. Ship it.
It’s tempting to approach procuring software like buying anything else for your office.
Write your requirements, get your quotes in, evaluate, award, and execute.
This approach is good at giving the appearance of control, but pretty frustrating in practise. Worse, it stifles the ability to deliver what you may really need.
What if, after talking more, we realise we were wrong on a key assumption around how a feature should work and it now takes 2 months rather than 2 weeks?
What if we get to the bottom of the real problem we need to solve and discover our original solution was over-engineered and unnecessarily expensive?
Time will pass and your priorities will change. What was important when you started a project may no longer be as relevant further down the line.
Is trying to specify and agree everything up front the best idea?
It costs how much?!
If building software is tough, estimating how long it will take to build is even tougher.
There are many unknowns. The specification is open to change. Assumptions are made around exactly what’s needed, feasible, and so on.
All of this uncertainty carries risk. You can handle this risk in different ways but the outcome for specific estimates in this scenario is that they are usually wrong.
If you want to factor in all risk, it will look like a huge amount of time, which is bad. If you don’t then it’s more likely to be wrong, which is also bad.
The end result is often a commitment you’re uncomfortable with combined with setting unrealistic expectations for your client. Never a good mix.
Just let me know when it’s done.
Your expertise isn’t in building software. So it sounds reasonable to say you shouldn’t be involved in the process of building it.
Solid logic, but what about the fact that the software only exists for you? When software is bad at its job that doesn’t help you look good at yours.
It’s convenient to silo feedback into a neat box which only takes an agreed amount of time. Do your designing, get your feedback, then leave me alone.
The reality is that finding the best solution to the most complex problems without wasting a bunch of time and money requires trial and error.
Is it better to make these mistakes in small increments and correct course, or bet everything on a few bullet points and some design mockups you saw 6 months ago?
Fewer releases = more stability
Releasing updates only once or twice a year sounds fine in theory. Fewer disruptive changes to get used to. Fewer things get broken.
This tends to work well for huge companies with huge products, particularly where the technology is rooted in the past – releasing more frequently is hard work.
The unfortunate but unavoidable reality of day-to-day life, however, is that your needs and circumstances change all the time.
Your own customer and business requirements will evolve and you will be expected to react. Bugs might be discovered now or discovered later, but they’ll always be there.
The best software isn’t “set it and forget it” for most of the year because neither is your business or the way you work.
What you need
Fall in love with problems, not solutions.
No one asks for a new feature without there being an underlying problem that needs solving.
Keep asking “why?” until you understand the problem you’re trying to solve from every angle. Now focus on that.
It can be surprising how many different approaches you can come up with in trying to creatively solve the same problem.
Sometimes what’s needed is exactly as complex as you first imagined, but other times it’s much simpler and cheaper.
By focusing on problems and desired outcomes, you ensure the things you build are always tied to delivering real value rather than just a checklist of features.
Embrace the reality of change
Software is complex, so is procurement, and both are constantly evolving.
Rather than trying to carve out exactly what you need upfront, recognise that no specification is perfect and things will change.
Rely on the process of short cycles and frequent releases to continue delivering value but enable flexibility.
Think big but start small
Recognise that the longest journeys start with a single step.
Focus on how to deliver value and solve a problem with the least effort first.
You’ll release something sooner and learn faster as a result.
Getting valuable feedback on your assumptions as quickly as possible avoids waste and informs a better solution.
Focus on the direction of travel
Avoid obsessing over specific dates and deadlines. Focus instead on priorities and the overall direction of travel.
Imposing specific deadlines in the context of uncertainty doesn’t mean you’ll get a better or faster solution.
Trust in the process to keep delivering and if you think your priorities need to happen faster then make that argument.
Shape the solution for you
The best way to get software that does exactly what you need is by talking to the people who make it.
You might think this is doing our work for us. Unless you’re handling the specification, design, code, testing, release and maintenance, then I can assure you it is not.
It can take as little or as much time as you have or are willing to give. Just be open, collaborative and give feedback when you can.
Help make the product as useful and usable for you as possible.
Get in touch now to demo our platform or share your software feedback.