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.Relieving the three of all other responsibilities was also crucial. For the duration of the project, they didn't have to contribute to the department's status reports. They didn't have to attend meetings. They didn't have to face all the work-related and did-you-hear-the-one-about interruptions that were routine. They were spared all the politics, the repetitions of "just one more change," and the persistent problems and pressures that characterized so many of our other projects. They had a job to do, and that was their singular responsibility.
Sending them offsite was also critical to their success. Remaining in their cubicles with endless distractions would have been a recipe for failure. But even relocating them elsewhere in the same building would have backfired since they'd have been interrupted repeatedly with "I just need a minute of your time." Having them out of sight, if not out of mind, was significant, especially since none of us worker bees knew where they were. Otherwise, despite management's warnings to stay away, we would have been tempted to drop by just to see how they were doing.
Although this strategy wasn't intended as a grand experiment, it served as such. It was as if management had asked, "How might productivity be affected if we carried out a high-priority project under optimal conditions?"
I would have loved for the company to have treated the situation as a genuine experiment, creating a control group that tackled the exact same project under everyday conditions. Comparing results of the two groups at the end of the mandated time period would have been fascinating. Instead we used our ample experience with other development projects as an ad hoc control group; based on that experience, completion in twelve weeks was unthinkable.
Sending a high-performance team offsite to do the impossible may not be a strategy that IT organizations can use on a regular basis. And it's possible that even this team would have faltered with a longer project or a follow-on project under similar circumstances. But it proved to me—and to many others in the company—that sometimes the best productivity improvements are not the result of tools, technologies, or methodologies, but just leaving people alone and letting them do their job.
