How to assess the feasibility of your mobile project
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.
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:
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.
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:
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:
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.
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.
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:
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.
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:
Andy Favell is ClickZ columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor.