Metamodel of a Methodology
The components (i.e., objects) of a methodology and their relationships are shown in the simple metamodel of Exhibit 2. 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.
[3 ]M. Hammer and J. Champy, Re-engineering the Corporation, New York: HarperCollins, 1993.
PROCESS MANAGEMENT
Modern adaptive methodologies support effective rapid project planning and estimating. Although each project is different, process management treats each one as an instance of a generic process rather than as a unique unrepeatable event.
Given a methodology to define it, the generic process c an begin to be managed, both day-to-day and at a strategic level.
Day-to-Day Process Management
Short-term process management is concerned with smoothing the work of the project team. It helps a staff member to answer such questions as:
§ If I am a team member, what am I supposed to be working on?
§ If I am waiting for someone to answer a question on one assignment, what should I work on while I am waiting?
§ What software tool should I use? Where is that tool on the LAN?
§ I am not sure how to do this piece of work; where can I get guidance?
§ What is the status of each piece of my work? How long has the work taken so far?
A process management support tool combines access to the automated methodology with the management of to-do lists of people’
s work, flagging the status on each
piece of work, and helping people capture the hours that they spend on each assignment. First thing in the morning, staff members may look at their to-do list, and pick the work that is most urgent or critical. The process management tool knows the generic task and the relevant software tool and can launch the tool if the staff member wants. At the end of each work session, staff members can record the time that they spent, and if the status of the piece of work has changed, record the new status.
Defining the Term Piece of Work. Each task in the project may imply a single piece of work or multiple pieces of work assigned to different people. The task of producing database design may be done by one person; however, developing code for version test may involve ten people each writing ten programs.
To automate process management, an assignment object is needed. This object describes a piece of work done by a single person that is part or all of a project task, which may be done using a software tool. Each assignment has a status and may involve one or more work sessions, each of which generates a time -spent record that becomes part of the project database.
Incidentally, this means that the tool can generate the person’
s status report and
time sheet at the end of each week. Process management should make the worker’
s
life easier too. Process management feeds project control. If up-to-date status and actual hours-to-date are captured on all the assignments in a project, the project manager can answer many of the project control questions.
Process Management Model The process management metamodel in Exhibit 3
unifies the object methodology and project management. Exhibit 3 is, of course, a very simplified picture. Real-world implementations must deal with many other objects and relationships and resolve the many-to-many relationships shown in the models of Exhibits 2 and 3.
Exhibit 3. Process Management Metamodel Combining Methodology Objects and Project Management Objects
Once deliverable status is automated, changes in status can be used to trigger project events that send messages to the project manager and other people who need to know.[4] For example, possible status values for deliverables might include:
§ In progress
§ On hold
§ Completed
Project events might be specified: If a high-priority deliverable has the status of “on hold” for three days, notify the project manager. In this way the project manager can receive messages that give exception reports about the ongoing status of the project, as a by-product of everyday work.
[4 ]K.D. Saracelli and K.F. Bandat, “Process Automation in Software Application Development,” IBM Systems Journal, 32, no. 3, 1993.
CONCLUSION
With day-to-day process management in place, building reliable project histories based on a consistent chart of accounts, project managers can start to ask the classical question common to continuous process improvement and business process reengineering: Now that the process is defined, how can it be improved?