John Parkinson: The Pursuit of Productivity

In 1991, the Technology Consulting and systems integration business was in a bad way, and the organization I worked for back then was amongst the basket cases. We were just coming out of a difficult post-merger integration effort. Our core business—developing large, complex, custom information systems—was losing a lot of money and not growing very fast. Our CEO demanded that we fix the problem fast. If we failed, our owners would likely close us down. Succeed, and we could be profitable leaders in an exciting, high-growth field. The story of how we fixed the business might make another column or two, but I mention this background here because it sparked my interest in the topic of productivity.

Productivity is generally defined as the output produced for each hour worked. So it’s related to efficiency (the ratio of output to input) but not necessarily identical to it. Generally we look for ways to get more output out of the hour. You then go back and see if you actually need more output. If not, you can cut the total number of hours required. Between 1991 and 1997, I ran a lot of collaborative research around productivity generally and software-development productivity in particular. We also looked at productivity in a lot of other areas around the use of technology in business.

I discovered that there seemed to be five interrelated approaches to improving productivity:

  • Eliminate unnecessary work;

  • Eliminate unnecessary re-work;

  • Shorten the duration of effort;

  • Automate as much as possible; and

  • Manage demand.

    The first four approaches are focused on better process design. The fifth is focused on—well, focus. By working with “customers” to limit the number of things you must be good at, you can reduce the number of variables to manage and improve your ability to get the first four approaches to work.

    If you do these five sets of things, you can just about double the overall productivity of the average application-development effort immediately—and continue to improve productivity steadily thereafter. If you use some of those savings to redesign your development processes so that the applications you develop are more inherently maintainable, you can get an equivalent improvement in lifetime costs, which dwarf development costs by a factor of between 5 and 11 times. And those savings really add up: Over a decade, you could theoretically take out between 50 percent and 80 percent of the operating and ownership costs of your business automation, and probably realize productivity gains of between 35 percent and 50 percent. You don’t get all of the theoretical productivity gain because of “backlog”: The more productive you get, the more you will be asked to do. Even with an aggressive “customer”-education program to help direct demand toward business-critical areas, you can’t do all that much about this increase; there is simply too much demand for automation that provides a decent ROI.

    Good news for the IT organization, right? Well, yes and no. It turns out that there is one final variable we have to add to the productivity equation: the unit cost of an hour of effort. In the U.S., it runs at about $85, fully loaded and blended over all of enterprise IT (it’s about $55 for skilled developers, though of course you need more than just developers to make an IT organization work). Our productivity efforts have done nothing to reduce this; we are just getting twice as much output from that $85 of investment. Unfortunately, there are resources available elsewhere that don’t cost as much. I can progressively reduce that $85 to $65 if I go offsite and near shore (say Canada or Ireland), $45 if I go mid-shore (Eastern or Southern Europe and “mature” India), or even $12 if I go far shore (“emerging” India and China). Generally, I lose some productivity when I do this, because the effort to manage and coordinate the process increases, and it will cost me some upfront investment to create a distributed development process. But I don’t lose as much productivity as I gain in lower labor costs. On a like-for-like comparison basis (fully loaded, blended rate), my hour of effort probably costs me around $40 in India and $25 in China—in part because I can’t yet send all the work there.

    This is still not a true like-for-like comparison. I really ought to factor in the basket of operational risks that come with geographically distributed application development, operations and maintenance. These risks come from cultural, financial, economic, legal and geopolitical factors, and they are real—ask any investment banker who invests in these places. If you “weight” that $40 hour of resource with an appropriate capital risk factor, the comparison would be more like $75. That’s closer to our starting point—but still $10 an hour better, and look how hard I had to work to get the “real” cost up to that number.

    Ten years ago, there were other factors involved. Skills (especially language skills), current technology experience and adequate, reliable infrastructure—especially bandwidth—were all lacking or expensive. Not any more. A combination of globalization, long-term investments in education, and the availability of surplus modern technology after the Internet bubble burst has allowed India and then China to catch up. Today, there are very few things you can do with technology that you can’t do offshore—in Eastern Europe, India, Southeast Asia and China. If you are willing to invest in broadband immersive videoconferencing and high-speed data links, I would argue that there is nothing you can’t do there. And that includes locating your data centers in areas where real estate is cheap, electricity is reliable and cheap, and security is a way of life.

    As these offshore markets develop significant consumer economies over the next two decades, the risk premiums will reduce sharply; as one prominent economist remarked last year, you don’t generally make war on your customers. Of course, as a consumer society takes hold in these offshore regions, we will see a rise in real basic costs that will partly compensate for the drop in risk premium. There will also be more local demand for technology services, thus reducing the supply somewhat. This macroeconomic stuff is hard to model, but the cost differential for an hour of software engineering capacity will probably stabilize at around 20 percent in favor of these offshore markets by 2010.

    Faced with this outcome, what should IT organizations in North America and Europe do? There is a real chance of knee-jerk protectionism in an election year—but in the end that just hurts competitiveness, probably more so in the digital world than it does in the analog. There is no question in my mind that we will see technology development and maintenance work migrate to these lower-cost resource pools. As more experience builds up, the incremental process costs of going offshore will decrease. Other risk factors will persist, but absent a major pullback in globalization trends, even these issues will gradually ease. So the right questions are: How do I take advantage of this opportunity to reduce my operating costs? And what should we be doing with the homegrown resources that will be displaced?

    These are hard questions, and I certainly don’t have answers, or even ideas, for all of these issues. But I would suggest, in the words of one of my colleagues, that we should abandon denial and “get used to it.” I’d also suggest that, faced with the inevitable, we should be getting ready.

    John Parkinson is chief technologist for the Americas at Cap Gemini Ernst & Young.

    Illustration by John Kascht

  • Get the Free Newsletter!

    Subscribe to Daily Tech Insider for top news, trends, and analysis.

    Latest Articles