|
White Papers
IRM's online library features a variety of white papers relating to the field of Business Analysis:
What is a Business Analyst?
Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available?
Each organisation seems to have its own ideas about the role, skills, responsibilities and expectations of the Business Analyst. Given the importance of the job, a common definition would assist both practitioners and employers. We explore some of the issues here.
Written by Derrick Brown, IRM's Director and instructional designer, it shares first hand observations and experience gained from training thousands of Business Analysts since 1980, first in the UK and since 1984 in Australia.
download paper (353kb)
The Partnership Scorecard
Why do we need partnerships?
Because today, organisations live and die by the effectiveness of their internal and external relationships. Time and again however, bad relationships result in failures or roadblocks – with no one able to pinpoint or rectify the causes.
To prevent this we need to effectively negotiate expectations, deliverables and responsibilities between all stakeholders. We also need to track relationship health over time and prevent conflicts before they arise.
In this latest paper, Dr. Laurie Lock Lee (IRM trainer and a specialist in value networks) describes how to use a scorecard system to measure both tangible and intangible value flows between people, departments, suppliers and customers
download paper (1,245kb)
The Creative Business Analyst: Part 1 - Understanding Problems
Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.
We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.
To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones...
download paper (114kb)
The How To of Essential Modelling
Also called abstract or business modelling, essential modelling can be an extremely valuable tool for the business analyst. Instead of modelling how things are done (the current system), or how they might be done (a proposed system), we model what is done, or what might be done. For example the purpose of a Customer Service Department is to provide customers with a level of service they expect (or the company defines). Things like call centres and customer relationship management systems are the how of customer service.
This switch in thinking is not always easy as we have to ignore the very practical matters of procedures, methods, people, technology etc. The more involved we are in the system that we are looking at, the more difficult it may be to look at things conceptually. We have to look at what business objective we are trying to achieve. The business analyst who can do this - and explain it to clients and management - becomes a most valuable asset to the business...
download paper (125kb)
An Introduction to Technical Writing
At some time or another we all have to communicate using the written word, but all too often improving writing and communications skills are at the bottom of our “to do” list. Yet how many times has poor communications lead to incorrect decisions or even downright confusion?
In the following introductory chapter from IRM’s Technical Writing Skills workshop we look at what defines good writing and how to get started.
download paper (202kb)
How to use Use Cases
Many business analysts and business users get frustrated at the perceived lack of information in a use case diagram. “It’s all very well drawing a picture” they say but what about the details – what’s actually going on? When producing project documentation, use case diagrams are rarely used on their own. They will generally be accompanied by a textual use case and if they’re complex, may also have a supporting activity diagram to show what’s going on “inside” the use case.
This paper includes several exercises from IRM's Modelling Requirements with Use Case & the UML workshop to test your skills.
download paper (210kb)
UML - Business Context
“Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system.
In the following extract from our Modelling Requirements with Use Case & the UML course manual we’ll take a brief look at which of the 13 diagrams are of most relevance for us and how they fit together...
download paper (233kb)
Stakeholder Communications - Pictures not Words
Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?
Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.
download paper (258kb)
Creative Thinking Techniques
This extract from IRM’s training material looks at how systematic, creative thinking techniques can be used to design practical solutions to business problems. The first step in developing a solution is to identify and define the problem - see the IRM paper Problem Analysis Techniques.
Using the problem definition as a starting point we can apply a number of creative thinking techniques to identify potential solutions, then further analyse and refine these to give us an optimum solution for the problem at hand. This paper discusses some of the successful creative thinking techniques used by business analysts and describes a generic model which can be used to guide the process.
download paper (499kb)
Problem Analysis Techniques
This extract from IRM's training material looks at how a structured approach to defining and analysing problems can be used as the basis for designing better solutions. Part 1 of this paper looks at problem definition. Part 2 introduces the reader to analytical techniques for determining the root cause of a problem. Future papers in this series will look at creative thinking techniques for successful solution design.
download paper (371kb)
Separating Analysis from Design
"Business Analysis is about thinking what your solution should do, while Design is about how to make it happen using the technology available. Don't ever combine the two - you save nothing."
This paper by Brian Cooney, formerly the principal instructor at IRM, describes the need for clear separation between the two phases and the benefits this provides for a successful project outcome.
download paper (206kb)
Manager's Guide to User Acceptance Testing
Whilst the technical testing of IT systems is a highly professional and exhaustive process, testing of business functionality is an entirely different proposition. Does the system deliver the business functions that are required – does it follow the company’s business rules – does it support a government department’s obligations - does it cope with exceptions?
The people who have to make these decisions – to accept or reject the new system – are the business users. It is therefore critical to get the business user involved in testing and not rely only on the technicians. In this paper we explore the rationale behind User Acceptance Testing (UAT), why it is so important, and how best to go about it.
download paper (319kb)
Was Your Last Software Specification Really Appreciated?
If you are still trying to write system specifications in English then you are in trouble. For the same reason that engineers and architects use graphical tools to specify their products so too must software specifiers. A system needs to be broken into small pieces in a structured way and we need to show various views of the system and how they fit together. Typically we may show a process view, a data view, perhaps a time-line view...
download paper (149kb)
Analysing and Managing Risk in a Project with Tightrope
Managing a project is like walking a tightrope - it is easy to fall off and hurt yourself. However, we can improve the tightrope and perhaps convert it into a bridge, hence reducing the risk of a calamity.
The project manager has total responsibility for the success - or failure - of a project. In the initial burst of enthusiasm - and the likely refusal of management to contemplate failure - it is easy to overlook the risks. It is the project manager’s responsibility to remain pragmatic, to check out the viability of the project, and to report any doubts about the wisdom of proceeding to the highest management level...
download paper (754kb)
|
|
|
|