Part of the Radolo process whenever we build a custom application is to begin with what we call discovery. The purpose of discovery is to define what needs to be built and how it will work. During this process we dig deep, defining requirements down to how every page will look, the functionality of every click, what happens when something unexpected happens, and how it all flows together. We always get questions about why we insist on doing this upfront before we write any code as many view it as a waste of time. After all they know their business need and generally what the applications needs to do, let’s just get started and flesh it out as we go. Not going through the discovery process should be a nonstarter for anyone building software for three big reasons, not planning is expensive, planning mitigates risk, and ultimately because planning improves the end result.
Example of a sketch wireframe
Imagine you want to build your dream house. You’ve thought about everything from the retro-chic game room to the old-fashioned porch swing. You know there are a ton of details in building a house, but you find a contractor and say “just start building and we’ll tackle the issues as they come up.” Would you ever do this? Hopefully not. Just like you’d commission an architect to develop a blueprint before building a house you should invest in a software discovery before building an application. Contractors need a blueprint for the same reason developers need requirements; it reduces rework. Making changes while they are written on a whiteboard or a piece of paper is quick and cheap. Making changes after they’ve been coded is expensive and time consuming. The more that can be defined out up front, the cheaper the development process will be.
Research shows that 75% of respondents believe that IT projects will fail. How can this be? More importantly, how can any organization take on such a huge risk when applications are becoming more essential to their business? A big reason these projects fail is due to poor definition upfront. Budgets and timelines are required upfront, but how can anybody give an accurate budget or timeline without knowing exactly what they’re building? Going through the discovery process doesn’t just reduce development cost, it also drastically reduces risk. Having a hard set of requirements ensures all parties are on the same page and moving in the same direction.
HIgh fidelity digital wireframe example.
The last, and likely most important, argument for going through a discovery process before building an application is that it will improve the end result. Inevitably, different assumptions are made by all members of the business and development teams which can lead to results that aren’t what the product owners envisioned. In addition, there frequently are parts of a process that the business took for granted and never fully explained. Discovery is not just a knowledge transfer from the business to the developers (though that’s a big part); it’s also an exercise to force the business to think through exactly what they need. Are we adding this functionality because you need it or because you’ve always had it? What does the person who will be using this application everyday think about this? Going through this process greatly increases the probability that the end result will be an intuitive, highly usable product. The only way to achieve this is to have all users of the application sit down and talk through what they need.
Building new applications is an exciting process. Tedious activities can be automated and productivity gains can be realized. However, too often we let the excitement of building (or the dislike of extra work) to lead us to a build-first, ask questions later approach. This results in application development having a fairly poor reputation of being expensive, late, and failure prone. However, by spending just a little bit more time upfront defining what you want, your success rate will skyrocket. Granted, discovery can be a huge pain to go through and it likely requires some extra cash up-front, but it doesn’t even compare to the pain and wasted expense of having your development projects implode.