Requiring Requirements
No one seems surprised to hear that most IT projects fail. One would think that the increasing number of delayed and over-budgeted projects would illicit some kind of existential crisis on the part of IT professionals. Many projects sustain on life support missing nearly every milestone, either to eventually die or find some inkling of success (albeit at a cost that no one would have agreed to at the start of the project). Repeating the same mistake over and over it points back to one thing: requirements. What the hell is this thing suppose to do?
Arguably, there are technical issues, people issues, and various reasons IT projects fail. There are however, necessary components to success (conversely, guaranteed failure) and all of them start with requirements. And I don’t mean the kind of vague nonsense requirements espoused by analysts (e.g., “make it work with Siebel”), I mean the rigorously defined requirements that most of todays analysts and IT consultants couldn’t write to save their lives.
Requirements
I have been apart of enough projects to have seen the failures and successes that are common in this industry. Examining the failures there is a common theme: lack of good requirements. Not lack of documentation, not lack of specifications or attempts at requirements. Attempts were made at requirements in almost all cases, but failures persisted in every situation where the requirements were vague, ill-defined, or unrelated to the business needs.
I have worked on such gems as “build an end-to-end data architecture”, or “add live flash streaming”, or “integrate at&t”. These type of things always missed their deadlines and expectations. It’s surprisingly difficult to meet expectations where none were set; in the IT world anything delivered in that situation will be wrong and likely your fault. Worse, if the management is poor then the lack of requirements slides downhill onto the engineers who didn’t think it was their problem.
The problems can be seen a mile away. The difference between the professional software engineer and most of the developers occupying IT roles these days is that the professional engineer will not commit to any deadline without clear well-defined requirements. Any amateur can promise an “end-to-end data architecture”; but the professional will make no promises without requirements that he or she can work from.
In many cases, just the exercise of defining requirements would lead to the realization that the project isn’t feasible and in some cases doesn’t even need to exist. Better to know up front that your project will fail than wait months or years later, right? Not if you want to keep your job, but yes, if you want to work on successful projects.
Having well defined requirements will not ensure success, but it avoids a guaranteed failure.
Managing Success and Failure
Most IT projects like to track risks, but where is the failure tracking? Perhaps it’s too negative to go around tracking how a project could fail. Call it Success Tracking so as not to offend ‘the law of attraction’, but a clear definition of success and a scientific approach to understanding how the project could fail would save most doomed IT projects.
Without well-defined requirements this exercise is difficult if not impossible. How do you define success or failure if the requirements are not rigorously defined? Without an understanding of success your left only with failure.
Quality Assurance
Yet another tried and tested method for killing a project is a weak or non-existent QA process. There is no panacea to software development woes, but a QA process is a necessary component to success. Further, QA is impossible without well-defined requirements. Yet in many IT organizations there are QA teams working tirelessly to assure the quality of products without any clear requirements. What kind of quality are they assuring? What does it mean to pass QA without a requirement? It’s like a scientist doing a test without a theory…
Any amateur can toy with software to assure that it works the way the developer told them it works. A professional QA engineer follows the same guidance as the professional software engineer: they will not commit to assuring the quality of a product that lacks a well-defined requirement.
Required
IT projects require well-defined requirements. IT professional wishing to avoid the same repeated mistakes will formulate requirements before committing to dates. As an engineer, I am happy to work on R&D in the absence of clear requirements and with the understanding that there is no date and no committed deliverables in that phase. In most organizations this can seem an impossible feat, but this is where we separate professionals from amateurs.
REFERENCES
http://www.pbs.org/cringely/pulpit/2008/pulpit_20080418_004737.html
http://www.computerworld.com/managementtopics/management/project/story/0,10801,84266,00.html
http://www.onlamp.com/pub/a/onlamp/2006/06/20/why-do-projects-fail.html
http://www.spectrum.ieee.org/sep05/1685