Entries for 'speeditonline'

How far can you take requirements elicitation in a project? Clearly, no one knows the ultimate answer. It would be very costly (if even possible) to capture all requirements, assumptions, rules, relationships, and hidden connections associated with a solution being built, so how do we know when we are done?

As I look back on the last nine years of my BA career, I realize just how well that initial reason for leaving the call center, that desire to make a difference for my customers, has served as a guiding light for me as a BA. Providing my customers with tools and processes that anticipate problems they may have has been a goal throughout my years as a BA.

Many IT professionals currently prefer the if-then form for expressing rules. Why? Put simply, it's closer to what they need for implementation, whether under a rule engine or a programming language. Consequently, they often resist expressions of rules from the business perspective as business people would naturally prefer them. But what effect does that have on the rules?

As business analysts, we know that a business process model is a crucial technique for transforming a business and redesigning automated business systems. Yet, we struggle with the best way to represent the business rules that guide it. This is not a surprise, but disappointing. Ironically, business rules may be the most important dimension of an enterprise. They are the core of business decisions and actions, whether automated or not. How do we treat them today?

Many business analysts lack a clear strategy to improve their abilities and increase the value they deliver to their organizations. They don't spend any time considering performance goals and envisioning strategies to achieve them, and as a result, they miss opportunities to continue to evolve and grow their role and responsibilities over time.

Fortunately, there are some steps that any BA interested in becoming a star performer can take to close competence gaps and learn new behaviors and strategies capable of increasing their productivity and the quality of their work. In this article, I will address one of the most effective ones: setting clear and measurable performance goals, and finding opportunities to practice the related skills that can produce the desired performance improvement.

Thousands of business analysts have turned to software visualization from as a strategy to simplify their jobs and cut through the confusion. With iRise, business analysts are empowered to quickly assemble a high-fidelity working preview of an application before development ever begins. These visualizations look and act just like the final product, creating an accurate visual model for what to build.

In many organizations, Centers of Excellence, PMOs (Program/Project Management Office) and PQA (Process & Quality Assurance) teams use a variety of manual techniques to vet documentation that are time consuming and manual; leaving room for unintentional mistakes, missed steps and delays in catching errors with regards to governance and best practices. In the spirit of delivering the project on time and under budget, many times these quality review processes are rushed and reduced to cursory checks. Like ensuring documents exist with the right naming convention, rather than reviewing the internal contents of documents and ensuring the contents are of high quality.

Almost every business analyst uses diagramming software in their arsenal of analysis tools. According to BABOK 2.0, an analyst’s traditional purpose in using diagramming tools is to “support the rapid drawing and documentation of a model, typically by providing a set of templates for a particular notation which are used to develop diagrams based on it.” Diagrams not only make requirements clearer to stakeholders through modeling, they help clarify an analyst’s thinking on a project through the process of their very creation.

Adoption of The Decision Model has escalated faster than anticipated. It also caught the attention of the Object Management Group (OMG) which is the subject of this month’s column. This column provides information to Modern Analyst readers regarding the OMG and its interest in decision models.

In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.

I believe the Problem Pyramid™ provides the appropriate structure for guiding effective business analysis, both for initiating and carrying out projects, whether for what BABOK® v2 calls projects or for topics that truly fit within Enterprise Analysis.

A user of almost any given software system or business application will require precise analytics in order to objectively measure its effectiveness, or the effectiveness of an associated product. These analytics –or reports—therefore, must measure the right criteria at the right time(s) in the right way in order to be useful to the user. For that reason, any newly proposed reporting function requires careful, measured, thoughtful and thoroughly vetted requirements in order to ensure its efficacy.

While most business analyst roles don't explicitly require static modeling expertise, developing a better understanding of static modeling concepts can be a measurable forward step for business analysts seeking to develop new competencies. Such skills can be useful in many aspects of the BA work, from obtaining a better understanding of stakeholders' information needs, to documenting those needs in unambiguous ways and communicating them more effectively to the technical team.

Yes, the world is flat, and the reality of today’s global economy is that business analysts (BA) from all corners of the earth – North America, South America, Europe, the Middle East, Africa and Asia Pacific – often work with one another. But they don’t always understand how business efficiency is impacted by the comprehension of their inherent differences. There are fundamental philosophical and behavioral differences between professionals across the world that impact business success. If BAs aren’t readily capable of adapting to the environment in which they work, they are most certainly setting themselves up to fail.

For many business analysts (BAs), the IIBA Business Analysis Body of Knowledge (BABOK®) Knowledge Area that is the least familiar is Enterprise Analysis (EA). In some ways, this may be a mixed blessing. On the one hand, the BABOK® Version 2 (v2) EA area describes important topics and techniques that BAs should be conversant with: defining business needs, solutions, business cases, and project initiation. On the other hand, I have issues with the ways BABOK® v2 treats these topics, especially how it portrays business needs and considers defining them as only part of EA.