I selected a topic, in this case Business Process Management, and then developed an initial outline of talking points for the webinar. I then iteratively build a slide deck with text that explains the ideas and images that stimulate the imagination on the concepts. With the slides done, I develop formal text on each slide along with estimated delivery time. This is what I called my baseline deck for the presentation.

Usage of one enterprise architecture language capable of expressing concerns from technology layers to business needs and drivers gives tremendous benefits to the organization. It streamlines the communication and enables easy collaboration between Enterprise and Business Architects...  ArchiMate was deliberately aligned to be compliant with the TOGAF 9 framework. It is also very useful for people practicing (high-level) Business Analysis, according to the BABOK Guide. 

Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work:requirements prioritization... Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process.

This article briefly summarizes the CBAP and CCBA programs, and how eligible business analysts can create a “foolproof” plan to obtain their certification. Bear in mind that any certification plan is only foolproof if you personalize it, commit to it, and follow it. The majority of the article covers the crucial steps for your plan and several tips to help you execute it to become certified.

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.

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?

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).