Every IT organization seeks to improve its productivity in developing systems. Most of the time, these organizations turn to new tools, technologies, or methodologies to help them do the job faster. In this column, Naomi Karten describes one organization's unplanned experiment in improving productivity without relying on any special tools, technologies, or methodologies.
One fine day many years ago, top management in the IT organization where I worked received a mandate from a regulatory agency for a new set of quarterly reports. This mandate was hardly a surprise. We'd known for a long time that it was coming and already should have had the capabilities in place to generate the reports. But we didn't, and we could procrastinate no longer.
Unfortunately, this was no simple project. Achieving the required results would entail, among other things, extracting and consolidating data from multiple incompatible and unsynchronized databases. Developing the system would require skilled coding and in-depth knowledge of the company's business and data environment. Adding to the problem, the deadline—a mere twelve weeks off—was non-negotiable and failure to deliver on time would have had some messy consequences.
IT organizations deal with urgent situations all the time, but the way this one was handled differed from anything the company had ever tried before. Management located some available office space nearby and quickly outfitted it with technology, furniture, and supplies. They tapped three people with development and business expertise, relieved them of all other responsibilities, and sent them off with the specs and the deadline. If the three needed any other resources—technology, people, or anything else—they had only to ask. Otherwise, their marching orders were clear: Get it done, and quickly.
I was a project manager at the time and not privy to the discussions management had in devising this strategy. Everyone believed that meeting the deadline was impossible. Management believed it. The appointed team believed it. And the rest of us believed it as well. This IT organization had never accomplished anything of this kind, particularly in such a short time frame.
One of the three selected individuals was from my team. As soon as he left, we missed him—he was a "life-of-the-team" type. But we were sternly instructed not to try to get in touch with him. I presume management was regularly in touch with the team, but the rest of us heard nothing about what was transpiring. We wanted to be optimistic, but we worried about what would happen when (not if) the team didn't make the deadline.
If there was a last laugh, it was on us. The team didn't complete the job in the mandatory twelve weeks. They completed it in ten. They returned as heroes, and we welcomed them back as such.
In retrospect, it's clear what contributed to the team's success. First of all, it didn't hurt that management selected high-performance individuals, people whose reputations for doing quality work were well known and well deserved. All three were highly motivated and loved a challenge. And each had prior experience in functioning under pressure. If management had put together a so-so, learn-as-they-go team, they'd probably still be plodding and coding today.
Other factors also contributed to success. A three-person team was just the right size. A team of two would have been too small for the work involved. More than three would have led to communication snags, conflicting opinions, and challenges in dividing the work.