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).
Tools &
Techniques
Knowledge
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
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
4 weeks
Project Plan
• Cost estimation
• Cost budgeting
Executing
• Steps of quality assurance and quality
6 weeks
improvement
• Bi-weekly reports
Controlling • Report any changes to project scope,
6 weeks
(same as
schedule, cost, quality, people
executing)
• Gantt chart update
Closing
Success, failure, 2 weeks
• Final report on the project (success,
lesson learned,
failure, and lesson learned)
and product
demonstration
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.
Executing + Controlling
Level of Activity
Planning
Executing
Closing
Initiating
Controlling
2 Weeks
Start
6 Weeks
12 Weeks
Time
14 Weeks
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
demonstrations, discussions, and occasional group meetings. Most of the group meetings were
held outside of the classroom. The course website (http://b3308bpa.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
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://b3308bpa.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
Instructor, CEO Project Sponsor
Student 1
Project Manager
Student 2
Programmer
Student 3
Deputy Project
Manager/Systems
Analyst
Student 4
Test Engineer
Responsibility
Monitor project and provides funding.
Designs, plans, and coordinates project. Handles
application features and technical designs.
Reviews, analyzes, and modifies programming
systems including encoding, testing, debugging and
documenting programs
Consults with users to identify current operating
procedures and to clarify program objectives. Create
documentation to describe program development,
logic, coding, and corrections
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 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
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
1
2
3
4
5
6
7
8
How was the group project experience for
this course?
How important and helpful do you think
the establishment of the project web site
was?
Did you find the lecture and course
materials taught in class helpful in the
development of the project?
Did the presentations help you learn more
about project management activities?
How would you rate your experience as
the project manager?
How did you find the overall team
experience?
Were the presentations by other groups
helpful to you? If yes then how?
How did the documentation help you to
understand project management?
Excellent Good Average Poor Very
Poor
32%
27% 27%
14% 0%
36%
45%
14%
5%
0%
14%
45%
41%
0%
0%
18%
45%
27%
5%
5%
27%
27%
37%
9%
0%
41%
32%
9%
18%
0%
33%
38%
24%
5%
0%
--
--
--
--
--
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 TwentyFourth 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
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 TwentyFourth 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.
26