In This Issue
Not Just Another Fairy Tale
Anticipation versus Avoidance
And Along Comes a Human Being
Update on Virtual Workshops
Editors’ Notes: Catalog Update and Beyond
Introduction to Business System Requirements
April 7, 2008, 11 AM - 12 AM EDT
Introduction to Business System Requirements
September 8, 2008, 1 PM - 2 PM EDT
Introduction to Business Process Analysis
June 2, 2008, 2 PM - 3 PM EDT
Introduction to Business Process Analysis
October 6, 2008, 1 PM - 2 PM EDT
Introduction to Modeling and Analyzing Business System Data
June 2, 2008, 1 PM - 2 PM EDT
Introduction to Business Use Case Documentation and Modeling
April 7, 2008, 1 PM - 2 PM EDT
Introduction to Business Use Case Documentation and Modeling
July 7, 2008, 1 PM - 2 PM EDT
Introduction to Business Use Case Documentation and Modeling
November 3, 2008, 1 PM - 2 PM EDT
Introduction to Preparing and Facilitating JAR/JAD Sessions
August 1, 2008, 1 PM - 2 PM EDT
Introduction to Planning, Preparing and Executing User Acceptance Testing
April 7, 2008, 2 PM - 3 PM EDT
Introduction to Planning, Preparing and Executing User Acceptance Testing
August 1, 2008, 2 PM - 3 PM EDT
Introduction to Planning, Preparing and Executing User Acceptance Testing
November 3, 2008, 2 PM - 3 PM EDT
1-10 How to Gather, Analyze, and Define Business System Requirements
March 11 - 13, 2008, Tampa, FL
1-10 How to Gather, Analyze, and Define Business System Requirements
June 3 - 5, 2008, Chicago, IL
2-30 How to Discover and Develop Business Use Cases
April 23 - 24, 2008, Chicago, IL
2-30 How to Discover and Develop Business Use Cases
June 9 - 10, 2008, Portland, ME
2-30 How to Discover and Develop Business Use Cases
September 9 - 10, 2008, Chicago, IL
How to Gather, Analyze, and Define Business System Requirements
May 5 - 8, 2008
How to Gather, Analyze, and Define Business System Requirements
October 20 - 23, 2008
How to Model, Analyze, and Improve Business Processes
March 17 - 20, 2008
How to Model, Analyze, and Improve Business Processes
July 21 - 24, 2008
How to Model, Analyze, and Improve Business Processes
November 10 - 13, 2008
How to Model and Analyze Business System Data
July 14 - 16, 2008
How to Discover and Develop Business Use Cases
May 19 - 21, 2008
How to Discover and Develop Business Use Cases
August 18 - 20, 2008
How to Discover and Develop Business Use Cases
December 8 - 10, 2008
How to Prepare and Facilitate a Successful JAD Session
March 24 - 26, 2008
How to Prepare and Facilitate a Successful JAD Session
September 15 - 17, 2008
How to Plan, Prepare, and Execute User Acceptance Testing
May 14 - 16, 2008
How to Plan, Prepare, and Execute User Acceptance Testing
September 29 - October 1, 2008
How to Plan, Prepare, and Execute User Acceptance Testing
December 16 - 18, 2008
Investing in Information Technology : A Decision-Making Guide for Business and Technical Managers by Bill Bysinger, Ken Knight (Contributor)
Problem Frames: Analyzing and Structuring Software Development Problems by Michael Jackson
Timing Analysis
is a great technique for identifying timing anomolies - and defining the requirements needed to eliminate them.
Voice: (813) 319-5851 Fax: (813) 864-0131
Email:
training@requirementssolutions.com
Internet:
www.requirementssolutions.com
|
The Goldilocks’sche Theory of Business Analysis
Not Just Another Fairy Tale
To paraphrase Lewis Carroll, if you don’t know what you want, you’ll never know when you get it. Some level of analysis is necessary in the beginning of a project to define what you expect to have when it’s over. That, in a single sentence, is what business analysis to determine requirements is all about. Unfortunately, life is never as simple as a single sentence, is it?
If you even contemplate analysis, your problems are just beginning. If you spend too much time in analysis, you’re wasting your resources and you may run out of steam (read time or money) before you’re done. If you spend too little time in analysis, you will end up with an unsatisfactory result which is frustrating for you and your customer. The goal, then, is to find the Goldilocks'sche level of requirements determination. (OK, Goldilocks is not Lewis Carroll, but at least I stayed in the genre!) The challenge, of course, is recognizing what “just right” is for you, your customer and your project. Projects, like life, are all about balance.
Anticipation versus Avoidance
So, what intelligent recommendation do we have to help you figure out when to quit analysis? A very simple one: good requirements make for a boring story. In line with the fairy tale analogy of this article, good stories rely on the unexpected to make them exciting, interesting and fun. Good projects, on the other hand, are based on avoiding the unexpected. You can achieve that either by anticipating anything that is remotely possible and planning on how to avoid it (a.k.a the structured approach); by rushing through to completion so as to not give anything unexpected time to develop (the Agile method); or by plain, old denial. Plausible deniability might be a desirable or even admirable trait in a politician; for business analysts, it stinks.
And Along Comes a Human Being
This leads to the question of the human element. We live to tell stories. We enjoy sharing the stupid, inexplicable events that shaped our lives. We often go so far as to embellish the events when they were too boring or simple just to make our stories (and ourselves) more interesting. So who wants to work on a boring project? You do!
Go ahead, business analysts of the world! Dare to be boring, at least while you’re actively involved on a project. And don’t worry, you can always add a lot o spice when you talk about how you deftly defied fate and foiled it’s attempts to derail your project by sticking to your plan: requirements first, design later. Requirements are King, long live the King. With good requirements, you have a much better shot at living happily ever after. And that’s the way every good fairy tale ends, isn’t it?
Update on Virtual Workshops
Recently, we announced the inaugural offering of our virtual workshop, "How to Write Effective Business Requirements" and promised a report of the efficacy of this new media as a tool for transfering skills. Having now completed several iterations of the training, we decided the best way to report was by quoting particpant evaluations:
- ’This was a "5" all the way! This type of subject matter is so well suited to the virtual workshop environment. ’
- ’I liked how the instructor used the participant symbols to get responses as well as randomly calling on the participants. He attempted to make it an interactive session.’
- ’Reinforced definitions of effectively written requirements.
’
- ’In my opinion, the training session was pretty interactive and professional especially given the fact that this was via teleconferencing. The trainer did a very good job to keep us engaged and he displayed good knowledge in his area of expertise. I learnt a lot from the session as well and applied them in my work. It's a pity that there wasn't sufficent time to cover more.’
As a result of evaluations such as these and our own impressions on the use of this exciting, new tool, we have decided to expand our offerings considerably. Check the side panel for our updated schedule of virtual workshops. Looking forward to "seeing" you at one!
Editors’ Notes: Catalog Update and Beyond
Also, for those of you who have downloaded copies of our course catalog in .pdf format, we would like to mention that you might want to update your version. We just uploaded the updated version of the catalog. It contains several renamed classes as well as a couple of workshops that we did not have in the old version. You can download it at http://www.requirementssolutions.com/CourseCatalog.pdf .
On a different topic, whereas we are convinced that today's feature, "Goldilocks'sche Analysis" has much value, we also thought it left a lot open. It was, like fairy tales tend to be, a bit vague and unfulfilled. Ergo (always love to use that word in a sentence), we have decided that we would launch a new series of articles in future Noiseletters. The series will deal with the differences between "good" and "not so good" requirements. The first one will be in the next edition of the Noiseletter and, depending on the reactions and remarks from you readers, we will see where that takes us.
Tom Hathaway and Dan Myers Managing Partners
Future Feature: "'Good' vs 'Bad' Business Requirements"
|