Enterprise Mobile Application Lifecycle

Enterprise Mobile Application Lifecycle

Developing a Process for End to End Mobile Application Development

Prepared by Daniel Maycock, Slalom Consultant

Introduction

With the increasingly vast array of mobile technologies being introduced every day, the need to support current technologies while not exceeding the capacity to develop and support new software releases is becoming increas-ingly more difficult, as operating systems and hardware types are becoming more numerous instead of less. This paper discusses a flexible approach towards mobile application development, from an end to end lifecycle perspec-tive, that will not only help to appease requests and ideas for new releases but will also help to streamline the software lifecycle and ensure capabilities are released on a more frequent basis.

Concept  /   Idea

Idea

Submission Ini-al  Review

Process  includes   checking  for  duplicate   ideas,  ini5ally   determining  if  idea  is   feasible,  etc Idea  Submission  would  

u5lize  exis5ng  web-­‐ based  tool-­‐set

Mobile  Applica2on   Idea  Team  Review

Internal  Web Pla7orm

Mi-ga-on  Review Analyze  5  W’s  of  problem  statement   (who,  what,  where,  when,  why)  and   determine  either  to  reject  idea  or   what  the  outstanding  issues  that  need   to  be  solved  before  promo5ng  the   idea  are.    

Turn  Down  Idea Inform  User(s)  of   decision  and  reasons   why  idea  wasn’t   promoted Promote Idea Mobile  Applica2on   Project  Ini2a2on Promote Idea Discovery Design

Resolve  outstanding  issues   determined  from  mi5ga5on  review   and  resolve  outstanding  ac5ons  to  be   able  to  kick  off  project.  Develop  SOW   &  Func5onal  Requirements   Specifica5on  as  well  as  required   architectural  deliverables  as  well.  

Mobile  Applica2on Development  Team Mobile  Applica2on Transi2on  Team Mobile  Applica2on Stakeholders (op5onal)   Introduc5on  of  3rd   Par5es Product  Release

Milestone  Reviews Ini-ate  Development

Development  team   receives  completed   project  deliverables  and   ini5ates  applica5on   development Periodic  reviews  with  Ebiz  

Partners  and  other   relevant  stakeholders   ensure  delivery  to  plan Once  work  is  determined  

complete  by  Stakeholders,   work  is  transi5oned  to   adver5sing  teams  to   prepare  material  for  release

Prep  for  Release Product  is  released  to  

public,  with  process   ini5ated  for  updates  and   maintenance  releases New  Updates  /   Changes  to   product Development  \  Tes2ng Deployment

Update  /  Maintenance  Release  Process Mobile  App

Request  Form

Technology  Review (POC  Phase) Perform  Lightweight  proof  of  concept   to  determine  if  technologies  included   in  proposed  applica5on  are  feasible   given  the  constraints  determined  by   Mobile  Applica5on  Idea  Team

Phase One should start with the process of gathering ideas, sorting them into meaningful cate-gories, and placing them under review to determine whether or not the idea should be promoted to a project.

The idea collection stage starts with capturing the initial idea. There are two methods for this. The first should be an online idea collection repository, or web site allowing internal employees to offer up their ideas for mobile applications or capabilities. It should be set up to allow for internal employees to contribute ideas, and have them filtered through a series of stages to pro-ceed to being evaluated by the Mobile Application idea team. The second method is a paper-based form, which should be located on a central intranet site for information on internal mobile content, and allow internal and external employees to capture ideas, which come in from methods other than the web form.

The process to filter initial ideas should be filtered to keep redundant, or obviously improbable ideas from moving forward for review. An initial screening should take place 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 Idea Team Review. Team should be comprised of business and IT representatives, responsible for project approval and acceptance regarding mobile software development. Team should review list and determine feasibility of turning idea into project. There should be a general consensus towards moving an idea forward, and any outstanding issues should be delegated to the appropriate team representative. In the event of an even vote to move forward, the business partner stakeholder will have final say as to whether or not to move forward. Team should also be limited to 3-4 representatives, to ensure streamlined meetings.

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 particu-lar solution to help aid in the functional specification and statement of work activities in the next phase. This work should either be carried out by the IT organization responsible for inter-nal software development, or a quote taken from a third party organization currently contracted for application delivery and support.

Phase One: Discovery

Idea

Idea

Submission Ini-al  Review

Process  includes   checking  for  duplicate   ideas,  ini5ally   determining  if  idea  is   feasible,  etc Idea  Submission  would  

u5lize  exis5ng  web-­‐ based  tool-­‐set

Mobile  Applica2on   Idea  Team  Review

Internal  Web Pla7orm

Mi-ga-on  Review

Analyze  5  W’s  of  problem  statement   (who,  what,  where,  when,  why)  and   determine  either  to  reject  idea  or   what  the  outstanding  issues  that  need   to  be  solved  before  promo5ng  the   idea  are.    

Turn  Down  Idea

Inform  User(s)  of   decision  and  reasons   why  idea  wasn’t   promoted Promote Idea New  Updates  /   Changes  to   product Mobile  App Request  Form

Phase Two: Design

Once the idea has moved into the project initiation phase, and the essential elements have been fleshed out (who, what, where, when, why), the design phase of the project should begin and the project initiation team will then be formed based on the scope and complexity of the project.

Key representatives from IT & business organizations (e.g. key stakeholders for project), as well as liaisons from Le-gal & marketing organizations where appropriate should be included. Team representatives can always coordinate with their teams outside of the meeting, keeping the meeting agendas focused and the meeting times short. The statement of work & functional requirement specification should be developed as key de-liverables for the Project Initiation team. These will include criteria for when a product is con-sidered done, the project manage-ment approach, stakeholders required for milestone review, and additional criteria such as requiremanage-ments for scope change and final list of features for re-lease.

Once these documents have been created and vetted, stakeholders will grant final approval be-fore moving to the development & testing phase. This process should consist of the business partner representative meeting with a single decision maker in key stakeholder organizations, and should be as streamlined and clear-cut as possible. Bottlenecks can arise in e-mailing doc-umentation into stakeholder groups and having the feedback caught in limbo due to high circu-lation from multiple sources, vs. buy-in from a single key representative that can speak on be-half of the stakeholder organization.

After incorporating feedback into final SOW & Functional Requirements Specification, and final approval is received from stakeholder organizations, project will then begin development \ testing phase.

Mobile  Applica,on   Project  Ini,a,on

Design

Resolve  outstanding  issues   determined  from  mi2ga2on  review   and  resolve  outstanding  ac2ons  to  be   able  to  kick  off  project.  Develop  SOW   &  Func2onal  Requirements   Specifica2on  as  well  as  required   architectural  deliverables  as  well.  

Technology  Review (POC  Phase)

Perform  Lightweight  proof  of  concept   to  determine  if  technologies  included   in  proposed  applica2on  are  feasible   given  the  constraints  determined  by   Mobile  Applica2on  Idea  Team

Phase Three: Development \ Testing

IT organization should utilize internal development best practices to develop and test product, per agreed upon functional requirements, with milestone reviews ideally taking place between stakeholder representatives and key members of development team.

This is also the point at which third party organizations (e.g. design consultants, contractors, etc) should be engaged, and brought into the project as key members of the development team, should external services be required. The relationship management with the third party should sit within the business stakeholder organization, or IT organization, depending on the given skill set required.

Milestone meetings should consist of high level review of features & functions associated with the given release, and should have both an architecture representative as well as a dedicated project manager present to ensure proper compliance & schedules are being met along the way. In the event that a necessary change needs to take place, the key people in the meeting can co-ordinate with their perspective teams to ensure project deliverables move forward in a stream-lined and coordinated fashion.

This will also ensure that elements such as scope creep stay to a minimum, because the func-tional specification is aligned with a work breakdown structure, with appropriate timelines as-signed accordingly.

As functionality is completed, and stakeholder buy off is complete. The project should go through a final approval, with key stakeholders engaged to ensure functionality aligns with the statement of work and functional specifica-tions. This should take place with small groups of key representatives, with a set timeline for feedback and data gathering to

Mobile  Applica,on

Development  Team

Mobile  Applica,on

Stakeholders

Milestone  Reviews Ini.ate  Development

Development  team   receives  completed   project  deliverables  and   ini$ates  applica$on   development Periodic  reviews  with  Ebiz  

Partners  and  other   relevant  stakeholders   ensure  delivery  to  plan

Phase Four: Deployment

The final phase is transitioning the finalized application to the product market. The marketing organization should be engaged to help determine the traditional advertising elements to help promote the application, as well as additional stakeholders throughout the company that are aligning their products or promotions with release of the mobile application. This process should be streamlined, with clear deadlines in place for each of the sub-processes that need to occur for the release to market.

Once the product is successfully deployed, ongoing maintenance and updates should take place utilizing the same processes and project management principles deployed during the initial build of the application. Streamlined releases will ensure key resources aren’t caught up and the product isn’t delayed, regardless of what phase the product is in. By successfully utilizing re-sources through project managed milestones, the team will ensure efficient delivery can be guaranteed for all stakeholders involved.

Concluding Thoughts

This white paper serves as a high level description of an effective way to take in new ideas, transition into software development, and deploy/support the release for distribution. Given the level of complexity inside any organization, this process will look very different, so we rec-ommend considerable analysis be done within the delivery & stakeholder organizations to properly customize this process to maximize it’s effectiveness, and provide significant benefit to your organization. We would appreciate the opportunity to discuss how we can help provide this analysis, and help your organization achieve success in deploying software both internally to your organization, or externally to your customers.

Mobile  Applica,on

Transi,on  Team

Product  Release

Once  work  is  determined   complete  by  Stakeholders,   work  is  transi7oned  to   adver7sing  teams  to   prepare  material  for  release Product  is  released  to  

public,  with  process   ini7ated  for  updates  and   maintenance  releases