Mobile Development Lifecycle – Part 1

Technology is moving at lightning fast rate as of now as compared to what it has been say 10 years back. To stratify it more we would say that an increasingly vast array of mobile technologies is being introduced every day. It is becoming more and more complex to support the frequent new releases while not exceeding the capacity to develop and support them.
What we discuss here is a comprehensive yet flexible approach to mobile application development from an entire lifecycle perspective. This discusses the methodology to be adopted for streamlining the product lifecycle and ensuring that capabilities are utilised to meet the requests for new idea releases.
The entire lifecycle of mobile development can be divided into 4 phases, which are as follows:

Phase 1 : Discovery Phase

The discovery phase as the name suggests is to be focussed on gathering ideas, sorting or stratifying them into small yet meaningful modules or categories, reviewing them from perspective of users and user needs and finally deciding as to whether or not the idea should be promoted to become a product.

There are multiple methods for idea generation. As an organization focussed on developing a product it should have an idea repository allowing its employees, clients and product users to offer their ideas which can be related to a new product altogether or just enhancing the capabilities. The process needs to be set up for the contributed ideas to be filtered through stages and finally landing up in the mobile application / product development team.

Once the ideas are collected the purpose of filtering the idea is to identify redundant and obviously improbable ideas from moving forward for review. This first level screening is done to assess viability of idea in retrospect to other ideas that have been unsuccessful or impractical to move forward.

Filtered list of ideas then proceeds to a mobile application / product development team for review. The composition of this team is very important and this team in general should comprise of business and IT representatives, responsible for project approval and acceptance and development. Team should review list and determine feasibility of turning idea into products. There should be a general consensus towards moving an idea forward, and any outstanding issues should be clarified with utmost importance so as not to miss out on any potent and potential idea.

In the event of that voting is required to move forward the project sponsor should have the final say. Another thing to keep in mind is to keep the team limited to 4-5 people so as to make it more streamlined.

If technologies are proposed as part of the solution, either because they’re too new to have been used in the past or obscure enough to not have any previous knowledge in house, a lightweight proof-of-concept should be conducted to determine the viability and pro’s/con’s of the particular solution to help aid in the functional specification and statement of work activities in the next phase.