A Project Management Tool for Computer-Supported Cooperative Work During Project Planning Gary Knotts University of Arizona
[email protected]
Moshe Dror University of Arizona
[email protected]
Abstract This paper introduces a new conceptual approach for project management with embedded computer support for group collaboration during project planning. We propose a tool by which project planning would be initially decomposed and distributed to activity teams working independently and in parallel, to determine the requirements of the activities they have been assigned. Upon completion of this, our tool would be used to simulate the project in a group setting during which plans could be reviewed, modified, and improved. Our tool would represent a project as a distributed, dynamic process of multiple independent, interacting agents pursuing a common goal. This representation would provide deeper understanding of the nature of the project and would result in more fruitful group interaction among those participating in the planning process.
1. Introduction Interest in Computer-Supported Cooperative Work (CSCW) has grown significantly in recent years. The motivation for this stems, in part, from two observations. First, almost any task can be performed more efficiently and reliably when automated by computer. Second, the outcome of a task when performed by a group is oftentimes superior to the outcome that would result if the same task were carried out by an individual working alone. In fact, the synergy resulting from two or more people working together can yield results which would otherwise be impossible if any one of them worked by him or herself. Thus, to the extent we can design computer systems to automate tasks and simultaneously support group interaction, we can take advantage of both of these facts. Project planning is a good example of the many application domains that could benefit from the use of CSCW tools. Project management is inherently complex [20] and generating feasible project schedules has always been one of the most challenging tasks [4] in an environment never without unforeseeable problems [19].
Bruce Hartman University of Arizona
[email protected]
The planning and scheduling of any project involves uncertainty concerning both internal and external entities and events [1] and matters are worse for large projects where conflicts for resources are more common [18]. Most importantly, although a project’s success depends significantly on the quality of the interactions among individuals, no existing project management tool provides direct support for this interaction [14]. In this paper we will provide some background on CSCW and project management. We will describe the implementation and use of a proposed tool for project planning that would provide direct support for group interaction. We will describe how our proposed tool would be related to traditional CSCW and traditional design processes. We will also define the manner by which our tool would address some of the challenges of good CSCW design and highlight the expected advantages of our tool. We will conclude with suggestions for future research.
2. The nature of CSCW and project management CSCW is a multidisciplinary field which focuses primarily on the nature of group work and how it can best be supported with computer-based information and communications systems [14]. In the CSCW field, groupware typically refers to computer software used to support the communication and coordination needs of individuals working in groups [17]. A common taxonomy for categorizing groupware systems is based on time and space within which there are four system types. Systems are defined as those which support interaction at the same-time/same-place, same-time/different places, different-times/same-place, and different-times/differentplaces [7]. Although proponents of groupware believe it can improve productivity where other computer applications have failed, the technology is not without its challenges [15] and it has been said we are at a point where the identification, clarification, and validation of best practices is of crucial importance [3]. One characteristic
1060-3425/98 $10.00 (c) 1998 IEEE
1.
Close the gap between those who benefit directly from the adoption of groupware and those who must do additional work as a result of the adoption of groupware.
by weighting the activities involved in the collisions and assigning resources to the activities with greatest weight. Zellouf, et.al., [26] have also proposed a project management tool with group support. They describe a framework for software project management including a tool to support cooperative work which schedules and coordinates the activities planned for the project. In this paper, we will propose a system of our own which would be similar to these in some ways, but also different in other important characteristics.
2.
Ensure that the critical mass of users required for the success of a groupware system is involved in its adoption and use.
3. Digital circuit design and traditional design processes
3.
Do not disrupt normal group social processes any more than necessary.
4.
Provide as much flexibility as possible within the groupware system to address the kind and number of exceptions that typically occur and are easily managed during normal group interaction.
of groupware which makes it difficult to design is the inherent complexity associated with group interaction [6]. As a response to numerous and expensive groupware failures, Grudin [12] offers a set of challenges for groupware developers that includes the following:
In regard to project management, there are numerous tools available for scheduling and planning. Although none of these directly support group work, they do have a somewhat longer history than groupware. The original scheduling tools are CPM and PERT, which originated independently in the late 1950s. Although these tools remain popular, there have been numerous extensions including GERT, P-GERT, Q-GERT, VERT, and others. But in spite of the variety of tools available for project planning and scheduling, most projects still fail in one way or another [5, 11, 25]. One study found that a mere 1% of all projects end on-time, as scheduled [23]. Although it appears that existing tools have done little to improve the effectiveness of project management, this does not mean new tools would not be welcomed. Lin and Horowitz [16] state that innovation in project management tools is especially crucial to the success of software development projects and Elmaghraby [8] agrees there is a need for new models. Ward [23] believes tools can be useful in the hands of good project managers while Ware [24] observes that project management software can be helpful in all cases. Fried [11] puts it most simply: “Project management tools are required because you can’t keep it all in your head.” As mentioned earlier, we know of no commercially available tool for project management that directly supports group interaction. However, at least two authors have proposed such tools in the research literature. Kurbel [14] describes a system used to help resolve conflicts among activities that simultaneously require the same resources. In his approach, collisions are resolved
The description of our proposed tool, which appears in the next section, will be presented in the framework of a typical project planning scenario. However, as the reader will note, our discussion relies heavily on analogies drawn from the field of electronic circuit design. This kind of cross-fertilization from other disciplines is important for many reasons. First, it can reduce the proliferation of unneeded formalisms when adequate and well-founded ones already exist. In addition, it can provide important insights into a problem which may not otherwise emerge [10]. Thus, we take a moment in this section to provide a brief introduction to the electronic circuit design process which will provide the foundation for later discussion. The design of an electronic circuit begins with a statement of the requirement the new circuit must satisfy [22]. For large, complex undertakings, the overall requirement is typically decomposed into subrequirements. Each of these subrequirements must be satisfied by subcircuits which will eventually become components of the larger circuit. The design of the subcircuits is usually distributed to numerous engineers who work independently and in parallel on their portion of the circuit. The decomposition and distribution of work is greatly facilitated by the fact that the interfaces between circuit subcomponents are standardized. Moreover, the engineers are thoroughly familiar with the standards and share a common language based on the standards. Also note that the design work of the engineers is usually done with a software tool such as MicroSim’s PSpice [2] that includes a library of standard electronic components which can be used to simulate the behavior of circuits built from these components. The individual subcircuits can be thought of as black boxes. Each black box must satisfy specific requirements in terms of inputs and outputs, but the internal design is entirely up to the engineer. Furthermore, the engineer need not be concerned with the internal designs of
1060-3425/98 $10.00 (c) 1998 IEEE
subcomponents other than his or her own. This provides the freedom to focus solely and fully on the subcircuit being created. The advantage of this is that engineers can work independently and are more likely to produce a good design for their subcomponent since they need not be concerned with outside issues. Once all the subcircuits are designed, software is used to assemble the subcomponents so that the full circuit can be simulated for testing purposes. Should any design problems surface during this process, the engineers will modify the subcircuits as necessary. The process is then repeated until the engineers are convinced that the circuit as a whole satisfies the original requirements. Though this kind of design process is not unique to the field of electronics, it is well-defined and has proven to be especially successful in that field. This success, in part, leads us to believe that digital circuit design practices are a good potential source of the kind of cross-fertilization mentioned earlier.
4. Terminology Before describing our proposed tool in detail, we must clarify the difference between two terms we will use frequently: project team and activity team. A project team consists of all individuals assigned to work on a particular project. An activity team consists of all individuals assigned to work on a particular activity. For every project, there is exactly one project team, but multiple activity teams. Furthermore, the various activity teams are made up of subsets of the members of the project team. As an example, assume a very small project team consisting of Bob, Sue, Joe, Ron, and Tim. For this small project, we will say there are only two activities and, therefore, two activity teams. Team 1 is Bob and Sue and Team 2 is Joe, Ron, and Tim.
5. The application of an integrated CSCW/project management tool to the project planning process A project begins with a statement of some goal to be attained and perhaps a date by which the project must be completed. With this established, a project team is assembled and one of its first responsibilities is to create a Work Breakdown Structure (WBS). The WBS is a hierarchical decomposition of the project into manageable units of work called activities where each activity is typically defined to produce a particular output. Next, the project team must devise a project schedule based on how the activities are related and when
they will occur. The primary purpose of our tool would be to support this scheduling process. With a WBS in place, the project’s activities can be delegated to the activity teams responsible for carrying them out. Although our tool would not strictly require it be used in this way, there are several good reasons for doing so. First, tools that provide quick what-if analysis for schedule development are needed [21] and distributing duties to a number of activity teams working in parallel accelerates the design process. Second, it is generally true that individuals responsible for doing the work are most familiar with how it should be done, the resources required, and the time needed. The scheduling process using our tool would initially be an independent task during which activity teams would define the nature of the activity assigned to them. Defining an activity using our tool would be similar to creating a black box electronic subcomponent as described earlier. The output of the black box would be defined as the output the activity is meant to produce. Based on this output, the activity team would work backwards to define the required inputs and the estimated amount of time needed to complete the activity. Although the activity team would not be required to consider it explicitly, it would be clear that the inputs to any black box come from the other parts of the project (i.e., other black boxes)1. Likewise, it would be understood that the output generated by the activity team’s own black box would be available for other black boxes in the project. The most important point is that the activity teams would not need to consider any black box other than their own and, therefore, could work independently and in parallel while concentrating solely on their own work. In addition to isolating activity teams from one another, our tool would also provide a standard way to address contingencies by supporting the six basic logical constructs: AND, OR, NOT, NAND, NOR, and XOR [13]. Our motivation for this comes once again from the similarities we observe between the design of electronic circuits and the scheduling of project activities. To illustrate, we begin with a discussion of the AND gate. The AND gate has some finite number of inputs and one output. As is true for all digital components, the only valid input and output values are 0 and 1. The output value of an AND gate is 1 if and only if the values of all of its inputs are 1. Our tool would treat an AND gate as being analogous to a project activity which requires some number of
1 With the exception of those black boxes which get their inputs from outside the project.
1060-3425/98 $10.00 (c) 1998 IEEE
things to be true before the activity can begin. As an example, consider an activity that requires the following: 1.
A design specification document must be completed.
2.
A particular individual must be available to work on the activity.
This can be modeled as a 2-input AND gate. To further our analogy, we note there is a short delay in a real AND gate between the time its input values change and the time its output value changes. This is called the propagation delay. We recognize this as being analogous to activity duration and we use this value to represent the estimated duration of the activity. To continue with the other digital elements, the value of the output of an OR gate is 1 when the value of any one or more of its inputs is 1. Thus, an OR gate can be used to represent an activity that can begin when any one or more of its input requirements are satisfied. The output of a NOT gate is the logical inverse of its input. The output of a NAND gate is 1 only when at least one of its inputs is 0. The value of the output of a NOR gate is 1 only when the value of all of its inputs are 0. Finally, the output of an XOR gate is 1 only when the value of exactly one of its inputs is 1. This can be used to model an activity that requires exactly one condition be true before it can begin. Using our tool, an activity could be designed to incorporate any number of logical elements. Figure 1 shows an example of this as used for part of a construction project. We have used standard representations of circuit elements in the example and have also labeled them for those not familiar with the standard symbol set. The example represents a single activity called CLEAR SITE which cannot begin until all the following are true: 1.
A building permit has been obtained.
2.
A frontloader or backhoe is available and an operator for one or the other is available.
3.
A dumptruck and a driver are available.
Observe that our circuit works because we use a value of 0 or 1 to represent the truthfulness of the statement given as the input. For example, the value of PERMIT OBTAINED will be 0 until the permit has been received. Once the permit has been received, the value of PERMIT OBTAINED will become 12.
The use of multiple logical elements provides sophistication, flexibility, and power in the stating of an activity’s requirements without introducing ambiguity. However, it is occasionally the case that some functionality is needed for which the standard elements would be difficult or impossible to use. An electronics engineer would solve this problem by designing a new logical element to suit his or her needs. New elements of this kind are called Application Specific Integrated Circuits or ASICs. Our tool would support this by allowing the activity teams to design new elements where the existing standard elements are insufficient. Thus, our tool would provide a degree of openness and flexibility not found in the traditional project management tools. (For a more detailed discussion of this capability and its implementation, refer to [13]).
CLEAR SITE PERMIT OBTAINED
AND
SITE CLEARED
FRONTLOADER AVAILABLE
OR BACKHOE AVAILABLE
AND
OPERATOR AVAILABLE DUMPTRUCK AVAILABLE
AND DRIVER AVAILABLE
Figure 1. Example project A completed activity would be recorded in an electronic file consisting of the data that defines the activity including: a unique activity designator, the output produced by the activity, the inputs required by the activity, and the estimated duration of the activity. Note that this is again very much like the process used in electronic circuit design. Activity teams using our tool would work independently until all the activities are defined then would submit their work to be used during a simulation of the project.
2 The validity of this approach has been demonstrated in previous research conducted by the authors and described in [13].
1060-3425/98 $10.00 (c) 1998 IEEE
6. An application of the proposed tool to a real project Figure 2 depicts an application of our tool to a real project. (Note: By convention, illustrations such as shown in Figure 2 are oriented from left to right. For publication purposes, ours is oriented from top to bottom.) The project shown in the figure was undertaken by one of the authors and two other software development professionals in support of a software implementation effort for the U.S. Air Force. The goal of the project was to upgrade a commercial software system used by the Air Force from Version 1.0 to Version 2.0. Although the scope of this project was relatively small, it demonstrated some of the flexibility of our proposed tool. In carrying out the upgrade of the new system, there were several organizational requirements that had to be satisfied. First, since the software to be upgraded is used for daily operations, the upgrade had to be done outside regular business hours. Second, the security policies of the facility are such that the work had to be done during a weekday evening because weekend access is rarely permitted. Finally, the entire upgrade project had to be fully completed in one evening since a partially upgraded system would be unusable. The technical requirements for this project were straightforward. The upgrade required that three major activities be accomplished. First, the existing database containing all the current data had to be exported. Second, a software utility had to be run that would automatically convert Version 1.0 of the system to Version 2.0. Finally, the data exported in the first step had to be imported after the upgrade. Upon completion of the final step, the new system would be fully functional and ready for production use. Figure 2 is a depiction of this project that satisfies all organizational and technical requirements. (Project activities are labeled A through F to facilitate discussion.) Activities A, C, and D are the three major tasks that were to be completed to upgrade the system. Activities B and E are part of a contingency plan devised to ensure that the system would be either fully upgraded to Version 2.0 or returned to Version 1.0. The durations of activities A, C, and D are all rough estimates since no one could know the actual times that would be required to complete each step. The duration of Activity B is set such that it functions as a deadline. The purpose of activities B and E are to cause the upgrade process to be halted once it becomes apparent that it will not be completed by start of business. If that were to occur, the system would be rolled back to its original Version 1.0 and the upgrade would have to be retried the next evening.
Since the tool proposed by this paper does not yet exist, the logic depicted in Figure 2 was created and executed using paper and pencil. However, even in this limited form, some of the value of our tool was clear. Although no formal analysis was done, the author and others involved in the upgrade project generally agreed that the depiction and simulation of the project as in Figure 2 was clear, concise, and useful.
Close Of Business Signal
System Version 1.0
Export Database 4 hrs
A
Count Down to Rollback Time 10 hrs
B
Rollback Signal
Database Exported Signal
NOT Rollback Signal
C System Version 2.0 Signal
D
Update Application to Version 2.0 3 hrs
NOT Database Imported Signal
Import Database 2 hrs
Database Imported Signal
E System Version 1.0 Signal
F
0 hrs
Upgrade Done
Figure 2. Real project
1060-3425/98 $10.00 (c) 1998 IEEE
Rollback Database 2 hrs
7. Group interaction supported by the proposed tool Through the example of the previous section, we have hinted at the kind of support our tool could provide for group interaction. With this in mind, we will now discuss how the project planning process would unfold with a fully implemented version of our tool. Assuming the design of all activities is completed as already discussed, the next step would begin with assembling the full project team to participate in a simulation, or multiple simulations, of the project. During the simulation, computer-based autonomous agents would sequence the project’s activities automatically. To accomplish this, our tool would provide one agent for every activity. Each agent would be designed to behave as though it were carrying out the activity assigned to it. Agents would operate in a blackboard environment where all available resources would be listed on the blackboard and, therefore, visible to all agents [9]. Most importantly, the entire project simulation would also be observable to the human participants in real-time as the tool executes and displays an animated representation of its progress. Before starting the simulation, the blackboard would be initialized with the complete set of all resources expected to be available at the start of the project. Once the simulation is started, each agent would look for the first opportunity at which the activity assigned to it could begin. The agent would determine this using the gate logic predefined for its activity by the activity team. As an illustration of our tool, recall the construction example given earlier. As stated, an agent would be assigned to the CLEAR SITE activity and would repeatedly scan the list of available resources for any of the following: a building permit, a frontloader, a backhoe, an operator, a dumptruck, or a driver. The agent would have sufficient intelligence to determine when the right combination of required resources is available. At that point, it would withdraw the resources needed from the blackboard and hold them for a simulated amount of time corresponding to the activity’s estimated duration. The time would be scaled (e.g., 4 days of real time might correspond to 40 seconds of simulated time). Once an amount of time equal to the activity’s duration passes, the agent would return all unconsumed resources to the blackboard for other agents to use. The agent would also place any output it produced on the blackboard. Placing the output of an activity on the blackboard is important because this is the means by which activities would be properly sequenced. To demonstrate this, consider our earlier example in which an activity
required a completed design specification before it could begin. From this, it is clear there must be some predecessor activity for which the output is the design specification3. This being the case, the successor activity cannot begin until its predecessor posts the notice of the completed specification to the blackboard. (We demonstrate in [13] that this approach can be used for all possible relationships between activities including those traditionally referred to as Start-Start, Start-Finish, Finish-Start, and Finish-Finish.) As a tool to support group interaction among the members of the project team, our simulation would be designed for interactive use. Instead of running to completion as rapidly as possible, the simulation would run slowly enough for the project team to observe the animated behavior of the agents and, thus, the nature of the project being represented. The value of our tool as groupware would come from the fact that the agents responsible for simulating the project would provide extensive feedback to the project team during the simulation. Each agent would report a variety of information such as: the resources it has, the resources it needs, the time its activity begins, the time it ends, how long the activity required, whether or not the duration was longer or shorter than originally estimated, etc. At any point during the simulation, it would be possible to pause the execution and allow the project team to consider the current state of the project. If everyone is satisfied with the progress to that point, the execution of the simulation could be restarted where it was interrupted. But more importantly, if anyone observes that the project is not running as hoped, a discussion/negotiation process could be initiated. To illustrate the discussion/negotiation process, consider the following example: during the simulation, an agent informs its activity team that it has everything needed to carry out its assigned activity except for one particular resource, and that resource is being used by some other agent. If the activity team believes this to be a potential problem for the project, it could pause the execution of the simulation to evaluate the project’s status. At that point, the activity team could consider several possibilities. First, they may discuss whether or not the resource is really needed by their activity. If not, the activity’s requirements could be modified and the simulation restarted. Alternatively, if the resource is needed and held by another agent, the activity team could enter into a negotiation process with the other activity team and the project manager(s) to determine which 3 Or, the design specification is an input to the project. In this case, the activity that requires it may not have any predecessors and, therefore, may begin immediately upon initiation of the project.
1060-3425/98 $10.00 (c) 1998 IEEE
activity should have priority4. Or finally, the activity team might conclude after discussion that their activity simply cannot begin as soon as had been originally thought. In that case, they have learned something about the project they might not otherwise have realized until much later in the life of the real project. Where negotiation between activity teams is made difficult by the complexity of the project, our tool would help by providing a rollback feature to be used for what-if analysis. With this feature, the project simulation could be run repeatedly under different circumstances for each run. Upon completion of each experiment, the simulation could be rolled back to an earlier point for the start of another experiment. This would allow the project team to perform multiple what-ifs as a means to decide, among other things, which activities should have highest priorities in acquiring resources.
8. Expected advantages of the proposed tool As described in the previous section, we envision an iterative process of negotiation, modification, and simulation that can continue until everyone is as satisfied as possible with the project’s outcome. At that point, a schedule based on the simulation could be produced to serve as the initial plan for the project. Thus, our tool would support a planning process through which all involved could acquire important insights into the nature of the project. A significant advantage of our tool would be that it would represent the project as it really is: a distributed, dynamic process of multiple independent and interacting agents brought together for the purpose of achieving a common goal. An animated representation, as we have proposed, would result in a deeper understanding of the project which is not possible using traditional static methods such as PERT or CPM. Another expected advantage of our tool is that it would support a design process much like the wellestablished methods, described earlier, for digital electronic design. In that discussion, we mentioned the value of a common standard that is thoroughly understood by all involved. Our tool would support this in creating a standard formalism and associated language that could be used by all participants in discussing the nature of project scheduling and planning. This would eliminate the ambiguity typical of traditional meetings during which valuable and significant time is often wasted in reaching a common understanding among those in attendance as to what everyone is trying to say. 4 Once the priorities have been decided upon, our approach to resolving this problem within the simulation is to weight the activities in much the same manner as is proposed by [14].
Thus, an advantage of our tool is that it would promote a more efficient meeting process where everyone is focused on the same objective and conversing in the same language.
9. The proposed tool in the broader context of CSCW We have described a computer-based project planning tool that directly supports cooperative work. However, our tool as proposed does not fit neatly into the taxonomy of groupware discussed earlier. In the first phase of project planning during which activity teams would be working independently and in parallel to design the agents for their assigned activities, the members of any one activity team would most likely be working in the same time and place. However, work across activity teams could occur at different times and/or different places. But as mentioned earlier, our tool would intentionally isolate the activity teams from one another to encourage an undisrupted focus on their specific activities without the burden of considering the project as a whole. In the second planning phase during which the project’s activities are combined into a complete project and run as a simulation, our tool could still be used in the same time and same place. However, the simulation could also be run concurrently at multiple locations or run at different times in the same place or different places. Each one of these has implications for the communication process, but the important point is that our tool would not limit its users to a particular mode of operation. Users could choose for themselves what they believe to be most appropriate for their purposes.
10. Discussion of implications We will now discuss how our proposed tool would address the challenges set forth by Grudin. First, we believe our tool would close the gap between those who would benefit directly from adopting of our system and those who would be required to do additional work because of it. For our tool, the work would be distributed not to project planners, but to those who would ultimately be required to do the work. Project simulations using our tool would help the activity teams reach agreements with the project manager(s) on reasonable deadlines by which work must be completed. We are also confident that a critical mass of users could be involved in the process. Through the distribution of project planning work to activity teams, there would be virtually no limit to the number of people who could be involved in the process.
1060-3425/98 $10.00 (c) 1998 IEEE
Furthermore, the only limit to the number of people who could participate face-to-face in the simulation would be the size of the facility where it would occur. Alternatively, if face-to-face interaction is not required, there would be no limit to the number of people who could participate. A simulation using our tool could be run repeatedly for a few activity teams at a time or run simultaneously for all activity teams by networking with multiple locations. Finally, our tool would support work at different times since there is no requirement that all those involved in a project be present at the same time during the simulation. Thus, our tool would support all four possible combinations of place and time. Our tool would not disrupt any of the normal social processes. We believe the interactions between activity teams, individuals on the same activity teams, and individuals across activity teams would be very similar to those that would occur naturally. In other words, the negotiations encouraged by our tool during project simulations would be much the same as those that would occur in more traditional settings such as weekly status meetings. However, the advantage of our tool is that it would make it more likely that significant interactions would occur earlier in the project’s life cycle when they would be most beneficial and when conflicts could be more easily resolved. Finally, our tool would provide all the flexibility inherent in human interactions because it would not replace those interactions. Instead, it would provide a standardized forum in which interactions could occur most fruitfully. The purpose of our tool is primarily to provide feedback so that the teams involved will be better informed and, therefore, more effective.
12. References [1] Arinze, B. and F.Y. Partovi, “A Knowledge-based Decision Support System for Project Management”, Computers and Operations Research, Vol 19, No 5, 1992, pp. 321-334. [2] Brumgnach, E., PSpice for Windows, Delmar Publishers, New York, 1995. [3] Cockburn, A., “Four Principles of Groupware Design”, Interacting with Computers, Vol 7, No 2, 1995, pp. 195-210. [4] Davis, K.R., A. Stam, and R.A. Grzybowski, “Resource Constrained Project Scheduling with Multiple Objectives: A Decision Support Approach”, Computers and Operations Research, Vol 19, No 7, 1992, pp. 657-669. [5] DeMarco, T., Controlling Software Projects, New York : Yourdon Press, 1982. [6] Easterbrook, S., “Coordination Breakdowns: Why Groupware is So Difficult to Design”, Proceedings of the Twenty-Eighth Hawaii International Conference on System Sciences, Vol 4, 1995, pp. 191-199. [7] Ellis, C.A., S.J. Gibbs, and G.L. Rein, G.L., “Groupware: Some Issues and Experiences”, Communications of the ACM, Vol 35, No 1, 1991, pp. 39-58. [8] Elmaghraby, S., “An Approach to the Modeling and Analysis of Software Production Processes”, International Journal of Operational Research, Vol 2, No 1, 1995, pp. 117135. [9] Englemore, R. and T. Morgan, Blackboard Systems, Addison-Wesley, Reading, MA, 1988. [10] Flood, R.L. and S.A. Robinson, “Analogy and Metaphor and Systems and Cybernetics Methodology”, Cybernetics and Systems: An International Journal, Vol. 19, 1988, pp. 501-520.
11. Directions for future research We are confident that the application of our tool to project planning could provide helpful insights into the nature of a project for those who participate in its use. However, a question remains as to the best way to build the interface to our tool. Users must not be required to have a background in digital electronics to use the tool effectively. Therefore, research is needed to determine the best means by which the complexities of digital electronics could be hidden from the user while providing all the utility we believe our tool would provide. In addition, research would be required to determine the tool’s strengths and weaknesses and how it could be best used in a group setting to encourage valuable interaction.
[11] Fried, L., “The Rules of Project Management”, Information Systems Management, Summer 1992, 1992, pp. 71-74. [12] Grudin, J., “Groupware and Social Dynamics: Eight Challenges for Developers”, Communications of the ACM, Vol 37, No 1, 1994, pp. 93-105. [13] Knotts, G., M. Dror, and B. Hartman, “An Improved Project Scheduling Methodology Derived as an Analogue of Digital Circuit Technology”, Work in Progress, MIS Department, University of Arizona, 1997. [14] Kurbel, K., “Groupware Extension for a Software-Project Management System”, International Journal of Project Management, Vol 12, No 4, 1994, pp. 222-229.
1060-3425/98 $10.00 (c) 1998 IEEE
[15] Lang, M., “Getting the Most Out of Groupware”, IBM System User, Vol 14, No 4, 1993, pp. 15-16. [16] Liu, L.C. and E. Horowitz, “A Formal Model for Software Project Management”, IEEE Transactions on Software Engineering, Vol 15, 1989, pp. 1280-1293. [17] Lundgren, T.D., “Work Groups and Groupware in Business”, Office Systems Research Journal, Vol 11, No 1, 1992, pp. 14-20. [18] Maroto, C. and P. Tormos, “Project Management: An Evaluation of Software Quality”, International Transactions on Operational Research, Vol 1, No 2, 1994, pp. 209-221. [19] O’Keefe, S.W.T., “Chrysler and Artemis: Striking Back with Viper”, Industrial Engineering, December, 1994, pp. 1517. [20] Pietras, C.M. and B.G. Coury, B.G., “The Development of Cognitive Models of Planning for use in the Design of Project Management Systems”, International Journal of Human Computer Studies, Vol 40, 1994, pp. 5-35. [21] Siddiqee. M.W., “Adaptive Management of Large Development Projects”, 1990 IEEE International Engineering Management Conference, 1990, pp. 191-198. [22] Wakerly, J.F., Digital Design Principles and Practice, Prentice-Hall, Englewood Cliffs, NJ, 1990. [23] Ward, J.A., “Productivity Through Project Management: Controlling Project Variables”, Information Systems Management, Winter, 1994, pp. 16-21. [24] Ware, R., “Project Management Software: Project Panacea?”, Journal of Information Systems Management, Winter 1991, 1991, pp. 79-83. [25] Willcocks, L. and C. Griffiths, “Predicting Risk of Failure in Large-Scale Information Technology Projects”, Technological Forecasting and Social Change, Vol 47, 1994, pp. 205-228. [26] Zellouf, M., P. Prevot, and M.H. Aubry, “Groupware and Peopleware Aspects in Software Management”, Proceedings of the IASTED International Conference. Modeling and Simulation, 1995, pp. 64-68.
1060-3425/98 $10.00 (c) 1998 IEEE
