My talk around the reasons mobile projects fail and what you can do to prevent some of the pitfalls. This talk doesn't talk about code or deep dive technical development - but about the "other" problems that can befall a mobile project - especially in large organizations.

3. Why do mobile projects fail?
!
!
Matthew Langham
!
Indiginox GmbH
Warning: There is no source code in this presentation!

4. STILL
Why do mobile projects fail?
!
Matthew Langham
!
Indiginox GmbH
Warning: There is no source code in this presentation!

5. Short answer
Because it’s harder than it looks!

6. !
!
!
http://www.flickr.com/photos/cameronparkins/3220496811/
Thanks and enjoy the beers coffee!

7. Matthew Langham
• Co-Founder - Indiginox GmbH
• Independent enterprise consultant for Mobile strategies
• Technical project management for Mobile operator and
corporate customers
• Visiting Lecturer for "Mobile Engineering” - University of
Applied Sciences - Münster
• Author & Speaker
• matthew.langham@indiginox.com
• @silentpenguin

8. Goals of this talk
• Pin needles into the map of mobile project
development to provide you with some “focus
points” for your own projects
• Provide some insight into things that can go wrong
and how to improve them
• Yes, some of it is “trivial” and not just mobile
related
• But all the following has really happened (to me) in a mobile
project

9. So, why do mobile projects fail?
• Of course - for the same reasons other IT
projects fail ...
• Too little stakeholder involvement
• Poor or unrealistic requirements
• Unrealistic time scales
• Scope creep over the development period
• No management of change control
• Quality assurance

10. But often ..
“No matter what they tell you, it's always
a people problem.”
Gerald Weinberg (The secrets of consulting)

11. Why mobile projects don’t usually
fail
Because of bugs in the app
These have been identified and can be fixed

12. Additional challenges
• Challenges affect the different phases of
a mobile project
• Conception
• Finding resources
• Implementation & Testing
• Deployment
• Business

13. Eric Schmidt (Google) said: “Mobile
First!”
!
I say: “Think First!”

14. The biggest mistakes are made before a
line of code is written

15. Conception phase
http://www.flickr.com/photos/mukluk/174688752

16. Do you know what you’re doing?
• Starting the project without understanding what you are
dealing with can be deadly
• “We’ve bought 500 iPads - and now we need an app!”
• “We need a native app for iPhone, iPad, Android, BlackBerry - oh
- and Windows Phone”
• “Have you thought about a cross-platform Web app?”
• “huh, what’s that?”
• “Our budget is xyz € and we need two apps that work on both iOS
and Android finished by the 1st of December - can you do it? We
haven’t completed the requirements list but we know someone
who knows someone who did a prototype in 5 days”

17. No, seriously, do you really know
what you are doing?
• Is (some of) the core functionality even allowed in the
country you want to roll-out in?
• Legal implications such as data-protection, sharing of media, allowed
content etc.
• Is (some of) the core functionality even possible on one of
the platforms you are targeting?
• What are your key differentiators?
• Are you sure you aren’t just building a “me too” app?
• Have you asked your users what they want? Maybe you just
need to make your Web-site mobile-ready?

18. Are you sure?
• Remember - if you are working in the mobile
space then you are probably not representative
• Use-cases
• Devices (shiny and new)
• Operating system
• The newest and the bravest
• Networks
• LTE vs. 3G vs. 2G

19. Are you sure?
• Functional requirements from people who don’t
understand the technology
• “Build a mobile HTML 5 widget game that is just like ‘Need for
Speed’”
• “Build an Android Facebook home-screen widget for this low cost
device that is just as fast as the native app on my high-end device”
• “The key proposition of the iOS app is to back up data in the
background”
• That was before iOS 7
• “I want my App store to launch with 1.000 Apps!”

20. How much time do you have?
• Typical way a project is defined in a large corporation
• Product Management / UE
• “We want an app that provides roughly this functionality. We haven’t actually thought things
through yet but you get the idea - right?”
• “We’ll start working on the requirements right away and get the wireframes done. Shouldn’t take
long.”
• “Oh, by the way, the release date is in 14 weeks, that’s plenty of time for you to develop it.”
• QA
• “Well, we will need 4 weeks to do the testing cycles at the end of the project. Lots of countries,
different networks - that takes time”
• In the end it took 6 weeks for the requirements to be defined which
left exactly 4 weeks for the implementation

21. Pro-Tip: Never trust someone who wants
to dictate a project’s deadline and scope
at the same time

22. Requirements documentation
• Wireframes
• Requirements document
• Use-Cases
• Which tool?
• Jira, Confluence, Word, something else
• However you decide to document your requirements
• Make it easy for the developer to understand what you want
• Do not link things together (e.g. Jira issues pointing to Confluence pages that point
to Sharepoint where the UE spec is stored)
• Developers won’t read pass the first page
• Don’t change things silently without informing the development team

23. Silent requirements
• Silent requirements are those
discussed informally in meetings or at
the water-cooler
• Rarely documented
• No-one is able to remember them a few months later
• They will come back to bite you

24. Change Management
• In long-running mobile projects changes will happen
(you had better be prepared)
• New versions of the operating system
• New devices
• New “ideas” / Hurdles for implementing old ideas
• Team fluctuation
• Establish a change management process as early on
as possible and make sure the implications of
changes are clearly communicated

25. Are you being over-ambitious?
• Way too much work is done before sanity checking
• Defining a scope for the version that is way too large to be
implemented by the team
• Defining functionality that cannot be supported by the
platform you are targeting
• Defining, specifying and designing the client before
checking if the needed backend APIs are actually available
• Yes, this really happens :(
• Iterate!

26. The challenge
How can we educate all project stakeholders
so that they know enough about the mobile
technology to make informed decisions?

27. The perception challenge

28. Perceptions
“The Product Owner has no idea what the product
should be doing and he doesn‘t understand how
difficult it is to do all that on Android”
!
!
“The developer doesn‘t share my vision for the product
and he isn‘t providing me with alternatives or solutions“

29. Self-Perception
Self-perception of a developer can be either:
!
Overcautious:
Won‘t change anything without spending a week looking at
the code and complaining that it really is too difficult to touch
!
Over-enthusiastic:
!
“I want to change A to B“
“Are you sure changing to B won‘t cause side-effects?“
“Absolutely“
!
Then spends following week fixing side-effects of changing to “B“

30. Communication
Repeat after me: “GitHub is not a communications tool”
!
Too many discussions carried out via commit messages
!
And neither is Skype!
!
If you are sitting 5 Meters away from the other person

31. Communication
Getting developers to actually TALK to each other is
the single most important thing you can do to improve
the development project
!
Regular standups can help
If you are the project manager then look-out for the
tell-tale signs of bad communication

32. Communication
Be careful when mixing developers and
product managers into the same meeting
When a developer says something is “unstable”
he may not mean what the manager thinks he
means

33. Improvements
• Make sure the product manager actually
installs the app that’s being developed for him
• Make sure the developers understand why
certain features need to be added
• Listen to feedback from your developers when
conceiving the product - they know the
platform

34. Improvements
• Arrange regular meetings between product owners and
developers
• e.g. Sprint Reviews
• Don’t just send out an invite to the daily standup and be done with
it
• Certain people just don’t understand why they should attend and think it isn’t
worth their time. Most often they will only attend at the beginning or when
things go pear-shaped
• Make sure all parties understand the “cost” of changing something
during development
• Starting out with an iPad app and then deciding you want it on iPhone as well

35. http://en.wikipedia.org/wiki/File:Handshake_(Workshop_Cologne_%2706).jpeg

36. Save the date!

37. Implications
• A day or so later …
• “Does our app run on iOS 8?”
• “Can we use the new functions that were shown
at WWDC yesterday?”
• “Can I see our app running on Android ‘L’ ?”
• “Please provide an estimate on the effort to adapt
our app to use ‘Material Design’ by COB
tomorrow”

38. Examples

39. Examples

40. Prevention tactics
• As soon as possible after the “event”
• Send out an email to major stakeholders outlining what was shown (relevant
for the app) and what areas need to be evaluated
• Install a pre-release version of the OS and run the app on it to find any major
issues
• Note that in many cases the beta version of an OS will improve over time fixing issues you may see in the first
version (looking at you Apple)
• Work with QA to “contain” any damage reports - i.e. you don’t
want this to happen:
• QA installs first beta of iOS 8, tests app and then sends out an email to
stakeholders outlining all the crashes and problems
• The perception will be that these are app issues (!)

41. Technology “ripening”
• Operating systems for mobile devices are often
released too early
• Very short release cycles during device and system development
• Often several times a week
• Functionality comes and goes depending on the release
• “..and the critical iOS 7.0.6 update just completely bricked my
iPad. Awesome.” - @parislemon (28.02.2014)
!
• Trivia question - how many Android versions were released in
2013?

42. Android in 2013 - 6 versions
• 4.2.2 (11.02.2013)
• 4.3 (24.07.2013)
• 4.3.1 (03.10.2013)
• 4.4 (31.10.2013)
• 4.4.1 (05.12.2013)
• 4.4.2 (09.12.2013)
!
• “but that’s cool - lots of new shiny things to play with”
!
!
• (source: http://en.wikipedia.org/wiki/Android_version_history)

43. Pro-Tip
Stay ahead of any incoming technological
changes (new OS etc.)
Even if you have to “wing it”

44. Technology influence
• Vendors and operators influence what goes into the device (and
operators own the network)
• Don’t make assumptions on what your customers are using!
• The underlying operating system plays a major role for your application
• Even if you’re designing a mobile Web app
• Keep looking at what your users are running the app on and adapt for
that
• There are plenty of SDKs that allow you to “track stuff”
• Check out what is causing the most crashes of your app and fix that
first!
• Before worrying about adding the next cool feature

45. Who’s leading Who?
• Mobile technology is still developing very rapidly
• Make sure your project won’t be obsolete by the time it’s finished
• Plan iterations to make sure you keep up with new developments
• Did you develop for WebOS? (Or BlackBerry?)
• Today, software innovation outpaces network innovation
by at least a factor of five: application developers often
reach market in only three to six months, while
operators take 18-24 months to launch a new service.
• Mobile-Developer_Econonomics_2011 (VisionMobile)

46. Technology cracks
• Fragmentation will remain the problem
• And I don’t just mean Android...
• Mobile browsers
• iOS 6 vs. iOS 7
• 10% of our current iOS users are still running iOS 6
• Should the next version of the app support it?
• The answer depends on who you ask
• The wrong answer can cause lots of issues
• Support drag and drop in Android version of the app (also in old Android versions)
• Support background uploads/downloads in old iOS versions

47. Choosing resources
• You’re looking for a Web developer
• Pretty straight-forward
• Frontend: HTML, JavaScript, Responsive
Design
• Backend: PHP, Node.js, Ruby on Rails

48. Choosing resources
• You’re looking for a “mobile
developer”
• Say what?
• Do you mean Android? iOS? Windows
Phone? HTML 5? Or all of those?

49. Choosing resources
• “Developers, Developers, Developers!”
• “Readily available” mobile development is still
relatively new
• Downloadable SDK
• Accessible devices
• Testing via simulators
• It’s difficult to find an all-rounder
• iOS, Android and mobile Web please

50. Choosing resources
• Google releases first “early look” Android SDK
• November 2007
• Apple released the first beta version of the native iOS SDK
• March 2008
• So, don’t go looking for the mobile developer with 10 years
of Android development expertise!
• And also don’t trust anyone that experienced
• Choose motivated and technically savvy resources with
“mobile” experience and an eye for the challenges

51. Choosing resources

52. Choosing resources
• Does your developer really know
mobile?
• “They don’t seem to grasp that one must
understand the native environment you’re
working in before going ahead and writing a
program to run within it.”
• Andy Firth - http://altdevblogaday.com/2011/08/06/demise-low-
level-programmer/

53. Choosing resources
• “Developers use 2.5 platforms at the same time, which is down
from 2.9 in our Q3 2013 survey, pointing to consolidation.”
• Down from 3.2 platforms in 2011
!
• “iOS is the preferred platform for developers in North America
and Western Europe while Android wins in every other region.
The difference is especially pronounced in Asia, where 46% of
mobile developers prioritise Android vs. 28% for iOS.”
!
• (Source: Mobile-Developer_Economics_Q1_2014.pdf - Vision Mobile)

54. Choosing resources
• But it’s not just developers...
• Great application user interface design
• Not every UI designer knows mobile
• Photoshop is not a mobile development tool!
• Find designers who understand the technology implications
• resolution, screen size
• touch vs. non-touch
• mobile vs. tablet
• browser vs. app flow
• implications of using native components vs. “roll-your-own”

55. Choosing resources
• Find experienced mobile project managers, designers, developers and
testers who can lead the team and act as mentors
• Make everyone part of the team
• Build up teams combining different skill-sets
• If you are developing for several platforms then don’t put all the good developers into a
single team
• Have regular “brown-bag” sessions where knowledge can be shared
through the team
• Encourage good mobile developers to coach developers who are not as
good
• Have a process where any code-commit needs to be reviewed before it
goes into the codebase

56. Implementation & Testing

57. Before we begin
“Most programmers regard anything that
doesn’t generate code to be a waste of time.
Thinking doesn’t generate code, and writing
code without thinking is a recipe for bad
code.”
(Leslie Lamport)
!
http://www.wired.com/opinion/2013/01/code-bugs-programming-why-we-need-specs/

58. Before we begin
• Storyboard the application using
mockups
• Use a tool like Balsamiq
• Test out your concepts with a target audience
!
• Even paper and pen is better than no
mockup!

59. Storyboard

60. Before we begin
• Designing a native mobile app is different from
designing a Web app
• Make sure everyone knows this
• Design the application with an understanding of
the technology you’re targeting for
• “Well it looked fine on an iPhone 5s”
• Did you remember not just to design for portrait
mode?

61. Before we begin
• What about tablets?
• “Can’t we just stretch the UI?”
• “We want these really cool sexy view transitions”
• Did you test things like that on low-end devices?
• Show your User Experience design to developers
as well as product managers!
• Don’t just throw the wireframes over the wall
• Remember: One design does not fit all

62. Before we begin
• Make your mobile Web design “intelligent”
• Use things like CSS media queries to be responsive
• Computers aren’t the only piece of hardware with a web
browser anymore
• Look at “Mobile First” and add other layers as needed
• Make sure your application is designed to look as
though it is doing something
• Mobile networks can be slow - so pretend they’re not and
cache if you can!

63. Bad design costs lives
• A single bad screen can cost millions of dollars in
lost revenue and brand value
• You get only one chance to make a first impression
!
!
!

64. Mobile UI Performance
!
!
!
!
!
!
!
!
• http://www.smashingmagazine.com/2011/07/18/seven-guidelines-for-designing-high-performance-mobile-user-experiences/

65. Development model
• Whichever model you choose
• SCRUM
• Waterfall
• Something else
• Make sure all project members can live with the decision
• Not just the developers
• This is probably harder than it looks
• “I don’t care which development model you use, just
make sure you deliver on March 31st”

66. Development estimations
• Sceptic vs. optimistic
• Try to estimate individual tasks and not just roll
the dice on a whole project
• Use something like story points and planning
poker to gauge how much the team can achieve
• If you are using a SCRUM model then start off
with a sprint that will let you “test” how good the
developers are at estimating

67. Development platforms
• Each has its own challenges
• Native (Android, iOS, Windows Phone)
• Support for required functionality in all versions of the OS
• Support for required functionality across platforms
• Various frameworks available that need evaluating and then integrating
• Technical decisions made at the beginning of the project will come back to haunt you!
• Mobile Web
• Do the requirements match what is actually possible?
• Which libraries are you going to use
• Provide a hybrid app?

68. HTML5 is not a silver bullet!
• Don’t let anyone tell you it’s “either or”
• It should always be a well-informed use-case based decision
• You still need developers who know HTML 5 and related libraries
• If you plan on providing a hybrid-app
• You still need a stable environment that supports your target platform
• You still need to test on different devices and operating system
versions
!
• By the way - your “native” mobile app developer will probably try
convince you not to use HTML 5 (and vice-versa)

70. Mobile browser usage
source: http://www.quirksmode.org/blog/archives/2014/01/browser_stats_f_7.html

71. Internationalization
• The pain of deploying the same app for 18
countries
• Language translations
• Are you still using an Excel sheet?
• Look at online tools such as transifex.com
• Get the regional branches involved in the translation process
• Set concrete deadlines for translations
• Even if you supply your base language file in “English” -
remember that there are other “versions” of English
• Some languages are easy - IT, ES, DE but what the heck is SQ?

72. Internationalization
• Networks
• Other countries have different network qualities
• Don’t just test your app on LTE
• Check for silent failures if the network is down or just 2G
• Country specific issues
• Displaying months - remember to use the functions for obtaining
standalone month names if needed
• Displaying tax information in certain countries

73. Internationalization
• Get the countries involved as soon as possible
• Check (or do) translations
• Provide any local laws that are relevant
• Perform testing in local networks and provide feedback
• If your app is data-heavy then you may notice a difference
between testing in Munich and testing in Albania

74. Testing
“I tested the reported bug and couldn‘t reproduce it”
!
“Did you test in on the same device / operating system /
network version it was reported on?”
!
“Umm.. No... Why?”

75. Testing
• Testing a mobile application is time and
resource consuming
• Plan enough time and resources in your project for
testing
• Make sure test-cases reflect actual use-cases
• Simulators are available
• Often part of the SDK (e.g. iOS)
• HTML 5 - Ripple - http://ripple.tinyhippos.com/

76. Testing
• Testing on actual devices is mandatory!
• And not just on an S5 or Nexus 5
• Make sure you test on the different OS versions
• Different memory configurations
• Also consider services such as DeviceAnywhere.com
• Regardless of how much you test (on how many
devices)
• Someone, somewhere will be using a device / operating system
combination you didn’t test on

77. Testing
Pro-Tip: Make sure you know which
device your boss / customer is using -
and test first on that one

78. Testing boredom
• Testers become bored if they have to repeatedly test the
same stuff
! • They will look to make life interesting by e.g. rapidly
tapping on something to see if they can make the app
crash
! • They should be focussing on testing the main functionality
! • Rotate testers around projects to keep things fresh
• Don’t get them too integrated with the developers or they
will know which things not to test

79. Testing hell
Email from central QA department to
development team:
“We have found a critical issue on a certain - not
yet released - device that we may or may not be
able to provide to you tomorrow.
However can you please tell us if the fix can be in
the next version you plan on releasing?”

80. Deployment
http://www.flickr.com/photos/isawnyu/4566381520

81. Deployment
• Deploying an app into a store takes time and effort
• Plan for app signing
• In a large organization - that may be harder than you think
• Plan for the acceptance period (dependent on App store)
• Remember that release date you were given? You have 2 weeks less than you thought!
• Plan for iterations as you need to update assets such as
screenshots, descriptions (multi-language anyone?)
• Check the assets (still) fit the app - especially if updating the version
• Don’t photoshop screenshots - you will be found out (yes, really)

82. Deployment
• If the App store is available in different
countries - have you tested with foreign sim-cards?
• Do you know what the limitations of different
countries are?
• Does the App store support the business
model you are considering?
• In-App purchases, Vouchers etc.

83. Deployment
• You don’t need to launch in all countries
at once (and you probably shouldn’t)
• Select certain ones as trial markets
• “Turn on” new markets selectively
• Make sure each market has met its
requirement
• e.g. set up the correct pages showing Terms & Conditions

84. Release Cycles
• A release cycle needs to be planned
• Development, testing, deployment
• Fixing a bug and pushing out a new version
is not always a “point and fire” process
• Developers find that frustrating
• “Well, I quickly fixed the bug, why isn’t it in the build
we just released?”

85. Business
http://www.flickr.com/photos/59937401@N07/5474437939

86. “Your cell phone has more computing power
than all of NASA in 1969.
!
NASA launched a man to the moon. We
launched a bird into pigs.”
!
(via Twitter)

87. Hot sellers - easy money?
• Angry Birds .. not quite so simple..
• Rovios 52nd title
• Titles written for companies such as EA, Digital Chocolate
• Initially spent € 100.000 to develop Angry Birds
• When it was released in December 2009 in the English speaking App Store - it was a flop!
• Tough to break into that market from the get-go
• Rovio tried to get a following in the smaller markets
• Sweden, Denmark and Greece
• Then published via Chillingo and with Apple’s help featuring the app on the UK App Store
- launched new versions in February 2010
• And the rest is history
!
• https://technology.ihs.com/403311/angry-birds-developer-raises-42m

88. Hot sellers
• What makes Angry Birds successful?
• Simple to play - difficult to master
• Constant rewards in the game
• Active continuous relationship with the customer
• Regular updates for free and new versions with a theme
(halloween etc.)
• Cared about feedback from the customers
• Phoenix bird that ignites the structure was a suggestion from a customer
• Rovio were able to create a “buzz” around the game

89. Hot sellers - short life?
• Flappy Bird
• Independent developer
• Developed over only a few days
• Released in May 2013 - became very popular in early 2014
• Criticized for level of difficulty and alleged plagiarism (but considered addictive)
• End of January 2014: Most downloaded free game in app store
• According to developer it was earning 50.000 $ a day through in-app ads
• Removed from both iOS and Android stores on February 10th 2014
• Developer said that he was under too much stress due to the games success
• Since it was taken down
• 60 Flappy Bird clones submitted to the app store every day
• source: http://www.forbes.com/sites/insertcoin/2014/03/06/over-sixty-flappy-bird-clones-hit-apples-app-store-every-single-day/

90. Hot sellers - one hit wonders?
• Candy Crush Saga
• Free to play (but to really play means you pay)
• Downloaded more than half a billion times
• $2 billion in sales in 2013
• $567 million profit
• Now looking for an IPO (valuation over $5 billion)
• But
• Company has published over 100 titles
• 80% of revenue comes from Candy Crush
• How long will that continue?

91. So think about this…
“Typically, companies will have that one big product, and then
they’ll sell some sequels to it. But, unless they manage to
become the center of an ecosystem, over time they tend to
weaken and disappear.”
(Prof Michael Cusumano, MIT)
!
source: http://www.newyorker.com/talk/financial/2014/03/17/140317ta_talk_surowiecki?mobify=0

92. Before you get too excited
• The average smartphone user in a
study added just 2.5 new apps per
month.
• 37 percent of users added no new
apps at all.
http://www.wirelessintelligence.com - Study was based on an analysis of more than 2,100 smartphone
users (iPhone, Android, BlackBerry and Symbian) in the US and UK during January 2011

93. Before you get too excited
!
!
!
!
!
!
• http://www.phonearena.com/news/The-average-global-smartphone-user-has-downloaded-26-apps_id47160
(Sept 2013)

94. Actually, things are getting worse

95. Auch in Deutschland
http://netzoekonom.de/2014/08/31/zwei-drittel-der-deutschen-laden-keine-apps-mehr-herunter/

96. Lots of downloads - but no money!
• PunchQuest launched in 2012 in the App store
• Free to play
• Quickly reached over 600.000 downloads
• Critics loved it
• Business model was in-app-purchases
• But: It didn’t make much money (only just > $10.000 after a few weeks)
• People were playing but not paying
• Company was worried that the popularity would quickly drop off leaving them with a loss -
even though everyone liked it
• Eventually switched to a pay-for-play model

97. So is Freemium the best model?
• In January 2014
• Only 1.5 % of all freemium players actually bought something
• Of those payers
• 49% only bought once
• on average, 0.15% of the payers are generating 50% of the IAP revenue of a game - they are the
“whales”
• average time to purchase is 24 hours
• Of those purchases
• Purchases between $1 and $5 make up 67% of all purchases but only 27% of all revenue
• on average, 0.7% of all purchases are over $50 and this makes up 9% of the total revenue
• source: http://swrve.com/weblog/some-thoughts-on-monetization

98. So, before you get too excited
• “Our latest Developer Economics survey shows
that 60% of [Android] developers are below the
“app poverty line”, i.e. earn less than $500 per
app per month.”
• “1.6 % of app developers earn more than all
others together”
• “23% make less than $100 a month”
!!
• (Source: Mobile-Developer_Economics_Q3_2014.pdf - Vision Mobile)

99. It’s just business
“Mobile apps aren’t a get rich quick
scheme where you can be oblivious to
best practice. “
“Usual business rules apply and there are
extra mobile rules for the unwary.”
Simon Judge

100. So to summarize ….
• An example list of things that went
wrong…

101. Lessons learned - real world
• Timeline expectation was given even before the project started
• Development was started without having all use-cases defined
• Limitations of office-space and co-location impacts development team
• 3 Platform implementations (iOS, Android, WP8) run in parallel
• Impact on coordination, scope, QA
• Use cases and initial UE specification alone were not sufficient to
detail all aspects of the product
• Too many change requests added during the project
• Mismatch between wireframes and design specs
• Feedback from local branches (internationalization) was received too
late

102. Lessons learned - real world
• Old version of the client “evolved” while the new version
was still under development
• Raising “implicit” change-requests - “of course the new client
needs to do x”
• Design changes received at late stages of project
• Design of Android app did not follow Android guidelines
• UE wireframes did not document user flows fully
• UE designs were provided in different formats (PDF vs.
AI) and not kept in sync

103. Additional links
• This presentation (2011 version) as an article -
http://webmagazin.de/business-strategie-mobile-projekte-
39956.html
• http://www.mobilebusiness.de/home/newsdetails/
article/warum-app-projekte-scheitern.html
• http://www.itespresso.de/2013/03/01/dresdner-projekt-
fur-mobile-payment-scheitert-an-formalien/
• http://qz.com/258066/this-is-why-you-dont-hire-good-
developers/

104. Thanks for staying to the end!
!
“Ever tried. Ever failed. No matter. Try
Again. Fail again. Fail better” - Samuel
Beckett
matthew.langham@indiginox.com
Thanks to Stefan Kolb & Reginald Rink for input
photo on slide 1 (c) Frank Köhntopp - used with permission - http://www.flickr.com/photos/koehntopp/
photo on slide 1I http://www.flickr.com/photos/landscape_photography/9631304512/sizes/l/