This is the story of an outsourced contract for development involving a Financial Services Company (BigNameCo) and an Outsourcing company (ServCo). It appeared to be a simple development project, but in the process, the CIO was fired!

The Top 10 Trends in Business Analysis for 2016 examines the evolving ways in which BA practitioners can help organizations realize better business value and the shifts needed within the BA discipline to achieve it. The 2016 trends highlight BAs evolution from “order taker and liaison” between stakeholders to an increased focus on being an “agent of change”, and communicating and collaborating about much more than requirements.

I’m frequently asked to summarize what business problems the business rule approach was created to address. Here’s my take on that important question. I believe the potential benefits for your company are compelling.

Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions.

The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.

It’s always the requirements fault! Whenever anything goes wrong with a software development project the requirements tend to be the scapegoat. It is a fact of life as a BA that at some point the requirements you write will be wrongly blamed for a mistake in the product. In reality, any oversight in the product is the responsibility of the entire development team. So what can the BA do to ensure they are not the convenient scapegoat for an issue with the product?

In addition to the fundamental duties and responsibilities of an employee, it is not uncommon for workers to misunderstand their various project assignments. Consequently time and money is lost as employees try to delineate their responsibilities, including their relationship with co-workers.

Have you ever wondered why the behavior of your client or your teammate change depending on whether he is acting individually or within his/her group (e.g. team, department, etc.)? Have you ever noticed how people tend to do what others around them are doing, that is how group dynamics shapes individual choices and judgments noticeably or subtly?

Customer journey mapping is a great way to understand your customer intimately to provide insights into providing targeted customer experience that empower the customer positively to drive better business outcomes.  This technique places the customer first with a deep emotional understanding, then looks backwards toward the experiences provided by the operating model, thus enabling good aspects to be reinforced and negative ones to be managed. It provides a complete 360 end to end experience of the customer to be realized driving customer insights, allowing more blue sky approaches to offsetting emotional deficits...

This article discusses a tool for documenting, categorizing, ranking and decomposing various types of requirements (business/user and solution).  The business analyst (BA) can use this tool to capture high-level business and user requirements and then decompose them into solution requirements. In fact, the tool can be used multiple times and results strung together to provide forward and backward traceability of requirements through specification and test cases. 

Despite of all the extensive literature available on Requirements Analysis, it is hard to find one which proposes an established framework on how to use this tool in general sense of application. However, let’s try to map a generic algorithm that can be leveraged for suitable circumstances since every problem or situation is different from the other. We need to calibrate our analytic skills such that a general algorithm can be applied suitably depending on the situation(s).

There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It's not a matter of what tools I use, but rather understanding the principles behind the design process itself.

Developers complain that customers don’t know what they want. At the same time, customers complain about having to explain the obvious. Many projects can get stuck in this type of behavior.

Fortunately, there is a loophole. Many of the problems that business people find don’t actually require a fully working application. Often, a simple “picture” (aka mockup) is enough.

This is a story of an outsourced product implementation contract between two companies, FinCo and ProdCo. What started out as an exciting contract turned out to be a bitter experience for both the companies. There are lessons to be learnt from this story – about outsourced contracts, about setting expectations and above all, about good old business requirements.

The scenario is simple: You’ve been tasked to determine the requirements for a new project. You’ve done your homework by reviewing existing documentation. And, now, you’ve arranged to have a meeting with a Subject Matter Expert (SME).

So, where does one begin on this path to enlightenment? When you talk to the SME for the first time, do you start by outlining everything that you think you’ve learned already?

Business analysts have been around for a long time, at least by concept, if not by exactly same designations.Business Analysts are employed by many organisations and businesses all over the world. But the fact remains that most professionals are still quite unsure about what exactly makes a Business Analyst and what to expect from one.