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 77058 (281) 283-3191 rob@cl.uh.edu 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

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

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

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

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

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).

Project Management

Knowledge Tools &Techniques

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

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

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

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

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

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 • Cost estimation • Cost budgeting

Project Plan

4 weeks

Executing • Steps of quality assurance and quality improvement

• Bi-weekly reports

6 weeks

Controlling • Report any changes to project scope, schedule, cost, quality, people

• Gantt chart update

6 weeks (same as executing)

Closing • Final report on the project (success, failure, and lesson learned)

Success, failure, lesson learned, and product demonstration

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

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.

C

p

A

Initiating

Planning

Executing

Controlling

Closing

Time

Leve

l of

Activ

ity

Executing + Controlling

Start Finish

2 Weeks 6 Weeks 12 Weeks 14 Weeks

Figure 2: Level of student activity in various process areas of the project life cycle

ourse Implementation

Most of the students in the course were from the MIS program and a few from the MBA

rogram. The course was taught in a PC-equipped classroom with a computer-assisted projector.

bout 40% of the class time was used for lectures, while the rest was used for presentations,

12

demonstrations, discussions, and occasional group meetings. Most of the group meetings were

held outside of the classroom. The course website (http://b3308-

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 group-

members 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

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

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 (http://b3308-

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

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

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

• 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

• 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 emails 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

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 real-

life 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

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 e-mail 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

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

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 this course?

32% 27% 27% 14% 0%

2 How important and helpful do you think the establishment of the project web site was?

36% 45% 14% 5% 0%

3 Did you find the lecture and course materials taught in class helpful in the development of the project?

14% 45% 41% 0% 0%

4 Did the presentations help you learn more about project management activities?

18% 45% 27% 5% 5%

5 How would you rate your experience as the project manager?

27% 27% 37% 9% 0%

6 How did you find the overall team experience?

41% 32% 9% 18% 0%

7 Were the presentations by other groups helpful to you? If yes then how?

33% 38% 24% 5% 0%

8 How did the documentation help you to understand project management?

--

-- -- -- --

23

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

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 4th Software Engineering, 378 – 385. Adams, E. J. (1993) “A Project-Intensive Software Design Course,” Proceedings of the Twenty-Fourth SIGCSE Technical Symposium on Computer Science Education, 112 – 116. 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, 60 – 67. Blackburn, J., Scudder, G. and Wassenhove, L. N. V. (2000), “Concurrent Software Development,” Communications of the ACM, 200 – 214. CMM: Capability Maturity Models (2002), Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/cmm/cmms/cmms.html. Glass, R. L. (1998), “Short-Term and Long-Term Remedies for Runway Projects, Communications of the ACM, Vol. 41, No. 7, 13 – 15. 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, 1 – 51. Gulezian, R. (1991), “Reformulating and Recalibrating COCOMO,” Journal of Systems and Software, Vol. 16, No. 3, 235 – 242. ISO 9000, (2002), “The Year 2000 revisions of ISO 9001 and ISO 9004,” International Organization for Standards, http://www.iso.ch/iso/en/iso9000-14000/iso9000/2000rev1.html.

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, 76 – 83. Lowe, G. S. (2000), “Preparing Students for the Workforce,” SIGCSE: ACM International Conference Proceeding Series, 163 – 169. 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, 1 – 23. 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, 145 – 151. Noll, C. L. and Wilkins, “Critical Skills of IS Professionals: A Model for Curriculum Development,” Journal of Information Technology Education, Vol. 1, No. 3, 143- 154. 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, 283 – 287. Sumner, M. (2000), “Risk Factors in Enterprise Wide Information Management Systems Projects,” Proceedings of the 2000 ACM SIGCPR Conference on Computer Personnel Research, 180 – 187. Tsoi, H. L. (1999), “A Framework for Management Software Project Development,” Proceedings of the 1999 ACM Symposium on Applied Computing, 593 – 597. 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.