What We’ve Learned Building Custom Applications for 20 years
What We’ve Learned Building Custom Applications for 20 years
RapidBIZ embodies much of what we’ve learned developing hundreds of custom business applications. But that’s not what this blog is about, it’s about mistakes we have made and things we’ve learned. Hopefully, these thoughts will help you consider how you would approach a custom business solution.
Gathering and Finalizing Requirements
We have worked with some very large organizations and were directly involved in the application requirements definition. In these organizations, the requirement gathering process involved all “stakeholders”. And while the goal of gathering requirements from every organization that would use the application has considerable merit, it is almost impossible to gain a consensus as to the main purpose of the application and the problem the application is designed to solve. So the process drags out for months (sometimes years) and by the time the final list of requirements has been committed and the development of the application has finished, the application no longer meets the requirements of business, because the process has taken too long.
The approach that has worked well for us is to meet with the knowledge workers and understand the basics of the applications – the workflow, the primary data, key users, etc. Then we develop an application prototype – just the core – don’t worry about security, user login, etc. This is a fantastic way to establish a context for ongoing discussions and it helps verify that you understand the process. Very typically, we can get the prototype to reflect 50 – 60% of the process requirements the first time – done in about two (2) weeks. Then it’s a matter of iterating based on regular feedback from the knowledge workers.
Application Look vs Practical Use
In the past we have had to ensure that the application really had a nice “look”, had some colorful charts and other “cool” things; and that we were using all the current buzz words, so when we’re demoing the application to the executives, they were impressed – and they needed to be since they were the ones making the purchasing decision.
However, remember who the users are and if they are not the executives, they need practical usability to do their day to day job. Things that get them to functions quickly – reduced clicks, functions that do a lot of work for them; i.e. auto fill forms, notifications automatically sent, etc. It’s great to have both a nice looking application and cool widgets, etc, but don’t forget ease of use for the primary user. We’ve made the mistake of focusing on the “glitz” and ended up redoing the user interface – additional cost, time and resources.
Focus on the Core Process
One of the reasons that gathering requirements like I described above is very time consuming is because the focus is generally not on the core process – those things that are done 75% of the time – everyday. It really does not take that long to define the core, so then the users tend to focus on all exceptions/problems they have with the running the process – maybe one or two customers situations. When this happens it’s very difficult to identify the core because so many of the requirements are intermixed with problems and exceptions vs what the core process needs to be designed to do.
Without a clear definition of the core process, it becomes extremely difficult to design an application that works well for the core processes and allows you to accommodate the exceptions. If you develop around the exceptions, everything becomes an exception – including the core processes.
Subject Matter Experts
We worked with one large customer who presented the Subject Matter Experts (SME’s) as the source of requirements. We spent considerable time understanding a fairly complex process, developed the application and iterated with the SME’s on changes. Then one day, we presented the application the actual users. Guess what – the application did not fit the way they did things day to day.
The SME’s were quoting the documented process(es) and didn’t know what was really going on with the people who did the work – fact of the matter was that the documented processes were totally out of sync with the real world. Considerable time and resources were wasted and in the end the project was scrapped.
Make sure REAL users are involved in the requirements gathering and development iterations.
Iteration Key to Success
Whether you’re using an Agile approach or some other iterative development methodology, the key is: keep real users involved - if you don’t get the end users involved and bought into what’s being developed, then they may not use the application – they’ll just keep doing the things the way they’ve been doing them.
Other Stuff
We only develop cloud capable apps and we've learned to always develop responsive apps so they render properly on any device. Users want access to their applications and data from pretty much anywhere and anytime. Applications that are responsive give them that capability through their browser if they have an internet connection.
Always develop standard browser delivered applications. We only develop applications that work with a standard browser. Don't use functions and features specific to browser - this will only cause you support issues when users try to use a different browser and things don't work as they expect.
Standard browsers provide a lot of flexibility for the user and you as a development organization. The user doesn't need special clients to run the application, and as a developer, you have much less dependency on knowing (and trying to control) what the user settings are on their workstation in order to deploy and support a client.
Summary
Custom applications can provide significant benefit, because they allow customers to have the application built around they way they do business. Some packaged solutions claim to provide "best practices" - well, I guess the question is "who's best practice" and is that the way you want to (or even can) management your business.
The key is understanding what you are about to build and build it quickly. In our world, RapidBIZ helps us do that.
Learn how VACAVA can help you. Contact me today.
About VACAVA Inc.
VACAVA's mission is to deliver high-quality, affordable custom applications that allow companies to reengineer their existing processes and operate more efficiently and effectively.
VACAVA's solutions are tailored exactly to the needs of the organization, allowing it to work with companies of all sizes, from fledgling ventures to Fortune 500 companies.