I have had the opportunity in my career to move, not only, from industry to industry, but from company to company. I have been a consultant as well as a full time employee throughout my career. As companies merge and/or begin to grow talent is needed and could come from anywhere. New/outside talent can bring in fresh wave of diverse perspectives and ideas. However, there should be some caution taken, if you are that new person entering into the organization. Whether you are a consultant, temporary employee or full time employee, here are 5 pitfalls that I have found in my career that can either make you or break you as you enter into new companies.

The Business Analyst is in a great position to constantly focus on the desirability of the product.  A well-defined requirement elicitation process must be focused on defining the problem the business is trying to solve for our customers. If defining the problem is the first step in your requirement process you are on the way to guaranteeing that the delivered product will provide value to your customers. Throughout the development process you will be able to monitor if the product is actually solving the problem. Additionally, your requirements should be directly related to solving the problem. It is a BA’s job to question the value of every proposed requirement that product owners want to add. If the requested feature or function is not directly related to solving the problem then it should be taken out of scope. 

A bid is like a product that, once designed, the team must be able to deliver it. This delivery includes manufacturing the product, testing it, preparing the marketing for the product launch and finally launch it.  We propose a staged approach that replace guessing a number with qualitative investigation. The model suggested, distilled from experience, shows how estimates are transformed into effort and, ultimately, into a coherent story with a price tag attached.

Sequential Development is the traditional approach that allows the business analyst to perform business analysis during the initial phases of a business process. The novelty brought by Agile was that it challenged practitioners to perform business analysis throughout the entire development process. This is a fundamental difference between Agile and Sequential Development because Agile recommends the continual re-evaluation of the initial business analysis. The present article will discuss business analysis in Agile by focusing on Scrum implementation.

Since when were Business Analysts a one stop shop for all project needs? We are expected to be Superheros; well-rounded BAs as well as Change Managers, Test Analysts, Project Managers and Implementation Managers. The boundaries of these other disciplines is often unclear so this article seeks to explore the activities that fall into business analysis and those that should be undertaken within the other disciplines.

To be a great analyst, you’ll need to ask great questions. In order to ask great questions, you’ll need to remain inquisitive.  Fact of the matter is, that if you are performing any kind of analysis, you need to become very comfortable with asking difficult questions. Questions that make people uncomfortable and questions that might even potentially expose unpopular answers.

If you are looking for a specific decision to be made on a specific issue or capability, then getting the meeting down to a small core team is important in order to ensure the decision is being made quickly. This is where Minimally Viable People comes into the picture. Minimally Viable People is the concept that a small group performs better by making decisions with higher quality while being representative of the larger group.

So you’ve developed a set of requirements for some portion of your next systems development project. Now what? Experienced project managers and software developers understand the value of translating requirements into rational project plans and robust designs. These steps are necessary whether the next release represents 1 percent or 100 percent of the final product. As shown in Figure 1, requirements serve as the foundation for project plans, designs, code, and tests. In addition to these connections, there is a link between the requirements for the software to be built and other project and transition requirements. Those include data migrations, training design and delivery, business process and organizational changes, infrastructure modifications, and others.

I’ve been a Business Analyst for about 15 years now starting as a graduate back in the day. And while I do not consider that to be close to a career’s worth of experience I have certainly seen significant changes in the way business analysis is performed and the tools that are used thanks to the evolution of technology.

This article covers a trend in the industry that has been yielding great results for companies looking to deliver more successful projects. By cutting down on huge initiatives with outrageous requirements documents that just can't be managed and focusing on implementing features and functionality a piece at a time, companies can be sure to deliver more value to customers more often. 

Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...

Bias is seen in action through bad decisions, miscommunication, perceptual blindness, and alienation of groups with diverse thought. Here’s what the dictionary says about bias: “A preference or an inclination, especially one that inhibits impartial judgment.”

It is common for projects to be initiated based on blueprints. However, a blueprint is just a guide to the future state. Its intended purpose is to guide the subsequent analysis and design activities. It does not answer all the questions. The details of what, how, and why are left to requirements analysis.

It appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design. Information Driven Design begins with a simple concept...

Essentially, the IIBA® does not view “testing” as being part of the BA role. Obviously I disagree. When it comes to hours associated with test planning/strategies, the IIBA® should accept them as work experience in qualifying to sit for the CBAP® exam.