So What is the Answer?
In response to the difficulties and failures described, to say nothing of the frustration felt by software development team members, a number of technological approaches have emerged or are emerging. For instance: Agile software development, Extreme programming, and so on. As an example, the manifesto of the Agile Alliance reads as follows:[3]
Quote
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
End quote
A very laudable vision. However, which ever way you look at it, project management is a process, and one wonders whether such a manifesto is more designed to assuage programmers discomfort with cost and schedule constraints than to solve the problem of executive project control. As we described it at the beginning, a project has a "start" and a "finish" and a "bit in the middle" and that bit-in-the-middle consists of planning before doing. That all adds up to serialized activities, and this should not be surprising because "process" is defined as "A set of partially ordered steps intended to reach a goal."[4]
I don't believe that any clear answers have yet emerged, but there do appear to be some pointers:
- Software development is a problem-solving exercise.
- Schedule adjustment is not amenable to effort loading because there is only a narrow range of "right number of people for the job." Too few and the project will be extended by under-staffing. Too many and the project will be bogged down by excessive communication.
- The inherent uncertainty in software development is closer to the high end of technological risk, such as research and development, than it is to traditional building construction. Cost and schedule control and consequent contingencies must reflect this reality.
- Project management does require some serialization to reach a required destination.
- Therefore, good solutions must be arrived at by iteration, not just for the product but for the planning for the product as well.
The idea of iteration, prototyping, or trial product recycling should not faze any project manager of experience. The technique is well know in the construction industry. Some twenty years ago I worked on a very innovative light rapid transit system for Vancouver, Canada. The concept called for driverless, fully automated computer-controlled light aluminum train cars powered by linear induction motors on 21 km of elevated track. The majority of that track would be constructed of pre-tensioned concrete track beams, pre-cast to a standard that would eliminate "cusping" of the track at the bridge-beam junctions.
To enable a smooth high-speed ride the whole system in this hilly terrain was designed to a continuous horizontal and vertical curve generated on a computer program written for the purpose. All these innovations were areas of high technological risk. To test the concepts, a full-blown trial section, i.e. a prototype, of one kilometer was constructed at the outset. This test section resulted in a number of changes, such that the final project was commissioned ahead of time and survived flawlessly its first full-scale, public free-ride overload test program. The system has since operated with remarkably little down time.
Another example of prototyping is more common. It is standard practice in the apartment and hotel building development business to construct a typical show suite or hotel room even before the structure is completed. This is to make sure that furniture will fit, circulation areas work and even furnishing, fittings and colors blend and are acceptable to knowledgeable marketing people in the industry.
But perhaps the final pointer in software projects is the most telling:
- It is typically necessary to enter the next stage of software development to establish the consequential effects of the previous stage before it is possible to validate the acceptability of that previous stage. This may well result in going back to that previous stage and modifying it.
This is a significant departure from the linear mantra governing construction projects.
3. http://agilemanifesto.org/
4. Rational Unified Process Glossary, 2000
|
People Problems
