“Especially for complex and costly IT deployments, customers need to invest more in the up-front evaluation, even if that entails … detailed requirements analysis ….” Rob Preston, “Montclair State Sues Oracle – Another Train Wreck,” InformationWeek.com, June 13, 2011.
And so it begins. Let’s do more up front analysis to keep us safe. More documents in advance, assuming that this will prevent any such slipups. So has this kind of waterfall approach succeeded in the past? Sometimes. But this is often how it gets started. Something goes wrong and the solution is often just this “figure it all out in advance before anything is done or committed.”
When I started computer programming, I would argue that we were what folks are now calling “agile.” Actually, I would call it chaos, but that is because we were often too eager to please. If a customer asked if our software could do “X” we would change the code and show it to them within a day and say “do you mean this?” This would start a back and forth relationship where we’d “tweak” the system until it was pretty close to what they wanted. Requirements document? What was that? Design and code inspections? What for — see it works! Comments in the code? Well, we are still making changes, so we don’t want to spend too much time doing that yet.
When this pre-agile approach inevitably caused degradation of the code and operations, management would step in and add controls on who could change the operational system and who would approve it. Additional phases and checkpoints were introduced to ensure all due diligence was done before proceeding to implementation. Pretty soon, we had huge checklists and process documents on how things were to be done. To make even the smallest change required significant documents, procedures and approvals. All sorts of “support” organizations popped up to ensure we were following the process and to ensure “quality” by auditing and inspecting what we were doing. There were now more “support” people than there were software programmers.
In retrospect, we clearly went too far in the “figure it out all in advance” direction just as we had gone too far in the “code and go” direction before that. It was all motivated by things going wrong and the unproven assumption that if we figured it all out in advance, then things would be better. They weren’t and the trend today is agility in software development and project management because the waterfall approach was not consistently improving results.
Recommendations as in this editorial too often help to send us, once more, to an extreme. Playing it safe is, well, safe. But it doesn’t necessarily result in better outcomes, only more “self protection” when the results turn out to be not good. It takes courage to do a really good job and that often means sticking to what we know works and managing the risk, rather than taking the personally safest route. I would have liked Rob’s conclusions better if he talked about using a more incremental or agile approach to minimizing risks and ensuring we were getting what we asked for. Instead, he suggested “an ounce of protection” but we know that these ounces often grow to tons of overhead without any improvement in the outcome.
Is your project management threatening to become overloaded with up front activities that add questionable value?