White Paper

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 increasingly 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 perspective, 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.
Mobile Applica2on Idea Team Review Ini-al Review Internal Web Pla7orm Promote Idea

Concept / Idea Idea Submission

Idea Submission would u5lize exis5ng web- based tool-set New Updates / Changes to product

Mobile App Request Form

Discovery
Mi-ga-on Review
Analyze 5 Ws 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.

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

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

Turn Down Idea

Inform User(s) of decision and reasons why idea wasnt promoted

Deployment

Product Release
Update / Maintenance Release Process

Design

Product is released to public, with process ini5ated for updates and maintenance releases

Promote Idea

Development \ Tes2ng
Mobile Applica2on Stakeholders Mobile Applica2on Development Team

(op5onal) Introduc5on of 3rd Par5es

Mobile Applica2on Project Ini2a2on

Mobile Applica2on Transi2on Team

Milestone Reviews Prep for Release

Once work is determined complete by Stakeholders, work is transi5oned to adver5sing teams to prepare material for release Development team receives completed project deliverables and ini5ates applica5on development

Ini-ate Development
Resolve outstanding issues determined from mi5ga5on review and resolve outstanding ac5ons to be able to kick o project. Develop S OW & Func5onal Requirements Specica5on as well as required architectural deliverables as well.

Periodic reviews with Ebiz Partners and other relevant stakeholders ensure delivery to plan

Phase One: Discovery

Concept / Idea Idea Submission
Idea Submission would u5lize exis5ng web- based tool-set New Updates / Changes to product

Mobile App Request Form Ini-al Review Internal Web Pla7orm

Mobile Applica2on Idea Team Review Promote Idea Mi-ga-on Review

Analyze 5 Ws 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.

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

Turn Down Idea

Inform User(s) of decision and reasons why idea wasnt promoted

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 theyre 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 pros/cons 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 Two: Design

Design
Mobile Applica,on Project Ini,a,on

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

Resolve outstanding issues determined from mi2ga2on review and resolve outstanding ac2ons to be able to kick o project. Develop S OW & Func2onal Requirements Specica2on as well as required architectural deliverables as well.

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 Legal & 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 management approach, stakeholders required for milestone review, and additional criteria such as requirements 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.

Phase Three: Development \ Testing

Development \ Tes,ng
Mobile Applica,on Stakeholders Mobile Applica,on Development Team
(op$onal) Introduc$on of 3rd Par$es

Milestone Reviews
Development team receives completed project deliverables and ini$ates applica$on development

Ini.ate Development

Periodic reviews with Ebiz Partners and other relevant stakeholders ensure delivery to plan

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 specifications. This should take place with small groups of key representatives, with a set timeline for feedback and data gathering to

Phase Four: Deployment

Deployment
Mobile Applica,on Transi,on Team

Product Release
Product is released to public, with process ini7ated for updates and maintenance releases

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

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 arent caught up and the product isnt 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 its 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.