IT Business Analyst: Benefits to the Enterprise

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

There have been many “hot” jobs over the years in IT, from Novell engineers to Windows admins and Cisco gurus to security experts. The job function with the best chance for long-term staying power, over time, across technologies, is the powerful new job role of the business analyst.

It is a well-known (but questionably true) fact that many IT projects fail. In recent years, rather than simply lashing out against IT, many businesses have started taking a look at why projects fail. They typically found the same key issues. According to leading IT business analysts, the top 10 reasons are:

 

 

  • There is a lack of user input: The project commences, people begin working diligently, but when the project is completed, the people wanted a horse and we built a camel.
  • Incomplete requirements and specifications: We build a terrific solution and after we submit it for user testing, we are told that it doesn’t do half of the things they need…and we were never told any of these requirements. Rebuild takes four months, and we miss project timeline and budget.
  • Changing requirements and specifications: Every two weeks during the project, sales manager Bill would appear and ask for a new set of features to match something he read in a book yesterday. Ten scope changes and $400,000 later, the project misses badly and everyone in IT is blamed because Bill didn’t make his sales numbers.
  • Lack of executive support: The project doesn’t get the people or money it needs to proceed successfully because the project isn’t seen as important by senior executives in the company.
  • Technology incompetence: To save a few dollars, parts of the project were outsourced to people who didn’t understand the technologies we were using. When the first review of their components came in, the entire component had to be rebuilt from scratch.
  • Lack of resources: The project was very important, but cash and people were tight, so IT was told to fit it in around their regular schedules. In the end, the project collapsed for lack of focus.
  • Unrealistic expectations: The new sales application was designed to gather important information to save the company. But having a great sales tool wasn’t going to do any good if the salespeople refused to use it and thus didn’t provide the company the information they needed to stay ahead of the competition.
  • Unclear objectives: The new network upgrade worked perfectly, and all of the infrastructure was in place, but because the company was hoping to save money, not improve performance, they dismantled a perfectly working infrastructure and outsourced everything to an organization providing half the services to save a few dollars.
  • Unrealistic timeframes: The new customer-relationship management tool was critical to the long-term performance of the university, but only six months were allocated to get everything installed and working and get all the people switched over to the new system. Ninety percent of the potential benefits were lost due to the timeline.
  • New technology: The project depended on a small, private company with a new technology with lots of potential but no track record. Six months into the project, the company was out of business, the software was no longer supported, and there were undocumented bugs everywhere that no one could find.

 

Enter the Business Analyst
The business analyst has a critical role. According to the Wikipedia entry for business analysis, “Business analysts contribute by analyzing objectives, processes and resources, and suggesting ways by which redesign or improvements could be made. Particular skills of this type of analyst are ‘soft skills,’ such as knowledge of the business, requirements engineering, stakeholder analysis, and some ‘hard skills,’ such as business process modeling.” In short, they must have a broad and deep understanding of the business, its needs and requirements, and be able to see possibilities for dramatically improving the delivery of services to the customer. The work of the business analyst spans the entire lifecycle of projects, and ultimately their impact is measured in whether the right projects are executed and deliver the best outcomes for the business.

The business analyst is ultimately responsible for delivering the benefits to the business. Therefore, the business analyst must forge an extremely strong relationship with the project manager. In many ways, the business analyst is responsible for making sure the project manager has the correct charge, the right people and resources, and the right information to make the project deliver results. This involves setting the right communications processes in place, capturing and effectively documenting all of the business requirements, facilitation, effective decision making, issue management and quality assurance.

Communications issues doom most projects. The business analyst is ultimately responsible for making sure that information is effectively distributed and understood by the working team. Verbal communications are not just about the content of what is said, but largely about tone and other nonverbal cues. Ensure people have a clear understanding of what you’re trying to say, and reiterate at the end to make sure they got the key points. Written communications are prepared for the benefit of the reader, not the writer. Keep it clear, simple and to the point. Have a (single) purpose and stick to it. If the written communication is e-mail, be doubly careful.

Most IT professionals don’t like documenting things. There are understandable reasons for this:

 

 

  • It means someone else can pick up on your project, and they might not “need” you.
  • It might be distracting you from other work on the project you want to do.
  • It allows other people to get a sense of what you’re doing even if they don’t understand the technology.
  • IT professionals prefer brief, verbal, informal communications.

 

All of these are somewhat true and understandable, but they detract from the ability of the whole team to deliver results. Technical gurus who won’t document anything aren’t less at risk for being moved to other projects or laid off. They are actually much more at risk because they aren’t seen as team players. Documentation takes less time than explaining your code to someone even once, so for those of you who think you’ll save time by not documenting, it’s been proven over and over again that even on a personal level, you’ll lose more time explaining than you would if you just documented in the first place. Other people who don’t understand the technology do need to understand what you’re doing, so that they can appreciate (and ensure others appreciate) the work you do. Lastly, informal is good, but document what you do so that others can benefit. Where would we be without open source docs? It’s part of IT culture now to document for others.

As a business analyst, it is imperative to lead and support a culture of high communication and documentation. It will save you and your team time, money and long weekends.

Requirements Analysis
Simply put, a majority of the defects in most IT projects occur during the requirements phase. Having a clear understanding of what is needed is essential in helping deliver successful business benefits. A business analyst works to develop three levels of requirements: the business requirements, user requirements and tool requirements.

Business requirements include business goals, measurable objectives and a detailed needs analysis for the business. User requirements include prioritization of capabilities, owners of key information, and the speed and usability of key components. Tool requirements (hardware/software requirements) translate the functional requirements of the business into technical requirements that can be used by the project manager and IT teams to bu

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>