Hybrid apps – are they the right approach for your B2E solutions?

April 18, 2013

When it comes to building mobile apps for your business the choice of approach is anything but simple. The tools and technologies available to build cross-platform apps are still immature and there’s no easy solution to this dilemma.

The 3 recognised approaches to building apps are

  1. Native apps – these are built for a single platform (e.g. iOS, Android) and can take advantage of all the platforms features
  2. Mobile web apps – these are usually a series of web pages optimised for mobile devices. They can run on any supported device but, amongst other disadvantages, lack access to some of the native facilities on the device
  3. Hybrid apps – these combine most of the capabilities of native apps combined with the portability of web apps.

In this article we focus on the area of Business to Employee (B2E) apps and examine what is the right approach for these types of apps.

Gartner recently stated that they expect that by 2016 over 50% of B2E apps will be built using a hybrid approach. One of the key reasons for this is the growth of the BYOD trend (Bring Your Own Device) where businesses allow employees to use their own mobile device to access the organisation’s systems and data.

As Gartner said “The BYOD trend and the increased pressure on organizations to deploy mobile applications to accommodate mobile work styles of employees will lead businesses to manage a portfolio of mobile application architectures, and hybrid architectures will be especially well-suited to business-to-employee applications”.

Making the right choice for your business

How do you make the right choice of app model for your business? Here’s a starting point. (Bear in mind this is about B2E apps – not gaming apps or other apps that might need the advanced features and performance of a mobile device)

Native apps

If you are in full control of the of the environment that an app will run on and can mandate what devices and operating system version can be used then you will probably choose to build native apps.

These will give you all the capabilities of the device and will allow you to take maximum advantage of the graphics capabilities and performance of the device. You will also get enhanced security and local data storage enabling the apps to operate without needing a data connection.

Some companies issue their employees with a specific device (e.g. an iPad) to enable them to work more productively. In such cases building a native app makes sense as they can control the environment that the app is used in.

The key disadvantages of native apps are that they are device specific, are more difficult to develop and require a level of experience that is higher than other development scenarios.

Mobile web apps

Mobile web apps are built using HTML5 and JavaScript which are device agnostic and can be opened with any modern mobile browser.

You would choose to build mobile web apps in scenarios where you need to support multiple mobile environments and to enable the broadest access to the app. You would also consider this route based on the skills you have in-house as you will likely have people with extensive HTML skills.

Mobile web apps have one big advantage over native apps and that is that distribution and support is much easier than for native apps. When you need to fix a bug or add new features these become instantly available once they’ve been deployed to the server. No need to submit then to an app store for download.

However, mobile web apps offer significant limitations when it comes to offline storage and security. Whilst you can implement some offline capabilities by caching files on the device, it isn’t an elegant solution. As a result mobile web apps typically rely on a data connection.

Mobile web apps also have restricted access to the native features of the device and generally offer a dumbed-down user experience.

Hybrid apps

In simple terms hybrid apps are apps that are written in web ‘languages’ – HTML, JavaScript and CSS – but that use a container (or stub) app that runs natively on the device.

This allows hybrid apps to take advantage of most of the device features whilst supporting multiple different devices. Unlike a mobile web app, Hybrid apps render the HTML5 & JavaScript in a full-screen web view control, not in a browser thus enabling a  better native-like user experience.

The vast majority of the app will exist as an HTML5 & JavaScript app but the native container app will enable it to use device features such as local data storage and tighter security. It will also enable access to device features such as the accelerometer, camera and geolocation. Hybrid apps can also be designed to work offline unlike most mobile web apps.

New toolsets, such as PhoneGap, are making it even easier to build hybrid apps. They leverage existing HTML & JavaScript skills so that you can more easily build apps that run on multiple devices without having to become experts in the native development tools.

So which approach should you choose

Most enterprises will have to manage a large and diverse set of mobile applications that will span all major architectures. They will have to build B2E, B2B and B2C applications that can run on multiple devices.

Depending on your business needs there may be situations where the only way to build a particular app is to build it as a native app. However, across the broad estate of apps that you will likely build the majority of these can be successfully built as hybrid apps.

Building native web apps requires a commitment to investing in specific skills and knowledge for each device supported. And as the number of devices expands the investment will only grow.

The one common platform that is supported across nearly all devices is HTML5 and JavaScript. You will already have these skills in-house so it makes sense to take advantage of them.

We would therefore recommend that, for the majority of your apps, you should consider using the hybrid approach. It will be the most cost-effective means of delivering new apps quickly and will have the highest chance of future-proofing your investment.

Leave a Comment » | App Development, HTML5, Mobile | Tagged: , , | Permalink
Posted by Paul S

Why Bespoke Software Might Be Right For Your Business

March 25, 2013

It is often assumed that choosing package software over bespoke software is the right choice for most business scenarios. However, as with many things in life, it’s not quite as black and white as many package vendors would like you to believe.

In my 30+ years in the software industry I’ve seen many package software implementations go wrong. I’ve also seen many millions of pounds/euros/dollars wasted on trying to make a package fit a business’s needs.

In my experience organisations consistently underestimate the amount of work needed to implement a new software package. In particular they significantly underestimate the amount of customisation that is needed to make the package suitable for their business.

If the “fit” of the package is not greater than, say, 80% then excessive customisation of the package may be required to satisfy requirements, or significant changes in business processes may be required to accommodate the software constraints. Such package customisation or process change, almost always extremely complex in execution, is a major cause for large implementation failures.

In fact, many companies would have been better off choosing a custom solution as they would have spent no more and would have got a perfect fit.

The Cutter Consortium investigated this area in their report ‘Application Package Software: The Promise vs. Reality’ and there were some interesting findings:

  • Of 78% that applied extensive or moderate changes to their packages, only 50% expected to apply this degree of change to their packages.
  • Nearly half of all respondents (49%) said that the customisations exceeded what was anticipated and what was budgeted for the project
  • The perception of senior management that packages can be dropped into an organization with little change is typically inaccurate
  •  31% of respondents expended a great deal of effort integrating application packages with existing in-house applications, and another 46% spent some effort on existing systems integration
  • 42% of respondents had a great deal of difficulty in integrating existing data into a package, while another 39% experienced some difficulty. This is an essential step with almost any package, and these findings indicate that data integration challenges are nontrivial
  • Application packages are, according to this survey, only fully implemented 28% of the time. While this is not necessarily a sign of success or failure, executives should note that a package is unlikely to deliver or be deployed to the full breadth of capability that a given package provider may be suggesting.

Of course this doesn’t prove that choosing package software over custom software is the wrong thing to do. Many packages do get implemented successfully. I would be the last person to recommend that you implement a custom accounting system or HR system unless (highly unlikely) you had some really unique requirements.

The debate over package versus custom really begins with those systems where your requirements are specific to your business and where a package doesn’t easily cater for them in a standard implementation. In these cases the decision is less clear-cut.

In part 2 of this blog I will be looking at the 7 reasons why custom software just might be the right choice for your business.

Leave a Comment » | Software Development, Software Development Best Practice | Permalink
Posted by Paul S

5 Reasons why social media should change your approach to CRM.

December 20, 2012

Customer Relationship Management has been carried out in the same way for a number of years. What’s so different about social media and why should social media change your approach to CRM?

1. You can’t “push” messages anymore

One way or another “pushing messages” within the traditional CRM approach means selling. Before social media, anyone interested in your product or service had to talk to someone in your company. This usually meant a salesperson.

With social media customers can decide when and how they want to interact with you, because there are communities of interest on line (forums) for your industry where good or bad experiences and reviews are shared, allowing people to make informed choices. You can’t readily sell to online users in the traditional way. You have to manage perceptions to create desire for people to make the effort to decide to buy from you.
This means you the marketer has to carry out activities which are not perceived as selling but “pull” believers or advocates to your product or service. These advocates then tell other people about you. It also means you need to manage some extra activities in CRM (see below).

2. Social media activity shouldn’t be owned by sales

Is social media activity “selling” as such? It’s much harder to track the success of lead generation activities when sales can’t follow up in the traditional way. It’s not about how good your sales people are it’s about how well you interact with queries.
The difference is that social media gives a potential buyer the opportunity to find out a great deal about your product, your service, and the very experience of dealing with you before the sale happens. This means it’s actually interactions with potential buyers that influence behaviours (and need to be tracked) in CRM not just sales opportunities. You then use CRM to identify which types of interaction are most likely to result in sales.
Should an on-line strategy be run by sales? It looks like a social media strategy may fit more comfortably with the PR function.

3. The customer has real time interaction with you – and everyone else

Information on the internet is available 24 hours a day, instantly. This creates an expectation of rapid response which means you are likely to need to structure your online activity to be able to respond far faster than traditional communications methods. After all, every other person on a forum could hear about perceived slow service the same day it happens. You have to interact with those communities and simply collaborate to help with their business problems, not sell.
Every area of the business which has contact with the customer or prospect has to be providing the customer experience in the same way and to a consistent high quality. It also means the metrics traditionally used in marketing may not be adequate in a world where interactions and engagements are important.

4. Online, Differentiation and Brand is everything

Guess what? Buyers have never bought solely on price. Branding is the means by which you build a perception of quality in the mind of your buyer and reduce the buyer’s dependence on price. Price is important but the commitment to you is made on the basis of a sort of perceptual bundle of goodies including how they feel about your product and service. Survey said on line 70% of the buyer’s journey is completed before they speak to a sales person (SiriusDecisions).
Online your credibility as a vendor and your brand are everything. In an environment of instant feedback having a clear message for how you are different to your competition and managing and maintaining that perception is more important than ever.

5. Social media moves the balance of power from vendor to customer.

The challenge is the customers POWER. By enabling so much more information to be gleaned without direct human interaction reduces loyalty and makes it far easier to switch vendors. The message really is that social media is here to stay and has to become part of your marketing profile. So ensure the online user has good experiences of you, be available, and use CRM to integrate your business processes so everyone can access up to date information on customers and prospects to deal with questions, challenges and opportunities effectively, as they arrive.

Summary

It would be a mistake to think social media is a black art. None of the above is fundamentally different to marketing off line, and social media is not so much totally different as more of a logical extension of traditional marketing practices. You still need metrics for tracking hard business results, you still need compelling messages, you still need to listen hard to customers. It’s still about building satisfied customers and champions. You still need CRM, because the speed and availability of information online means the customer becomes the centre of everything you do.
Tracking interactions has become more important online, with leads and sales happening as a consequence of managing collaborative customer engagements and interactions to solve their business problems. What is a waste of time is the idea of collecting fans and followers. The goal of social media activity is to build advocates, which means credibility and a clearly differentiated offering if you are to leverage the benefits social media can bring. For more information Contact Us

Leave a Comment » | Dynamics CRM, Implementing CRM, Uncategorized | Tagged: , , , , , , , , , | Permalink
Posted by Wayne C

Stop Wasting Money On Software You Don’t Need!

November 29, 2012

Part 3 of 3

In Part 1 of this article (http://blog.kynetix.com/2012/10/23/stop-wasting-money-on-software-you-dont-need/) I laid out the evidence for the enormous amount of waste that exists in all software. In Part 2 (http://blog.kynetix.com/2012/11/09/stop-wasting-money-on-software-you-dont-need-2/) I went on to examine how waste is created in software.

In this final part I want to put forward some ideas about how you can prevent waste happening in your software projects.

HOW DO YOU AVOID WASTE IN SOFTWARE?

You could probably fill a library with all the books available advising on all sorts of development practices designed to make the process better, leaner, quicker, cheaper. However, for the purposes of this short article I would offer the following four suggestions.

Adopt an incremental approach to development – No more big bangs

Commit to delivering only the most important 25%-30% of features in the first release. Get that released and then listen to the feedback. Make the second release contingent on the feedback from the first.

By responding to what’s actually needed, this will greatly increase your chances of not creating waste. It will also create a system that the users actually want to use.

If you think about it, good software will usually change people’s working practices and behaviours. They will be able to do things they couldn’t do before and they will become more efficient at certain tasks. It’s only through the use of the system that you can really know what the most valuable features for the next release are.

Make sure the users know that there are further releases to come and that you will base the decision on what to release on their feedback. This gives you a much greater chance of controlling the “kitchen-sink” mentality.

Use timeboxing to control scope (& waste) creep

This is the highest payback action you can take to avoid waste. Scope creep is the cancer in software development that leads to huge amounts of waste.

The key to this is to drive projects by strictly controlled timeboxes,  making the deadline more important than the feature set. This focuses everybody on only building the most important features for that release and will ensure that there is less opportunity for waste to creep in.

If you’ve never worked this way before it can be hard to believe that you will get the system you really want. And that’s true because instead you will get the system you really need and without waste!

Use an Agile development method

If you can get the first two suggestions implemented then you will need to have a development approach that is compatible with these. This is where Agile development fits perfectly.

Agile development is based around the concept of frequent deliverables where the requirements can change as the project progresses. It is also founded on the principle that adherence to timeboxes matters more than scope.

Don’t tolerate obscure or complex code

To deal with this issue you will need both an educational and a monitoring approach.

You should have rigorously enforced coding standards which ensures that developers follow the corporate line. You should also implement peer reviews of the code. It is vital that you have extra eyes on the code to ensure that unnecessary complexity doesn’t creep in.

To ensure that your developers are consistently improving you should develop a best practice culture in your organisation. Make it unacceptable to develop obscure code. Get your best experienced developers to mentor more junior people and set the quality expectations.

SUMMARY

Every organisation, large and small, has already wasted, and continues to waste, huge amounts of time and money on unnecessary software. The key question is this. Now that you know how much waste there is in software what do you plan to do to stop it?

Leave a Comment » | Software Development, Software Development Best Practice | Tagged: , , , | Permalink
Posted by Paul S

Stop Wasting Money On Software You Don’t Need!

November 9, 2012

Part 2 of 3

In Part 1 of this blog article (http://blog.kynetix.com/2012/10/23/stop-wasting-money-on-software-you-dont-need/) I laid out the evidence for the enormous amount of waste that exists in all software. In this follow-up article I want to examine where waste originates from.

HOW DOES WASTE GET INTO SOFTWARE?

There are many moving parts and processes involved in a software development project. Waste can occur at all points but here are 4 areas where I’ve regularly seen waste creep in.

Users with no buy-in to the budget and/or timescale

If the users face no consequence then why would they be motivated to keep the requirements under control? As far as they are concerned they want every feature that they can think of.

Without a strong product champion, who is committed to, and accountable for, the budget and/or timescale more than the feature set, you will certainly create waste.

Having only a single release

This is one I see time and time again and it just creates the wrong behaviour patterns. If users know that they are only going to get one shot at it they will pile in the requirements and it will be next to impossible to control waste.

Taking a big bang approach to development is such a flawed way to work but it is prevalent throughout the corporate world. If I could have one wish for this article it would be that I hope that it alerts some senior people to the vast amounts of time and money wasted on software development and that they review their approach to their projects.

A dominant character deciding what’s needed

I would rate this as one of the most pernicious ways that waste can get into a system. These people are very insistent about what features are “must-haves” without regard for the cost or time involved. Often they will insist that they know what other users want without even checking if that is the case.

Unlike a good product champion, there is usually little consensus in their decisions and they will usually ignore the fact that they are demanding more than can be achieved for the budget or in the time available.

These people invariably create lots of waste. And then what happens when they either move departments or leave the company? Does anybody else use those features? Does anybody even know those features exist?

Developers inventing requirements and/or complexity

What? I hear you say. Surely not? How could that happen? Well yes it does happen and far more often than you might imagine. Younger, less experienced developers are particularly prone to this but it can happen across the development spectrum.

Developers are prone to having a “just-in-case” mentality. They will add extra features or capabilities just in case the users need it or because they imagine that the user must want it.

They are also prone to writing code that is far more complex than is necessary. Object Oriented Languages (which we use) have a lot to answer for here.

Some developers go on a mission to abstract their code to the nth degree because that’s what the purists say should be done. However, purists tend to live in Nirvana where there are no deadlines, there’s infinite money for development and they don’t have to maintain and support their complex code. If only they would listen to Albert Einstein – ““Make things as simple as possible, but not simpler.”

Leave a Comment » | Software Development | Tagged: , , | Permalink
Posted by Paul S

Stop Wasting Money On Software You Don’t Need!

October 23, 2012

Part 1 of 3

The Biggest Scandal In Software Development

Many years ago I was invited by a FTSE 100 company to a meeting to discuss a project to audit one of their legacy applications and to make recommendations about how they could redevelop it. This application had been operational for over 10 years and was coming to the end of its life.

One of the things that I discovered was that one of the original programmers had put in a logging mechanism that counted the number of times each part of the system was used.

Boy, what an eye-opener that was!  On examination I discovered that just over 10% of the modules in the system had never been used since the system went live, over 10 years previously. A further 14% of the modules had only ever been used once. Beyond that there was a whole raft of modules (nearly 25% of modules) that had been used less than a dozen times. In total, close to half of the system had little or no usage.

At the time I thought that this was an isolated case but in subsequent years I discovered that, far from being isolated, this was a norm in the software world. In fact this is now a widely known phenomenon that is confirmed by further research.

In 2001 the IEEE in their paper “Improving software investments through requirements validation” found that in 400 projects examined over a 15 year period, less than 5% of the code was actually useful or used.

A 2002 Standish Group study of software projects found that 45% of features were never used and only 20% of features were used often or always. Another study by Dupont claimed that “only 25% of a system’s features were really needed”.

Whilst there are plenty of people ready to argue the accuracy of these numbers there is nobody arguing that the underlying principle is true – that we build vast amounts of software that never gets used.

In addition to my own personal experiences I’ve also had many conversations over the years with CIOs and other technical people and they have all had their own tales to tell of wasted development effort. It is happening on every project in every organisation around the world.

If you let your mind wander for a few seconds and you extrapolate all this data out then you could be forgiven for arriving at an incredible conclusion – that around half of ALL software that is running today is not used. Given the amount of software that now exists in the world this represents trillions of pounds/dollars/euros spent on software that is not needed. What a waste!

This is mind-boggling stuff. But it gets even more mind-boggling. We are still creating waste at a phenomenal rate. And as waste increases the costs increase on a non-linear basis due the increased complexity of the system.

In 2008 Grady Booch, an IBM chief scientist, said that “Every advance for the future state of the world requires the presence of software yet to be written”. We will therefore be writing more and more software way into the future.

So in the coming years further trillions (quadrillions?) will be spent on new software and further trillions of waste will be created unless we stop paying to have software developed that we don’t need.

If the above doesn’t motivate you to do something about the waste in your organisation then ponder this. You could cut your software development budget in half if you only built the features that were really needed. You would get the software in half the time and get the benefit of the software earlier. That’s all going to feed into the bottom line.

Leave a Comment » | Software Development | Tagged: | Permalink
Posted by Paul S

2 Very different approaches to implementing CRM!

October 19, 2012

We’ve recently been involved with a couple of CRM implementations (one mid-sized, the other early stages of an enterprise roll out) which have been very different experiences and have revealed some interesting learning!

Firstly, let me explain the projects. Project A was for a mid-size investment bank in the City of London that wanted to replace 3 separate but integrated systems for managing their client information, to help run events and road shows and generally to move from a transaction-centric business to one more defined by having sustainable client relationships. They expected to have around 300 users in locations all over the world using Microsoft Dynamics CRM.

The key stakeholders included senior business executives and managers, as well as some of the sales team, account managers and events team. Engagement with IT at the start was limited (more of that later!).

A few key points were driven home by the client at the early stages of the engagement:

  • Business users absolutely had to have current, integrated client data available from Day 1
  • We were instructed It was not going to be possible to have parts of the business or parts of the functionality delivered in stages, it had to be “all or nothing”
  • The business appeared to have more trust in us as an external supplier than they did in their own IT function (perhaps partly because the IT function had created the systems that were now being replaced due to lack of adoption and

The project required loads of custom development to Microsoft Dynamics CRM to deliver all the business functionality and integration, which in turn needed lots of testing. A combination of impatience from the senior management to have something to show and some technical challenges around integration eventually led to the business deciding that they could, in fact, put some users live without all the functionality and that once they’d done that, actual user experience of using the software was a far faster and more accurate method of gauging the real user requirements – after we had done hundreds of man days work!

Project B is the first stage in a global roll out for an enterprise organisation with offices worldwide, expecting to have around 3,000 people using the new system (again, based on Microsoft Dynamics CRM), although they had already decide to do this in ‘baby’ steps, with only 17 users being on the system initially. With less than 20 days consulting we have put an initial system live and the users are happy with it, as they understand it is just stage 1 of a longer project. Mind you, one difficulty has been the demands of one of the senior business sponsors who insists that mobile is in scope (when it was agreed not to be) and has added various other minor (but “critical”) requirements once we started work.

My key conclusion is that wherever possible, the maxim “start small and build on success” is especially true of CRM projects, wherever possible and taking into data requirements and integration.

Leave a Comment » | Dynamics CRM, Implementing CRM | Permalink
Posted by Matt D

« Previous Entries
Follow

Get every new post delivered to your Inbox.