Showing posts with label budget. Show all posts
Showing posts with label budget. Show all posts

Friday, July 29, 2016

What Will My Mobile App Cost?

** This post inspired a white paper -- download it here. **

There’s one thing about custom mobile development that everyone wants to know: What will my mobile app cost?

Unfortunately, there is no simple formula from which to reliably derive an estimate—mobile application development is a distinctly complex undertaking where myriad decision points impact cost.

However, based on our experiences developing a variety of mobile apps for a wide cross-section of companies and industries, we believe that—while there’s no magic eight-ball for estimation—there are seven starting strategic perspectives that will help you factor in key cost considerations.

#1 – There’s No Free Lunch (Expect to Invest)
Like any other significant upgrade to your business capabilities, building an effective enterprise mobile app will not be cheap.  Yes, you can get an agency to build you a beautiful mobile app—but it will be built for a three-month campaign, not architected for enterprise integration or a product lifecycle.  Yes, you may get some recent college grads in a garage to knock out a functional app, but it’s unlikely these guys will be 22 year-old versions of Steve Jobs or Bill Gates.  Finally, yes, you can get some offshore shop to build an app; however, it’s hit or miss whether these developers will truly understand cultural context (or you), properly implement security or securely integrate your back office—and they might even sell the secret sauce in your code to a competitor.

Takeaway:  Building a mobile asset of true value will require a commensurate investment of time and effort.  There are no shortcuts that can sustain your investment given the chaotic nature of the mobile space.

#2 – It’s a Product, not a Project (Lifecycle Plan)
If you’re looking at developing a mobile app as checking a box—“Hey, look we have an app!”—you might as well burn your money.  

The reality is that successful mobile apps (where success is measured as driving business outcomes) are planned and managed as products, not projects.  Thinking about your mobile initiative as a product with a lifecycle is much different—and critical to your success—than planning for a project!  (See also Mobile Project vs. Mobile Product)

From a cost perspective, the implications of product lifecycle planning include:
  • Establishing a product roadmap to create progressive value.  Expect that you will incrementally implement product features over time, most likely starting with a “minimum viable product” (MVP) release (see also Does an MVP Release Make Sense for Your Mobile Initiative?).
  • Establishing a product release plan with a cadence to support a “test and learn” approach.  Your ideal release cadence will be dependent on many factors.  A few principles are in play:
    • You will make mistakes of all sorts.  No one gets it 100% right the first time or can afford to rest on their laurels.  Users will generally forgive mistakes that are quickly addressed in a new release.
    • It’s much more effective to try a few new features that you can discretely evaluate than to roll out a ton of new features at once.  This implies frequent, small releases.
    • The device landscape will change rapidly.  New operating systems versions, new devices, security issues, as well as other changes will require you to update your app in order to remain operationally viable.  (Yes, you will be subject to less flux due to these factors in a private enterprise mobile app where you control devices and deployment.)
    • The competitive and market landscape will change rapidly.  Mobile is a key point of both competitive differentiation and innovation.  Expect that both competitive pressures and technical innovations will require you to regularly re-prioritize your product roadmap and release plans.
  • Identifying and empowering a product owner.  This person must have the business and technical acumen—as well as the authority—to quickly make product decisions to direct the product development team’s work.  Ideally, they have product P&L responsibility and report in to a product management organization or business unit, not IT.
  • Building and maintaining a product development team.  Teams that function at the highest levels of velocity and quality tend to be composed of long-term resources, especially in key leadership roles.  Assume that success will require velocity (ability to frequently release product updates) and quality, both in terms of user experience and software quality attributes such as reliability, performance, and scalability.
Takeaway: Plan to invest in building a product development team that will remain significantly intact over the planned product’s lifecycle.

#3 – Good Help is Hard to Find (Expertise: People and Partners)
Now that you’re bringing together a product development team, what types of expertise are going to be required?  While precise skills are technology-dependent, at minimum you will need core team members with the following skills:
  • Product Owner / Product Manager with mobile product management skills (see also Magenic Technologies' Product Owner or Product Manager?)
  • Mobile Architect with mobile application architecture and enterprise integration skills
  • Mobile Developers with specific experience and expertise on your chosen development platform and technology stack, including the ability to integrate supporting systems
  • Mobile User Experience Designers who understand mobile devices, mobile interaction design, your chosen platform’s design guidelines, and mobile design/prototyping tools
  • Mobile QA Engineers who with deep understanding of mobile device functionality, context and interaction models, mobile test strategies and tools, and an ability to test data at the code level
In addition to the core product development team, there may be also be extended team members from customer service, marketing, analytics/BI, back office systems’ IT (and this may be a significant need), operations, legal, security/compliance or other groups, depending on your industry and focus.

A major decision at this point is determining whether to make a long-term investment in full in-house mobile expertise, bring in staff augmentation resources to form a blended team, or work with partners to outsource development on a long-term basis (or until you reach a point where it makes sense to bring development in house).  In any case, locating, attracting and hiring resources with the right skills and experience—whether FT hires or through a partner—is a challenging task with many long-term implications.  (See also Magenic Technologies’ Are You Ready to Bring in a Partner to Create a Mobile App? and Best-in-Class Consultants or Learning on Your Dime?)

All staffing models can work; however, keep in mind that it will prove wise to work with mobile experts when building your mobile app’s foundational releases or tackling a complex initiative.

Takeaway:  A mobile product development team is composed of many specifically-skilled resources, many of whom are in short supply.  Plan to invest the time and funding in identifying and composing the best team you can find—it will be a top indicator of impending failure or success.

#4 – There’s a New Delivery Ecosystem in Town (Processes, Tools, and Infrastructure)

Delivery Methodology as Cost/Risk Control
As you’re assembling your product delivery team understand that this team can’t work efficiently or mitigate your considerable risks using a traditional waterfall-type delivery methodology.  The timeline from initiation to delivery is too long for a big bang release, there’s little room for re-prioritization, and your measurement of success will be totally different—you’re shooting for a business outcome, not merely coming in on schedule and within budget.  From a cost perspective, plan to embrace an Agile delivery methodology to reduce risks, increase flexibility, and best manage spend.

Mobile-Specific Tools Required
If you hire internal resources, plan also to invest in mobile-specific product development tools for developers, designers, and quality assurance engineers.  Additionally, you may need to also invest in enterprise mobile management (MDM/MAM) tools if you’re also investing in devices and/or using a private enterprise app store.  Furthermore, you may also need mobile analytics tools, mobile marketing tools—the list can go on.
Many mobile tools now are cloud-based and relatively inexpensive.  That said, licensing or usage-based fees can add up.  If you work with a partner and plan to bring development in house in the future, make sure that you own all tool licensing and subscriptions.

Infrastructure:  The Long Pole in the Tent
Believe it or not, updating your back office systems’ ability to support mobile applications may be your largest expense.  The integration architecture built to support web- or desktop client-based systems is poorly suited for serving mobile devices communicating over fragile (or offline) data connections with very high response, performance and scalability expectations.

In addition, your mobile app may require cloud-based services such as AWS, Azure, or Google Cloud—you will want to understand the various pricing models and available services.

In a recent interview with Diginomica, Kevin Benedict sums up the issue well:
“What we’re learning is that creating the world’s coolest mobile app isn’t going to do any good if your infrastructure can’t support real time interactions with your ERPs, and other business solutions and processes on the back end.  Mobile applications are driving this digital transformation back into the enterprise.  CIOs are saying, ‘We have to do this in order to be competitive, because more and more of our business is being transacted through our mobile applications.’”
Takeaway:  New delivery processes, mobile-specific tooling, and potentially extensive (and expensive) infrastructure updates will be needed.  Existing CapEx/OpEx financial cycles will be challenged to support an agile delivery team.  Significant CapEx—and leading time to implement—may be required to update back office infrastructure.

#5 – Expect Disruption (Competitive, Technology, and Market Pressures)
The harsh reality of the mobile world is that you can execute with all the prior strategic perspectives in mind and still be blindsided by an unexpected disruption or a competitive innovation that leaves you questioning your product’s enduring value proposition.  While this is also true of other channels, in our experience the innovation cycle is much more rapid and compressed in the mobile apps space.

From a financial perspective, these unexpected events create a variety of impacts from the relatively simple, such as supporting a new device, to the complex—perhaps a competitor is now driving his mobile app experience using artificial intelligence (AI).

Takeaway:  Plan to be financially flexible in order to quickly respond to the market.  Again, your customers will forgive you for falling momentarily behind if you establish a track record of responsiveness.  Better yet, plan to make the investment to be a mobile leader!

#6 – It Takes a Village (Digital Transformation)
As indicated earlier, to work most effectively toward enabling your mobile app’s capabilities to drive business outcomes you will need to form an extended team and socialize awareness so that all work in harmony to meet the same objectives.  

For example, if your industry is retail and your app is customer facing, what do your sales associates know about your mobile app?  Are there any promos in the store—or in promotional media—to advertise the app and its benefits?  Is the app integrated with your loyalty program?  What about integration with social media or coupon apps?  Does your web site highlight the app?  What happens if a customer calls Customer Service with a question about the app?  Is there an operational opportunity to use the app to significantly improve customer satisfaction such as through Buy Online / Pickup in Store?

Whatever your industry, know that you will need to identify and rally all customer (this includes internal users!) touch points in the organization to create a cohesive and consistent user experience.

Takeaway:  Plan to make the necessary investments of time and effort to raise internal awareness, make supporting roles and responsibilities clear, providing training or change management guidance, and communicate product plans and progress.

#7 – Innovate and Disrupt (Separate from the Field)
Have you considered that simply a having a cool mobile app won’t be the engine to drive targeted business outcomes?  Maybe everyone in your industry segment already has similar mobile apps.  Now what?  Can you afford to be a “me too” entry?

Depending on your market position and competitive pressures, you may need to consider investing in the necessary research to create an innovative new way of doing business that leverages customers’ “mobile moments” (see also Capturing the Mobile Moment) and fundamentally alters the value chain.  Innovation is typically an expensive proposition—think about the capital required to launch AirBnB or Uber.  Note that their mobile apps are only the tip of the iceberg in terms of technology and cost.

Takeaway:  Consider the possibility that a mobile app may only be a small part of an innovative streamlining of your industry’s existing value chain.  Creating something of this magnitude will require a full range of investment, not just a mobile app.

Closing Thoughts
Embarking on a mobile product journey is exciting but also full of risks, not least of which is being unprepared to make the necessary financial moves to ensure your initial investment is not lost. Making sure your financial bases are covered at the outset will go a long way to positioning your initiative for success.

Thursday, July 28, 2016

Mobile Project vs. Mobile Product

Are you thinking about starting a “mobile project” to build an app?  Think again—your plan may have a high probability of failure.

Why?  Depending on the characteristics of your initiative, planning to build a “mobile product” will be a much more effective long-term approach to meeting business objectives than a project.

What’s the Difference?
First of all, what’s the difference between a project and a product approach?  Isn’t it just semantics?  Actually, they are quite different.


While there is some overlap between project- and product-based approaches, the key difference is that a project is typically focused on delivery of a single mobile app release while a product is focused on achieving business outcomes throughout a product lifecycle spanning multiple mobile app releases.

But that’s not all.  Here’s a summary of a number of significant differences between project and product mindsets (credits to Marty Cagan and Moonshot Horizon):







Why a Product Approach Matters for Mobile
Wouldn’t the comparisons above apply to any application development initiative?  Unquestionably, yes. So, why the big deal about taking a product approach to mobile?
Mobile initiatives are subject to a unique set of vectors that impact success, including:
  • Users’ Experience Expectations.  You’re not just competing with competitors’ latest features; you’re competing with well-designed games, social media, music, video and other apps for your users’ eyeballs—and brand estimation.  Frequent updates required!
  • Stakeholder/Sponsor Expectations.  They want their app to do that new thing that Instagram does.  How hard would that be?  Popular apps are often updated with the latest capabilities inside of monthly—nobody wants a stale app.
  • Fluid Technology Landscape.  New devices, new OS versions with new capabilities, security or privacy issues, integration changes, new tools, regulations, etc.   The ground is constantly shifting.  Keep up or risk quick irrelevance.  Or worse, a security/privacy event.
  • Data.  User ratings/reviews, user event data, application crash data, customer service information, etc.—not to mention business KPIs—all must be constantly be monitored and analyzed to ensure key objectives are being met.  Data must also be analyzed to surface insights that will drive and prioritize changes to the product.
So, what are some of the risks in treating your mobile initiative as a project rather than product?  
  • Missed Opportunities/Lack of Innovation.  Some of the best-loved mobile apps today started as apps of a different color; that is, they made major pivots or innovated based on user feedback.  Here are two classic examples:
    • The founders of SnapChat struggled to attract users, but it started going viral in high schools.  This discovery led to the shift in focus in customer segment.  Today SnapChat is ranked as the #7 free app in the Apple App Store.
    • Burbn started as a mashup of Foursquare and Mafia Wars that let you check in to locations, earn points for hanging out with friends, post pictures, and so on. User data indicated that photos was the real opportunity so the team cut everything except for its photo, comment and like capabilities.  What remained was Instagram, the #11 free app in the Apple App Store.
By the way, did you know that Android was originally conceived as an operating system for cameras?
  • Wasted Investment.  Analysts believe that mobile apps typically require four major version releases—and typically a pivot—before they begin to deliver on business objectives.  Have you looked at a successful app’s App Store or Google Play release log?  It’s unlikely you will achieve lasting success on the first try.  Alas, your project budget was all spent on the first release.
  • Brand Injury.  Whether a mobile app is customer-facing or internal, users will judge your brand based on a wide range of factors such as effectively addressing their mobile needs (or needs not addressed), quality of user experience, device and OS support—and much more.  It’s highly unlikely you will achieve the right balance of these factors the first time around.  Don’t worry; app store ratings and reviews, social media, and blogs will all happily share the story.
  • Customer Satisfaction.  Mobile app users are often much more annoyed by a failure to improve (by releasing an updated app) than they are by an initial effort that falls short and is then improved based on feedback.  When you approach mobile as a project, you’re telling your users that their feedback is not important.
If a typical project is delivered on time, within budget and meets key requirements, we happily declare victory—no matter what may happen next.  However, achieving ongoing success with a mobile app clearly requires a much more complex, iterative and nimble journey.

How to Evaluate Your Mobile Initiative
Do all mobile initiatives need to take a product approach in order to be successful?  For the vast majority of mobile apps the answer is unequivocally Yes!  But there can be certain sets of circumstances where a project approach may suffice.

Here’s a few simple criteria for evaluating your mobile initiative:

Might be a Project if…

Might be a Product if…
  • Corporate-supplied and managed device or only a single device is targeted
  • No vision for future functionality
  • Private distribution (MAM)
  • Not customer-facing (B2C or B2B)
  • Not strategic for the business
  • Success will not be measured
  • Will be owned and managed by IT
  • Static, well understood environment
  • Very small user group

  • Customer- or partner-facing
  • BYOD/CYOD, public device support
  • Public app store distribution
  • Strategic (e.g., competitive differentiator) or new capability
  • Supports or enables key business objectives
  • Product owner and roadmap focused on customers’ needs
  • Data will be collected, analyzed
  • Investment will be measured; KPIs
  • Dynamic environment
  • Back office/third party integration

Each of the product characteristics indicate that change is highly likely.  Consequently, if you find that your mobile initiative has any of the characteristics of a product, a product-oriented approach is going to be the best long-term approach.

However, even if your initiative has several of the more static characteristics of a project, it would still be advisable to think through the anticipated mobile capability lifecycle.  What might be necessary in six months or a year from now?  The mobile app’s overall context may prove to be more dynamic over time than you think.

Closing Thoughts
Clearly there are many persuasive reasons for organizations to take a product-oriented approach to developing and managing their mobile investments.  And consequential pitfalls for those who don’t!


Why Your Mobile Initiative Isn’t Getting Funded

One of the biggest challenges in starting your company’s mobile journey is getting funding.  Potential financial sponsors are often positioned at one of two extremes.  

On one hand, some sponsors seriously underestimate the strategy, expertise, and overall effort that goes into building mobile apps and supporting a successful mobile program.  These sponsors tend to make a number of faulty assumptions, often including the following:
  • We don’t need a strategy—let’s just start with my pet project idea and see what happens
  • We have people internally who can develop applications, so they should be able to do mobile apps, too
  • It’s a small screen—how much effort can it take?
At the other end of the spectrum, potential sponsors will find every reason why now is not the right time to tackle mobile enablement.  They will typically bring up a variety of valid—but surmountable—concerns that, if not effectively addressed, will kill your mobile initiative.  Here are some common examples:
  • Fear of the fluid technology environment and potentially wasted investment
  • Security and compliance risks
  • Existing technical debt, question ability to integrate legacy back office systems
In addition to the challenges presented by both types of sponsors, you may be making your own missteps in presenting a case for mobile investment.
  • Lack of focus on producing ROI by impacting key KPIs 
  • Lack of an innovative, compelling story—you’re just “mobilizing” existing processes
  • Unrealistic perspective on mobile TCO
  • Selecting a set of mobile technologies before having a solid grip on business objectives
Clearly, there are many pitfalls to getting your mobile initiative off the ground and securing funding.

Here are several ways you can address your financial sponsors’ assumptions and fears—and look smart in the process:

Start with Strategy
Do an assessment of the organization’s needs as a whole.  Identify mobile opportunities in terms of mobile moments.  Then prioritize based on business value, feasibility, risk, differentiation, opportunity for innovation, and so on.  Make sure to identify KPIs that impact the business for each potential mobile product.

This is often a good time to invest in a few proofs of concept.  Target opportunities to translate a series of mobile moments into an app vignette, which can be as simple as a visual prototype (no code) or a skeleton app (coded)—both of which must run on a mobile device.  

The key in either case is to create an amazing user experience that you can socialize to enable stakeholders to envision success.  Alternately, if you have technology risks, you may wish to focus on proofs of concept that smooth the way forward by addressing technical barriers.

Create Product Roadmaps and a Supporting Technology Roadmap
Think of your mobile opportunities as products, not projects.  Each product needs to have a roadmap that maps out evolving business value.  Look for opportunities to innovate, differentiate, and positively disrupt existing inefficient processes.  Each product roadmap needs to support a clear, compelling story of how investment is strategically aligned with overall digital strategy and business objectives.

Create technology roadmaps that support product planning.  Don’t make the mistake of selecting a technology stack before business objectives are clear!  Also be cognizant of the reality that user experience design for each product may also influence technology selection.

Technology road mapping is also a perfect time to align needed infrastructure upgrades with creation of new mobile products that will deliver clear value—don’t miss this opportunity.

Plan for Delivery
Become familiar with the key workflows and expert resources required to operate an effective mobile delivery organization.  Understand probable release cadence, deployment and all the factors that drive it.  Don’t hesitate to bring in outside experts to provide guidance both for delivery process and technology selection.

Be realistic in estimating TCO.  Identify which resources and skill sets may be staffed internally versus relying on partners.  Determine if your delivery strategy will be reliant on partners long term or needs to include a knowledge transfer plan to bring key components or roles in house over time.

How will product maintenance and support be prioritized?  Who will users call for help?  Who will be responsible for training support resources?

Don’t Forget Governance
Once the mobile journey is begun users’ expectations—already high--will quickly rise.  Plan how you will approach maturing your organization’s ability to manage a portfolio of mobile products.  From best practices to standard architectures to ensuring leverage and alignment with business objectives, position your mobile governance model to enable mobile teams, not create barriers.

Closing Thoughts
The secret to getting your mobile initiative funded is to align with business objectives, demonstrate a value-driven plan based on product roadmaps, plan for operational success, and put in place an appropriate governance model to sustain success.