I bet everyone has, at least once in their career, heard the expression:

iRise gives Business Analysts the tools they need to communicate clearly with both the business and its stakeholders.  They use working previews that can be virtually indistinguishable from the final product.  When business analysts uses iRise to elicit and document requirements: the business analyst becomes a powerful weapon to get to the right answer, ...

State Models include two RML Data models (State Tables and State Diagrams) that show the transition of an object through various states or statuses, including which transitions are valid and what triggers an object to transition state. A state is a short-form description of a stage in a data object’s life that influences the behavior of the system.

The end products of requirements development for a business analytics project will be similar to those for any other project—a set of business, user, functional, and nonfunctional requirements. Process flows, use cases, and user stories can reveal that someone needs to generate analytics results, and performance requirements describe how quickly they need results, but none of these uncovers the complex knowledge required to implement the system... An effective elicitation strategy for business analysts (BAs) is to drive requirements specification based on the decisions that stakeholders need to make to achieve their business objectives.

A good business definition is not only good because it is clear and concise, but because it holds a clear, exclusive position within its full set of peers – i.e., the glossary for your business vocabulary. This discussion outlines five basic guidelines for ensuring the quality of a glossary holistically, focusing on avoiding naming anomalies, subtle redundancies, and avoiding circularities. Find out how you can become world-class at communicating the meaning of your business concepts. Part of the secret is a clear focus on seed concepts.

We hit a challenge however when we attempt to promote the value of Business Analysis to IT Management or the Business...  The reality is that simply promoting “better requirements” does not sell our value-add in terms that management from an IT or Business perspective understands... So how do we do this? Let me share five lessons learned based on my experience as a senior requirements management consultant. 

The paradigm shift towards agile and lean product development has brought collaboration between large cross-functional team in the spotlight. The existing literature is already mature explaining clearly how benefits can be reaped fast by executing a clean transition to agile delivery by enhancing the performance of the new cross-functional teams. However, in parallel, the time spent in endless meetings by product owners, business analysts, engineers, product managers and many others involved in the product creation, has grown exponentially. This leaves key product people with little or no time to do the critical activities they are employed for.

You see, I am a business analyst (BA), and more precisely the lesser-spotted, lazy beta alpha, the evolutionary pinnacle of my profession, at the tip of the BA spear. While the work of throwing or stabbing with the spear requires an effort by the arm that wields it, I prefer the sharp bit to do the work for me. In other words, doing as little as possible apart from…well, being sharp. While the sharp bit does all the work I am able to still the get the glory and recognition of a job well done. While the spear tossers return with painful shoulders, weary and, hopefully sometimes with a degree of success.

A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?

 

Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort?

There are various schools of thought about how to define terms, some arising from professional terminologists and academia. But those approaches are often relatively arcane and not well-suited to everyday business practice.

Definitions with subtle IT or ‘data’ bias are an anathema to effective communication with business partners. Good business definitions are oriented to what words mean when used by real business people talking directly about real business things.

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

When asked what my secret for Business Analysis success is, I indicate fundamentals first. You can acquire skills related to Agile, the latest modeling language, and software development tools but you will fail if you have not mastered fundamentals.   The following fundamentals are crucial to success...

A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.

Through the use of contract terms and conditions, this article provides insight on managing risk on outsourced projects beyond just transferring work to a contractor. Training courses on risk management typically cover transferring risk at a high level, but that is just a start. Read this article for the follow-ups on managing risk via contract terms and conditions.

My inclination is the smarter and harder approach but again I am asking you to contribute your thoughts. Channel your inner Justin Timberlake and consider how do we get sexy back to Business Analysis? How do we get the attention of the decision makers when we are no longer the shiny new product that every one wants.