After reading our recent blog posts “Why Not to Start App Dev with UI” and “Developing Apps in a Vacuum–Sound Familiar, we are going to assume you’ve had a lightbulb moment about rapid application development (RAD) and are now a believer and want to try an MVP approach. If so, this means you’ve built the business case to modernize your complex business application and likely plan on taking it to the cloud as a SaaS-based application and improving the user experience.
As a refresher, here is OUR definition of MVP (Minimum Viable Product):
M: As small as possible
V: It has to actually work – it’s not just a prototype or pilot
P: It has to be commercially viable, generating revenue or creating value for users immediately
The MVP approach supports your commitment to being cost-efficient, helping your organization expand, and attracting new customers with your new, appealing enterprise app. You understand the value behind creating an MVP, where you and your team create the most viable application quickly, with lots of user testing and iterations–all under the auspices of agile development sprints, where it’s okay to fail as long as you fail fast. This agile approach lets you deliver what stakeholders need and want, even as those needs evolve to keep pace with the marketplace. Now that you fully understand why this kind of approach makes sense–you and the team are ready to go for it.
But the question is where exactly do you begin? How do you tackle a big project like this and reduce the risk? You might as well ask, how do you eat an elephant? The answer–one bite (or byte) at a time. In other words, you slice it first into more manageable sizes, then you cut the slices in small pieces, so you can consume each piece one by one. In the case of a complex business application, this can be module by module or by sets of functionality. However you decide to go about it, you’ll want to pick the approach that offers the most value. This means you’ll need to assess which approach best aligns with and supports key business priorities.
Back to the immediate problem and that is deciding which bite of the enterprise application elephant to start with. Questions to ask yourself: “Why are we modernizing again?” Next, ask “Which is the fattest part, the part that I can resell the easiest?” Or “Which part is most unique?” or easiest to “chop off”? Other questions you should be asking is “How attractive is my mud-covered grey elephant?” “Is it possible to create a fit-for-purpose pretty pink elephant?” “One that is easier to transport to my customers to mobile-first?” “One that is totally UX focused?” “One with less functionality but is ready to go, can be configured by the customer itself, and doesn’t require consultants to implement?”
Consider starting with a small floating elephant “app” in the bathtub. Then, start pumping it up by adding functionality, quickly, every step along the way. And eventually, you will end up with a beautiful, clean pink elephant that lets you retire the ugly grey one. Obviously, the project management aspect of large and complex transitions comes with a great deal of risk. For it to be successful, you have to manage it well. As a developer, it’s tempting to drive this project management process based on technical decisions. But for baby elephant projects to survive and thrive, you need to align your approach with business drivers, the need for innovation, and always start with UX first.
Save the sinking elephant! From a project management and risk reduction point of view, ask about our Appsurance Program. Even if you aren’t using the Servoy platform to modernize your application, you need a solid system in place and probably new processes. We’re here for you and want to share what we’ve learned during the previous 15 years, through many modernizations, rewrites and projects to help you avoid false starts or even worse–project failures.