Recently a college and I attended a great conference where we met with a couple of people we new from before and were asked if we wanted to do a small talk on their conference. At first we weren't so sure about it but kept the idea in our minds.
So I came up with an idea about doing a small talk on how to present (sell), develop and maintain applications in a world of people with background in economics (as that is the filed I'm currently working in, banking/insurance to be more specific).
The biggest problem we are running into is how to present the new idea for the apps to the client in order for them to understand the value and benefits of using our apps instead of doing things in their current way.
As most if not all of them don't understand the IT world and it is hard for them to see the value in a fully automated system meant to speed things up and keep to process as clean and smooth as possible when explained in the technical terms.
So we devised a plan on how we can make things easier for us to present the client what we want to develop and why they should care about it.
First step:
Probably the most boring part of the process is creating the documentation explaining what the app will cover and the logic flow of the app. How the app will help/improve their current workflow and remove most if not all current problems they have in doing things the old way (by hand, paper, email etc).
One thing we discovered in this process is that people are often scared of the change and just want to keep doing things in the same way they have for a while as it easier than having to learn/master a new system. But what helped us with this step was having full diagrams of how the entire process would work in the new app and what steps it would remove from their old work flow and let them focus on other more important things or just give them some free time.
Second step:
Create a small proof of concept app that demonstrates all the logic and workflow described in the documentation to help them visually understand more about what you are talking. As they tend to understand things if they can see the forms, buttons and all the new shiny things :)
But make sure not to go fully overboard with the PoC app like it was being released into production after the first showing. It should only have the most basic of options and be able to demonstrate how it would all work once fully developed. This way you have something to show them and also in case they decide not to go for the app you haven't invested a lot of time or energy into building it.
Third step:
Propose a budget and a timeline required for your project (always try to leave some room for last minute changes and testing), sometimes even going on a bit of lower price as to make sure they accept the project but than make up for it in the maintenance fees and upgrades. It helps to have a really good contract that clearly describes the limitations of what can and can't be done during the development faze and how any new features would affect the timeline and/or cost of the whole project.
Fourth step:
Develop a fully working app that they can test and later use with everything described in the documentation.
And even if this might seem a like simple 4 step program it is not as easy as it sounds, since this whole process can last anywhere between few weeks to several months and having to deal with many and sometimes long meetings, emails, phone calls to discuss all of this. And during that time you should keep trying to improve their understanding of the application you are trying to make.
Top comments (0)