Business Analysis Articles

Sep 08, 2019
1285 Views
0 Comments
Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations.
Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads ...
For the business, it means they not only need to understand the problem the customers are trying to solve - they need to understand that problem in a context and design a full end-...
Successful projects—and successful relationships—are based on realistic commitments, not on fantasies and empty promises. This article, adapted from the book Practical ...

Latest Articles

12995 Views
2 Likes
0 Comments

The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild

118174 Views
81 Likes
12 Comments

Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.

In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

Author: Glenn R. Brûlé

8810 Views
1 Likes
1 Comments

In my last column I introduced you to the role of a typical security analyst, and explained that security is a part of the business lifecycle. In this column, I will dive into that concept, and I will highlight some of the areas a security analyst might play in determining the risk to an asset throughout its life span.

9252 Views
3 Likes
1 Comments

One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy. 

7615 Views
1 Likes
0 Comments

Not many people-including business analysts themselves-are able to agree upon a standard job description, typical skill sets, proper training methods or a well-defined career path for the business analyst position. Yet almost everyone who's ever toiled away on an 18-month software development project can agree on the importance of the business analyst role to project success.

So while everyone agrees that good business analysts are extremely valuable, and that cultivating business analyst talent is essential for effective IT operations, a new Forrester Research report says that businesses need to do more. To really take advantage of everything that business analysts have to offer, there needs to be an answer to a career conundrum that many business analysts face: What's next?

In the June 2008 report, "The Business-Oriented Business Analyst," Forrester's Andy Salunga offers several potential paths to future business leadership for business-oriented business analysts.

First it needs to be noted that Forrester categorizes business analysts (BAs) into three roles: business-oriented BAs, who focus on a particular function, such as HR, finance or supply chain; IT-oriented BAs, who report into IT; and business technology BAs, who possess a blend of broad business experience and operational know-how as well as a high degree of tech know-how. However, the analysis and discussion of business analyst career path seems just as applicable to all other BAs and those who are interested in becoming one.

Author: Thomas Wailgum , CIO

4071 Views
0 Likes
0 Comments
Over my last two articles, I have laid a foundation for a Service Oriented Architecture (SOA) as the enterprise architecture of the globally integrated enterprise and focused on how to define and establish the business side of the enterprise through a well defined business architecture . Before diving into the IT side of the enterprise, this articl...
8917 Views
1 Likes
0 Comments

In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration.  Now, our attention turns to how data should be defined.  Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

Author: Tim Bryce

5197 Views
0 Likes
1 Comments
Of all the roles associated with developing software, perhaps none needs a makeover as badly as the business analyst. Intended as a pivotal position that translates business needs to software requirements, the role varies widely across organizations. Often saddled with negative stereotypes, the job doesn’t command the respect it deserves. “It’s...
7111 Views
1 Likes
0 Comments

When developing or changing a process, and all its related assets, often the process engineers have to face an important issue: how defining an integrated set of processes so that each process element is designed taking in consideration its relationships with all the other interfacing elements. Together with this issue, we also have the need to ensure that all the relevant requirements for the processes and their process assets are fully understood and correctly managed. These objectives are even more difficult to achieve when more persons are working in parallel to the improvement of different process areas. The approach described in the following paper, leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. All the examples are referred to a CMMI® based process definition but the most of the concepts are applicable also when adopting process models other than CMMI®.

Author: Filippo Vitiello, method park Software AG

6461 Views
0 Likes
0 Comments

Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles.

Why is it, then, that a systematic requirements engineering (RE) system is so rarely established?

Where do the problems lie when it comes to implementing such a system?

This paper outlines the challenges and how these may be met using the example of the automotive industry.

Authors: Michael Gerdom and Dr. Uwe Rastofer, method park Software AG

13356 Views
13 Likes
0 Comments

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems.

Author: Tim Bryce

5712 Views
0 Likes
0 Comments
You may be the new kid on the job block, but that doesn't mean your salary has to start low on the totem pole. The PayScale.com Salary Survey identified an array of exciting jobs that pay a total compensation close to or above an impressive $50,000 per year right from the start. Here are some of the 10 hot professions that show you th...
17454 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

7958 Views
2 Likes
1 Comments

A colleague of mine asked me recently what makes a good Business Analyst, and this stumped me for a while. I had a rare opportunity to go trout fly-fishing recently and as the fishing was slow I was able to contemplate this question. You will gather from this that the question had worried me as I seldom think about work stuff when I am fly-fishing. 

So what does make a good Business Analyst? 

I decided to go back to basics; if I want to know what makes a good Analyst then I need to ask what do we, as Business Analysts, do? If I could understand that, then I can start to understand what makes one Analyst better than another.  

I asked around in business analysis circles for an on line description of what we do. Although I got a few different answers, I found I got the most consensuses with “a Business Analyst elicits, documents, and communicates business requirements”. But what does that mean?

Author: Robin Grace

6401 Views
2 Likes
1 Comments

How many times have you been at a project meeting, maybe a status update meeting, and heard a voice that isn’t familiar to you speaking up for the first time.

“Ah... we need to put 5 days in the project to do our VA”

A meeting room full of people turns their heads and looks at the face of the unfamiliar voice. “You need what?” the Project Manager barks.

“We need 5 days, you know, between the build and go-live for the VA.”

A Sr. Business Analyst with many years of experience pipes up, “That just won’t work. We need that time for the QA and sign-off.”

The PM, who has worked with the Sr. BA on other projects, shakes his head in agreement, “We just don’t have time for a VA, what ever that is, now let’s move on to the next item.”

That unfamiliar voice at the table was an IT Security Analyst, facing a common challenge in the modern day business, getting the project implemented, while ensuring the right security controls are in place.

Author: Stewart Allen

Page 55 of 67First   Previous   50  51  52  53  54  [55]  56  57  58  59  Next   Last   





Copyright 2006-2019 by Modern Analyst Media LLC