Facilitation is one of the most critical soft skills of the business analyst, as well as one of the most difficult to master. Working with various stakeholders requires tremendous preparation, insight and finesse in addition to an understanding of key principles of the facilitation process.

Like most business analysts, Charles captured business rules as part of requirements gathering. Also like most business analysts, he followed traditional business rules approaches. These included writing individual business rule expressions, storing them outside the confines of process models and use cases, and providing pointers to them. However, he changed his approach after experimenting with The Decision Model.

Transaction Business Logic is the processing required in processing database transactions to enforce business policies. It is sometimes characterized as Enforcement logic, since the transaction should be rejected if the rules are not passed. Consider the insertion of a new Purchase Order...

When used properly, a performance measurement program can help BAs and their managers identify specific improvement priorities, clarify responsibilities, and drive the desired behaviors required to achieve business goals. However, in practice it's rare to see managers taking advantage of the benefits a good performance measurement system can offer...

Worldwide, there are between five hundred thousand and one million people working as Business Analysts...  So why are all types of businesses, from charities to investment banks, hiring so many of them?...  What do they actually do?...

I often get asked, “How can I get stakeholders to attend my meetings?” or “How can I get stakeholders’ buy-in on the project?” These are complex questions and the easy answer is that you can’t. As BAs and PMs we can’t get anyone to do anything, but we can certainly influence them so that they want to.

The Decision Model in practice has delivered many unanticipated, but positive surprises. The most obvious and powerful surprise is how it drastically simplifies process models. In fact, we regularly receive unsolicited messages from people who experience this effect. For example, one practitioner condensed a 45-page process model to one with eight task boxes.
 

If I said Mentalist to you, I expect you would either think of a mind-reader of the David Copperfield ilk or the TV series of that name. In fact you would probably take it as an insult as neither of these images is particularly comfortable, but both would have a voyeuristic attraction.

The reason I bring this up is that there has always been a fascination with trying to guess what is going on the minds of the people in front of you. This is particularly apt when you are trying to understand what the in-duh-vidual in front of you really wants (aka requirements gathering).

So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period.

One day I found that my husband posted an interesting status on Facebook and it made me think of how these two simple questions can produce different results based on the situations. My husband’s quote is as follows: "We can ask the question "Why?" or think of how to make it happen and say "Why not?"

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I've long given up looking for panaceas.

Software development process is undergoing seismic shift from traditional waterfall software methodologies towards agile methodologies. Agile software development methodologies deliver high quality software products in rapid iterations with high flexibility and adaptability to changing conditions. This article discusses the dynamics of agile projects by comparing it with the SDLC project framework to help the IT leaders and organizations plan effectively for transitioning to Agile software development methodologies.

Congratulations! You've just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold.

As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers.