Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Project Progress Tracking Template – Using a Repeatable GSS Process to Facilitate Project Process Management Fang Chen 1
[email protected]
Robert O. Briggs 2
[email protected]
Gail Corbitt 3
[email protected]
Jay F. Nunamaker Jr. 2
[email protected]
James Sager 3
[email protected]
Stanley C. Gardiner 3
[email protected] 1
: University of Manitoba : University of Arizona 3 : California State University, Chico 2
Abstract This article presents the findings of an action research study in which a repeatable GSS (Group Support System) process was adopted by project teams to track their progress. The repeatable GSS process, implemented by means of a GSS template, was employed and evaluated in both face-to-face and distributed group interactions. The study results indicate that use of a GSS template can facilitate project progress tracking by providing structural support for team interaction and serving as an electronic repository or permanent memory of team interaction. The results also suggest that existing GSS software could be improved though various feature enhancements and additions.
1. Introduction According to statistics from the Project Management Institute (PMI), the US public and private sectors spend in excess of a combined $2.3 trillion annually, roughly one fourth of the gross domestic product (GDP), on project-based activity such as construction, software development, and systems integration [15]. In addition, organizations are not only outsourcing an increasingly higher percentage of their business processes but are also employing greater numbers of temporary or contract
workers who contribute their expertise to a project for a only limited amount of time rather than occupying a permanent full-time position [11]. Coupled with the increasing prevalence of project-related jobs is an increasingly higher proportion of "Mind” projects, which produce intangible, knowledge-based artifacts, as opposed to "Manual" or "Machine” projects which produce tangible or physical artifacts [16]. Furthermore, these mind projects often employ "virtual" or geographically disbursed projects teams rather than localized project teams, and these virtual or distributed teams require more sophisticated means of support for communication, coordination, and collaboration [7]. One critical factor for the success of distributed mind projects is project process management - the monitoring and control of project execution in support of project goals and plans. Project process management can be examined from two levels of task granularity. Viewed from a higher or holistic level, process management includes management of workflow, task integration, change, and risk. Viewed from a lower or day-to-day operational level, process management includes management of tasks, issues, problems and actions [6]. Prior research in project process management has largely been targeted at the holistic level and concerned with topics such as workflow and risk management. The principal focus of operational process management is project progress tracking. During
0-7695-2507-5/06/$20.00 (C) 2006 IEEE
.
1
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
project execution, task progress and task deadlines need to be monitored while any issues and problems that arise need to be addressed. When actions are taken to address specific problems, those corrective actions need to be accounted for as well. Project progress tracking ensures that misunderstanding and confusion over project process is reduced or eliminated and that there are smooth transitions when tasks are handed off among team members. Project progress tracking further ensures that project changes are monitored and the impact of change is well understood and anticipated. Several studies have focused on task management (e.g., [4], [12], [3] ) however, a better understanding of collaborative processes for project progress tracking – a major focus of project management at the operational level – might be valuable to project managers. The overall objective of project progress tracking is to increase awareness and visibility of a project’s process, which in turn increases the likelihood of project success. Insufficient project progress tracking can result in the entire process being treated as a black box. The black box phenomenon can cause a number of potential problems to arise. For example, project members may engage in unproductive efforts or lose track of a critical change in the customer’s requirements, project development approach, or individual task assignments. Without closely monitoring such changes, it is virtually impossible for project members to estimate change related risks and to identify alternatives that can be employed to mitigate such risks in a timely fashion [5]. As a result, projects are frequently subject to cost over-runs and cancellation. One technique for task progress tracking is to use technology to maintain a task list for team members. Callahan and Ramakrishnan [4] presented a Webbased tool to track project progress by maintaining a personal “to-do” list for tracking and measuring change issues and activities. Lam and Maheshwari [12] discussed a tool used by distributed software engineers to facilitate task self-monitoring. There are also a variety of commercial Web services, such as eGroup, iTeamWork, and OnProject, which assist clients in keeping track of task status and task-related documents. These tools or services facilitate team member communication, reduce information seeking time, and increase group awareness of project process. Another technique for project progress tracking is the use of email to distribute progress updates to team members. Brush & Borning [3] described how project team members used daily emails to report their task progress to all other team members. Their study indicated that daily project progress updates increased group awareness and coordination.
However, there were two issues with the technique of daily email reporting. Some group members felt that daily reporting was burdensome and that it should be less frequent. Other group members experienced information loss since they were not in the habit of archiving email messages. Task lists and frequent email updates may be very effective when the target project is simple and few problems or issues emerge during project execution. However, when the project is complex and there are unexpected problems during project execution, task lists and email alone may not be sufficient for effective progress tracking. To resolve problems or issues, team members need to engage in group activities such as discussion, negotiation, and joint decision making – activities which are appropriate for a meeting format. In fact, it is a common practice for project teams to hold periodic meetings to review their progress. Although reviewing project progress in a group setting is often an integral part of project execution, little research has been done to investigate the methodology and technology of project progress tracking in a group setting. There are several benefits associated with tracking project progress in a group setting. Sources of confusion can be promptly clarified and subsequent misunderstandings may be avoided. When all team members are involved in discussion and decision making, project awareness, collaboration and decision consent may be enhanced. These benefits, however, come at a cost. Preparation for frequent progress tracking meetings may be perceived as time consuming or burdensome. If team members develop a tendency to focus on trivial or irrelevant topics, the meeting may become unproductive and hard to manage. Finally, both decisions and decision rationale can be easily forgotten if no permanent record of group interaction is maintained. The most effective process for project progress tracking will likely employ a combination of techniques. Project teams could explicitly maintain a list of their tasks and issues, hold routine progress review sessions to examine and update the list, keep a record of the review session content, and make the content available for project members to retrieve at any time. This suggests that project teams may benefit from a group setting in which there are pre-planned, structured, and documented interactions. Due to advancements in IT and the subsequent ascent of business globalization, more and more projects involve professionals from dispersed geographic locations [7]. When the teams are distributed, they need to employ technology to both support project progress tracking and, at the same time, facilitate their communications. Collaboration engineering provides
2
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
a mechanism for designing a repeatable process that meets these criteria. In this paper, we present a repeatable GSS process for project progress tracking that can be used for both co-located and distributed teams. The remainder of the article is organized as such: In section 2, we explain why we believe that project progress tracking can be enhanced through the use of GSS. In section 3, we outline the research methodology for this study and in section 4 we describe the repeatable process. In section 5, we report our findings from an evaluation of the repeatable process in empirical settings and in section 6 we conclude with a discussion of future research directions.
2. Collaborative Engineering Collaboration Engineering is an approach for designing collaborative work processes for high value recurring tasks and transferring those designs to practitioners to execute for themselves without the ongoing intervention of professional facilitators [2]. The approach involves the following steps: designing a process based on useful patterns of interaction that a group must follow to achieve its goal, choosing or creating the techniques that the group will use to create those patterns, choosing the tools that will be used to instantiate each technique, and finally creating a fully documented script of the things people must do and say at each step of the process in order to execute the collaborative process successfully. We used the collaboration engineering approach to design the process reported in this paper. We used group support systems (GSS) technology to implement the design in the field. A GSS is a collection of collaboration tools that can be used to create effective, efficient, and predictable patterns of collaboration among individuals working toward a common goal. A GSS supports communication, information access, and most importantly, deliberation processes, while minimizing distractions. GSS tools support a variety of techniques for generating, converging, organizing, and evaluating ideas, and for building consensus [10]. Under certain circumstances, groups using GSS can attain large increases in productivity and participant satisfaction [8], [9]. Beyond their support for wellstructured, effective processes, GSS are often valued for three capabilities: anonymity, parallel input, and group memory. Although anonymity and parallel input are very useful for brainstorming, they are of little use for project progress tracking. In a project context, individuals are assigned specific tasks and each team
members has his/her own responsibilities. When team members report progress on their assigned tasks, their identity is either explicitly or implicitly revealed. Thus there is little benefit to be gained from GSS features which support anonymity. Furthermore, since project members need to focus on discussion and information exchange, which requires conversation “turn management”, parallel input is also mostly superfluous. Group memory, however, is quite useful since all content entered into the GSS is automatically recorded for later reference. Another useful feature of GSS is that it provides structured interaction for group activities. GSS can organize discussion content into different categories, and it can embed one interaction tool inside another to provide a layered interface for group communication. This hierarchically structured interaction may help with information capture and retrieval. Novice users of GSS often find it difficult to choose the appropriate tools and configurations to support the task at hand. Collaboration engineers therefore design every step of a repeatable process in great detail, specifying exactly which tools are to be used in what configurations and in what order, and specifying precisely what instructions should be given to the group at each step so the process can be executed successfully by people who are not professional facilitators. [2]. We employed the Collaboration Engineering approach to implement a repeatable process of project progress tracking reported in this paper. However, before presenting our project progress tracking approach, we must briefly explain our research methodology.
3. Research Methodology Since there has not been extensive research in project progress tracking in group settings, this study adopted an action research approach. Action research (e.g., [1], [14]) is similar to case study research in that both allow researchers to gain an in-depth understanding of the phenomena of interest in the rich context where it manifests. In case studies, however, the researcher seeks to remain as an external observer and seeks to minimize researcher impact on the phenomenon being studied. In action research, the researcher begins with a theory and a situation, then intervenes actively with the goal of improving both the situation and the theory. In this study, the authors had active involvement in the design, implementation, and evaluation of the repeatable group process used to track project progress. The next section discusses how the repeatable process for project progress tracking was executed,
3
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
and how collaboration engineering was used to automate the process.
4. Repeatable Process for Project Progress Tracking This study was situated at a large public university in the Western United States that has adopted a project-based methodology for teaching systems development and ERP implementation classes for MIS students. These classes are structured so that junior and senior MIS students experience hands-on learning in a context that simulates a real-world project environment. These projects are non-trivial. Students understand that they need to put serious effort into the class, not only for their grade (the majority of students’ final grade is based on their team’s performance and overall project deliverables) but also for system functionality. The typical semester unfolds in the following manner. A class spends the first few weeks defining their project, building teams, allocating tasks to individual teams, and being instructed in concepts related to their specific project. The class instructor then selects an overall project manager (PM) and a team leader for each team. Some instructors have also designated an engineering manager and a services manager who supervise a handful of subordinate teams and report directly to the PM. Next, the individual teams begin working to complete the parts of the project for which they are responsible. The work proceeds until the end of the semester when the class deliverables are either a working software system and system documentation or a successful ERP implementation. The project-based classes were scheduled to meet twice a week for an hour and fifteen minutes per class session. During one session each week, all teams summarized their progress in a meeting conduct by the project manager. In preparation for these weekly in-class project status meetings, each individual team held one or more separate meetings to review their team progress. To help the class track project progress in a repeated manner regardless of the content of the project, one instructor developed a template for project progress tracking (a weekly status report) and required its use for the class status meeting. Periodic status reports are a paper-based progress tracking technique widely used to serve the needs of project teams in industry. Although the granularity (e.g. individual, group, team) and frequency (e.g. daily, bi-weekly, weekly, monthly) as well as the exact structure of these progress reports vary considerably among organizations, they all serve to
promote awareness and visibility of a project’s process. Typically, a periodic status report contains entries in three primary categories: • • •
Activities and Accomplishments (prior time period) Planned Activities and Goals (upcoming time period) Issues and Challenges
The status report specified by the instructor classified reporting items into five categories: (1) Tasks completed in the Past Week, (2) Tasks for coming Week, (3) Approaching Deadlines, (4) Agenda Items, and (5) Open Issues/Questions. A task is a pre-defined unit of work that is listed in a team’s project plan is assigned to one or more individuals for completion. The Approaching Deadline category was used to remind team members about tasks which were scheduled for completion in the near future. The Open Issues/Questions category was used to identify problems or issues that might arise during project execution and require resolution. Reporting or discussion items not covered in one of the other categories were to be listed under Agenda Items. A more appropriate label for this category might have been “Other Agenda Items”. When the class first began using the template, it was strictly a paper-based approach. The project manager or instructor listed these five categories and associated topics under each category on a piece of paper before the meeting and groups discussed the topics on the list one by one during the meeting. Brief notes were taken during the review session. The instructor had used the template for project status meetings for two semesters and believed there were three main advantages of using the template: it helped project managers prepare the agenda for project progress tracking, it helped participants focus their attention on topics on the list, and the template helped with note taking for the group interactions. The instructor believed that individual teams would also accrue benefits as well if they would also use the template. There were two issues, however, with the paperbased approach. First, a single individual was designated to take notes. While that person was engaged in taking notes, other project team members were unaware of what was being written down. Without a way to audit the information real-time, important points might be missed. Second, the paperbased meeting notes were difficult to share among all project members. Project progress tracking would be more efficient and effective if every team member could contribute to a shared account of the meeting
4
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
that could be accessed by all team members at any time from any location. Because the paper-based approach exhibited these drawbacks, a decision was made to investigate implementing the progress tracking template using Cognito, a Web-based GSS. Although the template was tailored to address the needs of the university’s project-based classes, it remained substantially similar to reporting forms used in real-world organizations. Thus our results should have implications for industry practice. In conjunction with other authors of this paper, an automated GSS template was developed for the class using Briggs, Vreede, and Nunamaker’s [2] collaboration engineering framework. We classified project progress tracking as an “organizing” activity since the template organizes information that is recorded in specific categories. It is important to note that such a template is not just a set of tools preconfigured in some useful way and pre-loaded with some useful content. A collaboration process template also includes the fully-designed and scripted collaborative work process in which the tools are embedded. We implemented the process with variation on a collaborative tool called Categorizer. Categorizer presents users with a two-column window. The first column displays a list of categories. Double-clicking a category causes the contents of the category in the second column. Participants can type ideas into the second column, and they can drag-and-drop ideas from one category to another. Double-clicking an idea pops up a comment window where users can discuss the idea. We modified the standard Categorizer for this project. On startup, the category list appeared preloaded with five standard progress-tracking categories. (Figure 1) When a user double-clicked an idea, discussion window appeared containing two tabs: a comment interface (labeled, “Discussion”) and a shared list (labeled “Specifics) (Figure 2). Project managers could enter an explanation of a topic under the Specifics tab and team members could enter associated discussion or debate under the Discussion tab. If a team member had a comment or question about a particular idea displayed in the discussion screen, he/she could double-click on the idea to bring up a shared annotation window. A yellow-sticky icon appeared next to any comment in the discussion window that bore an annotation. Although the template was originally designed to support co-located teams in tracking their project progress, it also had the potential to support distributed teams.
Figure 1: The Modified Categorizer The left column displays a set of five standard project-tracking categories. Double-clicking a category displays its contents in the right-hand column. Participants could add discussion topics to the right-hand column.
Figure 2: Discussion screen. Unlike the conventional Categorizers, when a user double-clicks a discussion topic in this version, a window pops up displaying two tabs. The first tab contains a shared list for project details. The second tab contains a standard comment window to support discussion of the issue at hand.
5. Using the Template
5
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
To examine the template’s usefulness and ease of use, we asked teams to use it in three different modes of interaction: face-to-face (FtF), distributed synchronous, and distributed asynchronous. The investigation was conducted using two project-based classes during the Fall semester of 2003. Class one helped a fictitious company implement SAP/R3, an Enterprise Resource Planning (ERP) system. The class had 19 students who were divided into five teams: FI (financial and accounting), PP (process planning), SD (sales and distribution), MM (manufacture), and PMT (project manager team). All teams had three members except FI, which had six team members. Class 2 developed a Web-based application to maintain background information on faculty members, extract enrollment data from the university enrollment management system, and generate various summary reports required by the AACSB International (the premier accrediting agency for degree programs in business administration and accounting) in their role as the accrediting body for the College of Business. The class had 40 students who were divided into eight teams: DES (design), SW (software development), DOC (documentation), DB (database), TST (testing), QA (quality assurance), IMP (implementation), and MGT (management). The automated progress tracking template was used at the team level. Team leaders set up the template and entered topics under each category before conducting the team’s weekly project status tracking session. In FtF interaction mode, all team members met in a multi-media equipped classroom where each team member logged in the GSS system to access the template. Anyone could enter ideas and comments on the template as well as engage in oral communication. In synchronous-distributed interaction mode, team members were divided and seated in two different rooms. Again, all participants had access to the template via a networked PC. Team members occupying the same room could engage in oral communication, but they had to use the textbased GSS to communicate with team members in the other room. In asynchronous mode, team members simply logged in the system from any location, at any time within a 48-hour time window. One of the authors participated in every FtF and synchronous-distributed session. That author also frequently logged into and monitored the asynchronous-distributed sessions to observe the use of the template and the group interaction process. The author conducted informal interviews with participants and also collected online anonymous feedback.
6. Observations During Weeks 1 and 2 of the classes, team leaders used the stock tools provided by the GSS. Team leaders were instructed to develop their own category and topic lists for their team’s project progress tracking. The level of abstraction for the categories and topics recorded by leaders varied widely. Some were more specific than was useful; others were overly broad. Topics often appeared in the wrong category. In week 3, leaders were trained to use the template with the modified categorizer and pre-loaded categories, and they used the template for the remainder of the study. Meeting preparation became more systematic. Issues tended to be recorded at more useful levels of abstraction in the pre-defined categories, and more often fit in the category where they were placed. After introduction of the template, meetings became more focused and more efficient. When participants responded to the question “What do you like about the meeting,” eight individuals mentioned the template and reported that they appreciated the structure it provided. The following are example comments and notes made during interviews which indicate that participants recognized the value of the structured meeting support. Question: What do you like about the meeting? Answer: I like the organization or structure imposed on the discussion. - (Class 2 MGT Team Week 4 Asyn Feedback) Answer: Was able to organize discussion topics nicely - (Class 1 MM Team Week 3 FtF Feedback) Answer: The ability to have a structured meeting makes the meeting go faster and smoother - (Class 2 TST Team Week 2 FtF Feedback) Question: Was the meeting was better than week 1 Answer: “Definitely”. - (Class 1 SD Team Week 2 FtF – From the author’s field notes) Answer: “It is a lot smoothier” - (Class 1 SD Team Week 2 FtF – From the author’s field notes) Answer: “the structure of the meeting did help”. - (Class 1 SD Team Week 2 FtF – From the author’s field notes)
6
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Teams posted the results of their on-line projecttracking sessions to a project web site. Four participants reported that the permanent record of was beneficial. One reported that “the best feature (of the system) is a written record” (Class 1 PP Team Week 6 Syn Feedback). Another participant said that “It is a good way to keep track of comments given during the meeting” (Class 1 MGT Team Week 2 FtF Feedback). When asked whether they regularly read the online session notes, all participants who answered this question indicated that they had. There were 10 comments regarding online notes. One participant said “I read them so I can stay up to speed w/ what's going on” (Class 2 MGT Team Week 4 Asyn Feedback). Another participant noted “I read most of the notes. It is good if you are unclear about something that happened at the meeting.” (Class 2 QA Team Week 6 FtF Feedback). Participants’ perceptions of the utility of the template varied depending on their mode of interaction. The design of the collaboration process allowed participants to talk and type at the same time, which some FtF participants found distracting. This was less a problem for remote synchronous participants, and not a problem for asynchronous teams. FtF groups overcame this flaw in the process design by appointing one team member to function as the team secretary to type the notes. All participants could review the online notes instantly once they were typed. Some FtF participants felt that there was no need for the template, while others felt the template was useful for recording and preserving meeting notes. In synchronous-distributed format, participants were assigned to separate rooms, and they were linked only by the GSS, with no voice communication. Because the GSS template only provided support for text-based communication, participants had to type everything into the system. . To make up for a lack of voice links, teams used the comment window provided by the system as a chat forum. However, multiple simultaneous conversational threads tended to emerge, which led to misunderstanding and confusion. Prior GSS research has shown that under certain circumstances, parallel input can boost group productivity (e.g., [13] ). However, it is clear that for synchronous distributed groups, a more-explicit structure for that communication than this template provided would have been required in order for the benefits of parallel input to be realized. Further, much of the prior GSS research on parallel input focused on idea generation. Brainstorming contributions are relatively independent, i.e. they are not a threaded discussion.
Participants do not have to understand all of the prior input before contributing an idea. In our study, participants usually needed to engage in a focused discussion. Conversations always built upon what had already been contributed and thus ideas typed into the system were not independent of one another. Thus unstructured parallel communication was difficult. One participant said, “[in synchronousdistributed interaction] it took 30 minutes to accomplish what we could accomplish in five minutes in an FtF situation”. The following messages/comments which were copied from the minutes of session interaction illustrate this point. The notes inside parentheses contain information about the interaction session from which the comments were copied. For the protection of participant identities, all name tags were replaced with “Tom” for male participants, and “Jenny” for female participants. If a particular conversation involved more than one male or female participant, the name tags “Tom1”, “Tom2”, “Jenny1”, “Jenny2” and so on were assigned. Most messages have a system generated line number appended to the end of the entry. 1) 2) 3) 4) 5)
we are here [Tom1][#33] Hola [Tom2][#34] so are we [Tom3][#35] Where? [Tom2][#36] why aren't the names showing up [Tom4][#37] 6) 306 [Tom1][#38] 7) don't know [Tom1][#39] - (Class 2 TST Week 3 Syn) Note that statement 6 was the reply to statement 4, and statement 7 was the reply to statement 5. 1) why not more retail as distribution channel? [#15] 2) so, we have to define those two right now? or do research? [#16] 3) Jenny, can you invite Tom again? [#17] 4) do research! [#18] 5) retail is defined as selling goods to consumers in small quantities and not for resale, we are doing just direst sales and wholesale. [#19] 6) Tom i just reinvited you, did it work? [#20] 7) No [#21] 8) Tom didn't get and (sic) invitation again? [#22] 9) I'll try again [#23] 10) i just tried again, did it work? [#24]
7
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
11) so, I think wholesale and direct sale are difined (sic) as selling goods to customers (sic) or consumers in large quantities? [#25] - (Class 1 SD Week 1 Syn) In the above example, statements 1, 2, 4, and 11 were associated with one topic while all of the other statements reflected a different topic. The existence of two conversation threads may easily have led to a misunderstanding of the messages. To solve this problem, video or audio conferencing might be used to augment the template so that the template serves as a common visual aid rather than the primary communication tool. Either option would simultaneously address the inefficiency issues associated with text-based communication. We also predicted that the anonymity feature of GSS would not be particularly useful for project progress tracking and our empirical testing confirmed this prediction. Participants in FtF mode did not much care whether communication was anonymous or identified. However, when participants met in distributed mode they wanted to see name tags posted with all messages and they used identified communication almost exclusively. It seemed they were able to interpret messages more accurately when they knew who had said what. Our analysis of meeting notes found that only 2 out of 26 synchronous sessions, and only 7 out of 26 asynchronous sessions were conducted in which name tags were not used at all. A closer look at the meeting notes of the two synchronous sessions with anonymous communications indicated that there had been clear assignment of responsibilities among the team members and, furthermore, the interaction agenda was set up to indicate who was the primary spokesperson for a particular topic. The primary reason why more asynchronous sessions employed anonymous or non-tagged messaging than did synchronous sessions is that the system has the ability to automatically append name tags to each message in synchronous sessions but not in asynchronous sessions. During asynchronous sessions participants had to manually type in their name tags and in some cases they may simply have forgotten to do so. Participants in asynchronous interaction also preferred to see a date and time stamp for each message posted. Since the asynchronous template tool did not have the ability to append a name tag or date and time stamp automatically, participants felt very inconvenienced and suggested that a future version provides the automatic name tag and date/time stamp. After testing the template in different interaction modes, we concluded that the usefulness of the template could be improved. First, FtF groups tried to
talk and type at the same time. They found this distracting, and so appointed scribes to take notes. An alternative solution would be to redesign the process so that all participants contribute their thoughts on line in parallel first, and then discuss their contributions aloud later. This solution is likely to yield far more detail and variety, and is likely to be faster than oral conversation documented by a scribe. Next, synchronous distributed teams needed to carry on threaded discussions, but the template incorporated only flat chat-like capabilities. The template would be more useful if threaded-discussion tools were made available for the parts of the process where threaded discussions were required. The template would also be substantially more useful to synchronous distributed groups if it were to incorporate audio conferencing tools. The template would then serve as a common visual aid to display information and synchronize group interaction. Participants in asynchronous groups reported that it would be useful if the topic currently under discussion were clearly highlighted for easy identification, and if name tags and a date/time stamp were automatically appended to each contribution. Time/date stamps and nametags were not an issue for synchronous distributed or FtF groups.
6. Conclusion In this article, we proposed using collaboration engineering to create a reusable collaborative solution for project progress tracking. We developed a paperbased template for the process, and then automated the process using a Web-based GSS. We adopted an action research approach, intending to improve the understanding of theory and improve practice. Previous GSS studies indicated that three features of GSS (parallel input, anonymity, and permanent memory) could improve group productivity during brain storming. Our study illustrated that when participants conduct project progress tracking, anonymity could be a drawback instead of benefit, especially when the group was distributed. It also surfaced the need for a difference in the structure of parallel input for brainstorming and project tracking.. These results improved our understanding of utility of GSS features in project management context and distributed environment. The collaborative template was employed by multiple project teams for seven weeks. The field observations, individual interviews, and participant feedback all indicated that the template facilitated the progress tracking sessions, thus, the action research effort produced improvements in the situation under investigation.
8
Proceedings of the 39th Hawaii International Conference on System Sciences - 2006
Teams’ experience with the template and the GSS system suggests that some aspects of the process design and some features of the system could be improved to accommodate the varying needs of teams working in different interaction modes. The chief value of the GSS template used in this study appeared to be that all participants had increased awareness of the status of all aspects of the project, and so were able to offer timely and pertinent information and assistance to peers. Finally, while the teams in this study were forced into single modes of interaction, it became clear that it would be useful if teams could move readily from one mode to another as their projects progressed. The script could be changed so that team leaders post their lists of topics, then call on other team members to log in and contribute issues prior to the start of the formal project progress tracking session. FtF or synchronous distributed (supported by voice and threaded discussion) was useful for clarifying issues and resolving conflicts. It would be advantageous for both co-located and distributed teams to have an asynchronous session open at all times so that project team members can simply log in and update their status at any time. If up to date progress tracking data were thus available, FtF interactions for co-located teams could be reserved for crucial topics which might require lengthy discussion.
References [1] Argyris, C., Putnam, R. and Smith, D.M., Action Science. San Francisco, Jossey - Bass Publishers, 1985. [2] Briggs, R.O., de Vreede, G.J., Nunamaker, J.F. Jr., Collaboration Engineering with Thinklets to Pursue Sustained Success with Group Support Systems, Journal of Management Information Systems, 2003, 19 (4), p. 31 – 63. [3] Brush, A.J.B. and Borning, A., “Today” Messages: Lightweight Group Awareness via Email, in Proceedings of the 38th Annual Hawaii International Conference on System Sciences, IEEE Computer Society Press, Big Island, Hawaii, 2005. [4] Callahan, J. and Ramakrishnan, S., Software Project Management and Measurement on the World-WideWeb (WWW), in Proceedings of the 5th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE'96), IEEE Computer Society Press, Stanford, CA, 1996. [5] Chen, F., Romano, N.C., Jr., and Nunamaker, J.F., Jr. An Overview of Collaborative Project Management Approach and Supporting Software, in Proceedings of
the Ninth Americas Conference on Information Systems. Association for Information Systems, Tampa, FL, 2003. [6] Chen, F., Romano, N.C.J., and Nunamaker, J.F.Jr., A Collaborative Project Management Approach and Supporting Software Architecture, in press. [7] Evaristo, R. and Fenema, P.C.V., A Typology of Project Management: Emergence and Evolution of New Forms. International Journal of Project Management, 1999, 17(5): p. 275-281. [8] Fjermestad, J. and Hiltz, S.R., An Assessment of Group Support Systems Experimental Research: Methodology and Results, Journal of Management Information Systems, 1999-2000. 15(3): p. 1999-2000. [9] Fjermestad, J. and Hiltz, S.R., Group Support Systems: A Descriptive Evaluation of Case and Field Studies. Journal of Management Information Systems, 20002001. 17(3): p. 115-161. [10] Hengst, M.d., Kar, E.v.d., and Appelman, J. Designing Mobile Information Services: User Requirements Elicitation with GSS Design and Application of a Repeatable Process, in Proceedings of the 37th Annual Hawaii International Conference on System Sciences, IEEE Computer Society Press, Hawaii, 2004. [11] Krumboltz, J.D. and Worthington, R.L., The SchoolTo-Work Transition From a Learning Theory Perspective. Career Development Quarterly Special Issue: School-to-Work Transitions, 1999. 47(4): p. 312-325. [12] Lam, H.E. and Maheshwari, P., Task and Team Management in the Distributed Software Project Management Tool, in Proceedings of the 25th Annual International Computer Software and Applications Conference (COMPSAC.01), IEEE Computer Society Press, 2001. [13] Nunamaker, J. F. Jr., Dennis, A. R., Valacich, J. S., Vogel, D. R. and George, J. F. Electronic Meeting Systems to Support Group Work. Communications of the ACM, 1991, 34: p. 40-61. [14] Susman, G. I. & Evered, R. D. An Assessment Of The Scientific Merits of Action Research. Administrative Science Quarterly, 1978, 23(4): 582-603. [15] Wheatley, M., The Importance of Project Management. 2005. [16] Whittaker, J., Reflections on the Changing Nature of Projects, in Projects as Business Constituents and Guiding Motives, R.A. Lundin and F. Hartman, Editors. 2000, Norwell, Massachusetts, Kluwer Academic Publishers.
9
