Analytical and Problem Solving Skills

This article shows business analysts, systems analysts, and product managers how to build “trust into the UI” by writing practical provenance requirements for AI-enabled features. It introduces a simple Provenance Requirements Template that turns vague goals like “show sources” into testable product behavior: when to display citations (ideally tied to specific claims), how to handle conflicting sources with a clear tie-breaker, how to define freshness SLAs by claim type and what to do when data is stale, and how to support confidence/uncertainty, “what changed,” and audit exports. The takeaway is a repeatable way to specify “why should I believe this?” so answers come with receipts, stay current, and can be verified or audited when needed.

In tech teams, the word “just” (“just add a field,” “just change a label,” “just add an exception”) is a warning sign—not because people are wrong to ask, but because they’re only seeing the visible slice of the work. This article introduces the “Just Tax” framework to make hidden costs visible: Data, Decision, Dependency, Documentation, Deployment, and Diplomacy taxes. Through three quick BA-centric mini-scenarios, it shows how “small” changes become requirements debt when definitions, approvals, downstream systems, testing, and stakeholder expectations aren’t accounted for. It closes with practical, copy-paste lines BAs can use to keep momentum while turning “just” into a clear tradeoff.

This article shows BAs, systems analysts, and product managers how to turn vague AI “safety” statements into clear, testable requirements. It introduces a simple artifact called a Guardrails Catalog—a reusable list of Allowed / Not Allowed rules that define boundaries for AI features (forbidden actions, restricted data, safe defaults, and what the system must do instead). The core technique is writing each guardrail like acceptance criteria: specify the trigger, the prohibited outcome, the required safe behavior, the exact refusal wording the user should see, and a straightforward validation step. The article includes practical guardrail patterns and examples (e.g., no irreversible actions without confirmation, redact sensitive identifiers, refuse unauthorized requests, don’t guess when ambiguous, don’t invent sources) plus a short list of common pitfalls to avoid. A separate downloadable template is linked for teams to copy/paste and use immediately.

An inflection point. A forcing function. A once-per-civilization opportunity to prove that human judgment, contextual understanding, and adaptive intelligence remain indispensable even as artificial intelligence transforms everything around us.

You're not preparing for 2027.

You're defining it.

Act accordingly.

Thinking outside the box. Making a paradigm shift. Looking at the problem in a brand-new way. Taking a fresh approach. These expressions all refer to changing how we look at a difficult problem to solve it in a more effective manner.

People naturally get stuck in their established ways of thinking. It’s all we know at any given time. But sometimes that's not sufficient. Instead of continuing to pursue the current strategy that doesn’t work, we must shake up our thinking, sometimes radically.

I measure the success of my 50+ year career in IT by the positive feedback I’ve received from colleagues, stakeholders, students, and readers. I started as a Cobol programmer, progressed to software analyst/designer, and for the last 30 years have performed the role of business analyst. Interspersed in those years I’ve shared what I’d learned through writing, teaching, presenting, and mentoring. This article discusses the top seven “Takeaway Points” from the over-30 BA resources I’ve produced related to requirements for information systems.

The rise of artificial intelligence (AI) has drastically changed the business world, allowing companies to get useful information from huge amounts of data. The job of business analysts is very important in this change because they connect raw data to strategy decisions. One new skill that can help them make a bigger difference is prompt engineering, which is the art and science of making exact inputs to get the best results from AI models. By acquiring this skill, business analysts get insights that have never been seen before, Utilize AI solutions to fit the needs of their organizations, and stay necessary in a time when technology is fast pacing.

Software consultant Tim Lister defined project success as “meeting the set of all requirements and constraints held as expectations by key stakeholders.” There’s a vast body of literature on software requirements. In contrast, little is written about the various kinds of constraints that stakeholders might impose on a software initiative. Identifying, communicating, and working within constraints are essential aspects of successful software development. Let’s begin with a definition:

“A constraint is a restriction that limits the choices available for a product’s specification, design, construction, configuration, or project management.”

A software initiative is subject to three major classes of constraints: product, project, and process.

I don’t know if you are, but I am a very visual person.  When I see a diagram or process flow it helps me understand concepts quicker than reading it solely in text.  I have found that my mind just works that way and I tend to always make pictures when I am breaking down something complex or trying to understand a concept. I have found I even document my personal and professional goals visually and I do that through mind mapping.  I have found mind mapping to be a great way of brainstorming and organizing my thoughts and I want to share the magic of mind mapping with you. 

In the intricate world of business analysis, understanding the complex interactions between various economic agents is crucial for making informed decisions. One tool that plays a pivotal role in comprehending these interactions is the Circular Flow Diagram or CFD. Originating from the field of economics, this visual representation has found its way into the toolkit of business analysts, offering a holistic view of how money, goods, and services circulate within a vertical industry or within an organization. In this article, we delve into the essence of the Circular Flow Diagram and explore its applications in the realm of business and systems analysis.

Business Capabilities are at the heart of an organization’s planning ecosystem. Capability mapping serves many purposes, two of which are critical. First, business capabilities are instrumental in setting priorities more quickly focusing on the most profitable initiatives first. Second, well crafted detailed capability-based roadmap allows agile project planning that is more accurate, less risky, and takes less time.

As Business Analysts, when we’re at the sharp end of solution delivery that doesn’t match a customers needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages. In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements. 

We hear the buzzword “business transformation” everywhere. It has become almost expected of any organization to announce they are on their digital transformation journey. What does it mean?

There are many definitions of digital transformation. This abundance points to a broad interpretation of the term. The ambiguity of these statements reflects vague expectations of many organizations embarking on their “digital transformation journeys”.

When engaging on projects we need to lead our clients to get the outcomes we need for analysis. If we act passively and don’t take charge then they’ll take things all over the place and create chaos. In this article we’ll explore how a problem statement acts as a powerful tool to keep control of our engagement and analysis right through the project lifecycle.

Thanks to infrastructure as a service (IaaS) and software as a service (SaaS) architectures, the utility of and business case for model-driven, no-code and low-code platforms have become more compelling than ever. More and more enterprises are entrusting their digital transformation, regulatory compliance, and business process management objectives to model-driven, no-code or low-code business application platforms.  These model driven platforms also raise the bar for the business process modeling skills of the business analysts, systems analysts and process owners who use them.