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.

Being required to produce documents that create massive information bloat and don’t add value is frustrating as it slow projects down and creates additional project cost that isn’t needed. It’s a headache for Project Manager, Business Analyst and everyone on the team. What we need is the smallest set of information that can be verified and validated quickly that directly ensures the highest quality outcome of the project. 

Gathering and documenting requirements to develop software is often seen by business analysts as their core task. Actually, they are there to deliver value to the business—everything else is secondary.

Do we “on board” new project team members? In today’s busy organizations individuals are shuffled around all the time being assigned and unassigned almost daily to projects. We employ the “sink or swim” mentality. New person it’s your job to figure it out and get it done.

Many skilled individuals do ask themselves: “How can I be sure, that I am doing well?” Especially in the business analysis sphere, the criteria of a quality job may be vague or only partly relevant.

In reality, what many people do is try to measure the quality of business analysis work through analyzing some aspects of BA artifacts they produce.

This article attempts to explore a theoretical interpretation of “User Experience”. It will explore the meaning of ‘User Experience’ itself by focusing on the user, the technology and the resulting experience from the two interacting with each other. It will define some user experience roles relating to associated professions, and also attempt to describe the single important dynamic of user experience.

You finally did it. You figured out the real business problem your project is meant to solve, and identified a solution that is far superior than the originally proposed. Now you just need to get buy-in from the project sponsor so the delivery team can alter their plans and set out to build the higher-value solution you devised. But there is one problem: the project sponsor was deeply involved in identifying the original solution and nurturing it. It’s his baby… and if you say it needs to be overhauled, you are basically saying his baby is ugly. Now what? How do you make sure your news aren’t received as an insult, and dismissed with defensiveness by the decision-maker?

Discovery of real needs is the responsibility of the business analyst. Choosing the optimal solution is usually the responsibility of the stakeholders. Working together, both parties can ensure that they are providing the maximum business value.

Requirements are inputs to achieve the project objectives that transcend from routine operations to enhance the value proposition of a business endeavour. Stakeholders invariably perceive an endeavour to be successful only if they are able to clearly correlate the derived outcome to predefined business requirements. Thus project success is best defined in terms of effective user requirements.

While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.

Follow this script at the beginning of your requirements discovery process, and you should see visible results in terms of the quality of your solution requirements. This checklist will help you anchor any and all discussions about features and designs on how they will help your customers achieve their desired outcomes and benefits. It will also allow you to define a valuable, usable, and feasible solution without having to rely on your customers being able to describe it for you.