|
|
Like this article? PLEASE +1 it! |
|
Dowsing for Requirements
Written by: Tom HathawayArticle Overview: Dowsing is a method for "devining" where water might be before you drill. Given the challenges of getting good business requirements from the business community, it might be time to try to apply this fringe technique to the process of business analysis.
![]() |
Free Download - The "Significants": Seven Roles Responsible for Business Requirements By Tom Hathaway |
Dowsing for Requirements
When I was a young man and never been kissed – no, wait, this is not that story; pardon my digression. Ahem. When I was a young man, my Grandfather was in the business of drilling water wells for farmers in north central Montana - true story, I am one of those few people who grew up in north central Montana and got involved in business systems analysis – maybe the only one. The burning question on everyone’s mind should now be, “What on earth does drilling water wells have to do with business systems analysis?” – and, SURPRISE! The answer to that question is the topic du jour.
When you drilled for water (at least in that part of the country at that time, I cannot speak for other times or places), it was very much a haphazard affair. Grandpa’s customer told him about where he (or she, let us be fair) wanted the well to be located. Given the customer’s parameters, Grandpa would attempt to specify the exact location at which to start drilling. He always used a mystical device called a “dowsing fork” (which was a forked branch from which the bark was removed after he cut it fresh from the closest willow tree – I am not sure what he did if there were none around). My dear Grandfather taught me how to build and use this forked stick to locate underground water.
The Dowsing Theory
The theory behind dowsing (also known as “water witching”, for those who like to know those things – it is actually a recognized phenomena often referenced in articles about ESP, Bigfoot, and flying saucers), was that when you walked over an area that had underground water, the dowsing fork would dip substantially. You, the Dowser, could feel this dip and that indicated that this would be a good place to drill.
The actual practice involved wandering around the general vicinity of where the customer wanted the well to be while holding the fork with exactly the right amount of tension in your two hands. You had to mark the ground anywhere that the dowsing fork dipped, indicated the possible presence of water. When you noticed a pattern of dips in close proximity, you had identified what you perceived to be the spot “most likely to contain water at some depth”. Of course, confirmation of the spot by a second Dowser proved that you could be certain that you believed that there just might be water somewhere down there if you drilled deep enough. All you had to do was set up your equipment and drill until you found it – or not, in which case the problem was obviously that you had not drilled deep enough.
For all of you doubters out there, let me set the record straight. The dowsing fork is a very efficient tool. Grandpa actually found water in many of the places he and I dowsed it to be. I believe that it is powered by the same energy as Tinker Bell – you just gotta believe hard enough.
From Dowser to Developer
Given those humble beginnings, I became fascinated in information technology (back then, known as “EDP” which I assumed meant “Electronic Dowsing Power”) as a programmer (in modern parlance, that would be a developer). One of the basic things that appealed to me as a young developer was the relative reliability of the computer. When I told it to do something, it did it, no if’s, and’s or but’s about it – unless I goofed. I had finally found an area where I had control over uncertainty, no need to “dowse” for anything – or so I thought.
After several years as a highly successful developer, I became more and more concerned about how those people out there (a.k.a. “Users”) were misusing my applications to do things I had not designed the system to do. On top of that, they complained that the system did not do what they wanted it to do. Inevitably, that got me interested in this other dimension, the dimension called “Analysis”.
My Experience with Analysis
I started studying Analysis and found a completely new universe, waiting to be discovered. Given the fact that this was a recognized discipline, taught in serious business seminars (and, later, in universities), I was confident that this area, just like programming, had to be a clearly defined – or at least, definable – discipline. That implied more-or-less strict rules, tools, techniques, methods, and whatever else was needed to make it work reliably. Alas, ‘twas not to be.
Over the span of many years, I – and the entire information technology industry with me - have tried to figure out how best to analyze a user’s needs and guess what they might want at some future date when the system was ready for delivery. I have learned, adapted, and used a myriad of techniques from JAD sessions to interviews, emails, teleconferences, web conferences, and many other means for gathering business requirements. These approaches helped me capture, clarify, confirm, and analyze business requirements as complete sentences, business process models, business data models, business and system use case models, user stories, features, and other more obscure representations of the users’ needs.
State-of-the-Art Analysis
All in all, I would have to state that whichever technique we tried,we – thanks to extremely dedicated and talented individuals with whom I have had the honor of working – ultimately used to successfully complete the project. Obviously, some projects were more successful than others, but I can unequivocally state that we as a team (always including representatives from the business community) found a way to make the selected technique work.
As an industry, however, Information Technology still has no clearly defined, single best way for doing business systems analysis consistently - which reminded me of my Grandpa’s days and the uncertainty of drilling wells. I neglected to mention earlier that, when we found water where it was “dowsed” to be, there was no guarantee that it would be drinkable, of sufficient quantity, or possess any quality but “wet”. I also do not know whether we struck water there because the dowsing worked, because we were lucky, or because there is water everywhere beneath north central Montana if you simply drill deep enough. We had a ton of water problems up there in north central Montana, maybe they still do. That does not sound all too different from the world I live in now, the world of business systems analysis. We still have a ton of problems getting the business requirements right.
The Ultimate Analysis Tool
What we have been seeking for this discipline is a good dowsing tool. We keep looking for something to point us at least in the general area where business requirements might be located and where, if we drill deep enough, we might find what we are looking for – the right requirements for our projects. If my Grandpa was still alive, he could probably tell me which tree has that “Business Requirements Bias” built into its branches. Perhaps he could even show me how I could use it to locate the requirements-most-likely-to-be-right for a project. All I would have to do would be to cut it off, remove the bark, and start wandering around the business world.
I loved my Grandfather dearly and he was a great man – for his day and for me, especially. On the other hand, having taken a long, hard look at the world that worked on the dowsing principle, I have decided that it probably belongs to that world in which Tinker Bell lived. What we need in this world are proven tools and techniques that repeatedly deliver reliable results. I have to admit that the older I get, the stronger I believe that we will ultimately develop those tools and techniques – if we are agile enough to keep trying.
Article Tags: business analysis, business requirements, requirements elicitation, requirements gathering
|
About the Author: Tom Hathaway RSS for Tom's articles - Visit Tom's website Mr. Hathaway has over 30 years experience as a practitioner and instructor in business information systems. He has successfully facilitated over 300 accelerated JAD (Joint Application Development) sessions dealing with mainframe, client/server and web-based applications in the US, Canada and Europe. In the early 1990’s, Tom pioneered the use of interactive CASE technology in JAD sessions (iJAD) to create in-session documentation of business requirements (InstaDoc™). As an instructor, he has developed and presented hundreds of seminars to thousands of participants on Business System Analysis, SDLC, Testing, and JAD Facilitation. Tom co-founded and co-manages the Requirements Solutions Group, a Tampa-based organization that provides training and consulting in business analysis and requirements definition. Throughout his career, Tom's major focus has been developing, using and teaching tools and techniques for increasing the quality and accelerating the delivery of information technology solutions that meet the needs of the business community. His talent for analyzing and synthesizing has resulted in original contributions to the industry’s body of knowledge. Click here to visit Tom's website Dowsing for Requirements The Fine Art of Listening Six Stages in the Evolution of a Business Requirement The Significants Seven Roles Responsible for Business Requirements Virtual Requirements Meetings Your Time Is Now |
Related Forum Posts
Share this article with your friends. Fund someone's dream.
Leave a comment below or share on the left and you'll help support entrepreneurs in Africa through our partnership with Kiva. Over $50,000 raised and counting - Please keep sharing! Learn more.
Get advice & tips from famous business
owners, new articles by entrepreneur
experts, my latest website updates, &
special sneak peaks at what's to come!
Email us your ideas on how to make our
website more valuable! Thank you Sharon
from Toronto Salsa Lessons / Classes for
your suggestions to make the newsletter
look like the website and profile younger
entrepreneurs like Jennifer Lopez.



