A mobile web or app project requires a comprehensive evaluation of its technical requirements; the implementation plans and roadmap; company and customer readiness; legal and cultural issues and timescale.
If your mobile project passed the viability tests outlined in the previous column on business fit, customer fit and competitive environment, the next stage is a feasibility assessment.
The feasibility study asks: why should this project be given the green (go ahead), amber (needs more work) or red (kill) light?
There are four main feasibility assessments for technology projects, according to Castro and Mylopoulos, University of Toronto (Written in 2002, this is still one of the best introductions to IT feasibility studies). As many mobile (and digital) projects are customer facing, as opposed to just internal to the organization, it is essential to add a fifth: go-to-market feasibility.
The five feasibility studies are:
- Technical feasibility
- Operational feasibility
- Schedule feasibility
- Economic feasibility
- Go-to-market feasibility
This column will cover the first three of these, with best practice processes, techniques and tools, including an introduction to the feasibility matrix.
Economic and go-to-market feasibility will be addressed in future articles.
Technical feasibility study
Technology projects are notorious for running late, over budget or failing completely.
The good news is that mobile projects fair a lot better. According to the Standish Group Chaos Database 2015, 69% of mobile projects finish on time, on budget and with a satisfactory outcome, compared with only 29 percent in non-mobile projects.
This success rate is probably helped by the fact that mobile projects for large organizations tend to be smaller and involve less integration (sometimes – alas – no integration at all) with existing company IT infrastructure.
The bad news is that 26% of mobile projects are delivered late, over budget or with an unsatisfactory result and an additional 5% fail (cancelled or not used). To avoid your project joining the unsuccessful third, you need to undertake a comprehensive technology feasibility study.
Two notes on the Standish research:
- Standish measures the success rate for large US organizations like Bank of America, Home Depot, or the IRS, not start ups producing $1.99 mobile apps.
- This is success from a technology standpoint. A successful technology project will not guarantee commercial success, but will help prevent a commercial flop… assuming all other viability studies documented in this column and the previous column are carried out properly.
Geoffrey Handley a China-based venture capitalist and mobile-marketing veteran:
The main point of the feasibility study is to answer three questions:
1) Is this technically possible?
2) What is the best way to achieve it?
3) Are we the best people to do it?
The evaluation should include available technologies; required skills; deployment; ongoing management and support; integration into back end systems; scalability and futureproofing.
Start by appointing a suitably qualified, independent person to conduct the feasibility study. Ideally this will be someone who understands both the technology – mobile, web, integration etc. – and the business and customer goals behind the program, as well as having the appropriate assessment and reporting skills. Avoid anyone with a vested interest in making the project happen, or likely to steer it in a particular direction.
Provide them with a detailed project plan, including all features and specifications, all business goals and requirements – as identified in the stakeholder interviews. Give them sufficient budget and time to complete the study, evaluate the options and write the report. Do not skimp or rush it – you will pay for it in spades later.
The technology requirements vary greatly between projects, but in general the study should include:
- What is the most appropriate platform – web-based or individually coded in native Android and iOS languages?
- What technologies are required? Are they mature or still emerging?
- What can be used off-the-shelf and what needs bespoke coding?
- What are the options for development environment/framework?
- What features – e.g. location; camera –need to be accessed on the device? What is the best way of doing this?
- How will you minimize use of device battery life, memory and data allowance?
- With which internal corporate IT systems – e.g. customer database – must it integrate?
- What data feeds are required from third parties and how will these be accessed?
- What skills are available in-house, do you need to retrain, employ or outsource?
- How will the project maintained – how will bugs be fixed?
- What is the future roadmap for the project? What is the schedule for updates?
For each of these key requirements, assess the chance of success. It is useful to present the results as a percentage, for each option, with an overall score for the technical feasibility study.
Feasibility assessment matrix
A useful way to present the results of the feasibility studies is using a feasibility assessment matrix. This shows the percentage score for each criteria for each feasibility study – technical, operational, schedule, economic and go-to-market – and is repeated for each project variant.
The example matrix below, uses the three options of web app, native app and hybrid app, but the comparison could be based on in-house development v outsource or a feature-rich project vs a trimmed speed-to-market version.
Where technical feasibility considers if it is technically possible, operational assessment asks: is the organization ready for the project and its impact and what are the business, cultural, legal etc. hurdles that might stop it working in practice?
There is some overlap with business fit in the previous column, which considered how the project fitted with corporate culture and the need to establish stakeholder goals.
But the operational feasibility goes much deeper and much broader than this.
- Will management and employees welcome, accept or resist the new project? To what extent does this change the status quo?
- What new roles need to be created, what roles will be altered or lost and how much training required? E.g. if the loyalty program is being migrated from card-based to mobile phone how will that effect customer services staff?
- How will program be implemented? How will it be documented?
- Will there be customer privacy concerns; how will they be managed?
- What data is being collected; how will it be stored and managed; what are the risks?
- What are the data protection issues with information accessed by or collected by the mobile platform?
- What are the other legal issues e.g. copyright, licensing, distance selling?
- Are there government regulations; industry standards that should be taken into account?
- Will integrating the new platform increase the risk to the company from cyber-attack?
- What is the process for educating customers, partners etc. in the new platform?
Daniel Rowles, CEO of Brighton, UK-based digital marketing training firm Target Internet:
Mobile or digital projects, as a whole, do not fail because mobile/digital itself is inherently challenging or complicated. They fail because the company isn’t ready for such projects – i.e. it isn’t prepared for the organizational changes necessary to make the project successful.
The problem usually lies with ‘capability’ issues, including management buy-in, sufficient allocation of resources, team skills and the most common: infrastructure issues. Infrastructure is IT-related issues such as integrating systems along with inappropriate provision for data management and content management. Resource allocation isn’t just about ensuring you have the correct IT/digital team, it’s making sure there’s someone to respond to tweets etc.
The process of preparing the company and making it capable of implementing digital projects effectively is called digital transformation”
For each of these key requirements, assess the chance of success. It is useful to present the results as a percentage, for each option, with an overall score for the operational feasibility study. See the feasibility assessment matrix, above.
This step evaluates if the project can be delivered on time and if the time frame is realistic. Time to market is particularly important for mobile projects as the motivation is often to a) exploit a gap in the market; b) meet an identified customer or business need; or c) it is planned to coincide with a particular event e.g. sporting; product launch; or promotion.
This takes into account:
- How long it takes to recruit, train development staff.
- How long each element of the development process will take, including design, testing and revisions.
- Accounting for operational issues such as training staff, internal politics, arranging licenses and third-party relationships and ironing out legal issues.
- Allocating sufficient time for unexpected changes, unforeseen issues.
- If the estimated time required for promoting/bringing the product to market; including, if a native app, the lengthy app store approval process.
- If adequate provision has been made for scheduling maintenance and regular updates post launch.
This process helps evaluate if the project should/could be simplified to ensure faster speed to market by introducing efficiencies and/or saving features for the first scheduled update.
For each of these key requirements, assess the chance of success. It is useful to present the results as a percentage, for each option, with an overall score for the schedule feasibility study. See the feasibility assessment matrix, above.
Noah Elkin, a mobile marketing veteran and co-author of Mobile Marketing: An Hour a Day:
Establishing a roadmap is absolutely crucial. Think of it as a visual calendar of the necessary steps for completing your plan plus their interdependencies. You want something that will show the planned start and end dates of each task and where it overlaps and/or affects other tasks on the list.
It will help you show – and share – key information across the team or teams that will be involved in developing and executing your mobile strategy and help everyone remain focused on the big picture, and, where needed, the little picture as well. It also will help you figure out what’s possible logistically, for example, what you are able to execute internally and what you need to outsource, and what’s feasible from a cost standpoint.
Mapping out the path dependencies within your plan is important for another reason: It can help you identify potential roadblocks before it’s too late, and plan for the contingencies you need to put in place to ensure your plan will succeed. You don’t want a key part of your program to get derailed because you didn’t think ahead.
To keep track of time spent on each element, project managers will typically use a Gantt Chart (bar chart) and/or PERT Chart (flow chart).
The next stage after completing your technical feasibility, operational feasibility and schedule feasibility assessments is to conduct your economic feasibility and go-to-market feasibility studies. These will be covered in future articles.
This is the fourth part of the ClickZ ‘DNA of mobile-friendly web’ series.
Here are the others:
- Six mobile strategy questions
- How to identify your mobile audience
- Why prioritize mobile-friendly web
- Web apps: advantages of native apps in a web browser
- How to test the viability of your mobile project
Andy Favell is ClickZ columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor.
The traffic light image was adapted by Andy Favell from a Creative Commons image
A lot of cool stuff is happening with email today. As an email marketer doing your job day in and day out, ... read more
All restauranteurs have plenty to learn from a gastronomic tour of top chef’s mobile sites.