wp ent lifecycle

8/3/2019 Wp Ent Lifecycle

1/6

Enterprise Mobile Application LifecycleDeveloping a Process for End to End Mobile Application Development

Prepared by Daniel Maycock, Slalom Consultant

White Paper


2/6

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 soware releases is becoming increas-

ingly more dicult, as operang systems and hardware types are becoming more numerous instead of less. This

paper discusses a exible approach towards mobile applicaon development, from an end to end lifecycle perspec -

ve, that will not only help to appease requests and ideas for new releases but will also help to streamline the

soware lifecycle and ensure capabilies are released on a more frequent basis.

Concept/

Idea

Idea

Submission Ini-alReview

Processincludes

checkingforduplicate

ideas,ini5ally

determiningifideais

feasible,etc

IdeaSubmissionwould

u5lizeexis5ngweb-

basedtool-set

MobileApplica2on

IdeaTeamReview

InternalWeb

Pla7orm

Mi-ga-onReview

AnalyzeWsofproblemstatement

(who,what,where,when,why)and

determineeithertorejectideaor

whattheoutstandingissuesthatneed

tobesolvedbeforepromo5ngthe

ideaare.TurnDownIdeaInformUser(s)of

decisionandreasons

whyideawasnt

promoted

Promote

Idea

MobileApplica2on

ProjectIni2a2on

Promote

Idea

Discovery

Design

Resolveoutstandingissues

determinedfrommi5ga5onreview

andresolveoutstandingac5onstobe

abletokickoffproject.DevelopSOW

&Func5onalRequirements

Specifica5onaswellasrequired

architecturaldeliverablesaswell.

MobileApplica2on

DevelopmentTeamMobileApplica2on

Transi2onTeam

MobileApplica2on

Stakeholders

(op5onal)

Introduc5onof3rd

Par5es

ProductRelease

MilestoneReviews Ini-ateDevelopment

Developmentteam

receivescompleted

projectdeliverablesand

ini5atesapplica5on

development

PeriodicreviewswithEbiz

Partnersandother

relevantstakeholders

ensuredeliverytoplan

Onceworkisdetermined

completebyStakeholders,

workistransi5onedto

adver5singteamsto

preparematerialforrelease

PrepforRelease

Productisreleasedto

public,withprocess

ini5atedforupdatesand

maintenancereleases

NewUpdates/

Changesto

product

Development\Tes2ng

DeploymentUpdate/MaintenanceReleaseProcess

MobileApp

RequestForm

TechnologyReview(POCPhase)

PerformLightweightproofofconcept

todetermineiftechnologiesincluded

inproposedapplica5onarefeasible

giventheconstraintsdeterminedby

MobileApplica5onIdeaTeam


3/6

Phase One should start with the process of gathering ideas, sorng 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 collecon stage starts with capturing the inial idea. There are two methods for this. The rst should

be an online idea collecon repository, or web site allowing internal employees to oer up their ideas for mobile

applicaons or capabilies. It should be set up to allow for internal employees to contribute ideas, and have them

ltered through a series of stages to pro-ceed to being evaluated by the Mobile Applicaon idea team. The second

method is a paper-based form, which should be located on a central intranet site for informaon 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 lter inial ideas should be ltered to keep redundant, or obviously improbable ideas from moving

forward for review. An inial screening should take place to assess viability of idea in retrospect to other ideas that

have been unsuccessful or impraccal to move forward.

Filtered list of ideas then proceeds to a Mobile Applicaon Idea Team Review. Team should be comprised of

business and IT representaves, responsible for project approval and acceptance regarding mobile soware

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 representave. In the event of an even vote to move forward, the business partner stakeholder

will have nal say as to whether or not to move forward. Team should also be limited to 3-4 representaves, to

ensure streamlined meengs.

If technologies are proposed as part of the soluon, 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 parcu-lar soluon to help aid in the funconal

specicaon and statement of work acvies in the next phase. This work should either be carried out by the IT

organizaon responsible for inter-nal soware development, or a quote taken from a third party organizaon

currently contracted for applicaon delivery and support.

Phase One: Discovery

Concept/

Idea

Idea

Submission Ini-alReview

Processincludes

checkingforduplicate

ideas,ini5ally

determiningifideais

feasible,etc

IdeaSubmissionwould

u5lizeexis5ngweb-

basedtool-set

MobileApplica2onIdeaTeamReview

InternalWeb

Pla7orm

Mi-ga-onReview

AnalyzeWsofproblemstatement

(who,what,where,when,why)and

determineeithertorejectideaor

whattheoutstandingissuesthatneed

tobesolvedbeforepromo5ngthe

ideaare.TurnDownIdea

InformUser(s)of

decisionandreasons

whyideawasnt

promoted

Promote

Idea

NewUpdates/

Changesto

product

MobileApp

RequestForm


4/6

Phase Two: Design

Once the idea has moved into the project iniaon phase, and the essenal elements have been eshed out (who,

what, where, when, why), the design phase of the project should begin and the project iniaon team will then be

formed based on the scope and complexity of the project.

Key representaves from IT & business organizaons (e.g. key stakeholders for project), as well as liaisons from Le -

gal & markeng organizaons where appropriate should be included. Team representaves can always coordinate

with their teams outside of the meeng, keeping the meeng agendas focused and the meeng mes short.

The statement of work & funconal requirement specicaon should be developed as key de-liverables for the

Project Iniaon team. These will include criteria for when a product is con-sidered done, the project manage-

ment approach, stakeholders required for milestone review, and addional criteria such as requirements for scope

change and nal list of features for re-lease.

Once these documents have been created and veed, stakeholders will grant nal approval be-fore moving to the

development & tesng phase. This process should consist of the business partner representave meeng with

a single decision maker in key stakeholder organizaons, and should be as streamlined and clear-cut as possible.

Bolenecks can arise in e-mailing doc-umentaon into stakeholder groups and having the feedback caught in limbo

due to high circu-laon from mulple sources, vs. buy-in from a single key representave that can speak on be-half

of the stakeholder organizaon.

Aer incorporang feedback into nal SOW & Funconal Requirements Specicaon, and nal approval is received

from stakeholder organizaons, project will then begin development \ tesng phase.

MobileApplica,on

ProjectIni,a,on

Design

Resolveoutstandingissues

determinedfrommi2ga2onreview

andresolveoutstandingac2onstobe

abletokickoffproject.DevelopSOW&Func2onalRequirements

Specifica2onaswellasrequired

architecturaldeliverablesaswell.

TechnologyReview

(POCPhase)

PerformLightweightproofofconcept

todetermineiftechnologiesincluded

inproposedapplica2onarefeasible

giventheconstraintsdeterminedby

MobileApplica2onIdeaTeam


5/6

Phase Three: Development \ Testing

IT organizaon should ulize internal development best pracces to develop and test product, per agreed upon

funconal requirements, with milestone reviews ideally taking place between stakeholder representaves and key

members of development team.

This is also the point at which third party organizaons (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 relaonship management with the third party should sit within the business stakeholder

organizaon, or IT organizaon, depending on the given skill set required.

Milestone meengs should consist of high level review of features & funcons associated with the given release,

and should have both an architecture representave 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 meeng can co-ordinate with their perspecve 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-onal specicaon is

aligned with a work breakdown structure, with appropriate melines as-signed accordingly.

As funconality is completed, and stakeholder buy o is complete. The project should go through a nal approval,with key stakeholders engaged to ensure funconality aligns with the statement of work and funconal specica-

ons. This should take place with small groups of key representaves, with a set meline for feedback and data

gathering to

MobileApplica,on

DevelopmentTeam

MobileApplica,on

Stakeholders

(op$onal)Introduc$onof3rd

Par$es

MilestoneReviews Ini.ateDevelopment

Developmentteam

receivescompleted

projectdeliverablesand

ini$atesapplica$on

development

PeriodicreviewswithEbiz

Partnersandother

relevantstakeholders

ensuredeliverytoplan

Development\Tes,ng


6/6

Phase Four: Deployment

The nal phase is transioning the nalized applicaon to the product market. The markeng organizaon should

be engaged to help determine the tradional adversing elements to help promote the applicaon, as well as

addional stakeholders throughout the company that are aligning their products or promoons with release of the

mobile applicaon. 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 ulizing the same

processes and project management principles deployed during the inial build of the applicaon. Streamlinedreleases will ensure key resources arent caught up and the product isnt delayed, regardless of what phase the

product is in. By successfully ulizing re-sources through project managed milestones, the team will ensure

ecient delivery can be guaranteed for all stakeholders involved.

Concluding ThoughtsThis white paper serves as a high level descripon of an eecve way to take in new ideas, transion into

soware development, and deploy/support the release for distribuon. Given the level of complexity inside any

organizaon, this process will look very dierent, so we rec-ommend considerable analysis be done within thedelivery & stakeholder organizaons to properly customize this process to maximize its eecveness, and provide

signicant benet to your organizaon. We would appreciate the opportunity to discuss how we can help provide

this analysis, and help your organizaon achieve success in deploying soware both internally to your organizaon,

or externally to your customers.

MobileApplica,on

Transi,onTeam

ProductRelease

Onceworkisdetermined

completebyStakeholders,

workistransi7onedto

adver7singteamsto

preparematerialforrelease

Productisreleasedto

public,withprocess

ini7atedforupdatesand

maintenancereleases

Deployment

wp ent lifecycle

Documents