Background: Our leads and clients have often asked us, what is the best way to evaluate and decide which mobile app development studio for the project? That is a tough question to answer. Our previous article on picking the right mobile app development studio in Singapore shed some light on the topic, but it is a really complicated question and I felt that the previous article still lacks some degree of depth.
I’ve been on the client side, managing vendors for my bosses, have developed software for more than half my life, and am now the Managing Director of Originally US, an award-winning mobile app development studio. I thought it would be interesting and beneficial to share my honest perspectives on the topic to our client and leads.
To that end, I’ve embarked on the process on writing a mini guidebook, to be distributed as an ebook format once it is completed. In this book, I try to be as entertaining as possible, while covering a potentially very dry and complicated topic. I hope that works out.
New chapters will be made available here on a weekly basis (I try my best).
Chapter 1.1 – Procurement & Tender Process
Chapter 1.2 – Project Requirements & Scope
Assuming all is right with the sales, the next bit where things can go wrong is the requirements gathering or scoping process. Usually, during this phase, mobile app development companies will send their Project Managers or Consultants to sit down with the client, to document and align the finer details of what has to be built in the mobile app.
This is the part where many clients, especially if they are new to mobile app development, dig themselves into a hole.
1.2.1 A Matter of Perception
As human beings, are brains are wired differently. Take famous optical illusions like the one below for example. Do you see an old lady or a young woman? Or do you see both?
One of the worst mistake that clients and vendor can make is to assume that the other party has the same understanding about certain objectives, project specifications or business logic without confirming that understanding with the other party in a formal or written manner. Different parties could look at the same line on the requirements document and come away with totally different understanding.
For example, a requirements document could mention “User can search for tickets to book”. To the development company, this could simply be a calendar search, e.g. user can pick a date and view the tickets available on the date. But looking at the very same line in the requirements document, the client could take it to mean a full-fetched search feature that includes text search functionality, calendar search as well as filtering by price range and ticket vacancies.
If not discovered early, this difference in understanding in project scope could result in cost overruns as the client may be unaware that the original quotation does not include functionality that were required. It doesn’t help that there are app development companies in the industry that resorts to word trickeries in their requirements document for unscrupulous purposes.
If the client works on a tight budget, a surprise discovery that a key functionality is actually missing from the requirements can spell doom for the entire project.
1.2.2 The Devil is in the Details
To avoid perception misalignment like what was mentioned above, it is very important for the mobile app company to be as detailed as possible in their requirements document. The client also should expect the requirements document to at least provide a breakdown of the business logic of key functionalities as well as data input and output.
If not done properly, that’s as good as as paying for a car and only knowing it will come with “some wheels, an engine and a couple of seats”. You need to know exactly what you are paying for in order to avoid regret and getting a toy car instead of a Porsche 911.
On the other hand, having too much details also don’t help anyone as it can drive up the project cost due to the increased effort the app company has to invest in order to complete the document. At the same time, too much details can also slow down project progress because as the client, you may not be able to digest and make sense of the requirement if it is unnecessarily wordy or detailed.
The following is an example of a requirements with too little details.
User Account Module
- Registration
- Sign in
- Sign out
- User profile
- Display photo
- Email address
- Password
We would expect mobile app companies to at least provide this level of details in their requirements:
User Account Module
- User Account Module
- Registration
- Expected input
- Username (mandatory, must be unique, between 5 to 10 characters)
- Email address (optional, with verification email sent to user if input)
- Password (mandatory, max 8 characters)
- Mobile Number (mandatory, with SMS OTP verification if input)
- Sign in
- User may sign in with either mobile number or username
- An SMS OTP is sent to the user’s mobile number upon correct username and password
- Each OTP expires in 60 seconds and must be entered into the app before the sign in process can be completed and successful
- Sign out
- User profile
- User may upload and change the display photo
- User may change his email address.
- When changing email address, a new verification email will be sent to the new address
- The app only updates the email address upon successful notification.
- User may change his password
- When changing password, an SMS OTP will be sent to the user to enter into the app to confirm his identity before he may specify the new password
- Expected input
- Registration
And this is way too much details, and a waste of everybody’s time:
- User Account Module
- Registration
- Expected input
- There is a text box for user to enter his preferred username
- If the user enter a username with less than 3 characters, we will show an error in red colour
- If the user enter a username with more than 10 characters, we will show another error message in red colour
- The error message should show on the same screen as the textbox
- The error message should be below the textbox
- The error message should only show after user tap on submit
- If user did not enter a username, there will also be an error message
- If the username entered has already been taken, we will show a pop-up to inform user.
- There is also a textbox for user to enter his email address
- The email address must contain the ‘@’ character
- The email address must be a valid email address
- When user submit the email address, we will send an email to the address
- The email should contain a button
- The button should be clickable
- When user click on the button in the email, his email address gets verified.
- There is a text box for user to enter his preferred username
- Expected input
- Registration
…
Phew. Did you actually read through all of that? We haven’t start on the password requirements!
All 3 examples given above were taken from real world project documents. It is important to find the right balance between having enough details and too much details. Having experienced Project Managers on both the client and vendor side can help.
Originally US is a leading Android and IOS Application Developer in Singapore.
