5 Common Rarely Questioned Assumptions Undermining Analysis for IT

An sizable yet very visual course about the core of Systems Analysis can be downloaded for free at analystsredbook.net

Direct Download: TARB

A common and widely spread "understanding" of what Systems Analysis (SA) is and how it should be applied, is based on 5 assumptions. These 5 assumptions (or beliefs) constrain SA. and, by doing so, they decrease the benefits severely. They prevent from tapping into its true potential. They may even be very detrimental to the company. And, because these assumptions are so common, they are rarely questioned. The consequences are accepted and the causes not identified. Often, great progress is realised by questioning our beliefs.

The present understanding determine the role of the analyst as well as the necessary competencies.

I use the term "Systems Analysis" as broader term covering all flavours of Analysis on Corporate IT projects, like Business Analysis, Process Analysis, Information Analysis and Functional Analysis.

1) Analysis is about decomposing, studying the parts and their relations. Hence, the analyst must be given that which has to be analysed. Without this, (s)he doesn't know what to do and can't work.

• Instead, SA is about studying systems and their environment. This means it also looks outwards. Besides "looking inwards", it also considers many different perspectives. Analysis is about learning, about detection of issues and opportunities and about diagnoses and problem analysis.

2) The goal of IT projects is to solve Business Problems. Analysis in IT projects has the same goal.

• Business problems require business knowledge to be solved. Not all problems experienced by the business community are business problems. The business community has information needs and may experience information problems. These are the main types of problems and needs IT projects seek to resolve by engineering systemic and technological solutions.

3) Analysis is about creating models and specifications; about requirements, UML or BPMN.

• This is by far insufficient knowledge.This knowledge is pretty much worthless without the understanding of what Analysis is really about, of the environment and problem area, of what systems are, of what information is, and of so much more. It is not because one knows how to use a telescope, that (s)he is an astronomer.

4) Analysis is an activity.

• Analysis is not an activity. It is a professional discipline that takes years to be mastered and require an extensive background. Analysis can not be assigned as a task to just any person available.

5) SA answers how to use technology to satisfy the customers needs. The main concern of the Analyst is "What does the client want?"

• Instead, SA (in corporate environments) studies systems and their environments in order to conceive, to strengthen, to optimise, to adapt, to expand the enterprise as a system and to maximise the exploitation of information in the company, in the deployed business activities, or/and as products and services.
• It is easy to design a simple solution or to solve a simple problem in a simple problem area and environment. This doesn't require much skills. But once the environment is a bit more complex, when the diagnose is not obvious (too often we identify symptoms as problems, instead of the causes), when the solution is more complex, this is when SA becomes crucial.

An sizable yet very visual course about the core of Systems Analysis can be downloaded for free at analystsredbook.net

Direct Download: TARB

The course is free. If you valued it, please share it with others so they can benefit from it as well. Thank you.