Outsourcing mobile dev - how to think about your app

How much does it cost to build an app? How long does it take to build an app? Well, it depends on several factors. Apps can be built for as little as a couple of thousand to dollars, or as much as hundreds of thousands of dollars. It all depends on what you want your app to accomplish. We have a created a framework to help you think through your app in some very concrete terms, which can help determine the cost and time to required to build the app.

Requirements v01 MA 9Mar2014.png

We look at this framework as the building blocks for an app. Like with any structure, building it requires setting a strong foundation. This requires having a good grasp of the platform(s) on which you'd like the app to be developed, knowing your localization and internationalization strategy, not leaving security to be an after thought, and having a good sense of which APIs - both internal and external - your app needs to integrate with. Once the foundation has been set you can move to building the core of your application. This involves having at least a feature level grasp of what your application will do. Finally, to maximize the value delivered by your app, you need to understand and implement your apps reporting & administrative needs and how you plan to support the app once it hits production. Let's take a closer look at each of these areas.

The Foundations:

Platform: Knowing which platforms your app needs to be built on is of paramount importance. The wrong decision here can mean the difference between a great app, and one that delivers extremely poor performance and generates little or even negative interest. Some of the key considerations here include:

  • iOS vs. Android vs. Others: This might seem like a pretty simple decision at first, but based on the demographic and region of the world you are targeting, going iOS first or Android first, is not a given. We were helping scope an app targeted towards the lower income market in the emerging world for which a simple text message based service made more sense than an extensive app. On the other hand for some apps to gain maximum virality you might have to go cross-platform from the get-go.
  • Native vs. mobile web - A few years ago HTML5 was all the rage. Today developers have begun to recognize the limitations of HTML5, and the pendulum has swung the other way. The right decision here though is not whats in vogue, but what makes sense for your app - perhaps the limitations of HTML5 are not an impediment for your app.
  • Develop native vs. using a mobile application development platform (MADP) - We will cover this top in a more in-depth manner in a future post, but at a minimum you need to know what the advantages of developing using a MADP platform vs. developing a native app are and why your development team is recommending one over the other. The comparison is usually made between the cost advantages of MADPs vs. the performance advantages of native, however in reality the comparison is rarely that straight forward.

Localization: This aspect of app development is usually not given much thought, and perhaps is as simple as starting off as an English-only app that needs to be deployed in the iTunes app store. However, what if you were an international airline carrier with passengers from all over the world? Suddenly, a seemingly simple decision requires at least some analysis to know which languages your apps needs to support and which countries app stores the app needs to be made available in.

Security: Like with localization, security is too often an after thought. Some very popular apps have taken security lightly and have seen it come back to bite them. Recently the Starbucks app, the most used mobile payments app in the US, was caught up in an embarrassing security breach when it was revealed that it was storing its customers' username, email address, and password in clear text on their mobile phone. Our recommendation is to not take security for granted from the get-go. Do not assume that your app developer will build your app to meet best practice security requirements. Be explicit about the security requirements you expect - particularly as it relates to encryption, authentication, and authentication information retrieval policies. You at least owe this much to your prospective users.

APIs: Today APIs are available for a variety of different popular external B2C applications in particular Facebook, Twitter, LinkedIn, etc., as well as B2B applications such as Salesforce. At a minimum, we recommend that project owners know which applications they need to access through their app and the feature(s) they expect to be able to provide to the end-user by enabling said access. "I'd like my application to connect to LinkedIn" is usually not very informative. "I'd like my application to connect to LinkedIn to be able to auto populate x, y, and z user profile fields" is a lot more useful.

The Core:

Features: Most of the better development teams today either completely or partially adhere to the agile development philosophy. In agile development, the primary unit of work at the team level moves away from a discussion of requirements to a discussion of user stories. These user stories are generally developed in conjunction with the development team and are too granular to invest too much time in up front. Our recommendation here is for you as the project owner to think one level up - at the level of features. 

Screen Shot 2014-03-09 at 3.54.39 PM.png

So what is the difference between a feature and a user story? Let's take the example of a recent that app we helped facilitate the development of that helps you find things to do based on your mood and your location. The ability to determine your location is a feature. However, your location can be determined based on your current coordinates, some future coordinates, or the neighborhood that you live or work in - each of these comprises a different user story. Knowing what can and cannot be done at the user-story level generally requires the guidance of the development team, and is best left to be determined in conjunction with the team.

The Accelerators:

Reporting: Why is reporting important? Shouldn't I be able to capture stats via the number of downloads and the rating that my app has received directly from the app store? That is correct, but that is not really enough information to determine what features within your app are being used, or in what conditions your app crashes, or how long it has been since a specific user has logged into your app, etc. Usually developing your app is just the first step towards attaining a greater goal, and it is impossible to predict whether or not you are making headway towards that greater goal without some deeper insight into how your users are using an app. We highly recommend thinking about what user activities and experiences you'd like to keep track of and accounting for those capabilities when developing your app. Again, like with security, don't take for granted that your development team has a good sense of what those capabilities need to be - it's your app, and you need to take ownership of it. These days, integrating reporting capabilities - even advanced ones - into your app usually doesn't require a ton of additional development effort, but it does require identifying and integrating with the right reporting tools made available by external providers (e.g., Flurry, App Annie, Google Analytics). Knowing which reporting tool to integrate with to deliver which capability is something you should defer to the development team on, but knowing which reporting capability is required in the first place is your responsibility as the project owner.

Admin: There are very few apps that require no administrative capabilities. Below are some common examples of admin capabilities that apps require:

  • Roles administration: Not all users are created equal. Some users might be considered super users and require special privileges associated to a role that they perform on your app - for example adding new stores or restaurants to a curated recommendation app. 
  • Content administration: Your app might be dealing with content submission from your users and you might want to feature or highlight certain pieces of content more than others. This might require content curation capabilities that need to be provided to you as a superuser, but not to every user.
  • Security administration: You might want to be able to change the security policies related to your app, for example the password strength requirements or how often passwords are set to expire. You might want to lock down certain users from your app until certain verification steps are complete. 

When working with an experienced development team, one of the first things they are likely to do is build user personas that are related to different user stories. This should help define the specific actions that you'd like different types of users, including admin users, to be able to perform. However, at a minimum we suggest giving some though to what constitutes an admin user and what features the admin user should be able to control.

Support: Apps don't upgrade themselves, and just because an app works close to perfectly in the beginning, it doesn't mean it will continue to do so into eternity. Apps can break for a variety of reasons ranging from OS upgrades, to API changes, to experiencing a heavier load than they have been tested against. All of these problems can generally be fixed, but not if you don't have the right support mechanism in place to help you. Most teams that develop an app might give you a 2-week or one month warranty window where they will support the app for break-fix type issues, but often you might need support for a longer than a month on app. Additionally, it is critical to know the different between break-fix and a new change. Adding a new capability to an app is not a break-fix issue, in technical terms it is considered a change request, and - depending on the complexity of the app - a change request can be more complex and expensive than developing the app itself. 

In summary, there are lots of things to consider when you go down the path of developing an app. Maybe your app is a use and discard marketing app for which many of the above considerations are an overkill, but even if that is the case it makes more sense to start with a more holistic framework like this and eliminate what you don't need, vs. start something bare and then realize two months into the project that there were several aspects of the app that had not been thought through. Spending and extra week or two researching some of the capabilities that your app needs to support is not a waste of time when you consider that not having those capabilities can easily cost you an extra couple of months or, in the worst case, your reputation.

Mobile app development - why wage arbitrage matters little!

Wage arbitrage has defined the IT services sector for over a decade. Companies in the US in particular, and high cost countries (HCC) in general, began to take notice of the Indian IT workforce starting in the late 90s when preparing for Y2K. In fact, like with many other process optimizations, it was GE under Jack Welch, that began the trend of outsourcing IT services to India as far back as 1991, which was the year that India began to open up its economy. That said it was the noughties when IT outsourcing really came into its own. It was the decade that saw Accenture and Deloitte swell from sub-50K person consulting companies, to 200K+ person outsourcing behemoths, with a majority of that workforce added in low cost countries (LCC), and India in particular. It was also the decade that saw spectacular rise of the Indian IT services sector, most prominently Infosys, Wipro, TCS, Cognizant, and - until its eventual accounting-scandal led demise - Satyam.

However the tide has started to turn. It's not so much that wage arbitrage opportunities have disappeared - in fact an argument can be made that arbitrage opportunities will remain well into the next decade, particularly between India and the US. However, as companies move from leveraging IT to drive internal efficiencies to leveraging IT to build new digital products and services, i.e. towards digitalization, the need for wage arbitrage becomes somewhat irrelevant. Let's consider why.

When you shouldn't offshore:

Consider the following digitalization scenario. You are a large automobile company that is looking to develop an augmented reality app for Google Glass. The app essentially digitalizes your driver manual, by overlaying information pertaining to a specific automobile component or feature simply by looking at it and activating voice commands. Now assume you are the executive within the large automobile company, whose organizations responsibility it is to deliver this app.  From the executives perspective, which do you reckon is the most important success criterion vis-a-vis this particular app are:

  • building the app for the lowest cost possible
  • building the app of the high quality possible

With consumer facing products that represent a brand, it is rarely the former. The goal is usually to build the highest quality app possible under some realistic cost-constraints. This is where mobile application development begins to differ from traditional enterprise application development. With mobile you can build some very very powerful applications, e.g. augmented reality or sensor based applications, with minimal back-end, organizational, or process-driven complexity. What does this lead to? A lower price point than traditional enterprise application development. Traditional enterprise application development generally fell into one of two categories:

  • customization of complex packaged applications like SAP, Siebel etc.
  • full blown customized applications

In either case, these applications generally required integration with a multitude of complex systems and some very esoteric technology skills to build out the application. Additionally, to build these traditional applications, an army of professional services consultants is generally required for everything from gathering business requirements, to change management (as generally these applications required a change in organizational behavior), to deployment and a transition to operations. It is not uncommon for these applications to cost north of $100M, with prices north of $1B to deliver in the case of the most complex transformative apps - think healthcare.gov 2.0 to be delivered by Accenture. At a $100M price point, wage arbitrage makes a lot of a sense - a $20M savings is pretty significant in almost any context - but the average mobile app costs under $250K. Here savings of even $100K are easily trumped by working with a more expensive team but one that can deliver a very high quality product and significantly greater business value.

When should you offshore:

Wage arbitrage is by no means over but, when it comes to mobile application development, building a product offshore is not by any means purely a price decision. It usually only makes sense in one of three conditions:

  • the offshore team is very good at what they do - and is worth offshoring to regardless of price.
  • the client is offshore and needs a team that works in the same time zone/city/region.
  • there are some pretty significant budget constraints, and the individual/company requiring the offshoring capability has experience in managing the offshore team.

As discussed in our blog post on the golden rules of outsourcing, if you are an entrepreneur or a marketer that has no experience in managing an outsourced team, then you should try to avoid outsourcing all together or else enlist the help of a trusted individual/team that has experience outsourcing to do most of the heavy lifting while you learn the ropes. This is quadruply true if you are considering outsourcing to an offshore team for the first time.

The golden rules of outsourcing

In previous posts, we have covered when to outsource and the development options to consider when outsourcing. In this post we are making the assumption that you've already decided to outsource. Also, this post, as is the case with most of our posts, is in regards to outsourcing software design and/or development, not outsourcing the development of a physical good. Once you've decided to outsource, our experience is that the three most important to rules to adhere to are as follows:

1) Don't outsource without experience - If you are outsourcing for the first time, then it's not a question of if you will make mistakes, it's a question of when you will make a mistake (and how expensive it will be). If you are an entrepreneur that has raised a small friends and family round (say sub $50K) and you are outsourcing application development for the first time, then it could mean ending up with a lemon of an app, having no recourse to upgrade the app from a lemon to even just a pomegranate, and sitting through a few embarrassing thanksgiving dinners over the next few years (Note: we have made the argument before that in the scenario that you are a startup tech company you should ideally be building the app in house, but we know that this is not always an option). If you are a marketer that has an idea for an app but have never outsourced a technology project before, it could mean your job. So what if you are outsourcing for the first time? Well, in that case try to utilize at least one of the following suggestions:

  • Use the help of someone that has experience outsourcing - If you are an entrepreneur this could be a friend or a family member that has worked in tech and has outsourced before. If you are a marketer working for a large organization try to leverage the help of a full-time or contract PM.
  • Outsource something non-core first - For example, if you are a marketer working for a large company then start by outsourcing an app whose development, if it blows up, won't cost you your job (and hope that you are right).
  • Work for someone that has experience outsourcing, and learn from them - This especially makes sense for folks that are looking to become professional PMs. It also works an entrepreneur learning the ropes prior to outsourcing the development of his/her own app.

2) Do your due diligence - This might seem a bit obvious, but the devil is in the details. It's probably easier to get this point across by providing some examples of what due diligence does not mean. In particular, due diligence is not:

  • Outsourcing to the first referral you get from a friend or colleague. If anything, this is just the starting point towards building your target list of potential outsourcers.
  • Interviewing the CEO, president, or sales representative of the company that you are outsourcing to - unless they are personally going to manage, design, or develop your project.
  • Being impressed by a client list that includes some of the worlds largest brands. Many of these brands are not the best at policing who uses their logo and in what context. Additionally, just because a team has built a two-page jingle app with a dancing Santa for PepsiCo, does not suddenly qualify you them to develop Snapchat.

So, what does a half way decent due diligence process look like? At a minimum, it should include:

  • Developing a list of "trusted" outsourcers through referrals or through your own organization's procurement group.
  • Interviewing as many of the key stakeholders as possible that will be responsible for delivery (i.e., not the sales people). This might only be the lead product or project manager in the case of a larger organization, or could mean everyone on the team (designer, developer, and PM) if its a relatively small organization.
  • Checking in on client references. The easy part is making the call, the harder part is doing the research to ensure that the reference being provided is legitimate (try to establish the legitimacy of the relationship through LinkedIn), and knowing what questions to ask (focus on their management practices in dealing with the client and not just on how brilliant the app that the outsourcer built turned out).

Now for a bit of self promotion: if you'd like to do better than the minimum in terms of due diligence, then you could always use our services.

3) Manage your outsourcer - Outsourcing is NEVER about delegating away your management responsibilities. Even if you are Fortune 50 company that has hired a firm like Accenture or Deloitte to manage your $100M CRM transformation, you will still have a small army of your own VPs, directors, and senior managers that oversee the work of the consulting firm's partners, associate partners, and senior managers. Now this might seem like overkill but, having worked on both sides of the equation, we can tell you that very often there is no other way. When it comes to outsourcing application development, it's much better to be known as a helicopter client than a UFO by your outsourcer - at least if you want what is delivered to match your expectations.

The best practices in terms of managing your outsourcer can (and mostly likely will) be a series of blog posts in itself, but at a high level it should include:

  • Daily calls or scrum sessions to provide the necessary feedback, and to keep tabs on everyday activities.
  • Helping your outsourcer mitigate risks and manage issues that arise. Please note, these are not one and the same - an issue is a risk that has been realized, and if something becomes an issue without ever being a risk, then that is quite often the sign of poor project management.
  • Having a transition plan.  Outsourcing app development has a finite time bound, at some point an internal team or a different outsourcer will take over the project. If you haven't thought about what that transition plan will look like once project execution comes to an end, then you might be in for some rude surprises.

Note, that there are no silver bullets to outsourcing, but neither is it evil like some people make it sound. In fact, as we have pointed out before, in many cases it is the optimal operating model. As with anything else that you do, you get better at it with experience.

Enterprise Sponsored Consumer Apps - Development Options

Over the years, the word outsourcing has developed a very negative connotation. However, the reality is that in many scenarios companies do have to consider outsourcing product development. In this blog we examine the various development options available to companies when building consumer facing mobile products. You can use this as a guide to help you think through options that you should consider when developing a new product.

Consumer facing apps within an enterprise are generally sponsored by one of three entities - product or digital, sales and marketing, or customer service. In the table below we look at the type of apps produced by each of these entities, and some examples for each type of app.

 

Sponsoring Entity Description Examples
Product  Core product or service being offered is  digital  Bloomberg for iPadPayPal HereNike+
Sales and Marketing  Application helps drive marketing  campaigns, or maximize sales Iron Man 3 - The Official Game ,Ikea CatalogCoca-Cola Freestyle
Customer Service  Application helps improve customer service  and experience SQ Mobile, Hilton HHonors

I next combined this with the hiring internally vs. outsourcing development framework that I put forth all the way back in our second blog post

Screen Shot 2013-09-29 at 3.51.27 PM.png

The key idea put forth there was that unless you are an information technology company and building your core product, outsourcing development should always be on the table. Based on this I looked at the app examples above, and at the options one should have considered when developing these apps.

Example Company Type Product Type Optimal Strategy
Bloomberg for iPad Finance/Tech Core Develop In--house
PayPal Here Finance/Tech Core Develop In-house
Nike+ Fashion/Apparel & Accesories Core It depends
Iron Man 3 - The Official Game Media & Entertainment/Various Non-Core Outsource
Ikea Catalog Retail/Furniture Non-Core Outsource
Coca-Cola Freestyle CPG/Food & Beverage Non-Core Outsource
SQ Mobile Transportation/Airline Core It depends
Hilton HHonors Accommodation/Hotel & Lodging Core It depends

However, outsourcing is a very broad term, and there are a plethora options to consider when looking to outsource. Below are the primary and secondary options available for the examples mentioned above in scenarios where outsourcing should have been in play.

Example Full Service SI*/Consulting Full Service
Agency
Boutique Consulting/Industry Boutique Consulting/Mobile Licensed
Development
Nike+      
Iron Man 3      
Ikea Catalog      
Coca-Cola Freestyle      
SQ Mobile      
Hilton HHonors      
* = Systems Integrator;  - Primary Option;  ✔ = Secondary Option

Lets consider the rationale for each of the selections above: 

  •  Nike+: Here the product is part of a core product or service that company is providing, hence if the company has the ability to develop it in-house then the company should. That said, the development of the app itself could be outsourced to a team that specializes in mobile product development. Alternately, a full service agency can be used, however the company might or might not require the additional services that a full service agency offers, and hence might end up paying a higher margin than is required.
  • Iron Man 3 - The Official Game: The general industry norm here is to license out game development to external entities, which is what Marvel did here, and it remains the recommended strategy. Outside of this, engaging with a company that specializes in game development for media companies can also be a potential option. 
  • Ikea Catalog: A catalog is probably something that the company releases on a periodic (quarterly, semi-annual or annual) basis, and hence the company should have standard templates and forms that it can use to develop the digital collateral internally, however in the case of this particular app, Ikea was rolling out an augmented reality feature. They could have considered a full-service marketing agency for this, but given the degree of specialization required, a mobile development team that specializes in augmented reality should have been the primary option. 
  • Coca-Cola Freestyle: This app was primarily built to support the discovery of Coke's new freestyle machines. Releasing this app should have been part of a wider product marketing campaign, and hence should have been managed by the full service agency responsible for the campaign. This full-service agency would then have the option of developing the application internally, or outsourcing it to a specialized mobile product development team.
  •  SQ Mobile and HIlton HHonors: In both these case the apps have some very deep integration into the back end systems, including hotel and airline reservation systems, real-time flight scheduling systems, CRM systems, and ERP systems. This type of work is best handled internally or by a full-service Systems Integrator (SI), or a boutique consulting firm that specializes in that particular industry. The development of the front end of the mobile app itself could very well have then been outsourced to a mobile product development team to maximize the UX/UI and development expertise offered by the specialized mobile product development team.

In conclusion, while the decision to build internally vs. to outsource is an important one, it is equally as important to consider the options available when outsourcing and to choose the option that makes most sense for a given scenario. 

 

How to measure and manage project success

In a recent article published by McKinsey, the authors talk about how application development spend as a percentage of total corporate IT investment increased from 32% in 1990 to almost 60% in 2011. The article then talks about how few organizations have the means of measuring the output of their application development projects, and recommends an output metric called Use-case points (UCPs) that can then be used to measure productivity of IT projects. 

I think the post is a bit confusing because in its introduction it mixes two related, but separate, concepts (i.e. measuring team productivity vs. measuring project output). The confusion arises primarily from the use of the word "output" as it relates to projects. The output of an application development project is very different from the output of an application development team. Why is this? Because project output should always be tied to metrics that measure one of the following:

  • Brand awareness
  • Revenue
  • Cost 
  • Risk

A project that does not improve any of the above should not be undertaken in the first place - whether this be a software development project or building an entirely new line of business. Additionally, if a project is undertaken that addresses one or more of these objectives, then the output of the project should be measured against the metrics tied to these objectives. These metrics are usually very tangible and can range from an increase in the number of likes on Facebook, to an increase in revenue per customer, to a reduction in operational churn, or to the minimization of downtime.

Critically, the output of an application development team (measured in UCPs) can be stellar, but the output of the project itself can be abysmal. This can happen due to any number of reasons, not the least of which include:

  • Scope risk - if the scope of the project is continuously shifting, then even the most productive team will find it hard to be successful. Managing scope usually ends up being the single most important responsibility of a project manager, and requires strong leadership as well as executive support and credibility (which usually comes with experience).
  • Cross team execution risk - application development projects rarely occur in a silo. This is especially true in larger companies, where multiple teams both from within and outside an organization are generally involved. It's also rare that every team involved in the project buys into the project's output objectives, and may, in fact, openly oppose those objectives. Of the 7 reasons listed by IBM as to why projects fail, the top 5 are all, in some way, related to the risks that arise from cross team execution. In this case as well, the role of a strong project manager and executive leadership support of the project manager can prove decisive.
  • Market risk - this is critical in software development leading to the launch of a new product or service category. Apple's Newton PDA was released a decade before the PalmPilot, and two decades before the iPhone. The market was just not ready for it. One way of minimizing this risk is by taking the lean start up approach and iterating through ideas. This doesn't necessarily change the market appetite for a product or service, but it gives you a good sense of what the market is willing to accept at a given point in time.

While I agree that measuring the output of an application development team is important (though I am not in 100% agreement with the methods suggested; more on this in a later post), the output of an application development project should be tied to metrics that drive business objectives.