The Management of Teaching IT Project Management

Transcription

1 The Management of Teaching IT Project Management Mohammad A. Rob Management Information Systems School of Business and Public Administration University of Houston-Clear Lake 2700 Bay Area Boulevard, Box 330 Houston, Texas (281) Mohammad A. Rob is an Assistant Professor of Management Information Systems at the University of Houston-Clear Lake (UHCL) in Houston, Texas. He teaches courses on systems analysis and design, electronic commerce, active server pages, and project management. Before joining UHCL, he worked in several IT companies, where his activities spanned in areas of systems development, client-server programming, web-database development, and software quality control. He has received several grants from agencies such as National Science Foundation and NASA Johnson Space Center. He has published 12 papers in national and international journals. During the summers of 1994, 1995, and 2002, Dr. Rob worked as a Summer Faculty Fellow in two NASA centers. 1

2 The Management of Teaching IT Project Management Abstract Information Technology (IT) Project Management can be viewed as an integrated effort of three key ingredients: Knowledge, Methodology, and Tools & Techniques. Project managers must develop concepts in the knowledge areas of Project Management. They must also have practical experience in project management processes such as initiating, planning, executing, controlling, and closing a project. Finally, project managers must know how to use various tools and techniques to plan, schedule, and control project management activities. These ingredients were combined to form a one-semester course on IT Project Management for MIS graduate students. The course integrated the students previous knowledge of the Systems Development Life Cycle (SDLC) acquired from the Systems Analysis and Design course. Throughout the semester, the students applied the nine areas of project management knowledge in a team environment and actively managed the development of an information technology prototype following the steps of the project life cycle activities. The management practice was taught implementing the motto a well-planned project may lead to successful completion while a poorly planned project leads to disaster. Development of a clear project plan and delivering all project- and product-related documents in a scheduled timeframe were crucial to management activities. The course website helped teams organize all documents and disseminate them among geographically dispersed team members. The experiences of the several student project managers suggest: it is not necessary for everyone to be a project manager those who accept the assignment must be able to see the big picture. This paper outlines the basic principles of 2

3 course development, the methods of course management, as well as the lessons learned by the students in managing their projects. Key Words: Project Management, Information Technology, Software Development, Curriculum, Course, Teaching. Introduction Project Management methodologies have been successfully implemented in many industries over the years. However, information technology project management continues to receive significant attention in current literature (Blackburn et. al, 2000; McDonald, 2001; Murray, 2001; Sumner, 2000). The majority of the research is directed towards the management of software development projects that are often plagued by cost and time overruns (Tsoi, 1999). Numerous studies have focused on determining the risk factors that can lead software development projects to become runaway (Glass, 1998) or even bankrupt (Abe, Sakamura, and Aiso, 1979); the latter being the total loss of investment. Murray (2001) identified 16 hurdles of project management and Sumner (2000) provided a summary of 18 risk factors identified by several other authors. Scope creep, due to poor control of software requirements as well as poor communication between project personnel, were found to be major factors in project failure. Another important risk factor is poor estimation of project size during the early stages of project planning which can lead to unrealistic estimations of the projected completion time. Estimation tools, such as Function Points and COCOMO (Agarwal et al., 2001; Gulezian, 1991), appear to have wide acceptance in calculating software development efforts, however, many software projects get out of hand due to pitfalls of personnel (Tsoi, 1999). 3

4 Numerous remedies have been suggested to control runaway projects (Glass, 1998; Murray, 2001), and most of these relate to the controlling of the triple constraints of project management namely: scope, time, and cost (Schwalbe, 2002). Software quality has also been a subject of significant research, leading to the widely accepted Capability Maturity Model (CMM, 2002). ISO 9000 not only provides guidelines for developing quality industrial products, it is also applied to software development processes (ISO, 2002). The Project Management Institute suggests nine areas of knowledge in which a project manager should have competency in order to successfully manage a project (PMBOK Guide, 2000). While knowledge is important in understanding potential risks and in developing competency, actual project management is a set of activities performed in various phases of a project life cycle concept, development, implementation, and closeout (Jurison, 1999; Wideman, 2001). These activities do not follow a clear step-by-step process but are intertwined among five process areas: initiating, planning, executing, controlling, and closing (Schwalbe, 2002). The challenge of a project manager is to integrate various knowledge areas and perform appropriate activities to reach various milestones. In practice, most project managers spend a considerable amount of time managing people and apply personal experiences that work well in the work environment. For this reason, Project Management is often viewed as an art rather than a science. Recent curricular guidelines for information systems programs identified Project Management as core courses both in the undergraduate and graduate levels (Noll, et al., 2002; Gorgone et al., 2000). It is hard to duplicate the complexity of a real-life project and experience the art of project management in a classroom environment. Role-playing through group projects 4

5 is found to be an effective method of teaching software project management (Adams, 1993; Lowe, 2000; Sullivan, 1993). It requires students to actively engage in, practice, demonstrate, and perform group activities to understand and effectively apply the underlying concepts (Nance, 1998). It also provides an environment for improving interpersonal and communication skills that are vital in overcoming some major project hurdles (Sullivan, 1993; Sumner, 2000). However, in most group projects discussed in the literature, students typically participate as team members they hardly perform any project management activity. In the IT Project Management course developed for our MIS graduate program, students act as project managers and actively manage the development of an information technology prototype in a team environment. The course integrates the crucial nine areas of project management knowledge as well as their applications in the five process areas of project management throughout the project life cycle. The managers follow a strict timeline for delivering all project- and product-related documents as well as the final product. They develop their own project plan, follow through the steps of product development life cycle, make adjustments to the project schedule as needed, and apply real-life communication mechanisms to control the project. Through this process, they experience some of the hurdles of managing software development projects. Knowing the hurdles of IT project management processes and obtaining some experience in handling those hurdles can be beneficial to those who have little or no experience in managing IT projects (Murray, 2001). Development of a new course and successfully completing it can be viewed as a temporary endeavor, and as such a project. This paper discusses the activities performed in various stages of course development such as course conception, course planning, course implementation, and course completion, which are viewed as the life cycle stages of a project. In 5

6 addition, the lessons learned by the students in the nine knowledge areas of Project Management will be highlighted. Course Conception Project Management can be viewed as consisting of three major components: Project Management Knowledge, Project Management Methodology, and Project Management Tools & Techniques. This is illustrated in Figure 1. A project manager must develop certain knowledge in order to understand important areas of project management that lead to the successful completion of a project. These areas include: scope management, time management, cost management, quality management, human resource management, communications management, risk management, procurement management, and integration management (PMBOK Guide, 2000; Schwalbe, 2002). Knowledge Tools & Techniques Project Management Methodology Figure1: Components of project management The Project Management methodology includes the activities a project manager performs and the actions taken in unforeseen situations to successfully plan, execute, and control a project. 6

7 The activities include the development of documents such as a project plan, a systems requirement document, and a design specification. Project Management tools and techniques help to manage and expedite project manager s activities, which include computing software, analytical techniques, document management tools, and program management tools. Students who aspire to become project managers must develop competency in appropriate knowledge areas of project management, practice the steps of project management, and use appropriate tools and techniques to organize project management activities. Project Management has been traditionally taught as a professional course by many educational organizations and some business schools. Recently, it has been included in fields such as computer science (Sullivan, 1993), software engineering (Lowe, 2000), management information systems, and instructional technology. The IT Project Management course in the graduate MIS program is developed as a follow-up of the Systems Analysis and Design (SAD) course. It is designed to integrate the students knowledge of System Development Life Cycle (SDLC) with the project management life cycle. In a SAD course, students typically encounter a brief discussion of project management while learning the details of the SDLC. The goal of the Project Management course is to provide students with detailed knowledge of project management while applying the knowledge of SDLC through the development of an information systems prototype. In the SAD course, students typically work on a semester-long group project in which emphasis is placed on the development of product-related documents in various phases of the SDLC. In the Project Management course, emphasis is placed on the project-related documents themselves. This approach acquaints students with project management tools and techniques such as developing a project plan and its associated tasks, cost estimation, task scheduling, 7

8 tracking, controlling, milestones, and deliverables. Carrying out a group project in the SAD course following the SDLC steps proved to be of much greater educational value than individual assignments. The Project Management course should produce similar outcomes. Selecting the Text Selecting a project management text is a challenge. A simple search of project management on the Amazon or Barnes and Noble websites yields a broad spectrum of books on the subject. Some books provided rich technical knowledge but poor project management methodology; these are suitable as reference books for software engineering practices (Walker, 2001). On the other end of the spectrum was The Idiot s Guide to Project Management. We selected Course Technology s Information Technology Project Management (Schwalbe, 2002), which falls in the middle and addresses the nine areas of knowledge recommended by the Project Management Institute (PMBOK Guide, 2000). The PMBOK Guide provides guidelines for project management knowledge and practice; however, it does not provide details of tools and techniques to carry out the processes. The selected text fills some of these gaps but still lacks some technical details that should be acquired by all MIS students. We thus used supplemental materials to address issues such as scope creep, software development hurdles (Murray, 2001), remedies of runaway projects (Glass, 2000), COCOMO model (Gulezian, 1991), Capability Maturity Model (CMM, 2002), and ISO 9000 guidelines (ISO, 2002). Project Management Software Microsoft Project is a general-purpose project management software tool. It is widely used in industry and is commonly available in university PC labs. The selected text is 8

9 accompanied by a trial copy of Microsoft Project and was used by students in many facets of the project management course. Course Web Site A course website was developed to disseminate instructor lecture notes, reference materials, and other course-related items. It was also intended for storing of all project- and product-related documents as well as the completed products. All documents for the course were intended to be electronic but the course itself was taught in a classroom setting. Course Planning The original course layout contained classroom lectures, two tests, a research paper, class discussion, a group project, presentations, and documentation. The group project, presentation, and documentation were an integrated effort from a group of students. Students were expected to work in groups and actively manage the development of an information system prototype. The details of the management methodology are presented in the Course Implementation section. The class lectures were divided among the nine knowledge areas of project management, and included discussions on Microsoft Project and Project Management Professional (PMP) Certification as provided in the text. The lectures also covered various activities performed in the five project management processes and followed a sequence such that the topics kept pace with group project activities. Students were to participate in in-class writing and discussion on topics covered in previous class periods. In-class writing was found to be an effective mechanism for engaging students in the learning process (Sullivan, 1993). 9

10 Documentation The most important activity a project manager faces is the development of project-related documents to successfully plan, execute, and control a project. These include a project charter, project scope, work breakdown structure, responsibility assignment matrix, activity sequencing, work schedule, cost estimation, budget, risk management plan, control mechanism, and key deliverables. They also include revised project scope, schedule, and cost, as well as progress reports. Students were expected to develop these documents on a scheduled timeframe using appropriate techniques such as a network diagrams and Gantt charts found in Microsoft Project software. Students were also required to post their documents on the project website. Table 1 illustrates the types of documents expected and the projected schedule of submission. To help students at the beginning of the semester and to facilitate their learning, it also outlines how these documents are associated with the various process groups of the Project Management Life Cycle. All documents developed during the course were to be submitted in a binder at the end of the semester for grading. Presentation Once a project plan is developed, the role of a project manager is to execute and control the project development activities according to the plan. To place controls on the students project management activities, they were expected to make three presentations during the lifetime of the group project. Each presentation marked a milestone for the completion of certain activities in one or more process groups, which also served as the deadline for delivery of documents and products mentioned above. 10

11 Table 1: Outline of the project management documentation and presentation The project documentation should contain a project title, a table of contents, the following documentation, and an appendix. Process Documentation Presentation Time Initiating Project Charter Project Charter 2 weeks Planning Project Plan: Scope statement Work Breakdown Structure (WBS) Project organization structure Responsibility assignment matrix Activity sequencing network diagram Activity duration Gantt chart Schedule Gantt chart Resource listing Project Plan 4 weeks Cost estimation Cost budgeting Executing Steps of quality assurance and quality improvement 6 weeks Bi-weekly reports Controlling Report any changes to project scope, schedule, cost, quality, people Gantt chart update Closing Final report on the project (success, failure, and lesson learned) Success, failure, lesson learned, and product demonstration 6 weeks (same as executing) 2 weeks Appendix: The appendix contains the documents created by the analysts and programmers in analyzing, designing, coding, and testing the system. It should also contain interview documents, work samples, data-flow diagrams, forms and reports design, database design, codes, and a test plan. Table 1 illustrates the presentation timeline and its association with the project deliveries. As seen, 14 weeks of the 16-week semester course were scheduled for project activities. The first presentation was expected to be short it was intended to introduce the concept of the project while the delivery was the project charter. The second presentation was expected to be comprehensive students were to present the methodology they would use to manage the project, while the delivery was the project plan. The third presentation was marked 11

12 as the closing of the project and students were expected to highlight the activities performed and documents created through the processes of executing, controlling, and closing the project. Students were also expected to deliver the project binder as well as demonstrate the system prototype during the final presentation. Figure 2 is adapted from the PMBOK Guide (2000), and it illustrates the expected level of student activity as a function of time in various process areas of the project life cycle. The dark areas represent the major activities of the presentations. As shown, the development of the project plan was given the highest priority in the group project a well-planned project may lead to successful completion, while a poorly planned project leads to disaster. Planning Executing + Controlling Level of Activity Initiating Executing Controlling Closing 2 Weeks 6 Weeks 12 Weeks 14 Weeks Start Time Finish Figure 2: Level of student activity in various process areas of the project life cycle Course Implementation Most of the students in the course were from the MIS program and a few from the MBA program. The course was taught in a PC-equipped classroom with a computer-assisted projector. About 40% of the class time was used for lectures, while the rest was used for presentations, 12

13 demonstrations, discussions, and occasional group meetings. Most of the group meetings were held outside of the classroom. The course website ( bpa.cl.uh.edu/isam5931/course/pm/pm.htm) provides the lecture materials in sequence, and the resources used during the semester. After two weeks of lectures that described the nature of the course and the project itself, the focus shifted on team building and project development. Students were divided into groups with 4-5 students per group, and the instructor created a schedule for presentation and document delivery dates for each group following the projected timeline (Table1). The course website provides a presentation schedule for the spring 2002 semester. After discussing the background and expertise of each team member, each group divided themselves into two sub-groups: management and execution. The management sub-group was primarily responsible for the managerial aspects of the project, while the execution sub-group was responsible for the development of the system. The personnel for the first sub-group was a project manager, a deputy project manager, and a systems analyst, while the second sub-group contained a systems analyst and one or more programmers. This arrangement mimics an actual software development team in a real-life environment. The project manager had the authority of assigning groupmembers to particular tasks as well as reassigning members as needed. The deputy project manager was expected to work closely with the project manager and acted as backup in the absence of the project manager. During the initial stages of the project, both groups were expected to work together to develop a concept and scope of the problem, understand the strengths and weaknesses of the project personnel, and accept specific roles and responsibilities on the project team. The management sub-group then took the lead to develop a project plan, and schedule the work. The 13

14 execution sub-group acted as a support service during this period by collecting and analyzing system-related information. During the product development stage, the execution sub-group was responsible for developing the product; while the management sub-group held group meetings, monitored progress made in systems development, revised project schedule as necessary, and produced status reports. To ensure that every group member participated in some kind of management role, the two sub-groups interchanged their roles halfway through the project. Each group identified their own project, developed a project charter and all planning documents as required (Table 1), and made presentations according to the schedule. Each member of a team then worked on his/her part of the assignment following the responsibility assignment matrix and the schedule developed by the team. The instructor worked as a facilitator for all groups and left the responsibility of meeting deadlines to project managers. Expectation of documents from the executing and controlling processes were not clear to project managers, probably due to lack of their familiarity with actual work environments. The instructor guided them through the steps of updating changes to the work schedule, the budget, and the personnel, as well as logging biweekly progress reports, the meeting agenda, and the meeting minutes. At the completion of each presentation, students uploaded their documents to the website, thus making them accessible to the entire class and the instructor. There were two minor changes in the course schedule at the end of the semester. A course evaluation mechanism was added and the final in-class test was converted to a take-home test. The former was used to assess the students satisfaction with the course activities, while the latter provided information about their knowledge acquired from the course. 14

15 Course Completion The course was completed through the student activities such as making the final presentation, demonstrating the system prototype, submitting the final project document, taking the final examination, and participating in a survey. Students successfully completed five software projects and created a large number of documents, especially during the project planning stage. The project website ( bpa.cl.uh.edu/isam5931/course/pm/projects/projects.htm) contains the project management documents, product-related documents, presentations, and live demonstration of the systems. The documents include all planning documents as mentioned before, the steps of quality assurance, the steps of quality improvement, bi-weekly reports, data-flow diagrams, database schema, database design, interview documents, as well as changes in scope, schedule, cost, and personnel. Results and Discussion It was found that most of the students who took the role of project manager either had a full-time job in the IT field or used information systems regularly in a business environment. Their attitude taught other students to work on a professional level in a team environment, where fellow students had different ideologies and potentially different views of the project. One project manager faced a lot of criticism for implementing strict deadlines and high expectations. Another project manager took the lead in both the management and development activities, which was never intended. There were other pitfalls. One project manager had to leave the country for two weeks, however, the deputy project manager led the team during the time. A key member of another team became sick for a week, however, the group s contingency plan helped 15

16 them to stay on schedule. It is impossible to present details of all projects and examples of all documents. However, the following are highlights of some of the projects: Motel Management: The objective was to develop software that would provide all management activities for a motel from the front desk check-in to the back office. Figure 3 displays a partial snapshot of the group s home page, which provides the names as well as the links to all documents created by the group. One of the most important aspects of this project was the way the group handled quality control processes using the Ishikawa/fishbone diagram to improve group effort and tackle problems involving information gathering. They also used a Pareto diagram to identify the root cause of system bugs during the testing process. Details of the quality control process can be found in the course website. The biweekly reports contain detailed information such as starting and ending time, meeting agenda, team members present, as well as the outcome of the meetings. The overall software development process maturity as described by the team was at the initial level of the Capability Maturity Model (CMM). In the final bi-weekly report, the group members wrote: In conclusion, the Project Manager discussed the final presentation with the rest of the team and embarked on the delegation of assigned portions of the presentation. During the course of the project, everyone had the auspicious opportunity to tackle numerous problems, to analyze, to interpret, and ultimately to arrive at solutions. Our mistakes afforded us ample opportunities to learn and grow scholastically, hence avoiding such pitfalls in the future. 16

17 Figure 3: Web site listing of project management documents created by the Motel Management group Baby s Clothing Store: This group proposed to build a new system that would allow customers to identify merchandise they were most interested in purchasing from the store. This group did not have a project champion and faced a challenge with their verbal and written communication due to their culturally diverse makeup. However, their final report highlighting the success, failure, and lessons learned in the project are commending. The group rotated their roles three times during the semester, which might have hindered the emergence of a strong group leader. 17

18 Palm Lake Apartment Rent Estimator: The purpose of this project was to design an Apartment Rent Estimator Website that would ensure better service to potential residents. This group was highly coherent in terms of knowledge, motivation, and goals. They have developed the most comprehensive set of documents, kept records of all updated Gantt charts, and documented all biweekly reports in a professional manner. They used almost every aspect of Microsoft Project software. Table-2 displays the roles and responsibilities of the team members (with names omitted) as described in the group s project charter. The group s final report highlighted their learning in all process areas of project management. The following statements are from the discussion of their planning process: The team learned that taking what seemed like an inordinate amount of time to prepare for the project ended up being the most important factor in the project s completion and success. Furthermore, the planning out of each phase and sub-phase in the WBS, coupled with the team substitute plan (in case of illness) helped us avoid scope creep and stay on schedule. Table-2: Roles and responsibilities in the Palm Lake Apartment Rent Estimator project Name Role Responsibility Instructor, CEO Project Sponsor Monitor project and provides funding. Student 1 Project Manager Designs, plans, and coordinates project. Handles application features and technical designs. Student 2 Programmer Reviews, analyzes, and modifies programming systems including encoding, testing, debugging and documenting programs Student 3 Deputy Project Manager/Systems Analyst Consults with users to identify current operating procedures and to clarify program objectives. Create documentation to describe program development, logic, coding, and corrections Student 4 Test Engineer Evaluates, recommends, and implements automated test tools and strategies. Develops, maintains, and upgrades automated test scripts and architectures for application products. 18

19 Smart Card Security System: This group planned to implement a Smart Card System for the university that would allow students with after-hours access to different locations of various buildings, as well as purchase items from vending machines, cafeteria, and library. It was clear from the beginning that there was a champion in the group. This group planned to rotate their roles three times during the semester, but that did not materialize, and the project manager ended up doing most of the product development. This was attributed to the unfamiliarity of the system by most group members. This group created a comprehensive final report highlighting all activities of planning, controlling, and reporting. In describing the quality assurance/improvement plan, the project manager wrote: Standards for this project were set at the beginning: No Excuses, Just Results. Each person must participate in all activities of the project and once the strength of each are determined, he assumes the primary responsibility for that part of the project. Reports are to be submitted via s as everyone conclude their portions. Questions should be addressed to the entire team with the Project Manager having the final say on items in which more than one answer is possible. Any team member having difficulty accomplishing their assignment should immediately consult with the team and assistance would be provided. Lessons Learned by the Students The final exam was a take-home test, which evaluated students overall understanding of the group project. Specifically, it included the following questions: 19

20 1. Lessons learned in each of the nine knowledge areas of project management that you experienced in the project. 2. Evaluate yourself and each of your group members qualitatively by writing one or two paragraphs in the following areas: Participation in the meetings Participation in the project activities Participation in documentation Participation in communication Initiating activities/taking charge Interest in learning Completion of his/her part of the task. Having additional time for answering the questions and asking for input on their peers produced positive feedback. Responses were limited to four pages. Answers to the second question helped the instructor evaluate each student and reinforced his perception of each student s participation in the course. The answer to the first question provided a wealth of knowledge about the students learning experience, and the reports from the project managers were very informative. The students comments reflect the experience of a project team in a reallife situation. Of the nine knowledge areas of project management, the students had the most experience in the communication and human resource areas, while the least experience were in the cost and procurement areas. Most students seemed to grasp the knowledge of scope and time well, especially using Microsoft Project software. Understanding the capability and work ethics 20

21 of fellow team members was a challenge for most project managers. Unwillingness or active participation of some members was frustrating to some managers. In some cases, assigning more than one task at a time to a person was found to impede the expected result. Some project managers had to take on their team members tasks to meet the deadlines. Most project managers concluded that matching people s skills with the project roles and responsibilities were the most important factor of human resource management any kind of assumption may hinder team development and project performance. In the area of communication, most project groups found face-to-face meetings the best mechanism for communication in discussing past activities, current project status, and future plans, however, two successful groups used as their primary form of communication. It was clear that students of similar ethnic background formed groups among themselves, which may have produced the best communication mechanism but not the expected result. We communicated very well, however, if we had the diversity of group members, we would have more conflict and difficulty in communication, but we would have learned more from the project. If I had a chance, I would join the group whose members are from different countries and speak different languages, wrote one project manager whose native country was different from USA. In managing scope and time, almost all groups were comfortable in transferring WBS into a work schedule; however, the most difficult problem was the estimation of time for individual tasks. After finishing the project, I learned one thing that really matters: you have to know how to define activity, how to develop the schedule, and how to control the schedule, wrote one team member. In the area of risk, most students cited personnel pitfalls such as not completing the assigned job by unmotivated team members. One team had a contingency plan in case of sickness of a team member. Another team took a fictitious risk by outsourcing their 21

22 programming effort and had a contingency plan by setting aside 25% of the budget. The same group also hired a quality assurance expert to test for system performance, functionality, output, and reliability. In discussing quality management, one project manager wrote, I think the key to creating quality deliverable that matches specific needs lies in understanding your fellow team members and having tasks that enhance their skills. Another student wrote, The study of ISO 9000 and CMM standards helped me to understand the benefits of having a guideline. The analysis of our team revealed that we were either in the initial or repeatable stage of the CMM. This allowed us to realize that there was much room for improvement despite our best efforts. All teams developed their cost and procurement plans, however, these could not be applied in real-life situations. The group that had a fictitious plan of subcontracting their programming work reported it to be a failure. There was a wealth of information in the area of integration management, especially forwarded by the project managers. Almost all teams showed confidence on their project managers. Learning how to manage project integration was a lesson itself. The big picture lesson that I learned from the project is how to plan and coordinate all project-related activities so that they are executed on time and in proper manner, and they produce the output as planned in the scope statement, concluded one project manager. Student Satisfaction with the Course At the end of the course, a survey was conducted to evaluate the overall experience of the students through various methods of learning. The survey contained eight questions of which seven were designed to obtain quantitative feedback. The final question covered any suggestions or improvements the students felt were needed. The answers to the quantitative questions were 22

23 categorized in the range of excellent, good, average, poor, and very poor. In total, 22 out of the 25 students in the course participated in the survey. The results are tabulated in Table 3. As seen, most answers are in the good or excellent category, showing an overall satisfaction with the course. However, questions 3 and 5 require some explanation. The project management experience truly came from the group project rather than from reading, as evidenced through high ratings of questions 1 and 6. Furthermore, all members of a team could not be accommodated to the project manager role lowering the rating for question 5. It is clear from the answers of questions 2 that the course website was very helpful in the learning process of the students. Table 3: Results of the student survey Question Excellent Good Average Poor Very Poor 1 How was the group project experience for 32% 27% 27% 14% 0% this course? 2 How important and helpful do you think 36% 45% 14% 5% 0% the establishment of the project web site was? 3 Did you find the lecture and course 14% 45% 41% 0% 0% materials taught in class helpful in the development of the project? 4 Did the presentations help you learn more 18% 45% 27% 5% 5% about project management activities? 5 How would you rate your experience as 27% 27% 37% 9% 0% the project manager? 6 How did you find the overall team 41% 32% 9% 18% 0% experience? 7 Were the presentations by other groups 33% 38% 24% 5% 0% helpful to you? If yes then how? 8 How did the documentation help you to understand project management?

24 Question #8 was added during the survey and the seven students who responded all felt the documentation was excellent or good. Many students wrote additional comments about their experiences. Some suggestions follow: The project management groups need more diversity. For example, future groups should consist of a person with strong programming skill and a person working towards an MBA. Bi-weekly reports should be presented to the class to reveal each student s level of participation and objectivity. CASE tools such as UML and Rationale Rose should be utilized. The instructor should enforce diversity in cultures when grouping the project teams. Conclusion We have described the process of conception, planning, and teaching a new course in IT Project Management. Brief discussions of the outcomes of the course were also provided. The course provided an opportunity for students to gain Project Management knowledge and apply that knowledge through the management and development of a systems prototype. The website helped students to organize all project-related documents and products, as well as disseminate those to group members and other groups in geographically dispersed locations. The quality and volume of documents developed by the students reflected their sincerity and determination on learning. Microsoft Project software helped students to develop and automate most planning documents. Reading student commentaries describing their experiences in the nine knowledge areas of Project Management was extremely rewarding. They provided this instructor the opportunity to compare the original plan for the course with the actual achievements. They also reinforced 24

25 the expert knowledge of project management practitioners. It is not necessary for everyone to be a project manager those who accept the assignment must be able to see the big picture, as mentioned by several student project managers in describing their experiences. There is little doubt that some of these project mangers will emerge as true, real-life project managers in the future. In the future, a proactive approach should be taken in selecting group members with diverse business, technical, and cultural backgrounds. The frequency of rotating the roles during the project life cycle deserves some attention as well. References Abe, J., Sakamura, K. and Aiso, H. (1979), An Analysi of Software Project Failure, IEEE: Proceeding of 4 th Software Engineering, Adams, E. J. (1993) A Project-Intensive Software Design Course, Proceedings of the Twenty- Fourth SIGCSE Technical Symposium on Computer Science Education, Agarwal, R., Kumar, M., Mallick, Y.S., Bharadwaj, R. S. and Anantwar E., (2001), Estimating Software Projects, ACM SIGSOFT Software Engineering Notes, Vol. 26, No. 4, Blackburn, J., Scudder, G. and Wassenhove, L. N. V. (2000), Concurrent Software Development, Communications of the ACM, CMM: Capability Maturity Models (2002), Carnegie Mellon Software Engineering Institute, Glass, R. L. (1998), Short-Term and Long-Term Remedies for Runway Projects, Communications of the ACM, Vol. 41, No. 7, Gorgone, J. T. and Gray, P. (2000), MSIS 2000 Model Curriculum and Guidelines for Graduate Degree Programs in Information Systems, Communications of AIS, Col. 3, Article 1, Gulezian, R. (1991), Reformulating and Recalibrating COCOMO, Journal of Systems and Software, Vol. 16, No. 3, ISO 9000, (2002), The Year 2000 revisions of ISO 9001 and ISO 9004, International Organization for Standards, 25

26 Jurison, J. (1999), Software Project Management: The Manager s View, Communications of the AIS, Vol. 2, Article 17. Keil, M., Cule, P. E., Lyytinen, K. and Schmidt, R. C. (1998), A Framework for Identifying Software Project Risks, Communications of the ACM, vol. 41, No. 11, Lowe, G. S. (2000), Preparing Students for the Workforce, SIGCSE: ACM International Conference Proceeding Series, McDonald, J. (2001), Why is Software Project Management Difficult? And What That Implies for Teaching Software Project Management, Computer Science Education, Vol. 11, No. 1, Murray, J. P. (2001), Managing IT Project Development Hurdles, Systems Development Management, Vol. 27, No. 4. Nance, W. D. (1998), Experiences with an Innovative Approach for Improving Information Systems Students Teamwork and Project Management Capabilities, ACM Proceedings of the 1998 conference on Computer personnel research, Noll, C. L. and Wilkins, Critical Skills of IS Professionals: A Model for Curriculum Development, Journal of Information Technology Education, Vol. 1, No. 3, PMBOK Guide (2000), A Guide to the Project Management Body of Knowledge, Project Management Institute, Newtown Square, Pennsylvania. Schwalbe, K. (2002), Information Technology Project Management, Course Technology, Cambridge, Massachusetts. Sullivan, S. L. (1993), A Software Project Management Course Role-Play Team-Project Approach Emphasizing Written and Oral Communication Skills, Proceedings of the Twenty- Fourth SIGCSE Technical Symposium on Computer Science Education, Sumner, M. (2000), Risk Factors in Enterprise Wide Information Management Systems Projects, Proceedings of the 2000 ACM SIGCPR Conference on Computer Personnel Research, Tsoi, H. L. (1999), A Framework for Management Software Project Development, Proceedings of the 1999 ACM Symposium on Applied Computing, Walker, R. (2001), Software Project Management: A Unified Framework, Addison-Wesley, New York. Wideman, R. M. (2001), Managing the Project Environment, AEW Services, Vancouver, BC. 26