Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.
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.
Author: Jan Kusiak
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.
I have been very fortunate to see a lot of this history first hand. I have observed changes not just in terms of systems and computers, but also how the trade press has evolved and the profession in general. It has been an interesting ride.
Throughout all of this, there have been some very intelligent people who have impacted the industry, there have also been quite a few charlatans, but there has only been a handful of true geniuses, one of which was Robert W. Beamer who passed away just a couple of years ago. Bob was the father of ASCII code, without which we wouldn't have the computers of today, the Internet, the billions of dollars owned by Bill Gates, or this document.
I always find it amusing when I tell a young person in this industry that I worked with punch cards and plastic templates years ago. Its kind of the same dumbfounded look I get from my kids when I tell them we used to watch black and white television with three channels, no remote control, and station signoffs at midnight. It has been my observation that our younger workers do not have a sense of history; this is particularly apparent in the systems world. If they do not have an appreciation of whence we came, I doubt they will have an appreciation of where we should be going. Consequently, I have assembled the following chronology of events in the hopes this will provide some insight as to how the systems industry has evolved to its current state. I'm sure I could turn this into a lengthy dissertation but, instead, I will try to be brief and to the point. Further, the following will have little concern for academic developments but rather how systems have been implemented in practice in the corporate world.
"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, principal instructor at IRM, describes the need for clear separation between the two phases and the benefits this provides for a successful project outcome.
Author: Brian Cooney
brought to you by enabling practitioners & organizations to achieve their goals using: