Enterprise Mobile Application Lifecycle

Transcription

1 White Paper Enterprise Mobile Application Lifecycle Developing a Process for End to End Mobile Application Development Prepared by Daniel Maycock, Slalom Consultant

2 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. Concept / Deployment Product is released to public, with process ini5ated for updates and maintenance releases Transi2on Team Submission Submission would u5lize exis5ng web- based tool- set New Updates / Changes to product Product Release Mobile App Request Form Internal Web Pla7orm Ini-al Review Process includes checking for duplicate ideas, ini5ally determining if idea is feasible, etc Update / Maintenance Release Process Development \ Tes2ng Stakeholders Promote Team Review Turn Down Inform User(s) of decision and reasons why idea wasn t promoted Development Team (op5onal) Introduc5on of 3rd Par5es Mi-ga-on Review Discovery 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. Design Promote Project Ini2a2on 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 Team Once work is determined complete by Stakeholders, work is transi5oned to adver5sing teams to prepare material for release Prep for Release Periodic reviews with Ebiz Partners and other relevant stakeholders ensure delivery to plan Milestone Reviews 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 off project. Develop SOW & Func5onal Requirements Specifica5on as well as required architectural deliverables as well.

3 Phase One: Discovery Concept / Submission Mobile App Request Form Ini-al Review Promote Team Review Mi-ga-on Review Submission would u5lize exis5ng web- based tool- set New Updates / Changes to product Internal Web Pla7orm Process includes checking for duplicate ideas, ini5ally determining if idea is feasible, etc Turn Down Inform User(s) of decision and reasons why idea wasn t promoted 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. 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 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.

4 Phase Two: Design Design 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 Team 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. 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 ing 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.

5 Phase Three: Development \ Testing Development \ Tes,ng Stakeholders Development Team (op$onal) Introduc$on of 3rd Par$es Milestone Reviews Ini.ate Development Periodic reviews with Ebiz Partners and other relevant stakeholders ensure delivery to plan Development team receives completed project deliverables and ini$ates applica$on development 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

6 Phase Four: Deployment Deployment 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 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.