Analytical and Problem Solving Skills

13543 Views
25 Likes
16 Comments

Regretably, many of today's Systems Analysts are still glorified programmers in sheep's clothing.  I recently came across some job postings under the title, "Systems Analyst," and it occurred to me people still do not know what it means. In the postings I saw things like "seeking a Systems Analyst with 4 - 6 years experience... Candidate must have experience with JAVA and the ATG application framework."

 

12169 Views
13 Likes
0 Comments

 Ever had to interview your boss – or a divisional general manager – or the managing director of a key customer? What about a politician or a senior executive in a government department? All these scenarios can be nerve racking, yet they’re something a business analyst may be required to do on a regular basis.

12144 Views
4 Likes
1 Comments

In this final paper of the series we look at decision making techniques – how to select the best idea from the many we’ve come up with – and how to justify our recommendation to our client, manager and peers.
 

12955 Views
11 Likes
0 Comments

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

13609 Views
4 Likes
5 Comments

A lot of people think that coming up with solutions to business problems is the hardest part about being a business analyst – particularly when working with a client who knows more about the business than you ever will. Don’t believe it, after all you’ve already made considerable progress in understanding the problem – and your understanding is based on level-headed analysis rather than a potentially emotional interpretation by your client.

Now it’s time to look for solutions – to be creative and think outside the square. In this paper we’ll offer a few tips and techniques for getting the creative juices flowing. We’ll show you that anyone can be creative and that solutions can come from the most unexpected places – you don’t have to be a subject matter expert to come up with valid, workable solutions to business problems.

16426 Views
15 Likes
0 Comments

Like all professions, business analysis has its golden rules – rules that are fundamental to the design of successful business systems. They might seem like common sense but it’s surprising how often we forget them and get ourselves into hot water.

16550 Views
14 Likes
8 Comments

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

8890 Views
2 Likes
3 Comments

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 that 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'll 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.

Author: Jan Kusiak

8945 Views
1 Likes
0 Comments

In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration.  Now, our attention turns to how data should be defined.  Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

Author: Tim Bryce

13391 Views
13 Likes
0 Comments

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems.

Author: Tim Bryce

7274 Views
1 Likes
0 Comments

One of the biggest challenges in any system design effort is to produce a viable design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.

Author: Tim Bryce

9045 Views
2 Likes
1 Comments

In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:

  1. Develop artist rendering (to consider viability).
  2. Design foundation and superstructure.
  3. Design Floor plans.
  4. Design electrical and plumbing diagrams.

Author: Tim Bryce

11814 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

22229 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

9651 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

Page 3 of 4First   Previous   1  2  [3]  4  Next   Last   




Latest Articles

Domain Expertise and the Business Analyst: How Vital Is It?
Sep 15, 2019
3 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 tha...

Copyright 2006-2019 by Modern Analyst Media LLC