This is the second of three articles where we are considering what makes a good “business analyst” (otherwise called:  a functional analyst, a systems analyst, a business technologist, or a business process engineer).

This is an important subject because only 17% of IT projects and 21% of ERP projects are seen as successful by business leaders.  But the other 79% of ERP projects aren’t seen as failures because of technical problems – the technical infrastructure (i.e., the ERP software and hardware) is solid, well-designed – and it works (at least, when using software from ERP leaders, like SAP and PeopleSoft). Companies in the same industry can use the same software, and yet some succeed, while others fail.

Upon further research, comparing the successful projects to the failed projects, it becomes evident that the failed projects weren’t successful because of problems in the “business analysis” area.  In other words, there were design problems and/or cultural problems (i.e., resistance to the new technology), such that there was an improper alignment between the business and the new technology.

Proper alignment means that the IT system meets the need of the business . . . and that the businesspeople are happy with this system. It is the job of the analysts to make sure that the system meets the needs of the businesspeople – this should be the easier part.  It’s the second part (making sure that the business partners are happy with the system) that is more difficult, and usually given far too little attention.  Plus, this second part must be approached from both the top down and the bottom up; that is, from the top down by the project manager, and from the bottom up by the business analysts.

There is no simple formula for a successful analyst, as they come in all shapes and sizes, and they have different personalities and approaches to the job.  No one is equally good at every aspect or knows everything that might be useful in doing the job.

However, there are some personal characteristics that seem to be essential, and there are some key areas of knowledge, skill, and experience.  Let’s start by looking at the characteristics that a project manager should be looking for in an analyst.  These fall into three main areas:

1. Knowledge and experience of the business
   
   
2. Knowledge and experience of IT systems
   
   
3. Personal skills and attributes

Many of these are also characteristics that will help anyone – the project manager, business leader, business managers, or business employees – to participate in and support the change process and implementation of the new IT system.

The analyst needs to be able to work with people throughout the organization in their own language and understand the kinds of problems they face.  He or she should have some understanding of the products or services, the marketplace, and typical customers or clients.  He or she should understand the formal organization structure and the informal networks and alliances.  He or she should know the key players personally – what they stand for, who carries clout, and who influences opinion.  In short, the analyst needs:

• To have a good familiarity with this type of business

• To be able to quickly gain a familiarity with this specific organization, its situation, and its people

This person needs to thoroughly understand the IT system being implemented – or be willing and able to learn quickly.  However, the knowledge required is primarily strategic, not nuts and bolts. So, the analyst needs:

• To have a familiarity with this type of IT system, its processes and workflow

• To be able to quickly gain a familiarity with infrastructure of this IT system at this particular organization

Analysts who fail usually fit one of three types:

1. The analysts in this bad group are aloof, detached, unfriendly know-nothings.  Businesspeople don’t really know why these analysts are there, or what they are trying to do, so the businesspeople become leery and alienated from the project. These analysts don’t get involved, so they’re not informed and aware, and they have no good basis on which to shape the organizational dynamics.  Sometimes they pay lots of attention to external events, but almost none to internal events.  Good analysts are proactive, not reactive – and the proactive analyst must have detailed involvement and awareness.

2. The analysts in this bad group are pompous, domineering intimidators.  These “experts” come in believing that they are so important that they don’t have to work or build relationships.  They demand that everyone provide them with all the details, so that they can just assemble the necessary “deliverables” (which are invariably “paper-product” only useful out in the outhouse).  Everyone becomes either too frightened, or too obstinate, to take any initiative, and communication dries up completely.  These analysts huff and puff over the wrong things, and yell and scream at the wrong people.  It’s an exercise in futility – and a sure way to ruin a relationship and guarantee project failure.

3. The analysts in this last bad group are apple-polishing, political hypocrites who are all talk and no action.  This is the type of analyst who is all over the place, but “running for office” and gladhanding, not probing, understanding, and setting new directions where necessary.  This analyst’s personality craves the affection of everyone.  In pursuit of that desire, he or she has a kind word for everyone, and a word of counseling for no one.  As with the other two types of bad analysts, they are poorly informed, for two basic reasons. First, they don’t dig to find out what’s really going on. Second, the businesspeople soon learn it’s no use telling them what’s really going on and where the problems are, since the analyst won’t do anything about it anyway.  Analysts like this are in the good news business, not the bad news business.  They don’t ruin a project as fast as an intimidator or the aloof analyst, but the project still ends up costing too much for the returned value.

Yes, analysts do make the difference.  However, this is definitely a plus, not a minus; since otherwise, there would be no good way to mobilize the businesspeople in pursuit of a company’s IT goals. Because of our belief in the criticality of the partnership dynamics between a business group and IT, whenever we saw an IT project start to go sour, we knew that the situation could be corrected by sending in good analysts.  Plus, there was not a single case in which good analysts did not rapidly turn matters around, which then again reinforced this belief of ours in the importance of developing a good partnership between the businesspeople and IT.  So, it boils down to this:  It isn't so much that there are bad IT projects, as it is that there are bad analysts who did not, or could not, do their jobs.

We have concluded that there are seven attributes which are of great importance and very necessary in a good analyst, because of their extensive effect on both the project and the business partners. These are courage, confidence, savvy, maturity, integrity, a sense of humor, and desire.  These seven attributes interact with one another – that’s what makes each of the seven, and all of the seven, so very important.  In the next article we will go into detail about each of these desirable attributes, which, based on our experience and observation, are so very important in affecting a project’s success.