Many run into the problem of differentiating between a systems analyst and a business analyst. The differences in some organizations do not exist. In other companies, the comparison is almost an insult. Depending on the business or corporation, there are many differences. The job title is not the only thing with which to compare these two separate roles. The problem occurs when the title is not so conclusive. The business systems analyst or the systems business analyst can actually be one or the other or both. Job description is the only way to tell when this happens. There are differences, though.

Author: Tony de Bree

I learned this in a virtual meeting where about 10 stakeholders were invited to give input to a mock-up created by our project. They were all subject matter experts within the area, and had earlier provided some input on an individual basis. I walked through the whole thing, and what happened? There were no comments or suggestions. I couldn't believe it. I know that subject matter experts always have an opinion.

If you’re looking to manage business activities on a business-process basis, stability is key. But business rules aren’t stable. In fact, many change quite rapidly. What should you do? Separate the business rules from the business process model, so the business process model can do its job.

You walk into your local IIBA meeting and introduce yourself to a new attendee. They ask you what seems to be one of the toughest questions in the world: “How do I become a business analyst?” Hmm…  How do you become a business analyst?
 

I’ve written in the past about why hybrid approaches that incorporate traditional and agile methods of software development are been applied by organizations seeking to improve the results of their software projects. Here I’ll describe the 3 types of hybrid projects I have identified while working with different organizations in consulting assignments, and what impact each type has in the work of a business analyst.

There are three basic checkpoints the business analyst can facilitate to help ensure that he or she is on the right track. Two are informal, merely a get-together with other parties to review the situation and not fraught with the imprimatur of approval. The other is a more formal presentation. I’ll address each of the three checkpoints in this series.

“…The Analyst will [...] facilitate the identification, design and implementation of business and systems solutions in a rapidly growing and evolving business…”   What strategic initiatives might a business analyst as described above discover, and how will they deliver the “business and systems solutions” in today’s 21st Century competitive environment?
 

December ought to be a month of celebrations, but for managers it often isn’t. In many companies this is the time for the yearly performance appraisals. When top management is not trusting employees, and employees are not trusting top management, the middle manager is usually caught between a rock and a hard place. But they don’t have to be.

Leadership is like genius, it is one of those concepts that is recognizable when you observe it in action, but is otherwise somewhat difficult to define. And creative leadership is even harder to define because we haven’t been focusing on it in the context of business, unless we are talking about new product development. But creativity and innovation in the business world is not just about product innovation. 

... it became clear to me that it was time to revisit the core role a business analyst fulfills in an organization. In my experience thus far, well over 75% of the business analysts I know report through the IT side of their organization. Of the 25% that report through the business side, most have a primary responsibility that is outside of the typical business analysis role.

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.”

Does your requirements approach allow you to reliably identify blind alleys and showstoppers before your company invests large sums in modeling and software development? What’s missing? Most organizations do follow some project management approach. Do you find yours really helps in answering big-picture business questions?

Taking time to determine business requirements before launching into a new IT or process-based project is a critical component of good planning and protecting company assets. Clearly defining the current process, the problems that need to be focused on, and working with the people in the organization before beginning your project will allow for a much more streamlined process once you start, with better odds for success.

As I've had the honor and privilege of mentoring and coaching business analysts (BA’s) one of the areas that has been a challenge to some is moving from facilitating and eliciting face to face meetings to facilitating and eliciting virtual meetings. More and more BA’s are working remotely, work for companies who have global businesses as well as companies looking at very creative ways to cut cost which may result in having business analysts work from home.

The project involved updating a quote process and the technologies underpinning that process, this included dealing with an underwriting calculation, which was embedded partly in the legacy systems and, partly, in heavily manual processes. The project team could not determine how to unpick this calculation and provide a detailed specification to a 3rd party software house.