TECHNICAL AND VOCATIONAL TEACHERS’ COLLEGE

PROGRAMME: DIPLOMA IN ICT WITH EDUCATION

COURSE: PAM 310 PROJECT MANAGEMENT

UNIT 3.1: ORGANIZATIONAL CONTEXT OF IS DEVELOPMENT

Aims and objectives

The aims of this lecture are to:
• Show an understanding of project roles and responsibilities
• Define a Business Case

3.1 INTRODUCTION

It would be unprofessional for a project to be undertaken without first establishing a

business case for it. Without, in other words, showing that it is justified. The business
case defines what is to be done, why, and what are the timescales and costs involved.

Whether the project manager is involved in creating the business case depends on the
organization concerned. In some organizations, the project manager is appointed early in
the lifecycle and so would have a major input to, even if not total responsibility for, the
business case. In other situations the project manager may be appointed only after the
business case has been approved and the project has got the go-ahead.

However, in either situation, project managers need to have a good understanding of what
goes into a business case, as, once the project starts, they will have a major influence on
whether the business objectives are achieved and these will be used by stake-holders to
measure success. At some time or other, most project managers are asked either to
provide input to, or to review, business cases.

Once a project is under way, its progress should be measured against the business case to
make sure, for example, that costs or timescales are not being exceeded or that business
benefits are not being eroded. The business case thus provides the base for business-level
monitoring and control and, ultimately, for assessing whether the project was worth
undertaking at all.

3.2 FORMAT AND CONTENT OF A BUSINESS CASE

The format of business cases varies quite widely between organizations. Some like to
have multi-volume documents, with all the facts and figures carefully recorded, whereas
in other organizations a single-page format is mandated. (Although the latter may seem a
rather cavalier approach to what can be major business decisions, it should be borne in
mind that the only people who can make such decisions are usually (a) very senior and
(b) extremely busy and hence do not have the time to wade through vast business case
documents. Such people need the basics presented simply, briefly and clearly. If a large
document is inevitable, then even more attention has to be paid to the management
summary, of which more shortly.)

1
The fact that the format varies extensively, the content of a business case is rather more
predictable and, the following are the major elements that are needed in all business
cases:

3.2.1 Introduction and background

Most business cases opens with a short introduction setting out what the document is
about and sketching any background to the proposed project. This may refer to previous
work, particularly if a feasibility study has been undertaken to justify the project.

3.2.2 Management summary

The management summary is the most important part of the business case. As we have
already seen, the people who can make important business decisions are usually very
busy and so the management summary is the first part of the business case they will turn
to and perhaps the only part of it that they will read properly. So, it is vital to make the
management summary sharp, punchy and clear.

We have seen so-called management summaries that ramble on for dozens of pages and
we have wondered who the writers think will read it all. Although not always practical,
the ideal management summary would have three paragraphs only:

3.2.3 Description of problem or opportunity

This section offers a description of the problem that the project is designed to solve or the
opportunity it should address. Although enough detail needs to be provided to enable the
decision-makers to see what is the point of the project, brevity is again the ideal here.
Often, decision-makers complain that they have to read dozens (or hundreds!) of pages
that tell them what they know already.

3.2.4 Options available and considered

In most cases, there are various options that could be proposed to deal with the problem
or opportunity including, of course, that of doing nothing at all.

Those that are not to be recommended should be described briefly and the reasons for
rejecting them should be made clear. The option that is to be recommended should be
described in more detail, to allow the readers to see what exactly is being proposed.

3.2.5 Cost/benefit analysis

The cost/benefit analysis part of the business case presents a description and, where
possible, a quantification of the costs of carrying out the project and of the benefits that
are expected to flow from it. Costs and benefits are:

• Tangible (which means they can be reasonably quantified in some way)

• Intangible (which means that they cannot be so quantified)
Many business cases fail because of the careless treatment of intangible benefits. With
intangible benefits it is usually better to explain what they are and to let the decision-
makers place their own valuation them.

2
Getting reliable information on costs and benefits can be challenging, and input from the
organization’s management accountants is invaluable here. Costs for elements such as
new hardware or packaged software are usually not too difficult to obtain, but some sort
of preliminary project plan may be needed for the costs of systems development work.

3.2.6 Impacts and risks

Impacts may have costs associated with them but they also include hard-to-quantify
things like the need to adopt a different management culture or to manage suppliers in a
different way. Impacts, in short, are changes in the way an organization thinks and acts
and are worth spelling out in a business case so that the decision-makers can judge
whether the proposed changes are feasible or not.

All projects involve risk of some sort, In a business case, an outline of the principal risks
associated with the recommended option (and also, perhaps, of doing nothing), together
with the proposed measures for either avoiding or mitigating them, will raise the
confidence of the decision-makers that the proposal has been considered from side to
side.

3.2.7 Conclusions and recommendations

Finally, the recommended way forward should be described and the decision that is
needed should be set out clearly.

3.3 PRESENTING THE BUSINESS CASE

Once the components of the business case have been assembled, they need to be offered
to the decision-makers in an attractive and influential way, in the form of some sort of
written document often supported by a formal presentation.

If giving a presentation, remember that a presentation is usually a supplement to a written

report, not a substitute for it. The format of the presentation should follow that of the
management summary: describe the problem, outline the options, present and ‘sell’ the
proposed solution. The presenter(s) should select the main points to present but have the
full ‘chapter and verse available to answer questions and to enlarge on topics if requested.

3.4 PROJECT ROLES AND RESPONSIBILITIES

Here we shall examine the principal roles encountered within an information systems
project. In real projects, the people concerned may not be known by these titles but it is
important to establish who they are nevertheless. The figure shows an organization chart
containing these roles. but this is only a typical example and actual organization
structures will vary from this generic example; in many cases, roles may be combined,
especially on smaller projects.

3.4.1 Sponsor

The sponsor is the person who is accountable to the business for the investment
represented by the project and for the achievement of the project’s business objectives.

3
The sponsor therefore will:

• Define the business aims of the project.

• Justify the project to the board, or whatever the overall management body is
called in the particular organization.
• Define the project’s objectives and its priorities in terms of the ‘triple constraint’
of time, cost and quality/performance.
• Specify the minimum requirements that the project must meet if it is to achieve its
business objectives.
• Obtain approval for any capital expenditure involved. Initiate the project and
appoint the project manager.
• Monitor the progress of the project from a business standpoint.
• Monitor also the business environment to ensure that the project still meets the
business needs.
• Keep the board or higher management informed of progress.
• If necessary, terminate the project.
• Account for the success of the investment.
• Provide high-level support as a champion for the project.

The sponsor is thus the ‘owner’ of the project as a piece of business and the sponsor will,
ultimately, be responsible for its success or failure in delivering business benefit to the
organization.

The sponsor does not necessarily need to be a user of the proposed system and, in some
ways, it is preferable if the sponsor is not, as they will then be better able to make
disinterested value judgments on whether a particular feature or facility is essential. The
sponsor must, however, have the necessary authority to make major decisions on the
project and this implies that the sponsor should be a senior manager or director in the
organization.

3.4.2 User

The user is the person who will make use of the facilities of the system in their everyday
work and is therefore the person most directly affected by the project. The user will:

• Define the detailed requirements for the system to the developers.

• Review the developers’ specification to ensure that it supports the business
functions or requirements.
• Work with the developers in introducing the system into the organization.
• Conduct, or at any rate witness, the acceptance tests to ensure that the system
meets its specified requirements.

The user therefore requires a detailed understanding not just of what processes are to be
included in the system but also of how they work. This often means that there is not one
but several users with whom the project team must communicate in order to define the
system. Inevitably, different users will have different requirements of the system and they
will also adopt varying attitudes towards it, from warmly supportive to overtly hostile.
The developers will try to reconcile these differences themselves but, at the end of the
day, it may be necessary to refer contentious issues to the sponsor for resolution.

4
3.4.3 Project manager

The project manager is appointed by the sponsor and is responsible for the management
of the project on a day-to-day basis and for the achievement of the project objectives. The
project manager’s role is to:

• Achieve the project’s objectives within the time, cost and quality/Performance
constraints imposed by the sponsor.
• Make or force timely decisions to assure the project’s success.
• Plan, monitor and control the project through to completion.
• Select, build and motivate the project team.
• Keep the sponsor and senior management informed of progress and alert them to
problems especially if these could have an impact on the project’s achieving its
business objectives.
• Recommend termination of the project to the sponsor, if necessary.
• Serve as the principal point of contact between the sponsor, management and
contributors.

2.4.2 Risks manager

Risk management may be a significant part of the project manager’s work and it may be
necessary to appoint someone to assist with this. The project manager retains overall
responsibility for project risk but the risk manager will control the process of identifying,
classifying and quantifying the risks and for chasing people to carry out their risk
reduction actions

3.4.4 Quality manager

It could be worthwhile to appoint someone as quality manager. Under the guidance of the
project manager, this person will write the quality plan, develop the quality control
procedures, check that these procedures are being followed and provide advice and
guidance to team members on quality-related issues.

3.4.5 Analyst

This is an experienced business or systems analyst who will, under the direction of the
project manager, lead the analysis work. The analyst will advise the project manager and
project team on analysis methods and techniques and, with the quality manager, ensure
that appropriate standards are being followed. It is useful to have as an analyst someone
with extensive experience of the type of business being studied who can authoritatively
discuss business issues at the highest levels in the user organization.

3.4.6 Database administrator

The database administrator will be the principal custodian of the database and of its
supporting data dictionary. The database administrator will develop and enforce
standards for the use of the database product, the naming and placement of data items and
so on. Usually, the database administrator will work closely with the designers in the
development of the design and with the programming teams in using the database

5
3.4.7 Team leader

The project manager is responsible for the overall direction of the project, but detailed
management of the staff is often delegated to a number of team leaders. Typically in
charge of a small group of, for example, programmers, team leaders plan and direct work
on a day-to-day basis and either review or organize reviews of the team members’ work.