Is documentation a blessing or a curse? If you’re working on an agile project does it get in the way? If you’re updating a core system that runs your company’s business, are you cursing the analyst who didn’t adequately document all the business functionality? Is today’s agile project tomorrow’s core system?

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.

"Enterprise Engineering" is a term coined in to reflect the third and final part of the concept of Information Resource Management (IRM) representing a triad of methodologies to design, develop, and control all of the resources needed to support the information requirements of an enterprise, be it a commercial or nonprofit endeavor.

Many organisations hire external consultants with no experience of their business to shape strategies and propositions. In doing this, they are unconsciously ignoring internal resource with exactly the same skills but additional knowledge and experience of the business – namely their Business Analysts. BAs have a unique skillset, offering holistic insight, analysis and recommendations.

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.

As part of the Unified Modeling Language, Activity diagrams are often utilized for many software projects. However, a few questions about Activity diagrams linger in the minds of many Business Analysts, such as: Who is really using them? What kind of projects are they being used on? Why are people not using them? How are people using them? Are they providing any benefit?