In the discussion of the article “Consider DSDM as an XP Alternative,” members questioned the suitability of the European development method for use on large-scale projects. The discussion raises the question of what factors distinguish a large-scale development initiative from a small one in terms of methodology selection. Specifically, what are the points to consider when choosing a development methodology, based on the size of and expense of the project?

In the case of DSDM, the governing user consortium established criteria along these lines five years ago. These points, and a few others, are useful in evaluating the appropriateness of methodologies, in general, for large-scale projects. Before selecting a methodology for the big project you may be facing, ask yourself these questions:

  • Is the proposed system, regardless of cumulative size, easily broken down into smaller components?
  • Can those components be recycled (i.e., used in multiple applications)?
  • Can you easily differentiate the functions encompassed by the system and their associated user groups?
  • What is the time frame for the system’s development and deployment (and is that time frame fixed)?
  • Can the project requirements be clearly prioritized (and is it possible those priorities will change)?
  • Are the detailed system requirements likely to be modified as the project proceeds?

Have a map on hand before you start the journey
The questions above must be answered before you can make a prudent choice of development methodology. These points are absolutely key in bringing a project together on time and on budget, and with the promised functionality. The proliferation of methodologies is now a mixed blessing; there are many good choices, and each has its own unique strengths that can be put to good use in a particular situation. But to choose arbitrarily, or to choose with too little specific attention to the challenges your team faces, is like setting out on a cross-country journey without the correct map. You’ll be lost in no time, no matter how true your course was at the start.

Anticipate the barriers
In the mid-80s, as OOP technologies were beginning to form in the minds of software tool developers, there was a last gasp of a development methodology sect (in the 4GL mainframe world, of all places) that promoted a “holistic” approach to system development. In this style of thinking, often enabled by products like Unisys MAPPER, “super programs” were the big thing. These programs that did everything imaginable by fully exploiting metacommands, faster processors, and the then-new relational databases.

Rather than breaking down big jobs into small parts, the idea was to create touchy-feely software systems that were like multilimbed leviathans. The results were instantly gratifying to users—during the first month of deployment. But such systems were maintenance nightmares, especially when a new release of the platform came out, and users wanted changes that were as difficult as root canals to implement.

Now, in the post-OOP universe, the situation is reversed, but the dangers are the same. Your project breaks down into submodules, but the danger there is that the hands-on developer can lose sight of the application from the business point of view, and thus relinquish downline maintenance. To prevent this from happening, look hard at the methodology you are considering. Does your methodology promote ample review of business fitness of components? Does it promote maintenance evaluation at the lowest levels? Find the balance between what it requires of you and what you anticipate the post-deployment needs of the system to be.

Do the components of your proposed system need to be recycled? Do you anticipate redundancy, or dual use? Most systems, due to rapid development and deployment requirements, really need maximum mileage from work done at the lower component levels. Does the methodology you are considering call for system review that identifies such opportunities? Does it provide for multiple-use fitness evaluation, testing, and documentation? Does it offer structural suggestions for the system’s object library?

Taking care of business
Most large systems today are made complex by the interaction of many different subsystems, encompassing business functions that are often very different in nature but necessarily related. What degree of integration between business modules does your system need to achieve? The capacity of your development methodology to accommodate you in this area cannot be overstated.

The considerations here are endless: user interface is critical, for instance. Are the user groups whose routines will be changed easily differentiated? Are the business functions and the ways in which they will change thoroughly defined and clearly accommodated in the system design? Most importantly, are they driven by the users’ and the company’s partner organizations? Are the integrations that are planned useful and practical? And (this is a big one) what is the priority associated with the success of each functional interface between systems?

You must know the answers to these questions. Why? Because you must make the answers part of your methodology selection. The development paradigm you select may need to do some formidable jobs. Must user interface changes be reversible? Must data be immediately recoverable from pretransport stages, if downline processes abort? Is there instability (i.e., time cost) in a human review process where different business units interact? Do you have processing objects used in multiple and disparate functions that will rely on competitive users for change approval? Your chosen methodology must force the asking of questions like these as you evaluate the system design.

Accommodating change
Since senior management often harshly evaluates business fitness at initial deployment, and expectations here are high in this ultra-competitive age, you must modify, modify, modify as you go. Does the methodology you are considering facilitate rapid modification? How do prototyping and testing overlap, and what are the suggested personnel assignments for these tasks? What is the documentation standard? Is reversibility a priority in this methodology, and does it promote coding and design standards that make reversibility comfortable? You must give serious consideration to these questions.

Staying on course
Finally, carefully consider your biggest and most critical issue: time frame. The frightening reality of IT today is that most large-scale projects run far over schedule and far over budget. Such overruns win you no points, and so you need to choose a methodology that offers you tools for staying your course.

Do project phases overlap conveniently for your particular environment? To what degree are system design and business function analysis concurrent? Are the participating users given the freedom to participate in continuous testing, if it’s required?

Finally, there are the biggest questions of all: Where schedule is concerned, to what degree are your system goals clearly prioritized (by senior management and user groups alike), and how far does your methodology go to help you structure tasking and scheduling around these priorities? And (this is critical) how easily may these things be rapidly restructured?

This is paramount, and you must give careful thought to it before choosing a development methodology. The only way to meet senior management’s expectations at the time of deployment, when a variable amount of modification has trashed your budget and schedule, is to know what you can jettison from the system and what you can’t. Today’s rule is, deliver 100 percent of the most important 80 percent of the system, and let the less-important 20 percent go if you must. Choose a methodology that takes you there.