Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. Benefits, however, are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.

In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.

In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived this as eventually leading to lay-offs, this could kill a project because you almost always need those people as the business experts  for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.

In the previous chapter we saw the difference between a business use case and an application use case. In this chapter we discuss a process for deriving impacted AUCs from a BUC.
5.1    Overview

The BUC includes business process steps making up its workflow. Each of these steps has the option to be automated. The business analyst (BA), systems analyst (often the same person), systems architect and business process owners (BPO) determine between them which steps are to be automated. The systems analyst and architect roles are mainly to determine the time and cost to automate the business process. The BA and BPO will determine the return on investment (ROI) in order to determine if there value in automating a business process.

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc… The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

Estimating the cost of IT projects is a whole discipline in of itself. I highly recommend the writings of Vitalie Temnenco on this topic, such as “Software Estimation, Enterprise-Wide - Part I: Reasons and Means (June 2007), at

 http://www.ibm.com/developerworks/ration… ,

What are the tasks that should the business analyst leader do when assigned into big e-services project? In addition what the Business Analyst Leader should do in a project from business perspective and leader ship perspective?

Any company, and its IT organization, has a limit on the resources it can use on projects, so it has to choose, and choose wisely, from all the ideas and opportunities it may have before it at any one time.

The term that has emerged to describe this is Project Governance.  The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development. As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the company.

One of the most important considerations when interviewing for a business analyst position is the perspective of the hiring manager. This person is most often the person in the hot seat to decide whether or not you are hired.

Hiring managers can have varying perspectives. Their point of view will depend on:

• The scope of their responsibilities—do they oversee just BAs or multiple areas of responsibility?
• Whether or not they have been a BA before.
• The pluses or minuses of previous people they’ve hired into a BA position.
• The strength or weakness of the business team.
• The strength or weakness of the technology team.

Oftentimes you can read into job descriptions to find hidden information about perspectives. Lines like “will ensure we stay on scope” or “will keep the development team on track with requirements” often brush over some of the core issues the manager is trying to solve by hiring a new business analyst or filling an open role.