Agua superficial

There are several roles involved with an IT project and an understanding of these will help you understand how the parts fi t together into a reasonably coherent whole. Consultants are often sold into the business analyst or project management role, because it is these that link the IT to the business.

Figure 3.1. Who does what in IT consulting?

Strategy Consulting

—McKinsey, BCG, BAH

Program Management

—Deloitte, KPMG, E&Y

—PA Consulting, EDS Board Level

—IT Strategy

Management Level

—Requirements Management

HIGH VOLUME LOW VALUE

HI-VALUE

MED-VOLUME

Implementation

—IBM —Accenture

—Cap Gemini Operations Level

—Systems Integration

Project Description Example Value IT Strategy Understanding how IT can

help an organisation get to where it wants to go. fi rewalls be positioned in relation to its customer data? the core of a company’s communications and data.

Do HRM and Payroll share consistent information? How is this data to be shared?

Low

Systems integration

Pulling together disparate company systems so they work effi ciently and effectively together.

How can a company best integrate its customer

How can Vodafone create a betting product?

Medium

Information management

Ensuring the right data is in the right place at the right time.

How can accurate predictions be made with regard to customer purchases?

Medium

Table 3.8. Types of IT consulting project

The roles include:

Business Owner/Product Manager: this person “owns” the project for the business. They

•

ensure that the business is satisfi ed with whatever is being developed in terms of costs, functionality, and users.

Project Manager—plans and organises the projects resources (including the people) so

•

that the goals are successfully achieved. The level of project manager varies consider-ably: in some projects it is a secretarial/administrative role, in others it is a senior man-ager with responsibility for the budget.

Business Analyst—fi nds out the business needs of the project by talking to the various

•

stakeholders and product managers. The business analyst records these requirements and ensures that they are communicated, managed, and prioritised throughout the project. The business analyst attempts to provide a bridge between the business needs and the overall system requirements.

Systems Analyst—ensures the system design meets the requirements of the project

•

effi ciently and effectively. He or she ensures that the structure, data fl ows, and integration of the system are clear and logical. The systems analyst attempts to provide a link between the business requirements and the actual technological implementation.

Technical Architect—these are the people who actually get their hands on the

•

technology: the hardware, networks, and systems that are required to build the project.

Systems Architect—focuses on the high-level systems design, mapping how the project

•

components integrate with the wider organisation and ensuring that the overall design is light, logical, and effi cient.

Coders—write the code that the system, product, or application relies upon. In the late

•

1980s and early 1990s this role could demand high salaries. However, increasingly, this work is being outsourced to cheap overseas providers.

Under many systems development methodologies, the Product Manager/Business Owner will help defi ne the business requirements with the business analyst, who will then work with the systems analysts to defi ne what the IT systems should do. This then, structures the work for the coders and the technical architect (see Figure 3.2 below). The project manager and the systems architect act as a link between the project and the rest of the organisation. There are, of course, alternatives to this fairly structured model, but the skills and roles involved tend to remain the same.

IT consulting doesn’t require you to know a lot about IT. In fact, the best consultants have not come up from the coding route, because this allows them to focus on the busi-ness and what it needs rather than focusing on the technology and what it can do.

—IT consultant, large IT consultancy

Figure 3.2.

Product Manager

Business Analyst

Systems

Analyst Technical Architect Coders Project Manager

Systems Architect Business

Need Deliverable

Project Team

It’s the Business, Stupid . . .

There are several reasons why IT consulting interventions fail, but one of the biggest reasons is when they are not driven by clear business requirements. There is a tendency for some students to see IT as a special, unusual, and often mystical art. However, this representation does the success rate of projects no good at all. In reality, IT should be a second- or even third-line support to the business. In other words, once the business strategy has been decided and the marketing, operation, and sales strategies have fallen into line, the IT strategy (along with HR Strategy and Procurement Strategy) should simply support the business aims as effectively as possible. When this prioritisation of the business case is forgotten, IT projects fail. Companies are left with over-complicated products, excessive billing costs, and unmanageable projects.

Clients, especially those unaccustomed to IT projects, will often believe that consul-tants will come in, deliver the IT, and then leave the system operating itself. In this case, it is the consultants’ duty to inform the client that an equal effort needs to be invested in the business processes to support the IT processes with questions such as these:

Who will maintain the system—when and how?

•

What is the security policy—how is it enforced?

•

How will changes to the system be managed—and by whom?

•

What happens when the server catches fi re?

•

When a consultant presents an IT proposal, it should be treated like any other business proposition. A good client will want to see a quantifi able return on investment over a spe-cifi c timeline, they will demand penalty clauses for overruns and failures, and will want to ensure that their own staff are trained in how to operate the system. All of these issues present an opportunity for a well-prepared consultant.

To this end, therefore, it is important to understand the business rationale of typical IT projects. For example, Content Management Systems are primarily about adding value to assets, Supply-Chain Management should be concerned with reducing costs, CRM systems should focus on selling more products, and e-business must, at the end of the day, be about profi t. In other words, all IT projects are about basic business sense: reducing costs, increas-ing sales, and maximisincreas-ing effi ciency.

For this reason, the business requirements of any IT project must be used as the back-bone of the project. Business requirements are the detailed specifi cations of what the busi-ness wants out of a project. These must be collected from the marketing/product side of the business and clearly communicated to any technical consultants working on the project.

Requirements need to be prioritised, costed, and categorised (e.g. functional, fi nancial, technical). On its completion, the success of a project will be tested against how many of its requirements have been achieved on time and under budget.