It\u2019s 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\u2014particularly programmers\u2014are 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\u2019s use of these approaches doesn\u2019t necessarily mean that productivity is higher than that of all other knowledge-intensive professions\u2014and, of course, it\u2019s hard to compare across different types of work\u2014but I think it\u2019s fair to say that IT is doing better than most.Take measurement, for example. As the clich\u00bfoes, if you can\u2019t measure IT productivity, you can\u2019t 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\u2019t 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\u2014something that lawyers, doctors and (executive) chiefs can\u2019t 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\u2019ve probably heard of these five-level models, against which thousands of organizations have been assessed (if you haven\u2019t, 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\u2014more than twice as many as in the United States, unfortunately\u2014has 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\u2019s a great yardstick if you want to get better.Then there\u2019s 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\u2019ve replicated this bad practice in the reuse\u2014or lack thereof\u2014of custom code. Remember when everyone was going to reuse objects from an object library? But it\u2019s 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\u2019s the way it used to be in IT, and it\u2019s 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\u2019t. 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\u2019 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\u2019t 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\u2019m 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\u2019t 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\u2019t. Custom software reuse, as I\u2019ve 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\u2019t have software and hardware tools that are specifically designed to make IT more productive and efficient. Programmers\u2019 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\u2019t 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\u2019s 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\u2019ve got to keep running hard.