The success of process improvement projects is greatly influenced by good planning for gathering requirements or user stories. Part of the planning is identifying which of the analysis techniques will be effective for the elicitation of business needs with stakeholders. One objective for these techniques is to enhance project team collaboration by establishing a common understanding of the business process, thus providing a knowledge basis for developing changes. This article explores using job task instructions as an analysis technique for supporting project team collaboration by providing a platform to keep team members informed with the decisions on workplace changes.

Customers are demanding better service and they know they can get it and BAs have a duty to provide it through Lean Business Analysis (LBA). Not because customers see better service from a business’s competitors. But because they get it from all the other companies they interact with in their daily lives as consumers of Uber and Apple and Amazon and Netlfix and many more. They don’t care that one company is a bank and Uber’s an app.

CBAP certification is undoubtedly the most coveted designation globally among the Business analysts.

Even though work experience is one of the requirements of CBAP® as a prerequisite, the CBAP® examination needs you to have excellent practical knowledge of the business analysis concepts and the ability to relate BABOK® knowledge to practical scenarios/cases.

How can a business analyst mindset transform the practice surrounding good retrospectives, create an engaging meeting, and promote active change across their team? There’s no tried and true formula to a Retrospective, but I have found the ones that are the most successful rely on the characteristics and practices of good BAs. Thus, conducting Retrospectives that are data driven, clear, honest, creative, and experimental. Why? 

Success and failure are difficult to define and measure since they may mean different things to different people. An assumption that success can be quantified seldom holds true in the face of an ever-changing yardstick used to measure success. What might be considered to be a successful attribute today can be rendered unsuccessful under the influence of dynamic and multi-dimensional constraints.  A project is primarily implemented to target a predefined outcome, and it is imperative to measure the output in order to determine the benefit derived through the project. However, benefits realized do not necessarily add up to success. Project ‘success’ is different than ‘benefits realization’.

“Well it just so happens that I have a question about tools.”

"What tools do you suggest a business analyst use in pursuit of his or her vocation? What tools can be used as best practices for business analysts?”

How do you become a business analyst and where do you begin?  So you want to cross over to the land of analysis? A land of ‘schizophrenic’ people who need to possess multiple skills and make meaning out of ambiguity. You'll need to break down complex problems into bite-size chunks that can be easily understood. You'll also need to manage different stakeholders and break down knowledge barriers formed by these stakeholders. (Most having been in their organisations for decades) Finally, you'll need to develop a thick skin to stand in the firing line.

One of the key aspects to be considered before implementation of Agile methodologies is the degree of agility suitable for the organization. Due consideration should be given to the ‘current state’ before we create a proposal for the ‘future state’ of agility desired. Neglecting this aspect may invalidate the very purpose behind the endeavor.  Degree of agility refers to the relative ability of an organization to adapt to the lightweight methodologies in conjunction with an assessment of current state process maturity.

A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.