Below is a short list of free desktop/productivity tools that I use regularly. I thought some of you might benefit from knowing about them as well. Please feel free to comment or contact me with other nifty free tools you use to help you (or your computer) work more efficiently. I’ll continue to add to this list as I discover new ones as well.

Evernote

Evernote is my “external brain”. I use Evernote for my personal notes, work notes, and to brainstorm blog posts. It has handy web-clipping capabilities that make it easy to capture screenshots or text and save them for future use. Evernote allows you to arrange information into separate notebooks on different topics and supports tagging. I’ve been really pleased with it so far. Evernote also stores all your notes online so they are accessible from anywhere you can get a connection – even on your mobile phone. It also enables you to share notebooks if you want to collaborate on a small scale.

Freemind

Freemind is a free mind-mapping tool that I regularly use to help sort out my thoughts. It is great for use in decomposition exercises and for arranging ideas hierarchically.

Pencil

According to the web site, “The Pencil Project’s unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use.”  I don’t use it everyday on the job, but I have begun investigating Pencil as a GUI/Prototyping tool. It comes as a Firefox add-on, or stand-alone application. Obviously, it isn’t as robust or sophisticated as some other wireframing/prototyping products, but it provides all the basic functions one would expect in a quality tool, and you can’t argue with the price!

Fences

Fences is a tool for helping clean up messy desktops. It’s sort of like being able to throw all your clothes and junk under the bed and in the closet with a mouseclick. Basically, fences lets you sort your desktop icons by logical groups and temporarily hide information you don’t want to see. As a practical application, I often have to present documents or presentations via projector. Instead of the world seeing my cluttered Windows desktop, with a double-click I can hide all but those icons I want to remain displayed.

CCleaner

CCleaner helps clean up all the junk files and registry issues that can bog a computer down and cause it not to perform well. CCleaner takes care of the junk and is useful for uninstalling programs and cutting out some of the unnecessary programs from your startup menu that cause your computer start-up time to be slower than you’d like. An alternative with a few more features, but that I’ve not used for as long is Glary Utilities.

Icon Restore

As I mentioned, I have to do presentations via projector quite often, and one of the most annoying things about doing that is that your desktop icons end up getting moved all over the place. Icon Restore lets you save your desktop icons so when your desktop gets messed up by changing display types, you can quickly set it back to normal.

View the original post or comment on Free Desktop Tools a Business Analyst Should Know About

See the thin, black line down the middle of the table below? That’s the Business Analyst Tightrope. For wider appeal we could as easily call it the “Good Enough” tightrope.

If you’re an analyst, it represents the line you tread when trying to balance the risk of missing requirements against that of paralyzing the project until “everything” is known.

Not very wide, is it?

The trick to staying on the “good enough” tightrope is to learn and apply some important principles:

1. “Good enough” requirements are not perfect, but they are sufficient to allow design to proceed with an acceptable level of risk. (Thanks Mr. Wiegers!)
2. “Good enough” requires time, planning, good communication and cooperation from stakeholders, both in the business and in the factory. Hopefully it goes without saying that it also requires an analyst that does a good job of eliciting and analyzing those requirements!
3. You will miss important requirements if you don’t have the above.
4. You won’t produce a “perfect” requirements model/spec upfront even if you do have the above – no matter how long you decide you are going to spend on it.

To quote another of my favorite reads:

Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensible to everyone, you stop when the document is sufficient to the purpose of the intended audience.

- Alistair Cockburn from Agile Software Development

Now, I know the table above isn’t complete, and there is a lot more I could say on this topic. But you see, I have probably 20 or so blog posts that have been sitting in draft mode for up to a year. Why have I not gone ahead and published them? Because they weren’t perfect!

Obviously, I need a dose of my own prescription (as is usually the case with my more “prescriptive” posts), so I’ll start today. I didn’t want to let the imperfection of this post keep me from sharing what I think is a useful idea for BA’s, so here it is in its “good enough” state.

I’d love to add more to the table, though. If you have any more ideas on items that fall on either side of the missed requirements/analysis paralysis tightrope, please comment or contact me with them. I’ll continue to update the table with your contributions and mine as I think of them.

View the original post or comment on The Business Analyst Balancing Act

I was sorting through some of my bookmarks and articles I’ve accumulated over time via the Web, and found that there are a few articles that I  seem to refer back to time and again. I’ve provided links below to several articles/presentations I consider to be “classics” in the field of business analysis and requirements engineering that I think any analyst would benefit from reading.

Some are relatively new, and some have been around for quite a while but are still every bit as valid as the day they were published.

I hope you’ll get as much use and enjoyment from these articles as I have.

Analysis/Requirements

• Building a Requirements Foundation through Customer Interviews – Esther Derby
• Use Cases: Best Practices – Ellen Gottesdiener
• Why I still use Use Cases – Alistair Cockburn
• The Fuzzy Line Between Requirements and Design – Karl Wiegers
• Structured Analysis Wiki – Ed Yourdon

Architecture

• Straight from the Shoulder – John Zachman

Communication/Collaboration

• Customer Rights and Responsibilities – Karl Wiegers

Methodology

• No Silver Bullet – Fred Brooks
• Lean Primer – Craig Larman and Bas Vodde
• Software Development as a Cooperative Game – Alistair Cockburn
• Agile Analysis – Scott Ambler
• The Agile Manifesto and the Twelve Principles of Agile Software

If you have any “classics” that you’d like to share, please comment so I can add to my collection and readers can add to theirs, too.

Keep an eye on this post – I’ll add more “classics” as I come across them.

View the original post or comment on Classic Business Analysis Articles

Sometimes the benefit of completing and implementing a solution just doesn’t justify the cost. Or, despite the best of intentions, a project will be implemented that just doesn’t end up solving the problems it was intended to.

Unfortunately, in many cases an organization will spend months-worth of time and other valuable resources on such an implementation before coming to either realization. When this happens, the company has to cope with not only with the sunk cost of resources spent on the abandoned project, but also the opportunity cost of what those resources could have been used for otherwise.

So, how can situations like this be avoided? I could give a long answer, but I’ll keep it nice and short: Business Analysis.

Root cause analysis, business case justification and definition of clear and reality-based objectives are all fundamental business analysis functions. By performing them well, and early in the process (the earlier the better!) we can help our customers have confidence that we’re on track to solve the right problem in the right way, which gives them the best possibility of realizing the return on their investment.

There’s a commonly-held truism in the industry that the earlier a defect is detected in the life of a project, the cheaper it is to correct. That being the case, what better time to avert these ill-fated projects than before they even get started!

As analysts, it’s widely known that we produce specifications. We hold meetings, ask a bunch of questions, create nifty diagrams, and lots of other things. What I think is less widely known – or at least acknowledged – is the value that a good analyst can provide before a work request is even submitted.

Personally, I feel every bit as successful when I help save a customer from the sunk and opportunity costs mentioned above by scrapping a project before it gets started as when I help see a project through to successful implementation. In either case I’ve provided real value not only to the customer, but to the delivery organization as well.

To be able to do this, the BA needs to be “in the loop” early as a trusted adviser to the business and empowered to ask the types of challenging questions that can either reinforce a strong business case, or dismantle a weak or misguided one.

So, have you ever “killed” a project? Are BA’s in your organization involved in the process early enough to head off projects that shouldn’t be undertaken? Do you agree that it’s the business analyst’s role to get involved at such an early stage?

I’ll be interested to hear your thoughts and comments.

View the original post or comment on Business Analysis Can Kill a Project (In a Good Way)

I know I’m preaching to the choir, here, but I just have to tell you – Business analysis is flat-out hard mental work! I was exhausted when I got in today after a day full of requirements elicitation & analysis working sessions. Fortunately, I had already done enough thinking over the past few weeks to accumulate a few more passing thoughts on business analysis to share.

• As important as it is for a BA to identify and understand business need, understanding exactly what the business/customer needs doesn’t count for much if you can’t specify that need in a way that is easy to understand and use for those that are going to design, build and test the product.

• On a note somewhat related to the previous…. Time spent re-arranging and re-working requirements to shoehorn them into a particular standardized template is typically time wasted. Designers and developers could typically care less about how well you conform to the template du jour as long as the spec is – again – something they can read and use.

• I wonder if I’ll ever get bored of business analysis. As of now, I can’t see it happening. It seems like every day presents new puzzles to solve.

• A business analyst is well-served by developing a functional/working knowledge of a variety of development methodologies. It’s fine to have preferences for one over the next, but versatility increases opportunity.

• So, I wonder what will be the next “big thing” after agile?

• I’ve pretty much stopped using the term “Best practices”. To me, it’s mostly a persuasive/marketing term most commonly used by consultants and salespeople. There are lots of good practices that seem to work well enough in a variety of situations, but I am less convinced of “best practices” that are supposed to suit any situation – or of those selling them.

• … And, finally, why do I *still* occasionally catch myself starting to list use cases for plain “things the actor does” that don’t really represent specific goals? Seriously! I actually do know better!

View the original post or comment on Passing Thoughts on Business Analysis II

I’ve always been of the opinion that I’d like to know as much as I can about whatever  I can because you never know when something you learned may come in handy.

That said, I do think there are four key knowledge/capability domains that are especially important to the business analyst. I’ll provide a brief description of  each domain and then provide short lists of possible self-check/development questions that you might find useful in determining whether you think you have adequate knowledge in a given domain given your current situation or even your career goals.

Business Analysis Skills & Techniques

The business analysis domain is, unsurprisingly, the most important skill/knowledge domain for a business analyst. It includes those skills and techniques typical of the business analyst (BA) job description, and that set the BA apart from other roles – typically project managers on one hand and designers or solutions architects on the other.

A business analyst with a solid foundation of BA domain knowledge will have inevitably accumulated some knowledge in the other domains as well, but expert knowledge in the business and technical domains isn’t necessary for an analyst to be effective.

The Business Analysis Body of Knowledge (BABOK) is a widely recognized and recommended resource for Business Analysis skills and techniques.

Personal Development Questions:

• How well do I understand the principles and techniques of requirements elicitation, analysis, specification, validation and management? How well do I perform them?
• How well am I able to distinguish between symptoms and true business problems?
• What is a business case, and why is it important to the work I do as an analyst? If asked to, could I help build a business case? Would I have the will to be honest and objective if the business case just isn’t there?
• How do I link product/project objectives to strategy?
• How well do I understand the various forms of requirements and when they should be used?
• How well am I able to model complex ideas that are more easily understood visually than verbally?
• How well do I know the various solution delivery methodologies including traditional and agile methods? How well do I understand the role of the analyst in each?
• How well do I understand the needs of other roles typical to solution delivery – Business stakeholders, IT management, project management, QA, Development, etc.?
• Do my requirements meet the needs of solutions delivery teams? If there is a lot of churn, and “analysis paralysis” how do I achieve an understanding with these teams?
• What is my knowledge of requirements management technology and the tools that are available to help define, store, and manage requirements?

Business Domain Knowledge

Business domain knowledge includes an understanding of the broader industry, competitive landscape, and even gets down into the specifics such as your particular client/company’s culture and business processes.

A significant part of an analyst’s stewardship consists of helping business stakeholders identify problems and define objectives. Business domain knowledge enables an analyst to be more efficient. While an analyst that is gifted in analysis skills and techniques might be able to do an adequate job without deep business domain knowledge, it’s reasonable to think that an analyst that does have a strong sense of business context should be able to more quickly determine the right questions to ask, and the right approach for handling business challenges.

Personal Development Questions:

• Who are the key players in the market?
• What are the common elements of the most successful players in the market?
• What trends or innovations may change, or are changing the competitive landscape?
• What position does the company hold in the market?
• What is the company’s strategy?
• What are the company’s mission? vision? values?
• What products does the company offer to the market? How are they received relative to competitive products? Why?
• How are the company’s products distributed?
• How does the company measure product success?
• What are the company’s organizational and functional strengths and weaknesses relative to its competitors?
• What specific systems or products will you be working with? How are they important to the company’s success?
• In what ways the the company’s culture conducive, or a barrier to product/project success?
• What are other barriers to successful product/project implementation?
• Who are the key, influential people in the company whose buy-in is critical to getting things done?
• What “sacred cows” or untouchable products/systems/programs does the company cling to?

Technical Knowledge/Aptitude

This domain ranges from a general understanding of how technology is used to solve business problems to detailed knowledge of specific systems or technologies.

The analyst role includes being able to make solution recommendations to the business – or at least to help in the decision making process. Knowledge of what the company’s technical assets and their capabilities and limitations can help the analyst be more efficient in this area. Technical knowledge is also useful in that it brings the analyst credibility with designers and developers and business stakeholders alike.

This seems to be the area where an analyst with deep knowledge is inclined to overstep the bounds of solution definition and amble into solution design, and there are varying opinions as to whether it is a good thing or not for an analyst to be an expert of things technical.

Personal Development Questions:

• What business problems does the company address through software and systems?
• What software and systems does the company use? What are those systems used for?
• What is my understanding of general technical architecture concepts? Of the company’s technical architecture in specific? What are the layers or tiers of architecture, and what is the importance of each?
• What technology does the company use to transfer information internally and externally?
• What is the history/evolution of the company’s technical architecture (systems and technologies used)
• What alternatives to those systems exist in the market?
• What are the relative strengths and weaknesses of the software and systems the company uses?
• How do users interact with the systems and software?
• What systems have I used extensively, or have a working knowledge of?
• What software development or querying languages and tools do I have a knowledge of? Which ones are used in the company?
• What are the primary sources of data in the company? What are the primary destinations of data in the company? What is my understanding of data models and the specific models and schemas the company uses?
• How are the various systems interdependent, or how do changes to one system typically impact other systems?
• What is the CIO’s (or the equivalent’s) information strategy, or what is the vision moving forward for using software and systems to meet business needs? What is the plan for getting there from where we are now?

Soft/Interpersonal Skills & Professionalism

Soft skills and interpersonal skills have more to do with the individual. Some are naturally gifted communicators or great with people and others are less so. Some may place these types of aptitudes under the business analysis domain and that’s ok, but I list them separately because I think they’re more generalized. Although they can be points of differentiation for a business analyst, they are not at all unique to the BA skill set. In fact, they’re required, to some degree, of most roles.

Again, you can be a passable business analyst without being a “people person” per se, but the skills in this area can be pretty obvious points of distinction between the passable and the expert.

Personal Development Questions:

• How well do I work with others? Operate in a team environment? Put the interests of the team first?
• How well do I facilitate meetings, workshops and reviews?
• How well do I prepare for and manage meetings in general?
• How is my general professional demeanor? Am I punctual? Do I dress appropriately to the business setting? Do I show professional courtesy in my dealings with others?
• Do I have the ability to lead others even if I don’t have a title that requires others to follow?
• How well am I able to broker mutual, win-win agreements between parties? Do I have a sense of when it’s appropriate compromise, and when it isn’t in order to achieve the most favorable outcome?
• How well do I communicate ideas in spoken and written form? How good a listener am I?
• How well do I establish and nurture relationships of trust with key business and solutions stakeholders?
• How well am I able to track down and find answers to questions that I don’t know the answers to myself?
• How well do I package and present ideas? How well am I able to tailor the message to the audience?
• How efficient am I with my time and courteous with regard to the time of others?
• Am I self-motivated, or do I require constant follow-up to make sure I am completing my work?
• How well do I accept constructive criticism?

Recap

So there are  my thoughts on the four key domains of business analyst knowledge. I didn’t want to get into it in this post, but what’s interesting is that you’ll find that by assessing your mix of capabilities in these four areas, you can get some ideas as to what type of BA career might interest you and how/where you might want to specialize.

Would you have categorized the key areas of BA knowledge differently? What would you add or change? As always, I share my ideas on this in hopes of getting some good dialog and feedback.

View the original post or comment on Four Key Knowledge Areas for Business Analysts

I picked up an interesting article by Joe Gollner this morning in my Google Alerts that seemed to call into question the need or at least the timing of the creation of the IIBA and its accompanying body of knowledge, the BABOK.

I thought I’d send the link on over to Kevin Brennan to get his take, but by the time I had a chance to log on to Twitter, he had already received word of the article and responded via the IIBA blog.

I’d encourage all of you to read both, because a) I think Gollner’s criticisms are pretty common and worthy of discussion, and b) Brennan provided what I feel to be an excellent response.

Point/Counterpoint

Here’s a quick summary, then I’ll chime in with a closing thought or two.

Gollner’s main points, as I interpreted them, are:

• Business analysis is a “fledgling domain” that has been only recently considered a discipline unto itself, and definition of the role is still very much in flux.
• For those reasons, “distilling a body of knowledge, and associated certification standards and educational programs, seems very much pre-mature.”
• While the time is not yet right for formal BA certification standards, pulling together a BA body of technology is a worthy endeavor;  “the effort to bring some order to this field is laudable and overdue.”
• A central organization driving BA knowledge and standards  “should be directed towards building the necessary tools and techniques, and proving them in practice” rather than emphasizing formal certification at this early stage.

Brennan’s key points, again, as I interpreted them are:

• Business analysis is not a new profession. It has been around a lot longer than the “business analyst” role as now commonly known.
• In recent years, more in industry are recognizing the need for business analysis, and people who do business analysis are now more commonly referred to by the business analyst title.
• Fledgling domains whose role definitions and preferred techniques are in changing/evolving are precisely those that stand to benefit most from efforts to drive a central, standard body of knowledge (as was the case with PMI).
• Having a shared vision of expectations among practitioners is key identifying good/best practices. It is the aim of IIBA and the BABOK to identify and provide this vision.
• That the IIBA hasn’t gotten the BOK and certification standards perfect is not a good reason to not do them at all. I saw this as Kevin’s central tenet. In fact, the title of the post is, “The Perfect is the Enemy of the Good”. Further,

“The important question for practitioners is not whether the current BABOK Guide is perfect, but whether it represents an improvement over having no shared understanding or common definition of business analysis.”

My thoughts?

To be fair, I am a member of IIBA and will state upfront that I am very grateful for the work that they have done to provide a focal point and a forum for discussion. IIBA has not mandated standards, but has done just what a good analyst would do and done the research among practitioners to elicit, analyze, specify, validate and then manage them.

I find the BABOK (especially version 2.0. Didn’t care a lot for how 1.6 was organized) to be very useful and an important  step toward being able to compare apples to apples across companies and industries when speaking of business analysis techniques and competencies. I’m glad to be associated with the IIBA and look forward to working with their leadership to continue blazing the trail.

All of that said, I admittedly haven’t come around quite yet as to the need for CBAP certification, but I figure that’s all in good time. For me it has been more a question of economic cost/benefit, than one of concern over whether IIBA and the BABOK were too rough, immature or unstable to be of any value.

My parting questions to those  who might think organization of the IIBA and a set of standards is premature would be, “if not now,  then when? And if not IIBA, then who?”

Go take a look at both articles, though, as my summary gives the gist but doesn’t do either justice. First give Gollner a look, then read Brennan’s response. Hope you enjoy as much as I did!

View the original post or comment on The IIBA: Timely or Premature?

Laura Brandau (@ClearSpringBA), fellow BA blogger and friend of Practical Analyst, just published the e-book, How to Start a Career as a Business Analyst. She wrote it, “with the hope of helping other talented professionals discover if business analysis is their passion, and, if so, help them on their journey into the profession.”

Having had the opportunity to read the book myself, I would highly recommend it to those who want to understand what a BA does day-to-day, and how to get a foot in the door – whether as a recent college grad or an experienced professional looking to make a transition.

Q&A with Laura

Laura and I were recently swapping e-mails over some of the particulars of the book when I took the opportunity to ask her a few questions about the thought and creative processes that went into creating it, and about some of the things she learned throughout. You’ll find those questions along with her replies below.

When and why did you decide to write a book on becoming a BA? Of all the topics available in systems engineering in general, and business analysis in specific, what drew you to the topic of starting a career in business analysis?

I decided to start writing earlier this year after receiving several questions from professionals looking to become business analysts. I realized how challenging it was to break into our profession and decided to do what I could to help people out.

What motivated you to write the book?

I’ll be perfectly honest, the idea germinated in response to a brainstorming session I did using some spare time to turn www.bridging-the-gap.com into a sustainable venture—i.e. generate revenue in parity with the time I invest without compromising the quality of the site.

That said, the idea behind the book is much larger than that. It’s also my way to make a contribution to the profession and really help people who want to be business analysts.

When I started planning, my goals and aspirations where fairly contained. I thought that if I can help a few people into the profession, I would have done some good work. I also simply wanted to learn first-hand about the book writing, publishing, distribution, and marketing processes so that even if I didn’t get this book right I’d be better prepared for the next one.

What made you decide to go the book route? You’re a relatively prolific blogger, why a book in lieu of a series of blog posts?

I actually never considered writing a series of blog posts on this topic. For me blog posts tend to contain one or two small ideas and this was such a big idea I needed to approach it differently. The book is structured in a logical way and, for me anyway, blog posts tend to come at topics from different angles and there is not necessarily a logical progression from one post to the next. As I interviewed people, their perspectives crossed multiple parts of the book. By infusing those ideas into a structure, the book format provides more value to the reader than a series of posts that were published incrementally.

What was the most challenging aspect of writing the book?

By far the most difficult aspect of writing the book was final editing. I sailed through the initial planning and writing stages. I stayed in an “almost done” stage for at least 6 weeks. Just like software development, the more times I looked at the book the more I found that I could add. I had to put some pretty strict prioritization methods in place to keep myself from adding content that took away from the main flow of the book or didn’t really add to the book.

Moreover, once you’ve read and rewritten the same section multiple times, you can tire of your own writing. I put the book aside for a week at a time at least twice just to give myself the opportunity to come back with a fresh perspective. I was lucky to have you and Doug Goldberg take a pass through a final draft and find latent typos.

Which aspect of the book are you most proud of?

I am most proud of the section on accumulating BA experiences. I really tried to think outside the box for how people can gain business analyst experiences. I get emails all the time from people who are getting more education but have never worked in a business, but everyone I interviewed came into the BA profession with related experience while they were working professionals. You always can (and should) keep learning. But at some point you have to start applying your learning or you are not really moving forward. I tried to be broad enough with the ideas to make it possible for someone to accumulate relevant experience in nearly any work situation.

What are some things you’ve learned about becoming a business analyst by delving into detailed research of the topic?

I learned that there are multiple views of the BA fundamentals. While the IIBA® has defined the superset of BA knowledge in the BABOK Guide® there’s not a common understanding of what an entry-level professional needs to know. As a result, most people try to learn it all. In reality, there are some things you need to know to get started and some things that make a lot more sense once you’ve worked through a few projects.

Jumping ahead 5 years – what would you like to be able to look back and say about How to Start a Business Analyst Career?

I hope to look back and be able to say I helped at least a few people fine tune their paths and become successful business analysts. Hopefully this is what they love doing and they have now found their own way to give back to the profession as well. This is what it’s all about.

Anything else you’d like to share or any words of wisdom for Practical Analyst readers?

If you think you want to be a business analyst, just get out there and try it out. Our profession is made up of change agents. If you want to lead changes in organizations, you’d better be able to lead your own professional changes.

We no longer live in a society where employers take responsibility for us. That reality changed a long time ago. I think we all understand that from a job security perspective, but not from a professional development perspective. What it means is that no matter what you do or who you work for, you are responsible for your own professional development. No one is going to lead you down a specific path and crown you accomplished. If you are lucky, your employer will pay for some training and if you are really lucky you’ll find a mentor or a coach who will help you and inspire you.

Thanks Laura, for the interesting dialog and for the time and energy that resulted in How to Start a Business Analyst Career. I think it’s a great debut, and a nice contribution to the BA body of literature. I have quite a number of readers contact me about information on becoming a BA, too, and  I’ll be glad to be able to point them toward your book going forward.

Additional Information and Purchase Details

If you’re interested in learning more about How to Start Business Analyst Career, you can take a look at the information page which includes teasers, testimonials and, of course, a link to purchase and download the book at a special introductory price.

View the original post or comment on Thinking of Becoming a BA? Q&A with Laura Brandau

I mentioned last week that I had come across Ed Yourdon’s wiki for “Just Enough Structured Analysis,” and pointed out that it’s a great resource for business analysts.  Again, if you haven’t checked it out, I recommend that you do.

So, why do I make mention of the wiki again this week?

Well, as I continued my study of those materials, I found a story I really liked that describes the principles of complexity escalation and infinite regression; fancy words for pretty common ways simple projects can quickly morph into gargantuan ones.  First I’ll share the story, originally authored by J.P Eberhard* and cited by Yourdon and others, then I’ll provide a little commentary of my own.

The Story of the Doorknob

One anxiety inherent in design methods is the hierarchical nature of complexity. This anxiety moves in two directions, escalation and infinite regression. I will use a story, “The Warning of the Doorknob,” to illustrate the principle of escalation.

This has been my experience in Washington when I had money to give away. If I gave a contract to a designer and said, “The doorknob to my office doesn’t have much imagination, much design content. Will you design me a new doorknob?” He would say “Yes,” and after we establish a price he goes away. A week later he comes back and says, “Mr. Eberhard, I’ve been thinking about that doorknob. First, we ought to ask ourselves whether a doorknob is the best way of opening and closing a door.” I say, “Fine, I believe in imagination, go to it.” He comes back later and says, “You know, I’ve been thinking about your problem, and the only reason you want a doorknob is you presume you want a door to your office. Are you sure that a door is the best way of controlling egress, exit, and privacy?”

“No, I’m not sure at all.” “Well I want to worry about that problem.” He comes back a week later and says, “The only reason we have to worry about the aperture problem is that you insist on having four walls around your office. Are you sure that is the best way of organizing this space for the kind of work you do as a bureaucrat?” I say, “No, I’m not sure at all.” Well, this escalates until (and this has literally happened in two contracts, although not through this exact process) our physical designer comes back with a very serious face. “Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem.”

On the other hand is the problem of infinite regression. If this man faced with the design of the doorknob had said, “Wait. Before I worry about the doorknob, I want to study the shape of man’s hand and what man is capable of doing with it,” I would say, “Fine.” He would come back and say, “The more I thought about it, there’s a fit problem. What I want to study first is how metal is formed, what the technologies are for making things with metal in order that I can know what the real parameters are for fitting the hand.” “Fine.” But then he says, “You know I’ve been looking at metalforming and it all depends on metallurgical properties. I really want to spend three or four months looking at metallurgy so that I can understand the problem better.” “Fine.” After three months, he’ll come back and say, “Mr. Eberhard, the more I look at metallurgy, the more I realize that it is atomic structure that’s really at the heart of this problem.” And so, our physical designer is in atomic physics from the doorknob. That is one of our anxieties, the hierarchical nature of complexity.

Any of that sound familiar?

Now, Eberhard included “The Story of the Doorknob” in a 1970 publication*, so clearly these are not new phenonema. An Internet search or two will show that the example is relatively well-known and referenced in architecture and design circles.

I really wanted to share that excerpt, because I think it will resonate with a lot of BA’s the way it did with me. In fact, my main reasons for posting it are:

1. The example clearly articulates problems we as analysts (and other project professionals) deal with on a regular basis. By understanding the underlying principles, we can more easily identify and mitigate problems stemming from them as they arise.
2. It further goes to show that getting scope/requirements right is tough work, and can be easily thrown-off by our perceptions and those of the people we work with to define and deliver solutions.

Stalling tactics and good intentions misplaced

Richard Veryard provides another interesting observation on problems associated with escalation on his fallacy page:

Some people adopt the tactic of escalation to deliberately kill a change. By making it large and complex, they hope to make it impossible. Others adopt the same tactic in innocent enthusiasm, so excited by the potential of an idea, that they do not realise that they are overloading it.

I’ve always taken the position that we, as analysts, have an important responsibility to push back and reemphasize the business problems and objectives when it becomes clear that a solution is being escalated out of proportion – whether it’s being done purposely to stall a change, or in innocence/ignorance by those who want to do right, but are just overdoing it a bit.

Obviously, the key there is to approach the situation tactfully. Sometimes there will be technical interdependencies that an analyst won’t see or be aware of that make a seemingly simply change a bigger deal than originally anticipated. Of course such scenarios may have more to do with interest coming due on technical debt than on escalation or regression.

What are some ways to defend against problems associated with escalation and regression?

Looking back at the statement by the designer,“Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem,” let’s ask ourselves – what was the original problem? Why did Mr. Eberhard engage the designer in the first place?

If we go back to the top, Mr. Eberhard’s original problem appears to be that he just didn’t like his doorknob and wanted a more fancy one. He wasn’t concerned with capitalism or whether four walls were the best way to organize his space.

As analysts – who often represent the stakeholders’ interests in discussions with design – it is critical that we keep a laser focus on the specific point(s) of pain that the business needs addressed.

We defend against the anxieties of escalation and infinite regression through the work we do as analysts – much of it at project outset. Below are just a few examples:

1. Identify and define the business problem (or point of pain) to be addressed. If done properly, this will include some degree of root cause analysis to make sure we’re addressing a true business problem, and not just a symptom of another problem.
2. Identify and clearly articulate the objectives the product, to ensure that those objectives are constrained to those things that will solve the business problem.
3. Later in the project, ensure that work done downstream maps (or traces) cleanly and clearly back to those original objectives, or at least back to business requirements that trace back to the objectives.
4. Ask the following question, just as a litmus test: Does the path were taking lead closer to or further from “the simplest thing that could possibly work“? The further we get from the simplest working solution, the more likely that we are treading into the territory of escalation or infinite regression.
5. Raise concerns with delivery personnel when it looks like they might be stepping out into deeper waters than necessary with solution design and development. This is just a precautionary measure, and shouldn’t be done in the spirit of  “calling someone out”.  Typically, the project manager will be right at your side if a proposed solution is going to cause a project to go over time or budget.

To close, an understanding the principles of escalation and infinite regression is yet another useful tool in the analyst’s toolbox to help us understand how easily unnecessary complexity can arise, how to explain it and how to defend against it.

What are your thoughts on these the story of the doorknob? On the underlying principles? How do you defend against escalation and infinite regression?

*I wasn’t able to locate a copy of the original work, but FYI, here is the reference provided by Yourdon on his wiki: John P. Eberhard, “We Ought to Know the Difference,” Engineering Methods in Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press, 1970, pp. 364-365.

View the original post or comment on Escalation and Infinite Regression

Many types of requirements crop up again and again, no matter what a particular new system is for. The idea of requirement patterns is to provide guidance on how to specify common types of requirements, to make it quicker and easier to write them, and to improve the quality of those requirements.

With that in mind, we recognize that the requirement document templates we use are just prompts to follow patterns for specifying requirements and even our methodologies are nothing more than collections of patterns believed to aid in delivering successful solutions that have been formalized, socialized and then adopted.

But Beware…

There is a danger in using patterns when we try to force problems to fit a template just because we have a template. Just as there is no silver bullet with regard to delivery methodologies, no pattern is applicable all the time.

I found some wise counsel to this point in a post on ifacethoughts:

There is a lot of angst against patterns since they seem to impose rather than give space for innovation. There is a reason why patterns are not standards, because it is quite possible that they apply in most of the cases, not all. Patterns should be used as guidelines, not as a must-comply-with standard.

You may recognize arguments such as, “do we have to fill out every section on the template?”, or “do we have to follow every step in the SDLC to the letter?” Another aspect of becoming an expert analyst is that of knowing rules from guidelines and having the intuition to make the proper decisions on what needs to be done and how. It’s important to note that patterns are not of themselves “requirements”. When used properly, they don’t constrain, but provide guidance.

My approach to using patterns..

One thing I’ve made a conscious effort to do, and that I think has made a difference, is to be a near-obsessive note taker. Anything I learn that I think I might be able to use again later gets noted, tagged and filed – including, occasionally, things that I see in an old spec that I didn’t like accompanied by how I’d do it differently now.

With each new project I’ll look for aspects that are similar to problems I’ve dealt with in the past, and ask myself questions such as:

• How is this “item” (read: problem, process, function, interpersonal conflict, etc.) similar to others I’ve worked with in the past?
• What types of techniques and information were successful in our past dealings with the similar item? In the case of requirements, I might review specific requirements, questions I asked to identify them, constraints, types of visuals, etc. we found successful.
• What are some things  that were problematic with how we dealt with the item previously that we want to be sure to handle differently this time? What did we miss last time that we want to be sure to catch this time?
• How could the other BA’s benefit from what I’ve learned, and what might they be able to add to our collective knowledge of these patterns?

As a new BA,  a form to complete and a process to follow may be the only patterns initially at your disposal. While that doesn’t sound like much,  it’s ok. Business analysts with the basic BA skill set can -  and absolutely should – be effective in their roles. The important thing to remember is to write down and begin to catalog the things you learn. Also, be aware of the concept of patterns so you can begin looking for them as you gain knowledge and experience.

Quick summary -

I was a bit longer-winded than normal in this post, so if you’re just looking for the digest, here are the main points I wanted to get across:

• Business Analysis expertise doesn’t come overnight.
• It can come more quickly if we’ll strive to understand and use patterns in our working environment.
• Patterns are not just for requirements. Patterns in the specific business and technical domains, as well as those concerning soft/professional skills are every bit as important.
• Patterns are guides; not rigid, unbreakable rules.
• Take good notes on everything you learn and catalog them. Patterns will begin to take shape and you’ll be able to apply them to work smarter and faster.
• Share what you learn with your team.
• You don’t have to know all the patterns or be an “expert” to be successful as a new or junior BA, but it helps to be aware of them conceptually and to keep them in mind as you accumulate knowledge over time.

Additional Reading

So, there’s a quick overview of requirement patterns along with some of my own thoughts on them. If you’d like to know more about requirement patterns and how they can be used, I’ve provided a few useful links below:

• Steven Withall provides an interesting overview of requirement patterns on his website.

• Requirements Patterns via Events / Use Cases by Suzanne Robertson. I’ve never used Robertson’s approach specifically, but she does a great job of covering some of the fundamentals and provides lots of images and examples.

• Requirements by Pattern by Christopher Creel also provides some nice examples of requirement patterns.

Stay tuned! And as always, I’ll look forward to any comments you may have on the key areas of BA knowledge, use of patterns, or how business analysts mature and evolve.

View the original post or comment on Patterns and the Evolving Business Analyst