A paper by David McClinton titled "The Unwritten Laws of Systems Engineering," has three laws that are applicable to project management
- Everything interacts with everything else - a project is a "system." All the elements of the project - cost, schedule, scope, risk, resources, etc. - all interact with each other in know and possibly unknown ways. Most of these interactions are non-linear as well.
- Everything goes somewhere - projects are closed systems - all the elements of the project have to go somewhere. There are no left over parts in terms of cost, schedule, performance, risk, resources, etc.
- There is no such thing as a free lunch - the net effort to deliver the project is the same no matter what the methodology used. The seemingly extra effort of higher ceremony project methods must be paid by someone when using agile methods.
The last item - there is no free lunch - is especially important. For any proposed method, where do you define the system boundaries? If you are cleaver and define the boundaries so that some of the work and the cost is outside your domain, then you can claim a reduction in cost, effort and an increase in benefits over an alternative methodology. Say XP over a high ceremony software development process. This of course is fair and square from the point of view of XP, since it claims up front to push much of the work onto the customer, work hard to not do documentation, and generally skinny down the external processes that burden many development methods.
But in the end you need to expand the system boundary to include customer processes like requirements elicitation and management, verification and validation of the product, sunk maintenance cost, infrastructure changes and improvement management and the general project management activities found in any reasonably sized commercial firm (SOX mandated or not), then you come to realize that what ever the method there is a baseline set of activities - whether included or not - that must be done.
Who Pays in Agile Project Methods
The pitch of the agile project management proponents is that agile PM is less effort. The question is "who pays for the activities that are not performed by the agile PM method." Not pay in terms of money (although this may be the case), but pay in terms of effort and duration?
- If XP-style development projects can react to changing requirements, who defines and controls the requirements? The customer? So the customer has to be in the requirements management business.
- If there is little focus on documentation, then who pays for maintaining the system over its life. "The source code is the documentation." If you believe this, I've got a bridge I'd like to show you. The absence of documentation needs to be paid for in "perfectly clear and concise source code" or some other narrative of how the application works.
- If planning is of little interest in an agile development project, hen who pays for keeping track of cost, resources, deliverables sequencing, coordination among participants?
Software development is a Zero Sum Game - the attributes of the project - cost, schedule, performance, risk, etc. - are a minimal sum independent of the development methodology.
Any methodology can only INCREASE the cost and duration of the development project from its baseline.
By using the term "over" in place of "instead" Agile can have LESS of an impact on SOME areas of this sum, but someone, somewhere in the project community has pay for what ever costs are avoided by the agile methods.
