Business Analysis Articles

Sep 15, 2019
1074 Views
2 Comments
The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains that domain knowledge is not critical. A skilled BA, the thinking goes, can walk into nearly any project situation and do an effective job of exploring r...
The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains that domain knowledge is not crit...
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-...

Latest Articles

5027 Views
1 Likes
0 Comments
Many of us have Quality Assurance (QA) groups in our organizations, and the natural assumption might be that these groups are responsible for the quality of our products. For a few of us, that assumption might hold true, but for most organizations, the QA group cannot be held responsible for quality because they don't actually assure quality. What ...
4741 Views
0 Likes
0 Comments
Key to improving presentations is to focus on where your're audience is, not where you are, or where you want them to be. To do that, you must make a connection first. It is by making this initial connection that your "believe-ability" - your "buy-in" factor - and your "connection-ability" as a speaker are first made. Author: Tim McClintock, PMP
3511 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: ...
2980 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...
5477 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...
4354 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...
4074 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...
11799 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

22206 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

14358 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."

5416 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...
9643 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

8954 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

198048 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...
6269 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...
Page 58 of 67First   Previous   53  54  55  56  57  [58]  59  60  61  62  Next   Last   





Copyright 2006-2019 by Modern Analyst Media LLC