Methodology, a word with multiple meanings, is often used carelessly to make some simple technique or approach sound more impressive than it is. A precise definition of the term is:

A methodology is a generic knowledge base about tasks, techniques, deliverables, roles, tools, and tool use for carrying out some complex class of projects such as system development, plus a mechanism for adapting a generic knowledge base to each specific project.

Methodology Tasks At minimum, a methodology is a description of tasks to be done in developing a system. The scope of a methodology might be wider than just development and cover planning, enhancement, and maintenance. Tasks can include designing the database and coding the programs. Each task typically has one or more recommended steps to be done in sequence.

Methodology Techniques Some methodologies provide a somewhat detailed description of how to do tasks. However, these descriptions usually apply to more than one task. For example, a description of how to do a data flow diagram applies to the task of defining the process model as well as to the task of designing the transaction flow. Especially when a methodology is stored in a knowledge base on disk, it is convenient to separate the technique descriptions from the tasks and to provide a way (e.g., hypertext) to display a technique for a relevant task only when needed.

Deliverables Each task should produce some tangible output, usually called a deliverable or work product. For example, designing a database should produce a deliverable — database design — and the methodology should specify what a database design may contain.

Roles A methodology should also deal with the skills for each task. The most flexible way of doing this is to define roles. On a given project, one person may play several roles, or one role may be played by several people. The methodology should specify the role responsible for each task, and the other roles that may contribute to the task. Thus, for the task of designing the database, the prima ry role might be the DBMS specialist and the contributing role, the modeling specialist. For each role, a methodology should define the skills, experience, and background that are relevant. Roles are an important way to involve the right businesspeople in the project in the right way. Just as one of the principles of business process reengineering is to consider how the process adds value for its ultimate customer,[3] so the definition of roles that need to be played by various members of the business community helps to ensure that the application adds value to the business.

Task Dependencies If a methodology is to be useful for project planning, it should contain information about which tasks must be completed before other tasks can be started. For example, a methodology can stipulate that the task of designing the database is a predecessor to the task of specifying data security constraints.

Tools and Their Use Increasingly, deliverables are produced with software tools that often run on workstations. A methodology must describe each relevant tool and enable tools to be linked to tasks so that developers know which tools are recommended for which tasks. In many cases, a methodology also lists tips, tricks, and traps that are associated with using a specific tool to do a specific task. It is convenient to store tool usage descriptions separately from the tool description itself. For example, in addition to a description of a spreadsheet tool, the tool usage of a methodology for the task define the users at various locations might read, “Always list the locations down the y-axis of the spreadsheet and the types of user across the top.”

Phases and Deliverable Packages Tasks are usually grouped in phases, primarily for management control purposes. As development projects become more iterative, phases have less and less meaning, because the same tasks are being repeated for each iteration of the prototype or each version of the development application. It is often clearer to focus on packages of deliverables that may be grouped for management or user review. These deliverable packages may have such names as requirements package, discovery prototype package, and outline design package.

Metamodel of a Methodology

In automated methodologies these objects hold text and bit-mapped diagrams, with hypertext cross-references between them. In the future, a knowledge base will contain multimedia objects as well. Looking up a technique will involve opening a video window on a workstation, with an overview explanation of the topic, followed by a menu of more-detailed subtopics. This kind of adaptive video briefing will provide just-in-time training in the future.

Need to Customize

Obviously, no methodology of this kind is static; it needs to be an evolving knowledge base customized for the vocabulary and practice of each organization. Commercially available methodology products should be regarded as starter sets from which the evolving organizational knowledge base is to be built. Each organization needs a methodology administrator who is charged with the constant improvement of the knowledge base and adapting mechanism, as part of the continuous process improvement approach.

Need to Adapt for Each Project The knowledge base for a methodology can become quite large; several binders on a shelf or 3 to 20 megabytes of online disk space are common. Valuable as this information is, it is often useless to the people on the project. A project manager is in the position of saying, “Out of all this good material, which parts are relevant to me and my people on this specific project, and which parts can we neglect?”

The Adapting Mechanism A methodology must include in the description of the knowledge base a mechanism for adapting the generic knowledge base to each specific project. Pulling binders apart by hand to make a project subset of the methodology is obviously not feasible. Some methodologies offer templates for the various types of projects, which can include package installation projects and client/server projects. Even within such a template, however, projects differ markedly, and a project manager is still left with the job of adapting the template to the project at hand.

What seems to work well is to have an automated questionnaire that asks a project manager such questions about the new project as “Will the application serve multiple departments?” or “Will there be a change in communications network loading?” Once the questions have been answered, a rule-based job can be run, to extract the minimum set of tasks from the generic methodology and create a methodology that is unique to the project. The rules can have the following form:

IF the answer to the question "Will there be a change in communications network loading?" is Yes THEN include in the project the tasks:

"Review the network map"

"Do performance analysis of network loading"

Helping the Project Manager

With the sort of organization-generic, project-specific methodology described here, projects can be started up more quickly and, given a project history database, can be estimated and staffed more effectively. In an hour or so a project manager can answer the first six project planning questions:

1. What tasks have to be done?

2. Which of them must be complete before others can be started?

3. What skills are needed for them?

4. Who is available when, for how much time?

5. How long will it take?

6. How many people are needed?

To answer the first question, a project manager works through the questionnaire and runs the rule-based job to generate what the methodology thinks is the minimum set of tasks for this particular project. The second question is answered by the same job, which has the ability to work out project-specific dependencies from generic dependencies.

To determine these dependencies, the methodology says that task A must be done before task B, which must be done before task C, which must be done before task D. For example, if a result of the questionnaire is that tasks B and C are ruled not relevant to the project, the tool should then create the project-specific dependency that task A must be completed before task D.

To answer the third question, using the project tasks the tool can determine the subset of roles that are relevant to the project, list them for the project manager, and, given a project history database, list the people who have played each role on previous projects.

To answer the fourth question, the project manager needs access to the future schedules of the people who have the necessary skills. Of course, people are sometimes assigned to a project full time and this simplifies the scheduling job. The most effective way to answer the last two questions is to have project histories available, so that estimates can be based on actual experience.

The adaptive mechanism of a modern methodology means that, although every project is different, the same chart of accounts is used to build up the history. So, in every project that involves database design, for example, the time involved is charged to a generic task with a standard identifier and a standard name.