Electronically facilitated project planning
Lionel Q. Mew, Doctoral Student
William H. Money, Ph.D., Associate Professor
J. Frederick Sencindiver, Ph.D., Assistant Professor
Joseph R. Castle
Christopher L. Smith
The George Washington University
This paper discusses proposed research to improve the knowledge base of technologically enhanced collaborative project planning processes. A new browser-enabled software tool was developed to collect and reconcile project/task information. This tool, used in conjunction with previously developed facilitation processes, collects data from planning session participants, reconciles the data, and turns it into a Microsoft® Project® Plan. The expectation is that by integrating group support system (GSS) software with project planning software in a tool specifically designed for project and task planning, the quality and success of project plans will be improved.
There have been significant efforts to improve project planning through use of technology. Unfortunately, history has shown that the success of efforts to improve planning processes both traditional and using technology, has been sporadic and unpredictable, with complex explanations of failures. Research has shown that complex project plans often fail to integrate managerial or expert knowledge, and fail to contain evaluations of possible events or build consensus (Turban 1993, 515–516). Research and analysis of project characteristics has indicated that complex issues related to the number of tasks in a project, task component hierarchy, the arrival rate, and uncertainty of tasks all influence project planning and project success (Levy et al 1997).
When implementing new technology, innovative ways to employ it must be found. We have already seen the changes that group facilitation applications have made on team interactions. Less evident are the effects these sessions have on continuing efforts in a planning environment. Anecdotal evidence suggests that post-meeting actions are often lacking or poorly focused. Numerous reasons have been suggested for these failures. Some of the more common include poorly defined responsibilities, lack of group vision, required actions too complex, and demonstrated lack of ownership in the planning process.
In The Seven Sins of Deadly Meetings,Eric Matson considers post meeting actions a major detriment to accomplishing goals: “Sin #4: Nothing happens once the meeting ends. People don’t convert decisions into action” (Matson 1996). In their 1989 study, McCartt and Rohrbaugh found that the most successful meetings were those where participants felt decisions were made and action plans developed. Having seen the benefits of electronically facilitated meetings and computer based project-planning tools, we might expect development of applications that would not only improve electronic meetings and project planning applications, and would combine their abilities to present improved business solutions. Such a system would accept multiple inputs and recommendations from meeting participants, and would allow discussion and refinement of those ideas using the collaborative tools of electronic meetings. The resultant planning tasks would then be exported to the project planning application for further refinement and implementation.
We would submit that planning results are significantly more likely to be complete, accepted and successfully implemented if they are developed: 1) using collaborative electronic meetings to define tasks and build consensus, 2) using a well developed planning process (methodology) optimized for plan development and 3) provide a deliverable project plan in a widely recognized format.
Previous research involved testing/demonstration of a collaborative process and integration tool designed to address project planning conducted using electronically facilitated sessions. The work included constructing integrating tools to migrate critical planning data into project management scheduling tools. The tools were utilized in combination with structured planning processes to collect, sort, and sequence information necessary to specify the detailed steps in complex projects. It is proposed that a research project be conducted to assist in developing new tools and testing the effectiveness of the processes using project groups and predetermined project scenarios.
Exhibit 1. Descriptive Statistics
Certainly the most prolific and arguably the best current GSS application is GroupSystems, developed by a team associated with the University of Arizona in 1989. GroupSystems is widely used, and has many features conducive to project planning and other collaborative work.
Typical uses of GroupSystems include strategic planning, crisis management, risk assessment, focus groups and requirements definition processes. GroupSystems customers have reported reductions in cycle time of up to 90% and savings of as much as 50% in labor costs, while maintaining or improving the overall quality of the work product. (GroupSystems Website 2002)
Previous Integration Efforts
Since the mid-1990s, Associate Professor William H. Money of The George Washington University has been conducting research and developing applications that enhance the group support aspects of GroupSystems for project planning. While using the product in both commercial and academic settings, Professor Money conducted numerous electronically facilitated meeting sessions where the goals included project planning. He felt that while the current crop of GSS applications were good for brainstorming, collaboration, and associated tasks, they were not optimized for project planning and management tasks.
Money’s research centered on development and testing of a collaborative process and integration tool designed to address planning problems in the areas of information collection, task definition, and information display for electronically facilitated planning (Money et al 1999). Specifically, Money developed a software tool and a methodology, or process, designed to improve on the GroupSystems model. The tool, developed as a Visual Basic application, took the results from a GroupSystems session, and, when properly formatted, turned this output into a Microsoft Project file. When combined with the data collection process he developed, he won accolades from users. However, the tool was tedious to use, both because of its middle-ware status and lack of built-in error checking.
A significant number of test sessions, both academic and commercial followed development of the tool. A survey was conducted during two representative sessions to gauge participant’s feelings on whether the tools were helpful. One session had ten participants and the other had eleven. Only a cursory descriptive analysis was conducted due to the limited number of participants and superficial nature of the survey:
First, descriptive statistics on whether the process has helped develop a plan were reviewed. The data are presented below as a histogram, showing the frequency distribution. A value of “1” means that the participant “strongly agrees” that the process has helped develop a plan, whereas a value of “6” means that the participant “strongly disagrees.” A value of “2” means that the participant “mildly agrees,” and a value of “3” means that the participant “agrees.” The mean is 1.86, representing the arithmetic average (see Exhibit 1). However, the mean is not a good measure of central tendency, since the data displays a positive skewness, indicating a mean that is therefore artificially high (see the histogram, Exhibit 2). The median or mode would be a better measure, with the mode the best since the data are only moderately clustered around the median. Note the standard deviation of 1.01. The mode is 1. The significance of the process statistic is that participants largely felt that the process helped them develop a plan.
Exhibit 2. Process Statistic
We then reviewed the plan statistic, which measures how well the participants felt the tools helped develop a plan. The descriptive statistic histogram is presented as Exhibit 3. The values have the same meanings as in the process case previously discussed. The mean in this case is 1.81, but for the reasons mentioned above, the median or mode is a better measure of central tendency. The standard deviation is 1.03. The median and the mode are both 1. The significance of the process statistic is that participants largely felt that the tools helped them develop a plan.
Assumptions for New Research
The framework for new research stems from assumptions that the organizations and economies of the world today are vastly more interconnected than those of industrialized nations a half a century ago. Accelerating computer and information technologies have increased the interdependencies among the functions of the organizations, their infrastructures, and their communications and control systems. Project planning activities depend upon communications infrastructures and complex support systems to coordinate and manage the productive activities of the enterprises involved. The overall result is that modern organizations and the systems they use to deliver services and productive are closely and complexly tied together, sometimes in ways that are not obvious or intuitive.
Based on experiences using Professor Money’s tool, it became increasingly obvious that a new application would need to be developed—the process of converting GroupSystems output through another application to Microsoft Project was too clumsy, especially without access to the GroupSystems application program interface (API) information. With API access unavailable, the only option was to develop a completely new system.
Exhibit 3. Tool Statistic
Rather than attempt to replicate GroupSystems functionality, it was decided to start with a clean slate, and develop the application to emphasize and support task and project planning from the outset. There were several reasons for this. First, GroupSystems was designed as a tool to support all aspects of collaborative work. It was not designed specifically for project and task planning. Secondly, as mentioned above, an integrated mechanism for outputting files in Project format was believed to be necessary. Finally, It was easier given the chosen development platform vice the client-server paradigm of GroupSystems.
The interface was designed with rapid entry of task information in mind. Participants may enter task name, start date, end date, duration, and resource names. Additionally, participants can enter comments or notes on each task. System users can simultaneously enter tasks, and can enter comments on their own and other tasks. Tasks can be indented to represent three levels of subtasking. The facilitator has the capability of rearranging the order of the tasks as well, keeping or deleting the task/subtask relationship. Security is handled much like GroupSystems, with the facilitator having control of log-ins and sessions. Outputs are provided in text or comma separated value format, in Microsoft Excel®, or in Microsoft Project’s MPX format. Although with read-only support in Microsoft Project 2000 and later, it is still the preferred format for this system, since it is an ASCII format:
Microsoft Project 2000 can read files in the Microsoft Project exchange (MPX) file format; however, it does not allow users to save MPX files. The MPX file format was replaced with the Microsoft Project Database (MPD) file format in Microsoft Project 98 to improve file interchange support and enable cross-language compatibility. The MPX file format is essentially a record-formatted text file containing only project data in ASCII text format. While it contains only rudimentary project data, the MPX file format does enable users to exchange project data between other applications and versions of Microsoft Project earlier than Microsoft Project 98. Though Microsoft Project 2000 no longer saves in the MPX file format, users can migrate files from other applications to Microsoft Project 2000 by saving in the MPX file format, opening the files in Microsoft Project 2000, and then saving the files to Microsoft Project 2000 MPP file format. (Microsoft 2002)
Application development is nearing completion as of spring, 2002. The expectation is that the research project will be started as soon as participant groups can be identified, and internal and external validity factors associated with potential groups can be evaluated. Groups of between eight and twenty participants will be given complex and noncomplex tasks in various different scenarios. They will be surveyed upon completion of the assigned planning tasks.
The variables to be evaluated include meeting type and planning success. Meeting type is defined as nonelectronically facilitated, electronically facilitated, and electronically facilitated with integrated project planning software. We will later control for the electronically facilitated, Microsoft Project integrated, application. The dependent variable, planning success, will be defined by evaluating participant feelings through a survey instrument.
The first research hypothesis states that there is a relationship between electronically facilitated meetings and successful planning, regardless of facilitation methodology for non-electronically facilitated meetings. The null hypothesis, H0, is that there is no relationship between electronically facilitated meetings and successful planning; the research hypothesis, H1, states that a relationship exists. The second research hypothesis, H2, states that there is a relationship between electronically facilitated meetings with integrated project planning software. In this case we will control for electronically facilitated meetings without integrated project planning software:
H0: Plan Success Non-Electronically Facilitated =
Plan Success Electronically Facilitated Plan Success
H1: Plan Success Non-Electronically Facilitated ≠
Plan Success Electronically Facilitated
H2: Plan Success Electronically Facilitated ≠
Plan Success Electronically Facilitated + MS Project Conversion
We will use a standard 95 percent confidence level as our decision rule.
After gathering our survey data and completing descriptive statistics and t-test analysis, we will generate a correlation matrix. The correlations table displays Pearson correlation coefficients, significance values, and the number of cases with non-missing values. We will use these correlations to measure how our variables are related. Assuming that we find the correlation to be significant at the 0.05 level, we will see that there is a correlation between meeting type and planning success based on the Pearson Correlation Coefficient results. A relationship between these two variables, if it exists, will be intuitively obvious, and we would want to examine it more closely, perhaps with the intent to forecast planning success for specific areas or types of planning based on the relationship. We will first generate a scatterplot.
Eyeballing the data, we will see whether the shape of the plot indicates that a linear relationship between the variables. If we can determine beyond a doubt that a relationship exists, we will run the bivariate regression statistics. Linear Regression estimates the coefficients of the linear equation, involving one or more independent variables that best predict the value of the dependent variable. The usual battery of statistical analysis tests will be carried out with the intent of validating our research hypothesis.
We will next reassess the original relationship, then attempt to control for integrated project planning software, with an expectation that this variable would have an effect on the relationship.
Summary and Conclusions
Have you ever facilitated a fantastically successful electronic meeting session where all of the participants were satisfied and confident that good decisions and plans were made? Have you returned to the same client a few months later only to find that none of those superb decisions were implemented? The proposed research will hopefully move us closer to a new paradigm where a full project life cycle is supported by collaborative tools.
The purpose of the research project will be to determine the effects of electronically facilitated meetings and electronically facilitated meetings with integrated project management software on project planning success. By reviewing the variables, we may be able to develop a predictive model of project planning success based on the effects of the variables in different scenarios, i.e., predict success using predictor variables such as software type, and so on.
Follow-on research could include development and testing of templates for various scenarios. A typical example of a development template is the disaster recovery—business resumption scenario, where GroupSystems and CPT would be used to develop an information systems disaster recovery plan for a customer. A GroupSystems session would be preloaded with a survey including all tenets of the typical disaster recovery plan. Meeting participants would select options and come to consensus on how their plan should be constructed. By using the preloaded survey template, participants and facilitators can rest assured that all typical aspects of disaster recovery will be covered. Participants have only to decide which of numerous options are applicable, and customize the plan to their company. The experienced facilitator can lead them through the process, stating advantages, and disadvantages of various options. Once participants have agreed on what their plan should look like, the plan can be exported to Microsoft Project and delivered to the customer. Additional value is added to the deliverable because due to the format, the customer can continually make additions and changes to their Microsoft Project plan.
In this paper, we have discussed why project plans often fail, provided background on electronically facilitated meeting software development and briefly discussed some recent development efforts. We described a new system just emerging from development, and proposed a research project to validate the model it was built on. Finally, we discussed some new areas of research and development.
The intent is to continue to refine the tool and process, and conduct research into appropriate uses of the tool. Additional templates and business cases for application will be developed. Controlled tests of the tool and process will be conducted. Methodology for the task data collection process will be refined. At some point, the tool will be made available for general use. The proposed research is the first step.
Levy, Nino, and S. Globerson. (1997, December). Improving multiproject management by using queuing theory approach. Project Management Journal.
Matson, Eric. (1996, April). The Seven Sins of Deadly Meetings. Fast Company 1: 123.
McCartt, Anne T., and J. Rohrbaugh. (1989). Evaluating group decision support system effectiveness: A performance of decision conferencing. Decision Support Systems.
Microsoft Corporation. (2000, April). Supported File Formats. Microsoft Project 2000 Resource Kit. Online. Accessed 11 April 2002. Available: http://www.microsoft.com/office/project/prk/2000/Five/67ct_3.htm.
Money, W. H., L. Q. Mew, and J. F. Sencindiver. (2000). Decision support and information system tools for effective team project planning. Proceedings of the 2000 Information Resources Management Association International Conference.May 21–24.
———. (1999, Fall). Collaborative team project planning. Proceedings of the International Academy for Information Management ‘99 Conference.
Tur ban, Efraim. (1993). Decision Support and Expert Systems.New York:Macmillan Publishing Company.
Proceedings of PMI Research Conference 2002