What does Project Management have to do with Software Development?

The development style of a software project has a huge impact on the way that the project is managed. Until now I have been a strict believer in Iteration, while Jeff is a die-hard Waterfall guy. Over the last few weeks I have had the opportunity to sit in on Jeff's Project Management class. Any project needs to be managed to increase its likelihood of success. However different development methods call for dramatically different ways to manage the project.

Since I co-teach a project-based course for software developers at RPI, this simple fact is going to change the way we present development strategies to our students. I have a large collection of software development, UML, and other related technology books. Jeff grabbed Effective Software Project Management by Robert J. Wysocki from the shelf and refers to it in the class. I started reading it to get more information about a segment of the class I am contributing to. Wysocki talks in great detail about the different development models. He makes it quite clear that each development model has its place in the world. Iterative development is very good for projects where the solution is not fully crystallized in the minds of the stakeholders and the developers. Waterfall methods of development are suited for projects where the goals and solutions are completely developed and are not likely to change.

In our class at RPI, we poo-poo Waterfall methods as being risky as there is no feedback from the customer and testing. Using a waterfall methodiology an extended period of time can go by before the software being developed undergoes any kind of assessment for viability. When the developed software is evaluated, it may or may not do what it is supposed to do. If it fails its tests, lots of effort and resources, already spent, could be wasted. Using iterative development methods, you can have those results much sooner and that potential loss can be minimized.

Jeff argues that iterative methods are repetitive and wasteful of effort. The customer must have much more involvement in the development cycle and could potentially hold up the works if they don't respond in a timely fashion. (Experience shows that this is more common than we would like to think.) If a customer is not diligent about their response and their inspection the same result is easily possible. Near the end of the development cycle the customer could decide that the project is not really going in the direction they wanted and didn't realize this until now (because they hadn't been paying close enough attention).

In an email I received from Wysocki he told me that his book is the first step in developing a new discipline that combines software development life cycle and project management life cycle. Stay tuned for more developments about this emerging technology that could change the way we do things into the future.

John Sturman, Senior Consultant Documentation Strategies, Inc.