3 myths of enterprise software prototyping debunked
Design, user testing and custom development – we explain why some enterprise software myths are more fiction that fact.
Enterprise software is big business: over 1 trillion USD is spent annually on IT (according to IEEE’s Why Software Fails), with the US government spending $60 billion on civilian IT initiatives, and $16 billion on military IT alone. The revenues for software providers can be huge: SAS, for example, made revenue of $3.2 billion USD in 2015.
And yet despite those impressive figures, enterprise software has failed to lose its reputation for being unwieldy to both develop and use. It’s true that enterprise software is tricky to get right: complex, costly and historically clunky, enterprise application development implies a long lifecycle and a willingness to learn from mistakes. Traditionally, enterprises have been slow to react to developments in usability and UX.
But the landscape is changing, with many cutting edge enterprises investing heavily in design and user experience, industry disruptors such as Slack changing the game, and entrenched development processes being improved by innovations such as prototyping tools. It’s important to bust some of the pervasive myths that surround enterprise software – myths that hobble effective design and development.
Let’s take a look at 3 long-standing myths about enterprise software development and explain why they’re closer to fiction than fact.
Myth 1: There’s no room for design and development little guys
Back in the pre-disruption days of enterprise software development, the monopoly held by Microsoft and Oracle on the sector was enough to scare off smaller developers from even trying to compete, says Aaron Levie in his great TechCrunch piece ‘The 5 Myths of the Enterprise Start-Up’. But, as Levie points out, those days are gone thanks to changing technologies such as Cloud computing, which has opened up the software market and meant that SaaS applications can bypass monopolized distribution channels and eat into traditional vendor share.
So what does that mean for software development professionals? It means that it’s much easier to prototype and build a viable, ready-for-market product and successfully sell it to enterprises. Building a more streamlined ERP software that doesn’t suffer from years of complexity crud and is constructed for the omnichannel, social, BYOD era will win market share away from the in-agile, inelegant and unresponsive software providers of yesteryear.
Validate ideas painlessly. Download Justinmind.
Myth 2: Bespoke software is no more
The death of custom software has been heralded before, with packaged applications reputed to have taken its place. Not so, according to Forrester analyst Stefan Ried: in his report on myths and realities of the software market, Ried points out “enterprises spend about the same on custom-developed business applications as on packaged business software.” Bespoke isn’t dead, and in fact it can be the most economical solution for an enterprise that doesn’t need a whole software suite.
Myth 3: You only need to involve end users after the mobile application has been developed
This isn’t a consumer-facing software application so we don’t need to think about users until the final sprint, right? Wrong. The consumerization of enterprise software is not just any old trend; it’s one of the stand-out trends of recent years.
Increasingly, software is not selected on cost-factors by a distant C-suite but is downloaded and implemented by end-user employees – witness the rise of Slack to replace traditional enterprise project management software. Additionally, end-users now use world-class software every day in their personal lives and thus their expectations of enterprise software have shifted. Present them something inelegant and it won’t just be their productivity that suffers, it will be your reputation as enterprise software producer. No one wants to pay good money for software that looks like it was chipped into the Rosetta Stone.
The needs of the end-user perspective needs to be built into the foundation of the software, not tacked on as an after-thought
All this means that the needs of the end-user perspective needs to be built into the foundation of the software, not tacked on as an after-thought. Changing a feature after coded development can be up to 100% more costly than changing it in early design stages according to IEEE, and enterprise software that isn’t built for users can have devastating effects on profits if and when it’s rolled out: just take the example of HP’s flawed centralization of its ERP systems, which cost a cool $160 million in backlogs and lost revenue.
Build user feedback into the software design lifecycle by running usability tests on MVP prototypes, iterating on the original solutions and re-testing. Complex enterprise software is pretty much impossible to get right the first time out, and user feedback provides valuable information on information architecture, interface design and user acceptance.