The term project is to be completed as a team.

Information Technology project management is a difficult and tricky business. The countryside is literally littered with software projects that have failed, been abandoned, become runaways, or delivered in some significantly reduced functionality or usefulness.

Most real-world software projects in development today will be costly failures. Most of these projects will exceed their schedule and budget targets before they are delivered. According to McConnell, half of the most expensive software projects will be canceled for being out of control. Many others will simply be abandoned, written off, deployed but never used, or of such poor quality that they cannot be effectively used in practice. Most of these projects do not fail for technical reasons; they fail due to poor project management, control, and execution. In other words, they fail for reasons related to process rather than technology.

Developing high quality, real software is a complex activity. Because of its intangible and intellectual nature, some experts claim it is the most difficult, and one of the most risky of all engineering activities. Recognizing this, industry practitioners and academics have developed and refined numerous approaches - with varying degrees of success - to the software development process over the years.

The following may give you a good introduction to the state of the practice:

Chaos
When Bad Things Happen to Good Projects
"Buzzwordism and the Epic $150 Million Software Debacle" in Communications of the ACM (pdf format)
"Critical Issues in Abandoned Information Systems Development Projects" in Communications of the ACM (pdf format)

Gathering and analyzing information about software projects - whether "successful" or "unsuccessful" is costly, difficult and not well done. Most organizations developing or procuring software do not keep reasonably clean records of their project histories. As a result there is often little history to go on when making difficult project management. Unfortunately, intuition and learn-by-doing are the norm rather than the exception when it comes to project management.

Faculty of the Information Systems program in H&SS at CMU are beginning investigating the feasibilty of creating a database of software development project histories and mining it for useful information regarding rapid, short cycle software development projects - 3 to 5 months duration. The results of this investigation will be directly applicable to IS junior and senior student project teams.

Our approach is three pronged: first, to work with several leading organizations to define a database of standardized metrics and project history records; second, to obtain contributions to the database from organizations who wish to participate in the study; and third, to mine the database. We envision two positive outcomes. In the short term, to produce a "best practices" manual for whirlwind software projects. Longer term, we hope to develop a decision support system that can help executives and project managers determine the likelihood of various outcomes for proposed IS/IT projects.

ASSIGNMENT:

As a team, prepare a convincing proposal/feasibility analysis for this project. At a minimum, your team should complete the tasks below. Also, prepare a presentation to be delivered in class during the last class meeting. There are many good references (online and in print) dealing with software project management, metrics, measurement, and estimation to get you started.

1. Define the records that should be maintained in the database. In other words, what information should we collect? Records may contain any type of digital information.

2. Describe how to "mine" the database for useful information for the best practices manual and for identifying patterns in the data. Consider three separate scenarios:
a) The database contains 20 project records,
b) The database contains 200 project records,
c) The database contains 2000 project records.
Mining the database may involve a combination of manual and machine assisted techniques.

3. Describe the architecture and modeling component of a DSS for establishing likely project outcomes. Assume model development based on the assumption that the database contains 200 project records. Assume also the database will change over time as more records are added and obsolete records are deleted. Define model inputs and outputs and describe how the model works.

4. Describe the organizational, technical, operational, and economic factors that influence, or might be expected to influence, the success of this proposed project.

EVALUATION:

Your project will be evaluated on its overall quality, completeness, depth of insight, appropriateness or approach and recommendations, and appearance. While the team will receive an overall score for the project, peer evaluations will be used to make any necessary individual adjustments upward or downward from the team's score.

Back