As a result of budget constraints and limited resources, many companies, (mine included) look to automating tasks and processes to improve efficiency. And one of the easiest areas to demonstrate immediate improvement is by automating a manual process. While almost any manual process could show results by ‘simply’ being able to move documents and files electronically around the company, there is really a more important underlying requirement.

There are as many types of business analyst personalities as there are organizations and projects. The million-dollar questions is, how can a manager match an analyst’s unique skills to the projects that can really benefit from them, helping to ensure a project’s success? How can a manager build stronger, perhaps more suitable skills in his analysts?

Abraham Maslow once said “If the only tool you have is a hammer, you tend to see every problem as a nail.” This article provides the project manager (PM) / business analyst (BA) a framework for categorizing business problems as a baseline for selecting a solution development life cycle (SDLC).

“The overall purpose of Business Analysis is to build a bridge between business and IT”. This is a good enough definition for a position as hard to define as Business Analysis.

Can the same business rule be enforced differently in different contexts? The answer – an important one for re-use of business rules – is yes. This article explains. It also outlines what business analysts need to know to specify contexts of enforcement for a business rule effectively.

A software tool for The Decision Model supports the entire life cycle of Decision Management. This includes the authoring, analysis, testing and deployment of entire decision models. Whether managed by the business – as some people consider ideal – or managed by IT or business analysts on behalf of the business – as others consider necessary – business decisions need not only a repository for storing decision models, but a range of functions to manage them effectively.

Taking a long lens approach to looking at 2011 is an apt metaphor that should serve as a reminder to BAs of the perspective they need to take to in terms of both their professional development and their role in the organization. There’s no better time to take stock and strategize on how to best prepare for the opportunities and the challenges you’ll experience ahead.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It's like driving a racing car - you have to push close to the limits but any error can throw you completely off the track.

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?

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.