I’ve stated before that I believe the primary difference between the novice and expert analyst – all else being equal – lies in the ability to recognize and apply patterns to solve problems. Today, I’d like to expound a bit more on that idea.
As with all trades, there is a learning curve to business analysis. Part of the curve pertains to increasing knowledge and experience specific to where you work (business and technical domains), and part consists of developing the skills specifically important to the BA role; basically, the stuff in the BABOK, and “soft” skills (interpersonal skills, communication, professionalism) common to the BA job description. I consider the ability to learn, recognize and apply patterns in those areas to be the capstone to an analysts development or “evolution.”
What do you mean by “patterns”?
So, when I mention applying patterns, what exactly am I talking about?
I found a great answer as I was scanning one of my favorite reference books, Patterns for Effective Use Cases by Adolph and Bramble, from which the authors quote Christopher Alexander’s 1977 book, A Pattern Language: Towns, Buildings, Construction. Alexander defines a pattern as:
Each pattern is a … rule, which expresses a relation between a certain context, a problem, and a solution.
And:
[A] pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you could use this pattern a million times over without doing it the same way twice.
Why are patterns important?
Patterns (and anti-patterns) enable us to use accumulated knowledge and experience to solve present problems. Beyond that, they help us to avoid repeating mistakes of the past.
Patterns are used in some form or another in every discipline. Meteorologists use atmospheric patterns to forecast the weather, health care professionals study biological patterns to treat health problems, law enforcement professionals analyze behavioral patterns for use in tracking down criminals. Note than in none of those cases are the patterns a 100% guarantee on expected results but they can allow you to proceed more quickly and with a higher level of confidence than starting from zero.
Steven Withall, author of the book “Software Requirement Patterns” describes the importance of patterns in a requirements context:
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.
留言