The delivery of software services into organisations follows a common pattern. Some sort of need is identified, that need is investigated, some sort of software is procured (either bought or built) and the software is implemented alongside some sort of business change.
In the past decade that approach has been changed by the introduction of Agile methods, shortening the first stage of investigation in the spirit of iterative experimentation.
At no point is anyone seriously asked "What's stopping you?", and yet in our era of commoditised, consumerised, cloud-based software-as-a-service, increasingly a starting point for analysis should surely be "If you think this need is so important, why hasn't it already been addressed?"
Now of course it might well have been; over the years I've been part of many a project to try to unravel the delights of interlinked spreadsheets and Access databases. But where those "shadow" approaches were riddled with issues (not least because of challenges of versioning and file contention), a modern software-as-a-service offering to address a particular business need is probably as well architected, if not better so, than anything that can be built in house. Even a spreadsheet isn't that bad a thing these days when they have global scale and concurrent multi-user access.
There are issues of data ownership: what happens to our data, one may ask, if it's sitting "out there" in somebody else's system? It's a fair point, but it's also notable that exit strategies from proprietary systems are something that vendors have only got smart to in the era of cloud - when the data was sitting in proprietary structures, but in data centres that we owned, it was strangely OK to have little say over how you could extract yourself from the product.
"What about regulatory concerns?" I hear you ask. All this stuff happening without control must be a bad thing, right? Well, maybe. But then I'd also argue that regulatory concerns these days (because of the power of the services available at our fingertips) need to be embedded into every member of staff, not merely into software controls. After all, you'd be a fool to think that somebody up to nefarious acts is going to use the corporate systems if they are heavily regulated. But sometimes the controls get in the way of someone just getting their job done, and alternative routes need to be sought. "Forwarding to Hotmail", as it used to be called before substantial rebranding.
In all of this, often the answers to the question "What's stopping you?" are either "Because the current IT stops it working" or "Because actually it's not something that anybody really wants or needs". In the former case the barriers to prevention are increasingly difficult to maintain, and in the latter, well - if nobody's actually doing it today, in the free market that is modern technology, there might be a very good reason.
However there might be a third reason - that the organisation either implicitly or explicitly is telling people not to do the thing. And if that's the case, those barriers need to be addressed as much as any software delivery.