In this series of articles we will consider the job and the person of a “business analyst” (otherwise called:  a functional analyst, a systems analyst, a business technologist, or a business process engineer).  In other words, we are talking about a person who has the business expertise, the technological expertise, and the people skills required to effectively communicate with both businesspeople and IT professionals and to provide the guidance, analysis, and design in order to successfully implement technology-assisted, strategic business processes.

Someone might ask:  Is it really important to have good business analysts on one’s project?  The answer, as we will show, must be a resounding, “Yes!”

Current statistics show that 5 out of every 6 IT projects (83%) are either late, over budget, reduced in scope, or canceled.  Of course, one would expect this failure rate to go way, way down on projects implementing today’s modern ERP software, since this software is now so comprehensive, powerful, versatile, and flexible . . . and yet 79% of business leaders surveyed said that their massive ERP efforts had not been fully effective [Forrester Research, September 2001 Report].

Over the past ten years, software vendors have worked hard to make our tools and platforms better and better, but no matter how hard these vendors try, most IT projects still fail to deliver as expected. Why?  Because most projects fail, not due to technical problems, but due to problems in the “business analysis” area.  In other words, there were design problems and/or cultural problems (i.e. resistance to the new technology), which caused an improper alignment between the business and the new technology.

To insure that a project is successful, it is imperative that there is a proper alignment between the business and the technology.  Plus, this alignment must be approached from both the top down and the bottom up; that is, aligned from the top down by the project manager, and from the bottom up by the business analysts.

Imagine the following strategy for moving your people to a new building:  You announce the move and the availability of movers and maintenance people to hook up telephones and personal computers, knowing that most of the people want to be in the new building, and hoping that people will simply make their own way over there.  You expect that they will have the common sense to allocate the floor space and offices among themselves.  With this approach, what is the likelihood of an orderly move?  Oh, about as likely as an accidental explosion in a print shop will create neatly bound volumes of the Encyclopedia Britannica.

Whether considering an office move or a change in an IT system, a similar principle applies:  Unless there is a skilled team that takes responsibility for masterminding the whole affair, either nothing will happen, or there will be complete chaos.  In fact, even with a team orchestrating the changes, the process rarely takes place without incident.

Perhaps the business leader feels that he or she should remain personally responsible for an initiative that is so important and so all-embracing.  This is absolutely correct, but he or she still can’t do everything.  The business leader needs to have others play their appropriate roles.  Every team member must take part in designing the plan, take ownership of their piece of the action, and deliver on their commitments.  The business leader also needs many people within the effected group to sincerely embrace the change and show leadership.  However, as we shall see, analysts can guide this process in ways that no manager can.

Yes, none of this will happen unless there are skilled analysts assigned, to guide the team as they develop the plan, to help figure out how to accomplish the tricky or technical bits, and to provide ongoing support to these business partners.  So, it is most unwise to attempt a major business-process overhaul without very skillful analysts.  In fact, history shows that a key factor in the success of IT projects is the skill and dedication of these analysts.

Excuse us for a moment, here – we need to take a tangent and talk about the term “business partners.”  We have worked with many different companies; and when they talk to each other or to us, they were always referring to “your side, my side.”  But that’s wrong, very wrong and detrimental.  It should be “we.”  Everything should be “we” or “us.”  We also don’t like it when IT calls the people who use IT services “end-users,” “customers,” or “clients” – that’s just bad “us versus them” psychology.  No, they aren’t any of these; rather, they’re “partners”!  As long as IT treats the business side like customers and clients and end-users, IT will continue to have a problem.  Plus, IT should be thought of – and think of itself – as being part of the team, part of one cohesive group – all marching forward together to attain the same business objectives.

The role of the project’s analysts is to support the business leader, the project manager, and the project team in order to bring about a purposeful transformation from the current (“legacy”) system to the new IT system.  Since maybe only about one third of these people’s jobs is actually doing “analysis,” they should probably be called “business technologists,” rather than “business analysts,” as they also need to do “designing” (one third) and “guiding/ motivating” (one third).

You see, if the analysts properly do their jobs, after doing all of the analysis and design work, their work is, at most, only two thirds done. To insure the project’s completion and success, they must also diligently and sincerely work at being guides, motivaters, advocates (for the project and IT), teamworkers, team-makers, mentors, confidents, supporters and encouragers (of individual business partners), coaches, tutors, and role models.  While the first two thirds has the tangible, “hard” tasks, the last third has the intangible, “soft” tasks, but they are, by no means, less important.

There is a discipline and rigor involved in tasks like building relationships and overcoming fear and resistance to change.  These “soft” issues are just as essential to success as the more tangible, “hard” issues – and they, at times, require more time and effort to deal with successfully.  The analysts must secretly see themselves as “stealth leaders” who lead by example and motivate from the bottom up.

This is an important observation.  Like the change process itself; the analyst’s job has both “hard” and “soft” dimensions.  Both are critical to success.  Plus, both produce deliverables:  The first – the functional specification; the second – the support and involvement of the business partners.

Even if your analysts do the analysis perfectly and produce a detailed design that is without flaw, it is very likely that your project will still go down in flames, if your business partners have become alienated or left uninvolved.  One can not say about an IT project:  “Build it, and they will come.”  No, the analysts (who look like non-management equals to the business partners) must go out and bring in each business partner, one by one, by encouraging them, by gently prodding them, and by motivating them in ways that a manager couldn’t and wouldn’t.  It’s necessary – it’s important – and it works!

It is necessary for the project’s success that the analysts play a wide variety of roles.  Often, even in the course of a single day, an analyst will have to switch roles according to what is required at the time. Some of the possible roles have been described as inappropriate for the following reasons:

• Commander:  Analysts are support people; it is not their role to hand out instructions.  Rather, it is the function of management to allocate responsibility and accountability. Even if the business leader says to the analyst, “I want you to go and make them do it,” attempts by an analyst to command action or involvement are usually doomed to failure, and ruin the analyst’s relationship as a guide, motivator, and “stealth leader.”  If a manager asks an analyst to do something like this, an appropriate response might be “Okay, but only if you give me your job!”

• Competitive Person:  Everyone in the IT world is always talking about teams, teamwork, team players, etc.  And this is good . . . but people can’t be competitive and be teamworkers, because teamworkers must be cooperative, never competitive. Unfortunately, here in the USA, the word “competitive” is seen in the same light and as a synonym for the word “industrious.” Competitive people are seen as the heros, stars, and MVPs. However, stars don’t normally make good “stealth leaders,” confidants, friends, or team players.  Humbleness is a very rare quality today, as aggressive, arrogant self-assertiveness is certainly having its day.

• Spy:  Integrity is the analyst’s most valuable asset.  It is the foundation for open and honest relationships with the business partners, and it allows the analyst to earn their trust.  This will be impossible to achieve if the analyst is perceived as the business leader’s spy.  It is important to avoid any behavior or arrangement that could be misinterpreted in this way.

You can’t expect analysts to do more than just analyze and design, if they haven’t been taught what the whole job entails, and if they don’t have the right personality to do the whole job.  But we will speak more about this in the upcoming two articles.  However, make no mistake – all of this is important . . . that is, if you want to have a better than 1-in-5 chance that your IT project will be seen as successful by the business owner/leader.  But, does it really work? Oh absolutely, it has for us – 15 times in a row!