What does innovation mean to the Business Analyst?  This article is my practical way of handling innovation and understanding the role that the Business Analyst plays in innovative projects.  Giving five tips for success the article explains how innovative projects can be approached and how the unique skill set of the Business Analyst can add measurable business value. 

In a new business analyst role, typically there will be a few types of requirements documents that are most commonly created...  In this article, I’ll go through 7 steps you can take to write better requirements documentation or learn how to write a new type of requirements document.

You’re a successful Business Analyst, but are now ready to take the next step to advance your career. So what is your next step? Do you need to move out of business analysis to advance? Are you a BA who wants to see where your career may go in or beyond Business Analysis? Are you interested in managing BA teams or leading BA teams on projects?

While the benefits of an effective Business Process Management solution are clear, a truly successful, on-time implementation can prove elusive. As a Business Analyst, you may be held responsible for project timelines. So when the schedule starts slipping, your credibility can slip away with it. This article discusses how agile technology and processes can slash implementation times from months or years to a few weeks or evendays, reducing time to value and ensuring successful, on-time, on-budget implementations.

Requirements Planning is an important part of the requirements development process that is often overlooked. Requirements Planning is the brains of requirement development and enables successful execution of the requirements phase.  Developing a Requirements Approach is a way to capitalize on the following benefits of effective requirements planning...

The traditional axiom in business analysis that there should be a “Berlin Wall” between analysis and design is being torn down these days. Several authors and thought leaders are arguing that you cannot do analysis without designing and that you cannot design without analysis. This article is striving to visualize why this is really so.

Have you ever been confused about why you were not allowed to do what you tried to do? Been judged or evaluated in a way you didn’t expect? Stumped by the result or decision a business system produced? If so you are a ‘why victim’.
 

It is important to illustrate most of what goes on in the systems and software world is really not as complicated as people make it.  Most of what we do in business is process transactions, representing some sort of action or event, such as a purchase, a return, a back-order, a debit or a credit.

The goal of DMN is to provide a notation for decisions understandable to all audiences, including business and technical people. This is good news and is the very reason we introduced The Decision Model (TDM) to the public in 2009

Business analysts are jacks-of-all-trades -- and masters of some... unfortunately, many BAs fall short. They often spread themselves too thin, lack the requisite confidence to speak with authority, or don’t understand fully the important role they play.

Do you know? If not, should you? I’m using BA as an abbreviation for Business Analyst (really, though, it’s one who performs business analysis regardless of the title) and BOT for “Business Order Taker” (also an abbreviated term for ROBOT). They are different in the way they approach business analysis.

It’s pretty rare to be a business analyst and not facilitate meetings...  In this article, we’ll look at 3 possible roles new BAs fill in meetings, how to expand your meeting facilitation experience, and review 5 critical meeting facilitation techniques that will help you run working, productive meetings.
 

This article examines how to use tabulation to write better business rules. If you’re not writing business rules, well, you should be. Fortunately, the very same guidelines apply to writing requirements in general, so there is much to be gained on all fronts.

There are a myriad of requirements elicitation methods. The BABOK lists nine (Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire), but there are many more methods out there such as protocol analysis , job application design , and so on).

If you read the title and thought to yourself, “Hey, Mulvey got it wrong, it’s ‘Measure Twice, Cut Once’” I’ll bet you have had an experience with someone who used the old woodworking term. Woodworkers use it to indicate it’s better to double-check your measurements before you commit to cutting the wood, lest you waste time redoing work (and incurring expense if you have to buy more wood). It’s a great proverb to get you to think about double-checking your work and confirming your measurements. But what I’m talking about is using the measurement as an enterprise asset – once you create the measurement, use that over an over when you are working on different projects.