A swimlane diagram is a type of process flow diagram (also sometimes called a cross-functional diagram) that features divisions or "lanes." Each lane is assigned an actor (which may be an individual, department, division, group, machine, entity, and so on), or even a phase or stage in a process, that is responsible for the activity or work described in the lane.

I recently saw the "The King's Speech," a movie about the relationship between the stammering King George VI of England and his speech therapist... how is this commoner able to help the monarch and become his life-long friend? He is a master at influencing with absolutely no authority.  There are some lessons here for those of us business analysts and project managers whose jobs depend on our ability to influence without authority.

Structured business vocabulary is a missing ingredient in most current approaches to developing requirements. This omission should greatly concern every business analyst. Indeed, business vocabulary is key to a whole range of fundamental challenges, including but not limited to capturing business rules. One reason is that business vocabulary, like data and business rules, lives on beyond the point of system implementation and deployment.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of "features, functions, technologies, enhancements, and bug fixes," as "Agile Software Development with Scrum" states. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.

More and more organizations are taking advantage of business process management (BPM) solutions. And yet, it is often the case that, after an initial success or two, the growth of BPM within a company stalls.

We BA's are occasionally asked, "What do you do?" I try to make a joke out of this innocent question by replying, "Well, what would YOU do with English and writing degrees? I'm a Business Analyst of course." People don’t laugh.

The number of successes with The Decision Model is escalating. Organizations are using The Decision Model to solve a range of business challenges and opportunities including some we did not expect. Therefore, this month we summarize three real world projects to illustrate how organizations are using decision models and how quickly project teams are delivering them.

Most business analysts will never interview a CEO and many don’t understand how a company’s real objectives cascade down to the little bit of requirements they’re doing for a particular system.

How does my system fit into the company’s business strategy? What is my role in the big picture?

Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

An enterprise exists for a purpose, stated in its high-level goals and business model. It also has everyday operations which may or may not serve this purpose. We need a link between the two and this is what Enterprise Architecture is about – the establishment of a link between an organization’s ultimate goals and its day-to-day operations.

An activity diagram is a type of flowchart that is part of the UML (Unified Modeling Language) standard. Its purpose is to enable analysts to present a concrete, easy-to-follow visual of the workflow of a business use case.

We can probably all agree that Knowledge Management is generally A Good Thing and that we should do more of it. But what does “doing Knowledge Management” actually involve, and how as BAs can we ensure we effectively reuse our knowledge?

“Requirements are rules. They arise from business models, but they are different from those business models.”  Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they?  No!  Read this article to find out why.

In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

This month’s column explores the biological basis of human decision-making based on Lehrer’s book. However, it also suggests that lessons from the human brain can sharpen our decision models2 and enhance the process by which we create and manage them.