Information Technology Projects

Spring 2007


A significant fraction of information technology (IT) projects fail. By fail, we mean that the system that the project implements never gets used. Capers Jones reports that the failure rate increases with size.

To cite a specific example, after years of touting its Virtual Case File system as the pinnacle of case management software, in February 2005 the FBI informed a Senate Appropriations subcommittee that the project failed, thereby wasting $104 million. Thus, almost 4 years after 9/11, FBI agents still cannot use a modern computer system to manage information about terrorist and traditional cases (Wilson P. Dizard, Senators fume as FBI admits Trilogy foul-ups). The IT mismanagement problems that lead to this disaster are well documented and avoidable: US Department of Justice, Inspector General Audit Report, The Federal Bureau of Investigation's Management of the Trilogy Information Technology Modernization Project, and McGroddy and Lin, Editors, Committee on the FBI's Trilogy Information Technology Modernization Program, National Research Council, A Review of the FBI's Trilogy Information Technology Modernization Program.

Capers Jones also lists the characteristics that contribute to greater than 75% failure rates among software projects:

·         ISO 9000 - 9004 Quality Standards

·         Informal Testing

·         Manual Testing

·         Passive Quality Assurance (< 3% QA staff)

·         LOC Metrics for quality

·         Cost per defect metric

·         Rapid Application Development

What you'll learn

In this course I hope you will learn some of the skills required to participate in and run IT projects that succeed. You will simultaneously learn skills in the classroom and apply the skills in a small, real-world project at a local 'client'. Our clients are typically firms, but occasionally we serve non-profits or government agencies.

What are these projects like? I select projects that teach you about technologically important systems. I seek problems that involve widely used technologies of growing influence. These technologies include the Internet, the World Wide Web, Intranets, Java, and databases. However, I do consider projects involving other important technical areas of mutual interest to you and our clients. To increase the resources available to you, I try to obtain projects that use technologies that are available in our campus computing environment.

I recruit projects that conduct a variety of types of tasks:

·         Software development: A client needs some software to solve a particular business problem. The team quickly works its way through the software development life cycle – including requirements gathering, architecture, design, development and testing – to produce a prototype system that addresses the business problem. The deliverables are the prototype code and a report. The report should document advice and knowledge gained during the project that might be useful to the staff at the client who will build a production system based on the prototype. About ¾ of our projects involve software development.

·         Software purchase evaluation: In this type of project a client also needs some software to solve a particular business problem. However, suppose it makes more sense to address this problem by purchasing, rather than building, the software. Further assume that the client agrees with this assessment. In this case, the team begins by analyzing the business problem and gathering requirements. It then designs an architecture that would connect the new system with existing systems. In the project's second half the team evaluates commercial products that might meet the requirements. The deliverables are a report that compares that several best products for the purpose, and, perhaps, demonstrations of the functionality of one or more of the products.

·         Software tool evaluation: In this type of project a client needs to obtain some software tools which they will employ to help develop software that will solve a set of business problems. As in the previous evaluation, the team begins by analyzing the business problem and gathering requirements. Typically there are at most a few tools that are viable candidates. In the project's second half, the team usually evaluates the candidate tool or tools by designing and building a prototype. The deliverables are the prototype code and a report that documents the tool's strengths and weaknesses.

I seek projects early in their development, so you can experience the full software project life cycle.

I organize you into teams of about four students. Your team will undertake one project that lasts the semester. Note that as a team you devote about 3 person-months of effort to the project.

The readings, classroom lectures, discussions and activities will teach skills that help implement projects of this size. I attempt to convey skills that are pragmatic, simple and efficient:

·         Gather requirements

·         Specify goals and deliverables

·         Quickly choose a development approach

·         Estimate effort

·         Allocate tasks among team members

·         Evaluate and enhance code quality with testing and reviews

·         Communicate to 'management' (the client and me), including communications that range from brief status reports to prepared presentations

·         Communicate within the team

Concurrently with lectures, you'll practice these skills in your project and/or observe your fellow students doing so. (Not all projects require all skills.)

You'll also obtain feedback from me based on close observation of your work.

Classroom lectures will discuss cover software engineering (SE) skills and issues relevant to larger projects and the development and maintenance of good SE cultures. These include SE culture improvement such as the CMM and Weinberg's work, software standardization, and technology trends.

Your responsibilities

Given the team project, learning these skills and obtaining these experiences will involve responsibilities and activities that differ substantially from those in other Computer Science courses. You're primarily responsible for interning on their project, making progress toward its goal, and transferring their results to the client at the end of the semester. In the classroom you'll need to participate as both a presenter and a discussant. In your project you'll need to participate by both planning tasks and executing them.

To excel in this course you'll need to

·         Appropriately balance analysis and action; that is, balance your efforts between figuring out what you should do, and doing it;

·         Devote sufficient time, which should be about as much as an average course, ¼ of a week's worth of effort;

·         Work effective and efficiently with your teammates;

·         Understand your clients well, both by communicating directly with them and inferring their unstated desires from context and other signals;

·         Ask for help when appropriate; and

·         Practice the skills which are taught (or find and use better techniques).

In particular, each student will make a presentation to the class: either a project progress report, or a technology summary or a code review. You'll be asked to summarize your project at the DemoShow.
All students must attend the kick-off, transition and wrap-up meetings. You should prepare for and participate in these meetings.

Course particulars

Course home page:
Time: Most Thursdays, 5:00 to 8:00 PM (with advanced notice you may leave for a 7 PM class)
Place: WWH 402
Number: G22.3812-001
Email beacon: g22_3812_001_sp07 <at>

Credits: 3

Professor particulars

Professor: Arthur Goldberg
Email: artg <at> cs <dot> nyu <dot> edu

Office: WWH, 251 Mercer St., Room 409
Office hours: 3 PM to 4 PM on Thursdays or by appointment – please schedule by email


Clients for Spring 2007

Alvin Ailey American Dance Theater

EDGAR On-line

NYU Collegiate Science and Technology Entry Program (CSTEP)

Client Role

In exchange for our assistance, clients provide adequate resources for students to learn and to succeed on the project. Typically, they provide sufficient facilities, such as computers, software and office space for you to make significant progress on the project during the course. Sometimes, NYU provides such resources. A client technical project manager will spend about one half-day a week supervising students. Interactions with clients may provide opportunities for full-time employment following the course. Many students have obtained jobs during the last 6 years. Some clients will be paying money to NYU in recognition of the accomplishments we achieve in the course.

Team Composition

Students will participate in teams composed of "MS in IS" and CS students. After the first class meeting each student will rank each proposed project's desirability on a scale from 1 to 10. I will assign students to teams by the second class. I will try to maximize the class's total satisfaction, assigning students to projects for which they're skilled, and allocating students to each team. Each expertise and talent will support the other, so CS students with relatively modest management and/or English experience can feel comfortable, as should MS in IS students with less technical experience.
Sometimes we or a client breaks a project into 2 person tasks so team members can progress fairly independently.

Student Admission

In the spring of 2007, the Projects course can accommodate 12 to 16 students in 3 to 4 projects.


To be productive on a project a student must possess sufficient technical and/or managerial skills. These skills can be obtained by academic training and/or experience. Students interested in taking the Projects course should contact Prof. Arthur Goldberg for permission to register. Please email me a resume or short biography.

Registration Logistics

Admitted students will be emailed a 4-digit access code which they should use on Albert to register.

If I give you permission to register, I will email you a 4-digit access code which you should use on Albert to register.

Potential Conflict-of-Interest

Students who work must consider whether interning for a Projects course client might create a conflict-of-interest with their employer. I have checked, and none of our clients consider it a conflict if a student intern works elsewhere, as long as the employer does not compete with the client. Students should obtain their employer's approval to intern, if they feel it is necessary.


With some clients, students will access proprietary information protected as trade secrets. Student interns at these clients may be asked to sign a legal document called a non-disclosure which promises that they will not communicate trade secrets learned at work outside the client. If you indicate interest in a particular project, we assume that you're willing to sign a non-disclosure for that client. I will sign the non-disclosure too. Students who work should obtain their employer's authorization to sign the non-disclosure, if they feel permission is necessary.


We divide the course into two sections, 1) requirements gathering and analysis, and 2) prototype implementation and documentation. The team and I meet with the client at the beginning of the project, after the analysis phase, and at the end of the project. During the requirements gathering and analysis phase each team studies the client's business goals for our project and selects an appropriate software and hardware strategy for efficiently meeting the goals. In the transition meeting the team presents their findings and a plan and schedule for the second half of the semester.

IT Projects, like all graduate CS courses at NYU, demands significant effort. Doing a good job requires about 10 hours of participation a week; doing a great job probably requires more.

Weekly schedule

We meet as a class about 8 out of 14 weeks. The tentative semester schedule is below. Class attendance is mandatory, as class meetings include technical and operational lectures by both students and me.
Most clients are corporations which work "regular business hours". Projects involve coordination among students, and between students and the client. Students and clients are strongly urged to arrange a mutually convenient weekday on which students will meet and intern weekly at the client site. Some clients may work weekends and/or evenings, and may be able to schedule the regular meeting outside of business hours.

Students who are full-time employees

Some students who work full-time want to take Projects. They may do so.

Students unable to spend time at client sites during “regular business hours” should apply for projects whose regular meetings occur outside of business hours or at NYU. I will attempt to assign them accordingly. However, no student can be guaranteed assignment to a project that is scheduled outside regular business hours.

Resources for running special individual projects are not available.

Semester project schedule

To complete the projects and cover their full life-cycle during our 14 week semester, I schedule the Projects tightly. The Spring 2007 schedule follows:

By Jan. 18: Prospective clients submit project proposals. Proposals will be published on the course's web site to advertise the course to students.

Jan. 18: At the first class, students learn about the course and all available projects. If the course has space for MSCS students, qualified students are admitted on a first come first serve basis.

Jan. 22, noon: Students rank projects. The projects which really excite the students get staffed. In past years, I have been able to assign 95% of students to projects that they rank 9 or 10 out of 10. A copy of the ranking sheet is available at

Jan. 25: Students assigned to projects by me.

Jan. 28: I notify staffed and un-staffed clients.

Jan. 29 to Feb. 2: Liaisons schedule 3 hour kickoff meetings at clients. One student, designated the liaison, is responsible for scheduling the kickoff meeting and for scheduling a mutually convenient weekly time at which the client's project manager(s) and the student team can meet and intern together at the client's site. The meeting should be scheduled as early as possible.

Between Jan. 30 and Feb. 1, or Feb. 6 and 9: We hold a 3 hour kickoff meeting at each client. The student team and Prof. Goldberg meet with the client's authorizing and project manager(s), and any other members of the client's team who wish to participate. The client explains the set of projects we will pursue in much greater detail than the proposal. Together, we select a mutually satisfactory subset of projects to pursue. Each student leaves with the beginnings of a clear understanding of the project they will intern on. I assign some students a software topic to talk about at their technical lecture.

Project interning: Kickoff meeting through May 3: Each team interns for about 12 weeks with their client. Students meet weekly with their project manager. I supervise and teach the class at a weekly meeting at NYU. We study software engineering, technology, project management and presentation skills.

March 23 to 30: We hold a 2.5 hour transition meeting at which we transition from an analysis and planning phase to the second half of the project at each client. The student team and I meet with the client's project manager(s). We evaluate the project's progress and set clear goals for the rest of the work. Students present a Project Plan. Example plans will be made available by me.

May 3, 5 to 8 PM: At our “DemoShow” at NYU all teams present their results to all clients, interested faculty, family, friends and other students.

May 3 to 11: At a 1.5 hour wrap-up meeting at the end of the semester the team and I meet with the client's authorizing and project manager(s) at the client. Students present their results and hand-off their results to clients.

Class Meeting Schedule



Topic / Reading



Jan. 18

Information Technology Projects: Introduction and Logistics / Handouts

Course goals: Software project planning and execution: business analysis and requirements gathering; development planning and scheduling: software life-cycle. Description of all projects and clients, review course description, handout student questionnaire and project selection form. Course grading.


Jan. 25

Project Analysis

Understanding and describing business objectives: tactical and strategic goals, ROI; collecting and analyzing requirements, good questions to ask, individual research; use case analysis; UML; GDD.
Progress reports, kickoff meeting goals, agenda and preparation.
Team assignments, liaison responsibilities; Teamwork and problem solving skills.


Feb. 1

No class: kickoff meeting week


Feb. 8

No class: kickoff meeting week


Feb. 15

Project Analysis Continued, Transition meeting preparation, Project Plan, Requirements Gathering / RD, chap 10, 14, SPSG, Chap 7, 8 [photocopy to be provided]

Project goals and short-term task table

Business requirements gathering, Features and specifications, Project management, Risk management
What to do with requirements: managing expectations;
Analysis to development transition meeting format and goals; review sample project plan and outline


Feb. 22

System architecture and design, progress report / CC2 Section 3.5 and Chapter 5; Individual preparation / CC2 Chapter 33
Teamwork / RD Chapter 12

Some thoughts on how to make presentations

Effort estimation

Individual preparation: tuning technical skills; testing theories; risk-reward of guessing
What makes a good architecture? Interface design, specification, definition and implementation;
Present sample progress report; democratic programming teams


March 1

Student presentations: Project progress reports and technical summaries

Two-thirds of students, some from each team, present a project progress report or a technical summary
Professor: Project problem-solving; communications, understanding roles and skills.


March 8



March 15

No class: spring break


March 22

No class: Transition meetings


March 29

Large scale software engineering, changing organizations / Humphrey, Weinberg

CMM, Weinberg change model.


April 5

Writing correct code - Reviewing Code / Gries, the science of programming; extreme programming doctrine, Weinberg, McConnell and Humphrey on code review, Capers Jones, example code

What is 'correct' code? Approaches to making code correct:
Good design; avoiding bugs; invariants; correctness proofs; the individual psychology of programming--cognitive dissonance; testing: unit test, JUnit, extreme programming, demonstrate a code inspection

Software quality guidelines; inspection reviewer form


April 12

Student presentations: Code review

Student presentations. Half of students, some from each team, review code. (For code reviews, programmers distribute code and architecture and functionality overview to class by April 16. Reviewers take home code and look for errors. Reviewers return feedback error forms to Professor by April 18).
Programmer presents code, team members and professor offer feedback.


April 19



April 26

DemoShow planning and preparation

DemoShow presentation: demo content, other communication tools: poster, handout; preparation and resource needs, invitees, presentation style.

May 3


Demonstrate project accomplishments to the public.



[RD] Steve C McConnell, Rapid Development: Taming Wild Software Schedules, 647 pages (July 1996), Microsoft Press; ISBN: 1556159005.
[CC2] Steve C McConnell, Code Complete: A Practical Handbook of Software Construction, 2nd edition, 2004, Microsoft Press; ISBN: 0-7356-1967-0

Gerald M. Weinberg, Quality Software Management, Vol. 1: Systems Thinking, ISBN: 0-932633-22-6, 1992, 336 pages


[MTSP] Watts S. Humphrey, Managing the Software Process, 494 pages (May 1989), Addison-Wesley Pub Co; ISBN: 0201180952
[SPSG] Steve M. McConnell, Software Project Survival Guide, 250 pages (November 1997), Microsoft Press; ISBN: 1572316217

Gerald M. Weinberg, Quality Software Management, Vol. 2: First-Order Measurement, Dorset House Publishing Company, (February 1, 1993), ISBN: 0932633242, 360 pages
Gerald M. Weinberg, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, ISBN: 0-932633-01-3, 1985, 248 pages
Steve McConnell, Software Estimation: Demystifying the Black Art, 308 pages, Microsoft Press (March 1, 2006), ISBN-10: 0735605351


Patrick J. Lynch, Sarah Horton, Web Style Guide: Basic Design Principles for Creating Web Sites, Yale University Press (March 1, 1999), ISBN: 0300076754.
Alan Cooper, Robert M. Reimann, About Face 2.0: The Essentials of Interaction Design, Wiley; 1st edition (March 17, 2003), ISBN: 0764526413.
Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley Pub Co; 1st edition (April 28, 2000), ISBN: 0201485427.
[DP] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch (Designer), Design Patterns: Elements of Reusable Object-Oriented Software, 395 pages 1 edition (October 1995), Addison-Wesley Pub Co; ISBN: 0201633612
Watts S. Humphrey, A Discipline for Software Engineering (SEI Series in Software Engineering), 789 pages (January 1995), Addison-Wesley Pub Co; ISBN: 0201546108


Shared digital communications

This course depends on robust, accurate and frequent digital communications. All students and project managers at clients must read and respond to Internet email daily.

All students should join the class mailing list g22_3812_001_sp07 <at>, by filling out the form on the mailing list web page,

I will also create two mailman groups for each project. One group will be for communications among everyone on the project, including all students, me (the professor), and people with the client. The second will be for communications among just you and your fellow students on the team (and me). So, you should join both of these.

Finally, if you need it, I can create a Blackboard group for your project. You could use it to share files, scheduling information and real-time chats among yourselves and your client.

Project liaison

Each project needs a team liaison responsible for organizing interaction with the client. The liaison's job includes

·         Scheduling the three meetings involving the team, the client and me.

·         Scheduling first couple meetings between client and team.

If you want to be your team's liaison, please volunteer.

Progress report
Each student must send a weekly email progress report to your project email group on Thursday before class. A progress report is the best way for people who are involved in the project but do not participate in regular meetings (like me and the authorizing managers) to track the project's progress. It is an excellent habit. Many of the best run software organizations track team member progress with simple reports like these.

Spend 5-15 minutes composing the progress report (so if you devote 8 hours per week to the class the report takes at most 3% of class time). Writing the report will help you evaluate how you're doing. The report contains:

·         Description of the week's goal(s)

·         Description of progress toward the goal(s)

·         Description of the next week's goal(s)

·         Optionally, description of obstacle(s) making progress difficult

·         Optionally, list of ways, if any, I could help progress

Here is an example of a fine report:

1. Description of the week's goal(s)
· Prepare the Transition Meeting Report in the following sections:
a) Draft detailed designs
b) Development plan
c) Serious open issues
· Working on the mockups for the entire system
2. Description of progress toward the goal(s)
· Finalizing the Transition Meeting Report
· Finalizing the GUI mockups
3. Description of the next week's goal(s)
· Present the report on the Transition Meeting
· Demo the proposed GUI
4. Description of obstacle(s) making progress difficult
Confused about GUI design.
5. List of ways, if any, I could help
Recommend a GUI design book. Cancel the assignment :-)

This document and associated materials were authored or compiled by Arthur Goldberg. This compilation and supporting electronic teaching materials may be freely used for non-commercial use provided any electronic or print version includes this notice. All rights reserved. Copyright Arthur P. Goldberg, 1996 through 2007.