24-04-2012, 10:14 AM
Agent-Based Project Management
Agent-Based Project Management.docx (Size: 86.63 KB / Downloads: 28)
Abstract: Integrated project management means that design and construction planning are interleaved with plan execution, allowing both the design and plan to be changed as necessary. This requires that the right effects of change need to be propagated through the plan and design. When this is distributed among designers and planners, no one may have all of the information to perform such propagation and it is important to identify what effects should be propagated to whom, and when. We describe a set of dependencies among plan and design elements that allow such notification by a set of message-passing software agents. The result is to provide a novel level of computer support for complex projects.
Introduction
Today, traditional project management methods are not sufficient for managing the many tasks in the design and development process. They do not take into account all the sources of change, the task interactions, and the necessity for distributed planning. They do not provide proper change notification: notifying the right agents (people or software) of the effects at the right time in the process.
Process coordination is always most complex in domains that require artifact design and construction planning. This is particularly true when the artifacts are large and many people and software tools must be coordinated and managed.
When design changes cause plan and schedule changes, the problem is worse than simply modifying the design. Somehow, all the people assigned to the affected tasks, and no one else, should be notified of the change and how it affects them. This difficulty is reflected in the expense of coordinating projects and in the achievement of suboptimal results[Benda,McKinsey].
Example Problems
The following few examples serve both to illustrate this difficulty and to suggest the kind of questions answered by this paper.
"Fast track" construction attempts allow the architect to finish or change the design after construction has started. These design changes frequently necessitate a change in the construction plan and or schedule. As a simple example, suppose that the design calls for concrete roof tiles. Then the wall plaster must be applied after the roof is built, or the heavy tiles will deform the walls causing the plaster to crack. But if it is decided later that lighter fiberglass tiles should be used instead, it is no longer necessary to wait to plaster the walls - the two tasks can be more concurrent and the plan schedule shortened. What kind of computer support could ensure that when the architect changes the material specification, the contractor will be notified of the possibility of shortening the schedule?
Suppose that we are designing and building a prototype of a new gyroscope for use in navigation equipment. Suppose further that one engineer decides that high resolution encoders is a better design than the rate sensors plus low resolution encoders in the current design. How can we ensure that the machinist who is designing the frame to hold the components will be notified of this change?
A hospital adds a new surgery wing. The architectural specifications for the width of the doors into the new wing were determined by the width of the hospital beds that had to be wheeled through them. During construction of the new surgery, someone in the hospital decided independently to buy new, much wider, beds. What kind of process mechanism could have avoided the subsequent remodeling of doors in the freshly built surgery?
Imagine building the international space station with hundreds or even thousands of companies and engineers and contractors of all sorts. How can the emerging mass of design decisions and changes be coordinated across organizations? How could this ever be "fast-tracked"?
The problem is not lack of connectivity. With the Internet, and intranets, combinations of email and groupware enabling everyone to reach everyone else with ease, one could make a case that the ability to task each other so easily is actually making the problem worse. The problem is that there insufficient structure supporting the distributed task interactions of modern enterprises, especially for project management.
What is Missing
Today's distributed project management tool are still based upon a single-user model of planning and the change notification is still primitive- meaning that all change notifications must be pre-specified, usually by the users.
If one considers single-user project management tools, such as MacProject or MS Project, one can see immediately that they are completely inadequate. The model is that a single general contractor makes decisions and changes and then somehow notifies the people involved. Notifications to the general contractor that cause changes and the notification of the people affected by the change are simply not part of the computer support, though very much a part of any project. The only distributed support from such products is that emails may be sent when a task is assigned and completed.
AutoPlan{5} is in contrast a distributed project management tool that provides an electronic blackboard for change notification. This allows people to receive email when a pre-specified type of event occurs, such as assignment of a task. This definitely takes the computer support of Distributed Project Management (DPM) one step further, but it is still based upon a single-user model of planning and the change notification is still primitive. That is, the general contractor is still responsible for all changes and all of the change notification must be pre-specified, usually by the users.
In small or medium sized projects, a general contractor may track the hundreds of informal change orders with a cork bulletin board and notes. That we do not provide better support for such projects limits the complexity of the project to that which can be managed by a single person. As a result, plans are kept simple and rigid and many opportunities to improve the plan, or even to avoid mistakes, are missed.
But worse is the cumbersome formal change order process required on large engineering projects, which multiple levels of management approvals, with increased time and cost, in an attempt to catch most interactions. Usually, many more people are notified for a given design change than are actually necessary, burdening the whole design process.
The current lack of technology for coordinating design decisions and managing change over the life of a product creates higher costs, longer cycle times, and poorer quality than is currently possible. Occasionally, this lack of technology is even dangerous, whether one is maintaining an older passenger plane or decommissioning a nuclear weapon.
Distributed Integrated Project Management
As described in more detail in the white paper "Distributed Integrated Process Coordination"{9}, process coordination is missing from various well-known computer support approaches to business integration, group collaboration, and project management. Process coordination means the runtime determination of who should be notified and what task should be performed next. Computer support for this means some automation of the notification and tracking of task properties as they are created or change.
Process coordination is more general than workflow in that it does not require that all tasks and ways of doing them be identified prior to process execution. For instance, anyone should be able to assign any tasks to anyone else at any time during process execution. And appropriate notifications associated with that task delegation, or subtask assignment, should be handled by the computer support system.
Process coordination is most complex in domains that require artifact design and construction planning, especially when the artifacts are large and many people and software tools must be coordinated and managed. Distributed Integrated Project Management (DPIM) is an extreme form of Process Coordination in which design, planning, scheduling, and execution are interleaved across distributed organizations and engineering disciplines as well as computer tools.
In particular, we want to be able to support change that occurs from incomplete designs, in order to support "fast tracking", as well as contingencies and planning under uncertainty. We also want to be able to support design and planning that is distributed among people and software that can best solve parts of the problem.
Computer support for DPIM necessarily involves a heterogeneous mix of software and people passing messages describing tasks and changes. The least commitment strategy, with respect to platform, of federating people and their software tools is to use an agent communications language (ACL) such as KQML[Labrou],{6} or FIPA{7} . This only supposes that each software module, possibly just an interface for a person, can exchange ASCII text messages according to standard Internet protocols such as socket connections with TCP/IP.
If the software systems are sufficiently homogeneous so that they can make a stronger commitment, they can directly exchange objects using a facilities such as Java RMI and CORBA. An standard ACL. using an agent[Petrie 96] model, requires less of a commitment to transport mechanism and more of a commitment to message semantics and protocol. In any case, the choice of the interoperability infrastructure is necessary but not sufficient for coordination and management of distributed projects.
What is also necessary is that the human and software agents also agree upon a model of coordination. This is also consistent with the view of agents as software and humans that share a common protocol of messages in which some responses are legal and some are not[Haddadi].
Because the central problem of distributed interleaved planning is change propagation, we characterize our coordination model as a logical set of dependencies among the project elements that can be used to determine the effects of changes within the project. This paper defines a such set of dependencies that should be managed by a computer system in order to coordinate a distributed project.
Scope of this Paper
This paper does not address enterprise process models prior to runtime or organizational models such as VDT {1} and the Process Handbook and PIF{2}. We do not address specific buisiness integration approaches such as the commercial systems of SAP{3} and PeopleSoft{4}. All of these approaches are successful in their domains.
One key problem for change notification is agreement upon the technical terms and words used to describe different parts of the project. There are various schemes, proposals, and mechanisms for doing so, such as the ontologies in {14}, and so we do not address that important topic explicitly here.
However, managing the dependencies of the various aspects of a project, and understanding how changes should be propagated has been a generally neglected topic in the literature. Therefore, we address the latter rather than the former.
In this paper, we describe what the authors have learned in researching the topic of dependencies for distributed integrated project management while trying to extend a specific approach to the general problem. We address the use of dependencies for change propagation once a change to the plan, schedule, or design has been made. We do not address here the use of such dependencies for decision support prior to decision-making.
And while decision rationale is important for change propagation, we do not address specific forms of argumentation; i.e., reasons for or against particular courses of action. We focus on capturing facts and statements supporting decisions and the notification appropriate when they change.
We do not require that an agent be either "intelligent" or "autonomous"[Petrie 96] but only require that they be able to exchange messages with one another and be able to act either by making decisions or acting upon the results of such decisions. This paper will not prescribe a precise agent protocol such as contract nets[Lee] but will define a set of dependencies with which a given protocol should be consistent. We have implemented such a protocol within the ProcessLink project{0}.
Finally, we do not require a totally decentralized model such as market-based agent systems{8}. The dependencies we propose are consistent with such models as we make no restrictions on how planning decisions are arrived at, but we do require at least one special facilitating agent be aware of the actions of all others to the degree that dependencies among the actions can be tracked. That is, at least one agent's knowledge is complete with respect to these dependencies.