Beyond Blinking Lights and Acronyms

Business Analyst Job Description

Far and away my most popular post is Let's Get Down to Business.  Even though it was written about a year and a half ago, 20+% of my recent site visits are to this article coming in either through Google searches or Jonathon Babcock's review of this post.  Why is this so popular?  I think it is because it contains a great business analyst (BA) job description that gets to the heart of what a business analyst really does.  This job description doesn't just cover the skills they need but focuses more on the competencies that will make them successful.

Having just gone through the process reviewing a fair number of BA resumes I'd like to add one more item to the list.

Be able to describe and communicate the value of a project in terms of both its benefits and costs in terms used by the business community that will effectively obtain leadership understanding, support and approval of the project.

In other words the BA has to be able to "sell" the project.  Ultimately it is the responsibility of the business owner or sponsor to sell the project, however, the BA has to be able to play a critical support role in selling the project.  As I did in the original post I highlighted this competency in blue to convey convey the essence of what distinguishes a good business analyst from a good applications person.

The reason I've added this is that after reading a number of resumes it was apparent that many claiming to be BA's are missing this critical competency too.  (Perhaps I should have used a different colors since it may not be all that common with BA's either.)  How could I tell?

Interviewed On Dice.com About Business Analysts Raising Their Profile

Back in April, Sonia Lelii from Dice.com, a recruiting and career development website for technology and engineering professionals, interviewed me as part of her story, Business Analysts Raise Their Profile in their Technology Today section.  Lelii also interviewed recruiter Christa Baker for her perspective.  Unfortunately, I had forgotten about this until Monday's post on hiring business analysts reminded me.

The article talks in detail about the need for people who can communicate between IT and business groups and what types of background and  skills they need.  Take a look, I'd love to hear your thoughts.

If this topic was of interest, you might also like these:

• Hiring the Right / Wrong IT People to Achieve Alignment
• Jonathon Babcock's post Business Analyst Job Description
• Let's Get Down to Business
<
• Or the posts in the Business Analysts / Analysis category

Hiring the Right / Wrong IT People to Achieve Alignment

Dr. George E. Strouse had a great article recently on CIO.com entitled "Are You Hiring the Wrong IT Staff to Achieve Your Alignment Goals?"  Strouse contends that the major cause of business and IT mis-alignment is that IT is not hiring the right kind of people.   He states "The right people need strong backgrounds in both business and technology. Most IT hiring managers place too much emphasis on strong technology backgrounds."  Although I cannot comment on whether or not this is the major reason for the misalignment I wholeheartedly agree with his comment on the needed background nonetheless.

The most popular post I've made (accounting for about 20+% of site visits) is one that contains what I thought was a good business analyst job description.  While this job description does contains some technical requirements as you might expect it also contains skills that are not often found in traditionally trained IT folks.  These are the types of skills that are needed for an business analyst to understand business.

Dr. Strouse contends that the reason business can not get the right people is that we are asking for people with a Computer Science degree rather than an Information Systems degree.  As a professor of information systems at York College in Pennsylvania he is eminently qualified to layout the distinction and makes a strong case.  Now before anyone with a Computer Science degree gets upset please read his article carefully.  As he points out there is a need for both types of degrees but each is better suited for different functions.

An Unexpected Obstacle to Forming a Business Analysis Group

In the last post I talked about forming a Business Analysis group to provide a strategic service of helping the business operations to better utilize technology.  In talking about this concept with other people I was surprised to hear of one significant obstacle to implementing this.

A friend and fellow CIO was set to implement this concept.  He had support from top management and the business units and had started to interview candidates.  However under intense pushback from within the IT group he decided to postpone the implementation.

Sometime later I was talking to the president of a large company.  This president liked the concept but was concerned about the effect of it on the IT department.  To my surprise this president raised the same objection as my friend's IT staff had.  Wait a minute!  A company president and the IT staff having the same concern?  This seemed like a very unusual situation.

And just what was this objection they had in common?

Let's Get Down to Business

In my post on Monday I talked about forming a Business Analysis group within IT to act as a bridge between IT and the business units.  The reason for this is to make the business strategy more effective through a proper use of technology.  By taking the steps necessary to add value beyond just delivery of services IT can become a strategic service.

The typical first approach to this is to simply say that we'll take some of our applications people and make them business analysts.  Although I won't say that application developer can not make good business analysts I will say that it is not a common occurrence.  The reason for this is that these two functions call for different skillsets and training.  Applications folks are trained in the intricacies of programming language and processes with little or no business training.  Most of their business exposure comes from what they learn on the job.  Conversely, business analysts are primarily trained in business process with an overview of application development.

Let's take a closer look at the requirements for a business analyst.

Let's Get Strategic!

Within the IT community being "strategic" and "getting a seat at the table" are common topics of discussion.  So exactly what does being strategic mean?  A good definition I've found is "highly important to or an integral part of a plan of action".  Based on this definition I think it is clear that the proper use of information technology is a strategic concern.  However, the use information technology being strategic is far different than the information technology department being strategic.  After all, we can use IT's product strategically without using the IT department.  Our customers can and frequently do use outside application and infrastructure firms to develop strategic systems.  Sometimes this is done with minimal to no involvement of the IT department.  So why isn't the IT department strategic and what can we do about it?

How We Can Become More Like "Shadow IT"

In my previous post I made my case for formal IT becoming more like shadow IT by co-locating people with our customers.  I closed that post with what I thought were two logical questions about this proposal:

1. Just exactly how is this co-location structured?  Are you saying we put PC techs and programmers out with our customers?
2. How do we accomplish this?  It calls for more people than I have available.

I will now try to address these questions.

Keep in mind that what I've proposed deals with our tactical duties such as PC problems, questions about how programs work, connection issues, and simple programming issues.  These are the issues our PC techs and Help Desk people deal with on a daily basis.  In our quest for efficiency we've decided the best way to handle these issues is to physically locate all these people in the IT department.  Although this centralization has made us more efficient the presence of shadow IT indicates it has made us less effective.  Our customers have taken on the task of dealing with many issues because we in IT can't or won't.

I've proposed replacing shadow IT  with formal IT people co-located or embedded with our customers.  Specifically, I suggest we disband the PC tech and Help Desk organization and move these people out to work directly with our customers.  These folks remain IT employees and take direction from IT on items of policy, standards etc.  However, they take direction from the business units in terms of what things to work on first.

Because of our previous focus on efficiency we've tended to hire people for these positions that have "depth" that is, they are narrow in their focus.  They know a lot about their specialty but don't have a lot of "width" -- knowing something about a lot of areas.  In contrast, most shadow IT folks have more width than depth.  To make this transition we will need to make sure we have a lot of communication and training.  We also need to make sure we support these people by providing a way for them to come back to centralized IT when they have questions.

The second question is perhaps the more difficult one.  Even if you are willing to convert all of the PC techs and Help Desk people you may find that you don't have enough to provide someone for every group.    Plus we've all been around long enough to know that we aren't going to be able to increase headcount either.

The first step is to figure out who currently makes up shadow IT.  Ask your people and talk to your users and you can probably get a pretty good handle on who makes up shadow IT.  In many cases, the departments are very open about who their shadow IT person is and acknowledge it freely.  In other cases, fearing a loss of service they deny having any shadow IT.  Keep in mind that not every "department" has a full-time shadow IT person.  Smaller departments either have someone who does this only part-time or more likely they use someone from a neighboring department.

The next step is to work with the business unit manager to convert some of the shadow IT people to formal IT personnel.  To do this you have to address their WIIFM (What's In It For Me) issues.  If you can show that by doing this you still provide the same service they have had through shadow IT plus the IT concerns are addressed they will be more accepting of the change.  Business unit managers understand and really do support the IT concerns as long as IT's concerns don't hold them back.  If you can demonstrate the same level of service through co-location they will support the move.  Taking people out of their budget and into IT's can also be an added incentive (again, as long as the service level stays the same).

In doing all of this don't forget to work with the Human Resources and Accounting folks.  The key point is that although IT's headcount and budget goes up, there is an offsetting decrease in other areas for no net change.

Not all departments will go along with this.  For these groups I'd suggest skipping them and implement this where you can.  Over time as people see actual result they may be more agreeable to make the switch.  In fact, you may want to roll this out a department or major area at a time to work out the issues.  This gives you the opportunity to adjust the program as you go along and to demonstrate your seriousness about making this work.

Lastly, don't forget your IT folks.  Don't blindly ship them off with nary a fare-thee-well.  This change may be difficult for them.  Support them with training, communication and support.

Co-location isn't easy.  It makes our management task more difficult.  But keep in mind, our ultimate goals is to provide better service.

What do you think about this? 

If this topic was of interest, you might also like these:

• IT Needs To Become More Like "Shadow IT"
• Or the posts in the Business Analysts / Analysis category

IT Needs To Become More Like "Shadow IT"

Go into any company with a formal IT group and you'll also find some "shadow IT" groups.  Shadow IT is the un-official IT group that people have learned to depend on to get things done.  You know the folks I'm talking about.  It's the lady 2 cubicles down from you that you go to ask questions about Excel.  It's the engineer you go to when you have a question about your PC.  It's the guy that loads a bootlegged copy of a program on your PC for you or wrote the Access database that your department's operations have come to depend on.  It's the people the IT folks dismissively refer to as "those cowboys".  It's the guy that installed the scanner for you that upset IT so much when you called them for support because they didn't even know you had a scanner.  It's not anyone in the IT group.

Shadow IT is the bane of formal IT's existence.  Just go ask your IT manager about shadow IT and watch the veins in their forehead pop out.  Shadow IT can really be a problem for a company.  The problems with shadow IT have to do how they deal with issues of:

• Documentation - Why should Sally document what she did?  She's the only one that works on it.  It's not like she might ever quit or get sick or infamously get hit by a bus.  Right?
• Backup - Backup is just a hassle. It's running on a reliable PC.  What could go wrong?
• Standards Compliance - Why bother using IT's programming or hardware standards?  It's not like we'll ever ask IT for help or want to connect to other systems is it?
• Security - Security just gets in the way.  We all know each other don't we?  Would anyone really snoop through my files for salary information?
• Testing - I've been doing this for along time.  There's no need to test.  The result look about right so it must be running perfectly.
• Inefficiencies - Sure my shadow IT activities take up a lot of time but it's more fun than what I'm supposed to be doing.   Besides, Joe the Ph.D research engineer over in the R&D's shadow IT group is helping me write a database for our department phone directory.
• Software Licensing - One extra copy won't hurt.  It's easier than going through IT and Purchasing to get a legal one.  Besides, Microsoft makes too much money anyway.
• Proper Control - Controls just slow us down.  Besides it's the IT guys not us that have to answer to the Sarbanes-Oxley (a.k.a. SOX or Sarbox) auditors.

These are all valid concerns for both the company and IT and IT managers understandably want to do something about getting this under control.  Typical reactions include doing such things as:

• Locking down PCs and limiting what users can do on them
• Issuing strongly worded memos
• Going to the boss's staff meeting and getting all the managers to agree to talk to their people about this
• Writing lengthy and detailed policies and procedures
• Complaining to the boss about what problems it is causing us
• Talking to the department manager and explain the situation to them so they understand they really need to work through IT
• Ranting to anyone who will listen about how miserable shadow IT is making your life

Despite all of these valiant efforts, shadow IT continues to thrive.  Why is this?  Perhaps it is due to:

• Accessibility - They are in my area.  They are very easy to access them.
• Responsiveness - They respond quickly.  I tell them what I need and it gets done.
• Dedication - They only work on my problems.  The only problems I have with competing priorities are from others in my group.
• They know my business - Shadow IT knows my business and what I need.  After all, when they occasionally aren't doing IT stuff they do the same things I do.
• Easy to use - It's easy to use shadow IT.  No Help Desk to go through, no project request forms, no cost/benefit analyses, no Steering Committee reviews.

The reality is that no amount of ranting and raving, or writing of policies and procedures or threats or talking with managers will stop shadow IT.  The perceived benefits are just too attractive to users and their managers.  In my opinion the only way to put an end to shadow IT is for formal IT to compete with shadow IT head-on and outperform it.  We need to have more shadow IT groups by forming them out of IT.

Doing this means changing the way we have traditionally organized and run IT.  It also means giving up some control.    In a nutshell I'm suggesting that we physically place or "embed" IT people out in the business departments and we let the business departments control what they work on and what they do.  Basically the business determines the priorities and IT controls the methods (i.e. security, documentation, standards compliance etc.) which addresses the valid concerns of each group as described above.

I should mention one clarification.  This co-location is not intended to change how strategic IT projects are handled.  Although shadow IT is often involved in strategic projects they are not they sole implementers.  The same holds true with what I'm proposing.  However, although this proposal deals with tactical issues it does impact a significant effect on strategic issues.  It is a matter of credibility.   If you don't think executives say to themselves like following your kidding yourself:

• "Why should I believe that IT will be able to successfully implement an ERP solution when they can't even fix my PC, answer my questions or Microsoft Office?"
• "How can IT talk about configuring a solution to my needs when they don't have a clue about how my business works?"

One of the biggest advantages of co-locating IT people with their customer is how closely linked they quickly become with their customers.  It is a matter of empathy and can go along way towards alleviating the concerns above.  Jeffrey Phillips at Thinking Faster recently posted on Customer Empathy Matters which discusses the need for employees to be able to develop an empathetic attitude.  Christopher Koch at CIO.com also commented on this in his blog posting Play Fair.  I feel that this is so important that I feel it is a critical key competency that I look for when hiring new IT employees.  By co-locating IT people with our customers  we greatly improve our chances at being successful at this.

So although you may agree with this approach in theory, I imagine you have some very logical questions.

1. Just exactly how is this co-location structured?  Are you saying we put PC techs and programmers out with our customers?
2. How do we accomplish this?  It calls for more people than I have available.

Please bear with me.  To avoid making this post too length I'll discuss these questions in my next posting.

If this topic was of interest, you might also like these:

• Creating Customer Loyalty
• Or the posts in the "Customer Service" category