|
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. | 
Disclaimer
