In Jurassic Park, Jeff Goldblum famously said “your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should”. Now, he was talking about bringing dinosaurs back from extinction, not software development; but the same point applies to both.
You start with A Great Idea for a new piece of bespoke software. You get agreement from others that they think it’s A Great Idea too… and so you get started coding. Whilst working you have more great ideas, and you throw them in too. Your enthusiasm for this project is only matched by your certainty as to how much everyone else is going to love it.
Then… you reveal your masterpiece to the world… but nobody is popping champagne corks. No-one is using the system. Even worse, no-one is even bothered enough either way to tell you what they think, whether good or bad!
What went wrong?
Well, maybe the whole idea wasn’t so great after all; or a competitor beat you to market. Or it could be something much simpler - a system designed and built by a developer is at risk of being full of all the cool things that they can do and using all the innovative skills that they've learned. Because developers love that stuff.
The problem is that users do not share the love of that stuff. They want a solution to a real-world business problem. Anything else just gets in the way. What makes it difficult to bridge the developer-user gap is that the business users don't understand software. They don't know what software can do or what it can't do, and they quite probably don't really know what they want or what their 'business problem' really is.
This gap is often filled by a 'business analyst'; usually a role tasked with 'gathering requirements'. Unfortunately, in practice, this can just add a further link in the already difficult communication chain between developer and user.
Why doesn't it work? Why is 'requirements gathering' like this bound to lead to failure?
The business analyst needs the business knowledge to probe deeper into the users’ stated 'problem' and requested 'solution' so that they can fully understand what the underlying issue really is and answer key questions – Who are the users? What do they need? Why do they need it? What benefits will be realised?
They can then define the purpose of the proposed system, what problem it is trying to solve and how those benefits will be realised. This definition is then used to constantly test that the proposed system design will really solve this problem. Any feature that doesn't contribute to meeting this objective should be stripped out; and equally, if any part of the core purpose isn't being met by the design, then it must be redesigned. This is hard!
The analyst will also need to know enough about software development to be able to see what is possible and what is not possible in a system. They need to have an eye for potential problems and be able to spot the 'edge cases' where business users unwittingly hide subtle, and yet critical, complexities beneath words like 'mostly' and 'usually' or even 'always' and 'never'.
Beneath all of this is the question “why?”; or more directly, the use of the phrase “so what?” – which both force an explanation of the real business benefits.
“I want to know when invoices were sent out.”
“Because it will make my job easier!”
“We currently receive late payment for over half of our invoices because we don't know which ones to chase unless we do impossibly time-consuming manual checks.”
Once these conversations are all complete, the system design needs to be linked back to the business issues, business strategy, business benefits and business case. This then forms the starting point for a successful project. (We'll park the issues of change management and software development processes for another article!)
To do all that, and to do all that well, requires not only practical experience but the unique combination of business expertise and technology knowhow - a huge role to play.
Not bridging this business and technology gap is often where software projects fail – and it’s why so many business users end up disappointed with software and systems that are developed to solve their problems.
It’s just one reason why many of Waterstons’ clients engage our skilled and experienced consultants to help them bridge the gap – because we all know that the developers 'could' build the system, but deciding if they ‘should’ is the bigger challenge.
Sounds like Jeff Goldblum was right.
If you’re about to embark on a development project, take another look at why you’re doing it and the problems it will solve – and if you have any questions, just get in touch (but please don’t ask us to help you bring any dinosaurs back to life!).