Jim Highsmith Jim Highsmith
Director and Fellow

Jim Highsmith is Director of Cutter Consortium's Agile Software Development & Project Management practice and is a Fellow of the Cutter Business Technology Council, which prepares the Opinions for Cutter's Business Technology Trends and Impacts service. Mr. Highsmith is also a frequent keynoter at the annual Cutter Summits . Mr. Highsmith is the recipient of the 2005 Stevens Award, in recognition of his work on Adaptive Software Development and agile processes.

Mr. Highsmith has 25-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. He has consulted with IT and product development organizations and software companies in the U.S., Europe, Canada, South Africa, Australia, Japan, India, and New Zealand to help them adapt to the accelerated pace of development in increasingly complex, uncertain environments. Mr. Highsmith's areas of consulting include agile software development, project management, and collaboration.

Mr. Highsmith has held technical and management positions with software, computer hardware, banking and energy companies. He holds a B.S. in Electrical Engineering and an M.S. in Management. Mr. Highsmith is author of Agile Project Management: Creating Innovative Products and Agile Software Development Ecosystems (Addison-Wesley, 2002), which portrays the principles, problem domains, key industry leaders, and project success stories, associated with Agile methodologies. His first book, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House, 2000) won the prestigious Jolt Award. Jim is also co-editor, with Alistair Cockburn, of the Agile Software Development Series of books from Addison Wesley. He is a coauthor of the Agile Manifesto, and a founding member of both the AgileAlliance and the Agile Project Leadership Network, where he serves as president.

A frequent speaker at conferences worldwide, Mr. Highsmith has published dozens of articles in major industry publications and was the editor of Cutter's eBusiness Application Delivery newsletter. His ideas about project management in the Information Age have been featured in ComputerWorld and the Economic Times in India. He can be reached at consulting@cutter.com.

For more by Jim Highsmith, visit the Cutter Consortium Bookstore:



The Changing Face of Project Management

An Interview with Jim Highsmith, Cutter Consortium Senior Consultant and Director of Cutter's Agile Project Management Advisory Service

Is project management changing as a result of e-business projects?

People are beginning to realize that the traditional approaches to project management and software engineering are necessary, but insufficient, for e-projects. E-projects vary in their type and scope, but they generally all require three things:

  1. Fast time to market
  2. Very high quality (as we hook Web sites into back-end systems, they're doing transaction processing, so they have to be robust)
  3. Very agile (the team must be able to respond to frequent changes during the project)

I recently did consulting engagements with two very large system integration companies in Asia (bordering on the largest in the country). In both cases, their projects were traditionally very successful -- one company was certified CMM Level 4. But both companies recognized that the e-commerce projects they were going to be doing required a more innovative way of managing those projects. They wanted to maintain some of their traditional approaches, but they knew they needed to implement a different style for e-projects.

I see this as a long-term trend. We're five years into a 20-year transition into e-business. We'll continue to be in an environment where lots of things will be changing, the business models will be very turbulent, and the technology will be changing rapidly. There's a slew of technology that's brand new that we really don't know how to use yet. For example, Java, which has been around for five or six years, is just now enterprise-ready. Likewise, some of this new integration middleware is just in its first iteration.

The number one issue for the implementation of all these great ideas for e-business is pure project management. It's the definitive skill to make those things happen. And we're not talking about traditional project management.

What should companies be focusing on in terms of Agile Project Management?

I look at three critical skills for the new project management approach: innovation, discipline (to achieve high quality), and adaptability. Of those three, if you don't have innovation, you're dead. Because there is so much new technology, you have to have an environment where people are encouraged to come up with new answers, make mistakes and learn from them, and look beyond the norm.

Traditional practices focus on control; they're based on the premise that projects are fairly predictable. I can lay out a plan and then control to that plan. Traditional lifecycles are task oriented. First we do requirements, then we do design, and so on. The project plans are relatively fixed. We know the requirements, we know what we're going to do (or at least we think we do), and the project is expected to go pretty much as planned.

In an e-project environment, the development lifecycle is exploratory in nature. We have a plan, but we don't expect the plan to work out exactly. It's a direction we want to go, rather than a fixed destination. Additionally, the development lifecycle is focused on delivering value to the customer using a feature-driven approach. In short-interval cycles, we deliver something useful (a business feature) to the client, as opposed to starting out by delivering documentation. For example, the first cycle might involve delivering three partial features. We can't explore by looking at documentation -- we have to explore by looking at partially completed, actual features.

How should companies doing traditional management begin to shift their focus?

Traditional approaches are based on the idea of control, and they're focused on optimizing -- we've done it before, and we're focused on how to do it better. Many e-projects have not been done before, so we need to focus on how we can adapt over the course of a project. However, some of the practices are the same. We still do good project initiation and good project planning -- but we don't view the plan the same way.

The hardest thing a group doing traditional development has to come to grip with is the change in perspective. The best impetus for this is fear. The truth is, in most cases, they're already scared -- they know what they're currently doing isn't getting the job done. They're just not sure where to go. They're trying new things and looking for the "next practice."

One of the things I stress with organizations trying to make this move is that Agile Project Management is focused on different problem domain than traditional practices. It's not that traditional practices are wrong -- it's that we're tying to solve a different problem. When you get into the details of the new processes, you usually get some resistance because you're telling people to do things differently from what they've traditionally done. But I always return to the idea that we've got to put things in place that foster innovation, creativity, and adaptability to get this thing out the door.

Have you seen successes in companies using new project management practices?

I've been working with a pharmaceutical company in Canada. They have been building their software like this, both for internal use and external sales, for about five years. I talked to the IT director recently, and he said, "Lots of things have been changing in our organization, some for the good, some for the bad, but we're still using adaptive practices."

However, showing success by traditional measures can be difficult. On these kinds of projects, the measure of success is often very different from those used in the past. What's important is not whether the project came in on time and on budget; it's "Are these projects creating successful products in the marketplace?" These are people on the cutting edge -- they're much more interested in getting their projects out the door than in measuring stuff.

Another measure of success for these types of project management practices is taking ad hoc practices and adding some formality. For example, one of the larger banks in New Zealand is using an adaptive approach for their Web-based projects. They realized that their traditional approach to software development wasn't appropriate for their Web-based stuff, and their Web development staff said, "We can't use the traditional stuff for our Web projects, so we're going to do it completely ad hoc." When they implemented adaptive development, they were able to add some structure to their Web-based development.

Similarly, I'm working with two dot-coms. I'm helping them move from an ad-hoc environment to one with some framework and structure. It's not a traditional, highly controlled process, of course -- that would be much too heavy for this type of environment.

Jim Highsmith