Focusing on speed doesn't change just how people work -- although we certainly work differently from most companies. Speed changes all the fundamentals of business: how we train our people, how we relate to our clients, how we manage projects.
Forget about writing software for a moment. Think about hiring. Five years ago, this company had about 100 employees. Today we're adding nearly that many people every month. We've established a hiring cycle of 60 days between when we recognize a need and when a new hire reports for duty. That timetable -- that focus on speed -- forces us to be creative and disciplined about how we recruit, interview, and evaluate people.
Or think about strategy. We have a plan to be in 70 offices by the year 2000; we'll be in more than 30 by the end of this year. We've declared that any new office, anywhere in the world, must be profitable within nine months. We've developed a complete methodology to do this -- every step from the moment you think about opening an office to when it's fully staffed by a local team. The time dimension has shaped how we grow the business.
Let's stay with the business basics. What are some other fundamentals that change when you compete on time?
You have to manage the fallout from speed. We have 1,300 people working on 200 or 300 projects a year. They're moving around all the time, working with different clients and project managers. That's great; it's one of the benefits of working fast. A typical project lasts about six months. So if you've been here for two years, you've worked on four or five major projects. That's a real plus for young people developing their careers.
But we don't want a company of nomads who migrate from project to project. That's why we created the role of resource manager, senior people who act as career guides and mentors. It's a voluntary role, but most people consider it a privilege. Resource managers watch out for the young people they advise, check on their development, point them to interesting work. They also have a voice in who gets assigned to which projects. They'll tell a project manager, "I know two people who are just about to come off a team. They'd be great for your project."
That's so important. If we're not developing our people, they're going to leave. I would if I were them. If you're 28 years old and you've been at a company for five years, and what you're doing hasn't changed dramatically, it's a sign that you should move on.
It's interesting you mention 28-year-olds. So much of this company's personality revolves around youth. Are people in their twenties the only ones who can work this way?
It's not about age; it's about attitude. We call it Generation X thinking. Young people today are more different from their baby-boomer parents than the baby boomers were from their parents. They're interested in adding new capabilities and staying mobile. It's important to do work that's "cool." They want time and attention from their supervisors. That's more important than money. They also love surprises and fun. They don't want to know what's going to happen every day. They want to come into the office and see a birthday cake, have a spontaneous celebration, get a new assignment.
We hired lots of very young people early in our history. We figured it would be easier to train them in our methodologies than to retrain more senior people from other companies. Pretty quickly we realized that these people had very strong ideas about how they wanted to work, and that those ideas were absolutely pervasive. Many of us came from different environments, different kinds of companies. As senior managers, we had to decide whether we were going to adapt ourselves to these young people's thinking or ask them to think like us. We made the right choice. Their personal attributes are very conducive to building a fast-growing company.
Let's talk about writing software. It's the black hole of the new economy. Companies spend $250 billion a year on information-technology projects, and only 16% of them are completed on time and on budget. What's the problem?
The first thing to understand is that 90% of the problems in software happen before you write the first line of code. Applications are late because the people building them don't know what the users really want -- which means they keep changing. Or they're late because users ask for every feature they can imagine on the theory that if they don't get it now, they'll never get it.
In most companies, the front-end design process alone takes six to nine months. In our Rapid Solutions Workshop we do it in three weeks. The time compression is incredible. It can be an ugly, frightening experience at first. You go through a valley of despair. Users are laying out what they need, and the technology people want to crawl into a hole. Our people guide them through what features make economic sense, what you can tie to real economic benefits. We've been through hundreds of these things in the last five years. I tell you, the results are amazing.
The second problem is that most applications aren't considered urgent enough to command serious attention. We build only what we call "numerator" applications -- software designed to generate revenue rather than cut costs. Our systems relate to customer service, order fulfillment, sales, distribution. They're designed to increase market share and get products to market faster. Senior executives will get very involved in those projects. And users will stay involved as the system gets designed. Our focus on the numerator helps us, too. At the end of a Rapid Solutions Workshop, a client has two choices: start building the system tomorrow or spend six months sorting through competitive bids. I say to them, "Do you really want to spend six months on bids when you know this application will generate returns of $2 million a month? Are you prepared to give up $12 million on the chance you might save a few hundred thousand dollars on development costs?" Remember, if you don't capture those returns, they're gone. You never get them back.
What are some other techniques you use to accelerate the software-development process?
We write most of our applications -- not all, but most -- using object-oriented software. We're always asking ourselves, "How do we reuse objects we've created for other applications?" We use an internal networking system called KnowledgeShare to share objects. Today, technology we create in Amsterdam gets used in applications we're building in California.
But KnowledgeShare is having an even bigger impact than reusing software. It's allowing us to reuse knowledge itself. We share everything: technical documentation, presentations, lessons from individual projects. It's all about making quick connections: "I just finished a project for a client. Here are the 17 lessons I learned. Before you start on your project, why don't you look at them?" The most important knowledge is what you learned today that someone else can apply tomorrow.
Recently I was on a trip to Ireland with Fergal Mullen, our director of mergers and acquisitions. In the middle of the trip we met a potential client in the insurance business. He asked us to visit the next morning and make a presentation. We literally had to put it together overnight. Fergal went into KnowledgeShare, discovered something we'd done on the West Coast a few days before, downloaded the presentation and all the documents behind it, and stayed up late that night putting it together. We walked in the next morning and knew exactly what we were doing.
The speed is just incredible -- taking work that had been created in California and using it in Ireland a few days later. Once people see this kind of impact, they become religious about sharing knowledge.