The most process-oriented country

The United States is the most process-oriented country I know. You can see it in the principles of scientific management by Frederick Winslow Taylor (1856-1915) and the first automobile assembly line by Henry Ford (1913), to the Speedee Service System designed by the McDonald brothers for quick burger production (1940s) and more recently the cookie-cutter Starbucks expansion (pun half-intended) to 15,000 locations around the globe.

In 1870, the GDP of the US was less than the GDP of British India, and just a little higher than the GDP of Germany. Today the GDP of the US is nearly four times that of Germany and more than ten times that of India. While a part of this surge is probably due to American inventiveness and a history of free trade and open business, at least a part is due to the process mindset.

This process mindset is inculcated in children at a very young age. Sometime last year, my father was visiting my sister in New Orleans and spending an idle day organizing the things in her garage for her. Her son, then four years old, wanted to help. My father said, "You are too young to help with this, this is a big job". The little child replied, "Nanaji, when you have a big job, you should just break it down into little jobs. Then you can do those little jobs one by one".

This too is a principle of scientific management! Such process thinking is completely missing in the students the Indian educational system churns out. I can't remember ever being instructed about such things in any class, either in school or in college, even though I studied operations management.

Lead time optimization - from SupplyChainge to Infor

On a cloudy Portland day almost a decade ago, I and two colleagues - Steve Hochman and John Thorbeck - pulled up in John's black Ford Explorer SUV to the office building that housed our startup, SupplyChainge. We were discussing what to name our revolutionary optimization and operations concept and software, which we believed could double profits at most apparel and footwear companies. "I'm not going to let anyone get out of the car until we finalize the term", said Steve. So, a few minutes later, we had Lead Time Optimization, or LTO for short.

We went on to trademark the term. When we partnered with Infosys (the Infy US CEOs Phaneesh Murthy and Basab Pradhan took a big bet on us) and went out to the industry, we did so under the banner of Lead Time Optimization. You can still find an LTO whitepaper I co-wrote with an Infy colleague Anil Pahwa on the Infosys website here. And there were other partners like IBM and Sun (see a Sun press release here).

SupplyChainge had a few good successes, by our standards. But when SupplyChainge broke up due to personal issues and the assets were transferred to Predictix, we thought the term LTO was gone for ever. So we were surprised today when another SupplyChainge colleague Prashant Kumar found via Google that the multi-billion dollar company Infor has put out a solution offering called Lead Time Optimization, almost totally identical in its target customer, its terminology and its concepts to what we had developed. Their whitepaper on the subject even quotes an article by Prof. Warren Hausman of Stanford, a SupplyChainge Board member, and John Thorbeck, my SupplyChainge co-founder! You can read the Infor Lead Time Optimization whitepaper here. I am skeptical that they have actually done all the very hard work required to make LTO succeed, but am willing to be convinced.

It is somehow satisfying to see that something that was just in my head at one time, and which we as a team had slowly built up into a full-fledged concept, application and commercial solution, is now being pitched by a leading software company. As Steve Hochman, now global head of supply chain strategy at Nike, says today, "SupplyChainge was about 10 - maybe 20 - years ahead of where the industry was when SupplyChainge was founded". And we were not smart enough then to know how to bridge that gap.

To share this blog on Facebook, click here:
Share

Case study: How a software usability workshop can work wonders

We have all heard the usability spiel: that technology is more or less a commodity, that ease of use – and in fact “delight of use” – should be paramount. We have also heard the horror stories of expensive enterprise and consumer applications that failed miserably because they were just too “kludgy” to use. Yet even today, for every wonderfully user-centric design (think iPhone) there are dozens of desktop or web applications that are boring at best, and simply unusable at worst.

Why is this so? Perhaps the problem is that when you are early in the software development lifecycle, there are so many other challenges and moving parts that you have little time to worry about usability. You worry that bringing the “naïve” users in for design discussions will just derail the project or send it off on a tangent. On the other hand, if you wait till you are through with version 1, you have been compromised as well – it requires great courage to admit at this point that usability is poor and that major elements of the application have to be re-designed.

These are formidable challenges. Yet we at Nagarro recently had a very positive series of usability-related discussions with a major client, which may be useful to recount in this context.

The client is one of the world’s leading travel-related companies. We are building a business-critical application for this company that will be used by a handful of users. The IT project management on the client side had invested a lot of intellectual muscle into the functional and algorithmic design of the application. We too put in a lot of effort to make mockups of the entire application UI and these were approved by the client – but by the IT project management, not by the users. The users did see the application from time to time, but in short bursts and they definitely did not have enough time to play with it and give their feedback.

Then after we had a successful development release and were reviewing progress with senior folks on both sides, we all collectively realized that the usability of the application left quite a bit to be desired. It was a depressing moment.

It wasn’t just a matter of aligning data elements or fiddling with the color palette.

It wasn’t even a matter of trying to streamline workflows to reduce the number of clicks required for each task.

It was the fact that the application’s UI looked like it had been designed by highly analytical engineers and scientists, which it in fact had. Would the users – who were neither engineers nor scientists – find it easy to use? Would they buy into it? Would they find all the features that they would need?

Luckily, the client team comprised very intelligent and wise folks. Rather than blame the team members on either side, the client’s senior VP-level executive said, “We should think of this as continuous improvement. You all did a great job, but we now see it can make it even better. Let’s see this as a positive opportunity and move forward.”

So, no blame game, no recriminations, no requests for “free rework”. The gentleman basically had the wisdom to see that when you are building something highly innovative, you may have to iterate to get the design just right.

Still, on our part, we offered the client a free usability workshop with our best consultant, a person skilled at combining “right brain” creative thinking with the “left brain” analytical thinking required for software design. The users were the star participants in the workshop, which started from first principles – what exactly is it that the users want to achieve? Our engineering team got the chance to put itself into the shoes of the users and try to come up with metaphors and overarching design principles that would work for them and, hopefully, delight them.

The workshop ran for two days and turned our previous thinking on its head. Yet everyone was thrilled with the insights and we agreed we’d run such workshops for each new project. The client agreed to fund a few person-months of effort to upgrade the user interface. Perhaps the cost of the overall development rose by 10%. But as a result, the chances of the application being very successful and useful in the hands of the users probably doubled or tripled.

And that’s always the most important metric!

[This article was first published on the Nagarro blog.]

The Double Slit experiment

It's Sunday, and while others may today visit a temple or a church or a mosque, I will be reading one of those books on quantum physics that are meant for lay people like myself ("In Search of Schroedinger's Cat", by John Gribbin). It is a thrilling read. Quantum mechanics results are so whacky and difficult to wrap one's brain around that they're almost mystical.

Let me tell you about one of the simplest experiments that shows the weirdness of the world we live in - the double slit experiment. Perhaps you performed this experiment in school - we did. All you need to perform it is a small light source (a bulb, let us say), an opaque sheet with two fine slits in it, and another sheet to act as a screen. If you put the bulb on one side, the slits in the middle and the screen on the other side, what will you get?

You might think that you will get two bands of light on the screen, one for each slit from the light passing through. But reality is different. Let me turn to Wikipedia to describe it accurately:

The wave nature of light causes the light waves passing through both slits to interfere, creating an interference pattern of bright and dark bands on the screen. However, at the screen, the light is always found to be absorbed as though it were made of discrete particles, called photons.

So you have individual photons not going in a straight line to the screen but instead hitting the screen in certain areas but not others. When you look at the total picture created by thousands of photos, you see these alternating bright and dark bands.

Yet if one of the slits is closed, the interference collapses and all you see is one single line on the screen, not alternating bright and dark bands. The photon acts like a particle moving in a straight line. Hmm...

But it gets weirder...

The most baffling part of this experiment comes when only one photon at a time is fired at the barrier with both slits open. The pattern of interference remains the same, as can be seen if many photons are emitted one at a time and recorded on the same sheet of photographic film. The clear implication is that something with a wavelike nature passes simultaneously through both slits and interferes with itself — even though there is only one photon present.

So:
One photon, one slit = Particle moving in a straight line
One photon, two slits = Something going through both slits and ending up as a particle on the screen (not necessarily in a straight line with either slit)? Yet if you send one photon after another, you will see each crash onto the screen at what seems like a random point, but gradually a pattern will emerge - the same dark and light bands that can be statistically predicted.

Something very interesting is going on here. Feynman once said that the double-slit experiment "contains the only mystery".