Why it’s important and ways toimprove.

Advancement of technologies in software development and deployment, andthe emergence of the cloud have drastically lowered the barriers to entryand time to market for business software products. If you are a businesssoftware vendor, you could be facing stiff competition already. Else, you willsoon be.

How can you ensure you deliver better value than the competition?

The feature set and its alignment with business processes of thetarget customers would naturally establish the base value of the softwareproduct. This is something you take care of, by default. But what is oftenoverlooked is the efficiency - i.e., how efficient the product enablesthe said business processes to function, resulting in an increased throughput.Efficiency could make your product a winner or a loser.

‍

Value of Efficiency

Well, it’s not rocket science! Let’s take a simple example: Imagine a‘window’ (a graphical user interface) of a banking system, which has beendesigned for a banking executive to use when catering a walk-in customer.  

·        A banking system from vendor X mightprovide this window, which requires 20 clicks (on average) when serving asingle customer. Total time spent while interacting with the window measures,say, 1.6 minutes (on average).

·        Vendor Y has a banking system. Theirwindow for the above function requires 17 clicks (on average) and the time 0.9minutes (on average).

Now, if the executive handles, say, 100 customers per day, the timesaved by choosing Y over X is:

      (1.6 – 0.9) x 100 minutes =70 minutes

If the bank has 50 branches, each employing, say, 4 executives onaverage, for the total of 200 executives, the time saved per day is 70 x 200minutes = 14,000 minutes ≈ 9.7 days

The bank saves 9.7 man-days each workday just on that singlewindow by using System Y. If the bank was using System X, they wouldlose 9.7 man-days every workday just on that window!

A banking system can have hundreds / thousands of windows…

Efficiencyimprovement – the challenge of discovery.

Having UX engineers onboard and having experts with years’ worthhands-on experience in the target domain will save many miles.

However, gaining insights on ‘how well the product functions’ andmaking it an integral part of the development process is likely to provideyou a more persistent outcome. Before discussing why, let’s try to look at theunderlying problem.

A business software system is essentially a solution to a specificbusiness problem. The problem is communicated in the form of requirements.

Typically, the requirements will be communicated at different levels ofabstraction. For a bespoke product, for example, the management of the customerand the vendor may communicate requirements at a more conceptual - strategiclevel. Consultants (and/or business analysts) may sync up at a level moregranular – more functional. A large scale product would require multiple suchlevels. In case of Agile, product owners will also participate from thevendor’s side.

Engineers, however, receive concrete requirements from the team’sproduct owner or the consultants (and/or business analysts). As the ones whoactually develop the product, is there a way for them to know what the end-usersreally want? Do they have a complete-enough picture of the ground reality?

Often this is the root cause of a product being developed to deliver therequirements on paper but doesn’t necessarily enable the user base (theworkforce) to achieve their full potential producing an optimal level ofthroughput. There’s no magic formula to take us to the paradise. But there aresome simple ways that can make things far better.

Efficiencyas part of Development Process.

‍

Optimizing a system for efficiency can be integrated into thedevelopment process. Performance metrics are collected and analyzed. Changesnecessary to improve efficiency are identified and carried out. The changes arethen implemented (deployed) in the target environment(s) and assessed forexpected improvements.

In a continuous delivery setting, this will also give you thefreedom to experiment new ways to improve in small steps at a certain degree ofrisk. You make changes and collect analytics. Keep the changes if they’veyielded improvement. If not, or if this has resulted any negative sentiments inthe user base, rollback the changes in the next incremental release.

By integrating this cyclic approach into the development process, theefficiency of your product will keep on increasing by means of continuousimprovement.

Waysto improve.

Discussed below are a few qualitative and quantitative approaches.

1.Directly Involve end-users in the development process

If possible, you can request the customer’s consultants to bring along agood user or two to the Agile sprint demos. Even if you are following aclassical model such as Waterfall, there’s room to get the involvement ofend-users, at least in the requirements stage.

There are 3 kinds of users around a typical business application:

1.       Regular user: uses the system through thewhole day every day. She expects the right things to be at the right place -most frequently used features within the closest reach. Expects convenience andproductivity.

2.     Power user: an experienced / expert userwho would love a CLI (command line interface) over a fancy looking GUI(graphical user interface) if that enables her to achieve her level best. Readyto compromise convenience over productivity.

3.     Occasional user: a userwho doesn’t remember how she did it last time 3 weeks ago and doesn't have timeto recall or find help. Expects the system to take her through the steps of thefunctional flow.

Make sure you identify the correct kind(s) of users for the functionalarea that’s to be developed. The discussions can be done online if the partiesare located in different geographies.

2.Monitor on the fly

One of the most accurate ways to gain insights is to measure the productin action, via collecting analytics programmatically.

For example, you can log the visits of the fields and windows (traversalof keyboard focus), along with how much time the user spent at each. You cancollect the frequencies which might reveal where the users have visited the most.Doing this doesn’t involve much technical complexity, but the results are quitepowerful.

For example, you might discover workflows that have not beenidentified in the specifications but used in practice. You would then refinethe design so that users can do things faster and with less effort.

Logic can also be optimized for performance by measuring the time taken,starting with the most frequently used ones that are noticeably slow.

‍

‍

Pay attention to the data that you collect. Whatever collected shouldcomply with the agreements with your customers and should not violate any laws/ regulations of the jurisdiction(s) the data is collected, transferred andstored.

3.Interviews

Developers can talk to end-users via interviews. This can be a one-on-oneor a discussion with multiple developers and multiple users. This can quicklyreveal the pain points of the existing system, features that they believe thenew system ‘must have’. A suggestion coming from an experienced user can bequite valuable.

You can collect as many suggestions as possible, without anycommitments. They can then be filtered out, refined and integrated into thebacklog.

4.Ethnography

This is a technique that has been borrowed from social anthropology.In our context, the consultants (business analysts) and/or engineers visit thecustomer site and passively observe how the end users use the existing system.The observations are documented and analyzed. They would be used as input torefine the existing requirements or to create new ones.

Though this looks quite naïve at first, this is pretty much the onlymeans of discovering implied requirements. That is, the features thatthe users are so familiar with, that they never occur in one’s mind even tomention.

Implied features are often the ones executed very frequently, hence ofhigh value.

Conclusion

We have discussed the benefits of improving efficiency of a businesssoftware product and a few ways to do so. We believe this would have helped bymeans of giving your product a competitive advantage.

What we have discussed so far are the techniques to make horses run faster. In the next blog post, let’stry to explore how we can invent a car!

‍