Unlike the ad hoc approaches that came with rapid application development and the stifling structure of “heavy methodologies” that were used commonly in the 1970s and 1980s, “light methodology” offers e-consultancies a way to complete large, complex Web application projects quickly and efficiently, despite the changing nature of e-project environments.

In this e-business setting, where speed is everything, the move toward a less structured, light methodology is tearing down much of the conventional wisdom about system development disciplines. I recently talked with Jim Highsmith, director of Cutter Consortium’s e-Project Management Advisory Service and a leader of the light methodology movement, to find out why he says IT consultants and project managers must familiarize themselves with these new development techniques.
Cutter Consortium defines light methodologies as “thin-process, thick-skilled, action-oriented project management and software delivery.” These approaches are replacing the heavy methodologies of the past because they:

  • Focus on customer value.
  • Create a culture of innovation and rapid delivery.
  • Appeal to talented people (focus on skill).
  • Facilitate collaboration, knowledge sharing, and decision-making.
  • Decrease time, cost, and defect levels significantly.

Exploring light methodologies
Freedman: After running the gamut from ad hoc processes to very structured, process-driven, “heavy” methodologies, as you call them, don’t many organizations recoil from the risk of moving back toward less structure in their development disciplines?
Highsmith: To look at risk, you have to go back and look at project risk to start with. I define e-projects as “extreme projects,” and these are the targets for these light methodologies. These are large [e-business] projects. Web projects that used to be four- or six-week projects are now getting larger because they deal with legacy systems and those kinds of things, and secondly, they have to be delivered fairly rapidly. The other thing is that they are research-like and mission-critical. What I mean by that is that a lot of these projects are things that we haven’t done before, so they’re projects in which you’re exploring (as opposed to planning) and doing. You’re deciding on what you’d like to have and then exploring how to get there.


Freedman: So, it’s more of a creative approach than one of taking a tried-and-true [course of] implementation.
Highsmith: That’s right. These projects tend to be very innovative, because just coming up with the same old thing is not going to work. At the same time, they’re still mission-critical. We have to manage these projects in a turbulent business and technology environment; because the technology is changing, business models are changing. If you look at that as the project definition—large, rapid, research-like, mission-critical, and carried out in turbulent environments—the risk is inherent to the project, [not] to how you approach it.


Freedman: You often talk about the failure rate of CRM (customer relationship management) projects in [conjunction] with these light methodologies, as if light methodologies would be a valuable tool in managing these projects. Help me understand how the new methodologies would add value to these implementations.
Highsmith: These kinds of projects are more complex from the standpoint of all the things we just talked about, plus the fact that they involve the front office rather than just the back office. They tend to be more knowledge-centric than process-centric. Salespeople will talk about “process,” but that word means something different than when someone from a manufacturing or accounting or back office talks about process. The back-office process is the normal way things happen, with a few exceptions, whereas the front office process is a general guideline, and everything is an exception.


Freedman: And also, when a salesperson talks about “process,” he’s talking about his individual way of approaching a customer or closing a sale.
Highsmith: That’s right, and so there’s much more need for general knowledge as opposed to process-driven information. There hasn’t been a lot of experience with CRM products, and so there’s a lot of mistrust between the front-office people and the IT people. A lot of IT people don’t even realize that there’s historically a lot of animosity between sales and marketing, so the IT people blunder in to the front office and expect it to be like a back-office ERP implementation, and so they lay out this detailed plan and try to implement it, and the front-office folks are just not used to working that way.

Applying light methodologies
Freedman: We’ve talked about what doesn’t work; now, walk me through the ideal world. Help me understand how these light methodologies would be applied to bring up the success rate of these complex, high-turbulence projects.
Highsmith: Let me start by saying that the light vs. heavy debate has been in the wrong dimension. In the process dimension, the discussion revolves around things like how much documentation you have, and I think that’s only one axis of the debate. The other axis is the amount of collaboration, decision making, adaptability, and skills you have. You just can’t reduce documentation without increasing collaboration practices or skill-building practices. There’ve been some studies recently about the difference between documentation and understanding; just because I’ve documented something doesn’t mean I understand it.


Freedman: As evidenced by much of the documentation that’s produced today.
Highsmith: That’s right. There is a balancing act. We’re not likely to do away with documentation, but we need to understand that documentation has a limit in terms of the understanding it can convey, and you need to have practices like collaboration or peer programming, [like] putting programmers together to develop something in a collaborative practice, and with that shared understanding, you may not need so much documentation. You want to have a life cycle in which there’s an exploratory mindset. In my life cycle, I’ve substituted the word “speculate” for “plan.” We don’t necessarily do less planning, but I want to show people that we don’t necessarily expect the plan to work out like that. We expect [the plan] to change over time, we expect the project to change over time, and to evolve over time, as we uncover new things.


Freedman: As we go through discovery and uncover things that we could not have seen up front.
Highsmith: That’s an important point. It’s not that we did a poor job on [determining] requirements, it’s just that things happen that we couldn’t foresee, a change in the marketplace or in the business model. So, we need to have this evolutionary mindset. The other thing is that these light methodologies are feature- or component-driven rather than task-driven. Focused on the business features as opposed to the task approach, in which we say, “Okay, I need to [come up with] the requirements, then the definition, then the programming.” Then there are iterative cycles every three to six weeks, at the end of which we demonstrate back to the client that we were actually able to accomplish something.

Freedman is the e-technology practice leader for the Kansas City office of Influence LLC, the Midwest’s leading e-business professional services firm. He has 19 years of experience as an IT consultant, both as an employee of large corporate organizations like Citicorp and Dun & Bradstreet, and as a principal consultant for Cap Gemini America and ENTEX Consulting Services. Freedman is the author of The IT Consultant: A Commensense Framework for Managing the Client Relationship—currently ranked number two on Fatbrain’s bestseller list of consulting titles—and two upcoming works: The e-Consultant and Building the IT Consulting Practice, both scheduled for publication in 2001.

As a supplement to his “Consultant Master Class” column, Freedman periodically interviews a leading executive, practice manager, or consultant from the top IT professional service firms. If you have a question for Rick, e-mail us.