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

Trust Everyone

The world, to me, is a spectacularly confusing and amazing place. I am, admittedly, wildly ignorant to anything outside of my own reality; we all are, save God-like intelligence on the order of omniscience. My ignorance is to such a degree that I don’t even know why I exist and I’ve yet to meet someone who does. The “fundamental question” and we don’t even have an answer!

So, we’re blindly cruising through life with some “feelings” about what we should be doing and from what I can tell there’s a bunch of other people equally clueless about what they’re suppose to be doing. We seem to be born trusting these other people, and over time learn to distrust them (often for good reasons). What’s worse, I’m not even sure what those words mean: to trust or distrust a person…

It seems to me that you don’t “trust” another person, you trust your expectations of that person. That is, that the person will act the way you thought they were going to act. In that case, “distrust” is when you are expecting things from someone where you have knowledge that they will not (or refuse to) comply to your expectations.

Our expectations are often based on those same “feelings” and can even include moral judgments; some notion of a perfect or right way of acting. Our expectation of perfection yields distrust in the world around us.

I would argue that while we have a desire towards perfection we would be silly to expect perfection (and breed distrust). If we release our expectations of ourselves we are free to pursue perfection while maintaining ultimate trust in ourselves, and the people and world around us. It then forces the burden of trust onto the individual, trust becomes a matter of learning and knowing rather than expecting.

In other words, my trust is only a measure of how well I know… my distrust is only a measure of how wrong I was in what I thought I knew.

Lounge with a View

When I got home today there was a package at my doorstep that appeared like a black duffel bag. It contained instructions to cut open the bag.



As I opened it slowly expanded. A little less dramatic than the memory foam mattress that I ordered but it was interesting as this thing grew bigger and bigger.



Apparently it takes 48-72 hours for it to properly expand to its full-size after being compressed for shipment. Memory foam is awesome! Eventually it looked like this, albeit apparently not yet its full-size. Perfect for enjoying the view!



There’s a few other items on order, comfy chairs, and some coffee tables. Zen-like simplicity to sit down to a good book, draw, paint, work on a laptop, or just sit quietly over food and wine. Whether we choose our own design or just accept what was given it effects our every thought and every action. Our lives often are as malleable as my lounge cushion; out of the bag it was born in it expanded to full-size, and ironically can no longer fit in the old bag!

Late Night Avocado Shake

I haven’t used my blender since I was in college. One of the few things I found through the move and give-away that I decided to keep. For a while I’ve been thinking that I should be trying different avocado recipes, though never seemed to find the time.

Rather than look for time, I changed the design. Call it feng shui or ergonomic usability; the design of the environment will effect the thoughts, perception, and outcomes of our actions. Surround yourself with distractions and you will be distracted. Place a blender near the refrigerator, on the counter next to the sugar above the silverware drawer. Milk and avocados in the fridge… Everything within reach. The human factors were there, the Qi was flowing…

The avocado shake practically made it self. I just simply enjoyed it!

View from Bed

I’ve finally moved out of Solana Beach and to La Jolla. Despite giving away most all of my possessions moving was still a pain — but this morning waking up to an ocean view did make me feel better!

Letting go of old possessions and changing habits seems to be as continuous as life itself. We acquire then purge, acquire some more and the cycle continues. The layers and layers of perceptions that bind us to this reality I’m not even sure have a limit.

In the meantime I’m happy to explore La Jolla; enjoy the restaurants, cafes, clubs and enjoy the view from bed.