Cadle, J. & Yeates, D. (2008). Project Management for Information System.
5th Edition. Pearson: Prentice Hall.
………………………………….
Part One: The Business Context
Chapter 1: Types of information Systems Projects (Pages 3-14)
There are nonetheless ways in which the different types of IS project do diverge from
one another and which we need to address before getting into the detail of IS project
management. We have grouped IS projects into nine broad types:
1. Software development
In principle, development projects have a lot in common with other types of construction
work, and most of the traditional project management methods and techniques are
applicable. The managers of software projects need:
n Flexibility of approach in being prepared to revisit the specification and negotiate with
the customer as the project proceeds.
n Well-developed interpersonal and stakeholder-management skills. (Cadle & Years,
2008, p.4)
2. Package implementation
3. System enhancement
There are some particular issues that face the manager of a large enhancement project,
including:
n The difficulty of keeping the existing system operational while work proceeds on the
enhancement.
n The fact that the developers involved in the enhancement are often also engaged in
supporting the system, when it can be hard to balance and reconcile the competing
demands on their time.
n The need for rigorous ‘regression testing’ to ensure that the new enhancements do
not damage parts of the existing system that were working well. (Cadle & Years, 2008,
p.6)
4. Consultancy and business analysis assignments
Some IS projects do not involve developing or installing anything tangible at all.
Sometimes, they are about investigating a business issue and proposing solutions using
information technology. Such consultancy and business analysis assignments are
nevertheless projects, although they do pose some peculiar difficulties from a
management perspective:
n We have already seen that software is, by its very nature, rather intangible and
therefore difficult to estimate, plan for and control. This is even more so with
,consultancy and analysis work where the customer’s need may be for someone to look
into an issue where they (the customer) are not quite sure what the problem is or where
suitable solutions may be found.
n Because of this, the budget and timescale for the project ought to be fairly flexible.
However, often, the customer wants an ‘answer’ by some deadline and the problem
now becomes one of expectation management; making sure the customer understands
the limitations of what can be achieved within this constraint.
n It is hard to fix the scope of consultancy projects – what is included and excluded.
Indeed, the investigation work itself may reveal that the original boundaries of the
project have been drawn too narrowly and will have to be expanded if worthwhile results
are to be achieved. The scope will therefore have to be managed flexibly and carefully
and the project manager needs to tread a fine line between, at one extreme, being seen
to stick too rigidly to the original brief and, at the other, being accused of trying to
expand the job, presumably to increase the value of the consultancy work. (Cadle &
Years, 2008, p.6-7)
5. Systems migration
This type of project is one where an existing operational system has to be moved to a
new operating environment – perhaps because the current one is now longer supported
or supportable. There may be some software development involved, because the new
platform does not work exactly like the old one, and it may be necessary to create
interfaces with other systems. There may also be infrastructure implications, for which
see the next section, to consider. It might also be necessary to carry out some limited
retraining of users to enable them to utilize the new environment. From the point of view
of the system’s users, the project’s success will be judged by the smoothness of the
transition and the lack of interruption to their workload.
6. Infrastructure implementation
This type of IS project includes ones to introduce or replace hardware, servers or PCs,
for example, to put in place communications infrastructures and also sometimes the
physical construction of things like computer suites or the fitting out and equipment of a
new office building. General project management principles are all applicable to this
type of project and it does have the advantage, usually, that the outcomes of the project
are nicely tangible – unlike, as we have seen, some other IS projects. However, there
are some issues that managers of this type of project need to consider, including:
n Usually, the need to maintain ‘business as usual’ whilst putting in place the new
infrastructure. This can be tricky where, for example, there is limited space for old and
new to sit alongside each other.
n Supplier management features heavily in these projects, as most of the work is
usually subcontracted and all of the equipment is bought-in. It therefore becomes
especially important to establish firm and realistic timescales for delivery and to
examine carefully the interdependencies between tasks, as otherwise time, effort and
,money can be wasted waiting around for things to be delivered or completed. (Cadle &
Years, 2008, p. 7)
7. Outsourcing (and in-sourcing)
The reasons for outsourcing IT provision in an organization are many and various and
have been discussed and debated widely over the past decade or so. They include:
n The wish to gain access to the pooled expertise of the outsourcing providers.
n Difficulty in managing the IT estate internally.
n A desire to reduce costs, through economies of scale or by taking advantage of lower
labour costs elsewhere.
n The need to reduce employee head-count.
n A wish to put the provision of IT on the same basis as that of other essential ‘utilities’
such as gas or electricity.
n The belief that IT has become commoditized and no longer provides a source of
competitive advantage.
n Long-term dismay by general managers over the costs of IT and the seeming
impossibility of controlling it. (Cadle & Years, 2008, p. 8)
8. Disaster recovery
We have highlighted this last type of project because, although timescale is an essential
element of any project, it is especially so when there has been a largescale failure and
the organization needs to get its systems back up and running as soon as possible. The
best way to manage a DR project is, of course, not to have it at all; in other words, to
put in place adequate defensive measures to prevent the occurrence of the various
threats. However, even the best defensive measures are not proof against everything
and there can always be something that the best prepared organization cannot have
anticipated.
If a disaster does occur, then pre-planning of the recovery process is by far the best
way of ensuring successful recovery; making things up ‘on the fly’ is almost certain to
lead to further problems and maybe an even bigger disaster. (Cadle & Years, 2008, p.9)
9. Smaller IS projects
it is sometimes asked ‘is all of this really necessary for a small project?’ In order to
answer this, we would say that project management is – or at any rate should be –
essentially pragmatic in nature. The approach selected should be that which will deliver
the best value for money in terms of getting the job done and ensuring adequate
control. So clearly, with a small project, it is both practical and sensible to adjust the
project management approach to the size of the project. One thing we feel should never
be skipped is the creation of a project initiation document (PID), as described in section
7.4.3. The PID establishes, for the customer and the supplier of the project, exactly
, what it is about and is designed to achieve and, without a PID in place, the chances of
argument and recrimination are considerably increased. The OSCAR format for a PID
described in section 7.4.3 need not take up more than one or two A4 pages, or more
than an hour or so to create, and yet this simple format clearly defines for all parties why
the project is being undertaken. Part of the PID covers the ‘constraints’ on the project,
including its proposed timescale, and in arriving at that the supplier will perforce have to
make some estimate for the work. But this can be a very simple estimate indeed, just
their ‘best guess’ based on their understanding of the scope/requirement – again, part
of the PID – and on their knowledge of the technology to be employed. (Cadle & Years,
2008, p.10-11)
…………………………………..
Chapter 2: Business Strategy and Information Systems (Pages 15-30)
the business context within which systems projects are created; how the strategy of an
organization determines its shape and how that shape determines the business
processes and their systems. Typical business goals might be related to profit, or
growth, or market share, but could also focus on customer services, safety or staff
development. Business goals lead to the identification of key result areas (KRAs) which
specify in turn the need for new systems. Information systems management is therefore
concerned with the development of new systems to contribute to the achievement of the
business’s key result areas. (Cadle & Years, 2008, p.15)
What is Strategy?
We can begin with some general definitions of aspects of strategy and identify the
components of an effective strategy.
