Big Offices Increase Productivity

It’s pretty common to beat up on IT organizations for one reason or another. Yet when it comes to knowledge worker productivity and effectiveness, some IT people—particularly programmers—are the poster children of knowledge workerdom. In fact, some of the practices employed in IT are considered state of the art in enhancing knowledge work.

IT organizations are among the only knowledge work institutions on earth to measure productivity and processes, reuse assets, work collaboratively across organizations, and experiment widely with new approaches. IT’s use of these approaches doesn’t necessarily mean that productivity is higher than that of all other knowledge-intensive professions—and, of course, it’s hard to compare across different types of work—but I think it’s fair to say that IT is doing better than most.

Take measurement, for example. As the clich¿oes, if you can’t measure IT productivity, you can’t manage it. There are two domains in which IT measurement is relatively advanced: programming, and IT processes and capabilities. In programming, some organizations have measured for decades the production of either lines of code or function points, and various researchers have analyzed the considerable variance in productivity. These measures aren’t perfect, but they have allowed us to begin to understand differences across individuals. How many times have you heard that the best programmer is 10 times as productive as the worst? We may not know exactly how to bring everybody up to that high level, but we at least know the degree of variation—something that lawyers, doctors and (executive) chiefs can’t measure nearly as well. By the way, one of my other favorite research findings is that programmers with bigger offices are more productive. Feel free to try that one out on your boss.

The other primary domain of measurement is the assessment of IT processes, particularly software engineering (but also software acquisition, people management and the development of software-intensive products). Thanks to the Software Engineering Institute and researcher Watts Humphrey, we have an international standard for the quality of software engineering: the Capability Maturity Models. You’ve probably heard of these five-level models, against which thousands of organizations have been assessed (if you haven’t, check out the CMM link at www.cio.com/printlinks). CMMs have been enormously influential in the offshore movement of software development to places such as India and China. The fact that there are many organizations certified at the top Level 5 CMM in India—more than twice as many as in the United States, unfortunately—has led many companies to send work offshore with confidence (see our outsourcing special report starting on Page 44). There is no similar global standard for other forms of knowledge work capability, unless you count the ISO 9000 family of standards for manufacturing quality. Of course, the availability of a global standard cuts both ways: It means that knowledge work will flow to where it is best and most cheaply done, and that may well be outside your company or country. But it’s a great yardstick if you want to get better.

Then there’s asset reuse. IT organizations are among the best of a bad lot in this regard. Knowledge workers generally create knowledge from scratch, rather than modifying or reusing previous efforts. In IT, we’ve replicated this bad practice in the reuse—or lack thereof—of custom code. Remember when everyone was going to reuse objects from an object library? But it’s never really taken off in a big way.

Why do IT people get so much credit for asset reuse? The answer is: packages, my friend, packages. Our profession has made great use of software packages, and it has bumped up our productivity enormously. Imagine if people had to write their own accounts payable systems, database management systems or word processor systems? That’s the way it used to be in IT, and it’s still the way it is for most other types of knowledge work. Lawyers have only recently begun to sell legal advice in reusable packages. Doctors and engineers still don’t.

IT people sometimes become more productive by leveraging the efforts of others, both inside and outside their organizations. Most good software architects attempt to break up work so that multiple people can work on different parts without getting in each others’ way, like a big architectural and construction project. But IT people are most impressive in their collaboration when they work across organizational boundaries. Take Linux, for example, which was developed by thousands of people across hundreds of organizations. And they don’t even charge for their time, which makes for a very high level of economic productivity!

The final productive touch for the IT profession is the panoply of attempts to improve basic processes. This is sometimes described as making software development “a professional engineering discipline,” though I’m not sure how much we actually have to learn from other types of engineers. But not all improvement approaches are heavy on discipline and process. I gravitate toward “extreme programming,” which relies more on small-team dynamics and a culture of urgency than on a deep process orientation. Prototyping has been another improvement approach that doesn’t require an anal-compulsive nature to implement.

I have to say, though, that IT folks are not as productive as they could be. Some of the productivity approaches could have been adopted much more broadly. Many IT processes can be measured, but aren’t. Custom software reuse, as I’ve mentioned, has largely flopped. Some organizations still build their own systems when they could be using packages. And while the improvement approaches such as engineering and extreme programming receive a lot of publicity, many IT shops studiously ignore them.

Ironically, the productivity aid we have taken least advantage of is information technology. Sure, we use technology to develop and configure software, but we don’t have software and hardware tools that are specifically designed to make IT more productive and efficient. Programmers’ workbenches and computer-aided software engineering have largely gone the way of the dinosaur (for reasons that are complex, only partially known to me, and not what I want to write about in this column). And even though much software development takes place in teams, I don’t know of many exceptional efforts at using collaborative software tools to help develop software.

In the past, adopting knowledge work improvement processes in IT was a good thing to do, but it’s unlikely that anyone ever got fired for not doing it. Now, however, many IT people are battling with offshore providers to keep their jobs. Whether IT workers use all the productivity tools and approaches at hand will determine whether the work is done in Bangor or Bangalore. Fortunately, we have a head start compared with other knowledge workers, but we’ve got to keep running hard.