Business Analysis Articles

Dec 08, 2019
412 Views
0 Comments
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which looks at the solution to the business problem. It does this by assessing alternatives, and then choosing the best solution ...
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which loo...
For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge...
Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programm...

Latest Articles

3525 Views
0 Likes
0 Comments
"Life is a series of presentations!" I'm not the first to say that. Tony Jeary said it before I did, in his book of the same title. If life really is a series of presentations (and, as a business professional, you're going to be called on to present information) the question is, what are you presenting? What is your presentation saying? Author: ...
3004 Views
0 Likes
0 Comments
Call them "Lessons Learned," "Retrospectives," "Postmortems," or whatever you wish; taking the time at the end of each project to look back is almost universally considered to be a good idea. In fact, I can't remember ever having someone tell me that they don't think it is a good idea. "Oh yes!" I am often told, "We should do them!" Author: Alan K...
5512 Views
0 Likes
0 Comments
Have you found yourself wondering those exact words just moments after a conversation with a co-worker? Or have you found yourself in a heated discussion because of something you've said to your spouse or loved one? Better still, your teenager gives you the "deer caught in the headlights" look when you ask where have they been so late at night? You...
4365 Views
1 Likes
0 Comments
When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop and retain a good editorial staff, and do not forget to keep everyone's skills...
4103 Views
0 Likes
0 Comments
Any project that is cancelled, not completed, or fails to meet its objectives and has to be written off, is obviously a waste of organization resources and time. However, it is also not enough just to successfully execute a project to completion. A successful project that is not implemented or used because it doesn't meet the customer's or user's r...
12215 Views
4 Likes
3 Comments

Over the last four decades I have met a lot of Systems Analysts in a lot of different industries. Some impressed me greatly by their knowledge of their business and the systems they designed, but I have also met a lot of duds along the way. When I think about the better ones, I consider the attributes they share which I can narrow down to three areas

Author: Tim Bryce

22849 Views
9 Likes
0 Comments

In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to be studied, an analysis of the current mode of operation, a definition of requirements, an evaluation of alternatives, and an agreed upon course of action. As such, the activities for preparing a Feasibility Study are generic in nature and can be applied to any type of project, be it for systems and software development making an acquisition, or any other project.

Author: Tim Bryce

14595 Views
7 Likes
5 Comments

So you want to be a Business Analyst?

“Analyst – analyse thyself….”

Introduction
This is what Business Analysts do in the real world when embarking on a new project: they analyse… 

  • Why? Why are we doing this project - what is the business problem/need and so what measures and targets for those measures will define what success is. These are known as objectives.
  • What? What needs to be done (from business/logical perspective) in order to affect the measures to the point where the project can be declared successful (i.e. it has got the targets) – these are known as requirements.
  • How? How will the requirements be realized? What are the rules that will deliver the requirements? These take the form of process models, process definitions, data models, data definitions and various non-functional requirement rules.

So – as any good BA should do when undertaking a new project – analyse what are your objectives in wanting to move to a new career as a Business Analyst.
Put another way, how will you know (once you have done it) that it was a good move to make?

When you know your objectives, deduce the requirements necessary to affect things such that you achieve your target measures for your objectives.
Put another way, what do you need to do to be able to move in to Business Analysis?

When you know what your requirements are, define the process you will need to follow to deliver your requirements.
Put another way, what is the process you will follow to become a Business Analyst? How will each step of each process execute? What data will you need to provide/will you get at each stage of the process?

Throughout this analysis and your progress towards your goal, define as they arise and refine as you progress: 

  1. costs to achieve your objectives (e.g. initially you thought around $10k to train as a Business Analyst – actual quotes refine this to $7,040) 
  2. constraints that will curtail what you are able to do (e.g. budget and timescales) 
  3. dependencies that affect the order and timing in which things can be done (e.g. can’t get the ISEB Diploma in Business Analysis until you have 4 ISEB Certificates in Business Analysis, you can’t get the IIBA CBAP until you have 5 years’ experience) 
  4. issues that are outside of your control but are affecting your progress (e.g. availability of training courses) 
  5. risks to your career move that may (or may not) arise from the issues (you may not pass the ISEB Certificates or fail the Diploma) 
  6. assumptions you are making in the absence of the facts that allows you to make progress (analyzing the RISK that your assumption may be wrong!) (e.g. It is assumed that the ISEB Diploma in Business Analysis is the most relevant professional qualification to get. If wrong, then a number of jobs requiring another qualification could be ruled out).

Author: Guy Beauchamp
Guy started out in IT in 1985 and transitioned to Business Analysis in 1990 - he now works as a trainer for Business Analyst Solutions (
www.BusinessAnalystSolutions.com) - a niche supplier of all services for and related to Business Analysis."

5501 Views
0 Likes
0 Comments
Defining business requirements accurately is one of the most important success factors for technology projects.  Rather than focus on solutions that satisfy a list of requirements, we need to focus on solutions that satisfy desired business outcomes. The best way to achieve this is by performing business process modeling.  Employing a vi...
9826 Views
1 Likes
0 Comments

Good question! What do you think?

This is an important question which is ultimately at the heart of a lot of the problems in systems and software development. There is one camp that believes development to be an art form requiring free-spirited creative types of people, and another camp believing it to be a science requiring people that are more disciplined and organized.

The difference between an art and a science is subtle but significant. An art form is based on the intuitiveness of the person performing the work, something that is difficult, if not impossible, to pass on to another human being. For example, apprentices serving under an artist may try for years to emulate the master, but may never attain his level of skill and creativity. In contrast, a science is based on a governing body of concepts and principles and, as such, can be easily taught to others.

Author: Tim Bryce

9139 Views
0 Likes
0 Comments

Having been involved with the systems methodologies field for over 30 years I have been occasionally asked what percentage of time in a project should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study, Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a means for estimating the remainder of the project. For example, if I were to say Phase 1 represents 10% of the overall project, they would simply multiply the amount of time spent in Phase 1 by ten. This is an unreliable approach for estimating which is why I usually balk at giving out such figures.

Author: Tim Bryce

205366 Views
4 Likes
3 Comments
Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall projec...
6417 Views
1 Likes
0 Comments
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead agilists will do just enough initial requirements envisioning to identify their projec...
7766 Views
1 Likes
1 Comments
To be honest, I'm not very enamored with the term "best practice". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:...
8443 Views
4 Likes
0 Comments
Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the r...
Page 59 of 67First   Previous   54  55  56  57  58  [59]  60  61  62  63  Next   Last   









Copyright 2006-2019 by Modern Analyst Media LLC