One of the interesting (if tedious) responsibilities for my Senior Project class at NJIT is to discover, interpret, and choose a project management methodology. Having had no real prior experience in the theory of project management, this has been a real challenge to me: I feel like I’m desperately trying to claw my way up from the bottom of the learning curve. Read on for more.

A coworker had asked me recently what sort of study Computer Science is (we were looking at colleges on the web at the time). The answer is actually a bit more interesting than simply “a science.” CS actually finds its roots in the Engineering field since the adding machines that once passed as computer technology looked a lot more like car engines than the pleasant beige boxes with which we now find ourselves. As the descendant of the Engineering field, Computer Science has inherited a number of organizational and developmental disciplines.

However, over the past several decades, thought has changed significantly regarding the development of information systems. It is interesting to note that analysts and economists have coined the phrase, “Information Revolution” to describe the latest trend in market forces. Before the rapid advancement of computer technology, the most recent market dynamic had been governed by forces put into effect by the “Industrial Revolution.” One revolution is defined by the way material things are produced for consumption. The other is defined by the way people manage the flow of information—a far less tangible commodity. This is an obvious reality that has far more subtle implications for the way their respective commodities are produced, which leads me to the topic at hand.

It was once thought that Information Systems should be constructed in similar manner to the way we build bridges. If you don’t know, engineering on a large scale is generally done in phases, during each of which various discrete tasks are given to people of different skill sets. For example, architects set out a design on paper, which is then given to several different engineers (environmental, civil, and so on) to determine feasibility and flesh out the resources involved. The engineers turn around and give their more concrete blueprints to contractors, who go out and do the work that has been defined for them in previous phases. This approach is referred to as a Cascade or Waterfall approach, where the output of one team becomes the input for another and so on down to the project completion. The first phase begins with the idea of a thing, which takes on more concrete reality as it is passed to the people who actually do the building. The builders do not have to deal with having to think about the placement of a staircase or the direction of waterlines, because all of these details have been determined before they put the bid on the project. All large-scale manufacturing follows a similar monolithic model.

Information Systems, for some time, have been modeled after a similar fashion. I spent my entire CIS 490, Guided Design in Software Engineering class learning that this is how a system is built, from idea to reality, all while filing hundreds of specifications reports as the work is passed from one level to the next. Architects architect. Analysts analyze. Designers design. Programmers program. Testers test. This approach to software engineering has official sounding acronyms like UML and advertises such stalwart names as IBM and Microsoft. With such powerful backing and proven entities, one might wonder what reason anyone would have to dissent. As it turns out, though, the monolithic approach to systems design does not comprehensively deal with the realities incumbent upon the intangible information system.

From a 50,000-foot view, the waterfall methodology looks like it sounds: one process leads to the next such that the output of one is the input of the next:

The major difficulty with this approach is that it assumes that the process of developing software is a repeatable, predictable event. Those in the trenches of software development know only too well that requirements change, budgets constrict, and timelines evolve. In order to deal effectively with this chaos, the process needs to adapt to look like this:

Here, the processes in software development occur simultaneously, with milestone releases to keep the processes in sync with each other and with the customer. It provides an inherent mechanism of efficiently and quickly developing code that is to the customer’s specification and welcomes changes in requirements. The overarching name for this category of software development is the Agile methodology, which comes in all sorts of flavors: Scrum (2), Extreme Programming, and Evolutionary Delivery.

Because the product life cycle for the senior project is approximately 12 to 13 weeks, an agile methodology really seems to be the most appropriate and will be adopted by our team. Of those available, Scrum seems to best fit the management style I believe I can contribute and is the most flexible model that can be adapted to our very busy schedules.

This document at ControlChaos.com has been most helpful in discussing the advantages of scrum.