Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Project Management for Information Systems
by James Cadle and Donald Yeates

End of chapter Questions and Answers
Chapter 1 Managing change
Q1 Figure 1.7 shows how bad an implementation can become. Action needs to be taken to
prevent this kind of situation. What would you recommend should be done?
This model is about how badly wrong the development and implementation can
become, but it applies equally to the imposition of change. The secret lies in
preventing this situation from arising by
Making sure that everyone understands the reasons for the change
Has the opportunity to play a part in influencing the shape of the new situation
or system
And doesnt have to deal with so much change that there are no anchor points
for those involved.
Q2 You are the project manager for a new management accounting system that will
provide monthly profit and loss accounts to a chain of 30 computer dealerships, each of
which is franchised to its local owner/manager. They have all done their own accounting
before. What change issues would you expect to encounter? Does the fact that they are PC
dealerships make any difference? Why might they have joined together in the chain?
Several change issues will arise;

the imperative to change? Why does the franchise owner want to impose this
change if indeed it is being imposed?
meeting the many and varied individual needs
the implementation process
the changeover process
post implementation support
the nature of the franchisees response and the resistance if any
In principle, the fact that they are PC dealerships should make little difference, but
they will be well aware of the problems of changing over from one software system to
another, and interfacing it to other existing systems.
The dealers probably joined the franchise network in the first place to share
purchasing, advertising and marketing costs. They may pay the franchise owner
according to their success, in which case the new system may have a big impact on
them as it will declare financial information in a consistent manner across all
franchisees and reduce the opportunity for creative adjustments by the franchisees.
Q3 Consider the organisation that employs you or where you study. What is its culture?
Why does it have that particular culture? What organisational culture would give you most
satisfaction as an employee? Where might you find such an employer? Given your
preferred organisational culture, what would it mean for you as an employee in terms of
your responsibilities and obligations?
Two models for analysing culture have been described in this chapter. Identify your
organisations culture using these models. Work with others if you can. The culture
may be the result of deliberate choice or may have arisen by accident. The key
Qs and As Page 1 of 35

question is whether or not it moves the organisation forwards in an efficient way
towards the achievement of its goals.
To identify a culture that suits you, first work out what you want from your work and
from your employer. Do you like freedom to get on with things, the opportunity to be
creative, and do you have an urge to make changes all of the time. You do? Then an
Apollo culture may not suit you. The is no inherently good or bad culture just
different ones, so choosing one that suits you is a personal choice that doesnt come
with value judgements attached.
Q4 You have to design a hearts and minds programme connected with the
implementation of a new system for the recording and management of stock in a bookpublishing company and for the supply of books to booksellers. What would be the main
stages of such a programme?
A good place to start is with the reasons for the implementation of this system. If it
aims to reduce stock holding costs for the publisher but may lead to delays in shipping
books to bookshops, then the message is different from if it also speeded up or made
easier the ordering and delivery of books.
Next, make a stakeholder analysis and assess the impact of the new system on the
different stakeholders. Involve the stakeholders in planning for implementation and
think about getting key change agents from the publisher and the book trade to work
with you.
Ensure that everyone knows whats happening and that people are properly trained
and supported. Create a forum for the identification and speedy solution of issues.
Chapter 2 Business strategy and information systems

Q1 Why is it important for project managers to understand the strategy of the organisation
that uses their services?
It enables the project to be seen in the context of what the business is trying to
achieve. It means that links between this system and others under development or in
operation can be better understood and managed. It enables the project manager to
see how the project delivers value and how further value could come through the
identification of new opportunities.
Q2 If you knew about an organisations strategy, could you suggest IS applications that
would support it? For example, how could a large supermarket chain use information
systems for cost reduction, or for a strategy based on differentiation?
Systems that aim at cost reduction strategies might lead to applications development
in logistics, stock control and stock planning, or in financial management and
budgetary control, or in supplier management. Differentiation strategies might call
for TQM applications, the launch of new systems in customer care or in symbiotic
applications such as personal banking, loans and insurance.

Q3 If you had to develop a strategy for a small software house employing 50 or so
professional computer people, how would you go about it? What criteria would you use to
test whether or not the strategy was sound?
A firm of this size is probably owned and run by the top management with some
outside financial backing, so you should work first of all with this group of
stakeholders. You could take it in stages as follows;
1. Collect data. What does the management team think? What are the
companys strengths and weaknesses (use SWOT?) and core competencies?
What about competitors and markets.
2. Develop some alternatives and evaluate their attractiveness. Decide on the
kind of business they want to be.
3. Create a vision for the business and a strategy to achieve it.
4. Put the structures, systems, styles, skills, staff and shared values in place to
achieve the strategy.
To test the soundness of the strategy you could ask someone else to assess it for
Clarity. Do all of the companys managers know what to do in their

part of the business to support the strategy?
Empowerment. Is everyone enthusiastic about it and do they feel
empowered to act to achieve it?
Concentration. Does the strategy focus on the core competences of the
business?
Flexibility. Can the strategy be flexed in the face of market changes
and competitive pressures?
Chapter 3 The business case

Q1 At what point in the project lifecycle should the business case be prepared?
The short answer to this is before any serious work has been done and before major
resources are committed to the project. Many projects are preceded by a feasibility
study, the aim of which is to see whether there is a prima facie case for undertaking
the project and a business case is often a major output from such a study.
In addition, IS studies often start with some form of requirements analysis and
specification. Where this is the case, the detailed information discovered here may
necessitate a reappraisal of the business case, to make sure that the costs and benefits
identified in the feasibility study are still realistic.
In fact, the business case should be revisited at each stage of a project, to make sure
that the project is still on target to achieve the business benefits for which the project
has been initiated.
Q2 What should be the role of the project manager in relation to the business case?
Ideally, the project manager should be appointed early enough to contribute to the
development of the business case or even to take the lead in its development. At the

very least, someone with a project management background should be asked to review
the business case to make sure that the approach proposed is realistic.
If the project manager has not contributed to the creation of the business case, then
one of his or her first jobs after appointment should be examine it and to satisfy
themselves that they are happy to take responsibility for the project. If they think that
the scope, budget or timescale is unfeasible, they should raise their objections with the
project sponsor and endeavour to negotiate a more realistic programme.
Once the project is underway, the project manager needs to keep a watchful eye on the
business case to make sure that the way the project is going is not going to
compromise the achievement of the benefits outlined in the business case.
Q3 Explain the term cost/benefit analysis
Cost/benefit analysis is the process of identifying, and as far as possible quantifying,

the costs of undertaking a project and contrasting these with the benefits expected to
flow from it. For a project to be approved, senior managers will have to be convinced
that the benefits outweigh the costs.
Q4 What do you understand by the terms tangible and intangible when applied to costs
and benefits?
Tangible costs or benefits are those for which a plausible quantitative value can be
calculated, such as increased profits or reduced staff costs. Intangible costs or
benefits are those where it is not practical to calculate a quantitative value.
In theory, almost anything can be quantified, given enough time and the right
resources to do the analysis. For example, improved public image could be
measured through opinion polls or surveys and could even, perhaps, be linked directly
to sales figures. However, in most cases, the expert resources are not available to do
the research and, in any case, the results are often debatable and sometimes not
believed by the decision makers. It is generally better, therefore, when dealing with
intangible costs and benefits to explain in the business case what they are and to let
the decision makers put their own (subjective) value on what they might be worth.
Q5 What is meant by the term benefits realisation and why is it important?
Benefits realisation is the process of managing a project and the post-project

operation of, for example, a new information system so as to maximise the chances
of getting the benefits claimed in the business case. All projects should be followed,
after a suitable interval, by a post-project review, the main aim of which should be to
find out whether the expected benefits have been realised or not.
Chapter 4 The organisational framework

Q1 How many different types of customer may there be for a systems development project?
Who are they? What kind of relationship and reporting arrangements should the project
manager have with the sponsor?

Depending on the specific project, the customers could include some or all of the
following:
The management of the organisation that has commissioned the project, who will
be interested in the achievement of the benefits described in the business case.
The users of the proposed information system, who will probably mainly be
interested in its effects on their jobs.
The end-customers of the organisation commissioning the project, who will be
interested in how it affects the customer experience.
Managers and others in other departments indirectly affected by the project.
The sponsor of a project represents the management of the organisation that
commissioned it. Thus, she or he is THE customer for the project manager and it is
important that they have a good, frank and effective working relationship. The
sponsor and project manager should agree between themselves a suitable timescale
and framework for reporting but, typically, this would involve a regular written report
supplemented by a meeting where issues can be discussed face-to-face. The
frequency of reporting will clearly depend on the overall size and timescale of the
project; one with a total duration of a month or so will probably require weekly
reports but, for a project spanning several months, a monthly reporting cycle may be
sufficient.
Q2 Describe the roles of (a) the sponsor and (b) the project manager
(a) The sponsors role is to represent the organisation commissioning the project and
to make the major business decisions concerning it. The sponsor should approve the
original project initiation document and decide on any subsequent changes of scope.
The sponsor is also the internal champion of the project and may, on occasion, have
to knock heads together where various users cannot agree on the projects direction.
At the end of the project, it is the sponsor who must accept from the project teams the
various deliverables specified.
(b) The project manager is responsible for the day-to-day management of the project
within constraints laid down by the sponsor. It is a good idea for the project manager
to be given some tolerances within which to operate for example, a completion
deadline of 1st March with permission to delay until 1st April if necessary. Essentially,
it is the project managers job to ensure that the defined scope of the project is
delivered within timescale and budget.
Q3 What are the principal problems of managing projects within a completely functional
organisation structure?
The main problems of functional organisations are to do with what may be termed a
silo mentality, whereby people pursue functional, rather than organisational,
objectives. In addition, people may have little knowledge of or interest in things
outside of their functional specialism.
The problem with managing a project in this environment is that, if the project is run
from within one function, people from other functions may not cooperate fully with it,

or may even work to frustrate it. If the project is cross-functional, the project manager
may face interference from line managers in the various functions.
Q4 What are the pros and cons of a pure project organisation compared with a project
operating within a matrix structure
A pure project organisation contains within itself all of the resources needed to
complete the projects objectives. Thus, the project manager has the whole project
under his or her direct control. However, the project may be inefficient in its use of
resources, since one cannot have less than one resource of a particular type even if
there is not a full-time job for that person. In addition, project team members often
suffer from a feeling of insecurity, not knowing what will happen to them at the end of
the project. Finally, the project may become somewhat detached from and possibly
resented by the rest of the organisation.
A project operating within a matrix structure tends to be more resource efficient since
it is perfectly feasible, say, to have the part-time services of a particular specialist.
Team members also do not lose touch with their home functions. The main
problems with matrix structures stem from people having more than one manager,
leading to difficulties in prioritisation of effort and time management.
Q5 In a PRINCE2 project structure there are formal committees, a project board and
specific roles. What is your opinion about the value of this kind of arrangement? How do
you see it working in large and small projects? Could it be useful for projects outside IT?
The use of established roles within the PRINCE2 environment usually smoothes
setting up a project, since people get to understand what is required of, for example,
the executive on a project board. The project board itself provides an excellent
forum for the various stakeholders and customers (see question 1) to come together to
make decisions about the project. Part of the design brief for PRINCE2 was to
make it suitable for non-IT projects. PRINCE2 has been proven in practice over a
large number of large projects.
Smaller projects often have some difficulty with the PRINCE2 approach, since it
can feel somewhat bureaucratic and top-heavy in these circumstances. But it is a
tailorable approach and, for example, the project board can be reduced to two people
executive/senior user and senior supplier) if that seems appropriate. The reporting
regime between the project manager and project board can also be streamlined and
abbreviated for smaller projects.
Chapter 5 The programme and project support office

Q1 Explain why the concept of PPSO arose in the first place.
The origins of the PPSO lie in the provision of administrative support for project
managers, to take care of some of the routine tasks such as writing meeting minutes
and updating plans. In time, it was realised that this sort of support was required for
all projects and could be most efficiently supplied by having a PPSO that supports a
number of projects. This also enables PPSO personnel to develop a good

understanding of the basic issues of project management, which can be placed at the
disposal of many project managers.
Q2 What are the advantages to an organisation of having a PPSO?
The main advantages to an organisation from having a PPSO include:

Collection of information on past projects, which can be used to assist in planning
and risk management.
Consistency of approach, in terms of practices, planning and documentation,
across all projects thereby avoiding re-inventing the wheel for each new
project.
Independence, whereby the PPSO can provide a slightly different perspective on
all projects for senior management.
Specialism, where PPSO staff develop skills for example in project management
tools that can be used by many projects.
Centre of excellence the development of a central repository of guidance for
project managers and project teams.
Q3 What conflicts are likely to arise between project managers and PPSO staff?
PPSO staff can, if they are not careful or if they are not properly managed begin to
think that they are actually running projects, rather than acting as a support function.
The management of the project remains the responsibility of the project manager.
In addition, in pursuit of consistency, PPSO staff may try to impose on all projects the
same one size fits all methods and standards, where specific projects require a more
tailored approach.
Finally, where senior management ask a PPSO to audit the various projects that they
support, the PPSO can come to be seen by project managers as a police force, rather
than as a support organisation.
Q4 What skills are useful when working in PPSO?
The skills that are most useful probably include:

A logical approach to the collection and analysis of information.
The ability to draft succinct meeting minutes and reports.
Skill in using project management and other software packages.
Tenacity in getting to the real facts of a situation.
Diplomacy and tact for dealing with people involved in projects, who are usually
under a lot of pressure.
Chapter 6 Development lifecycles and approaches

Q1 You have been asked to take charge of a system development where the customer
requires about 50 per cent of the functionality very urgently to meet a business opportunity
but where the remaining functions can be delivered over the next few years. Which of the
various development lifecycles do you think would be most suitable for this project and
why?

Either the incremental or the spiral model would provide a good approach in this
situation. With the incremental approach, the whole system is designed in outline and
then developed and delivered as a number of stages. The spiral model assumes no
overall design at the outset and the system evolves as new features are introduced in
progressive stages. Which of the two lifecycles is most suitable in the circumstances
described may depend on how fully the users of the proposed system can specify their
overall requirement at this stage.
Q2 What would you say are the principal advantages and disadvantages of the sequential
approach to system development offered by the waterfall and V lifecycle models?
The waterfall approach and its V model variant offer a logical set of steps that have
to be followed to develop and implement a system. They provide good control for a
project manager as in theory at any rate each stage should be complete and signed
off by the project sponsor before proceeding to the next. This also means that each
stage builds properly on its predecessor and hence assists in the creation of a highquality deliverable. The models assist in resource deployment as it is easier to see
what skills are needed at each stage business or systems analysis during
requirements analysis, designers during the design stages, development during code
and test and so on. The V model has the additional advantage that it shows
explicitly the connections between the earlier and later project stages between
requirements specification and user acceptance for example.
The main disadvantages of these approaches are that projects undertaken with them
can take rather a long time from inception to delivery and this is often not very
suitable for modern business conditions, where change is incessant and constant.
With the linear approaches, changes that arise later in the project are difficult to
accommodate as the earlier stages should be revisited to reflect the changes. Finally,
these approaches do assume, as a starting point, that the users can specify in some
detail what they want from their new system whereas in many cases for example,
where a system is needed to meet an unprecedented business situation this is very
far from being the case. Where such uncertainty exists, an evolutionary lifecycle (the
spiral) is probably more suitable.
Q3 Some critics have said that the use of structured methods, such as SSADM, increases
both delivery time and bureaucracy. Do you think these criticisms are justified and what
are the claimed advantages in the use of structured methods?
It is true that structured methods require more work to be done up front in a project,
during the analysis and design stages. The formality and rigour that their techniques
impose require analysts to get down to more detail than often happened using
traditional methods. The upside of this, of course, is that there is greater clarity
about what the users want which should (a) reduce the actual work of system
construction, since programmers do not have to keep going back to the users with
questions and (b) result in a system that better meets the users' real needs.
An additional advantage of the depth and quality of documentation that results from a
structured approach is that it is easier to maintain and enhance the system once
delivered. Bearing in mind that most of the costs of an information system are
incurred after initial delivery, this can be of considerable benefit.

However, it has to be admitted that, although these advantages sound plausible, there
is an unfortunate lack of hard evidence to prove that they have been realised in
practice. To a large extent, the benefits of the structured approach are only apparent to
people who have worked in the IS field for some time, especially those involved in
maintenance and support.
Structured methods are, nevertheless, open to the charge of bureaucracy. Because
everything is documented very thoroughly, projects using structured methods can end
up accumulating a vast amount of paperwork. This, in turn, can prove very difficult to
control and lead to the project team spending a lot of time in document management
instead of in actual analysis or development. The answer to this, of course, is to find
or perhaps create, using one of the readily-available database products a suitable
CASE (computer-aided software engineering) tool.
Q4 Increasing interest is being taken in the use of rapid application development. Why is
this, and are there any dangers associated with the RAD approach?
RAD has come to prominence because of the increasing pace of change within all
organisations. The argument goes that, against such a background, the conventional,
linear approaches as represented by the waterfall lifecycle do not produce results
quickly enough. Often, it is more important to get some sort of solution quickly than
the best solution in a couple of years. In addition, the advocates of RAD, for example
the DSDM Consortium, contend that, because of the close working relationship
between users and developers that is inherent in the RAD approach, the users are
more likely to get a system that meets their real needs than with a more conventional
approach. Indeed, in recent years, RADs proponents have been stressing fitness to
purpose over speed of development.
The main dangers associated with RAD are to do with its very speed in that it leaves
little time for reflection and, if not managed tightly, less still for documentation.
Some critics have described RAD as a licence to hack. The real problems with
poorly documented systems come later in their lifecycle, when maintenance becomes
difficult and unpredictable, since the support engineers do not have adequate
information on why and how the system has been created as it is. A further potential
problem is that the part of the system chosen as a starting point because of perceived
business needs may not, in fact, turn out to be quite so central and the finished
system may be skewed as a result.
Q5 Consider how you would organise your project team for a RAD-type project. What
leadership practices would it require from the project leader and what would the team
members have to do? How, and at which points, would you involve the users?
RAD requires, for its success, a close and ongoing relationship between developers
and users. The actual organisation may depend on the skills available on the
development team, for example:
If the analysts have the skills to create software themselves, they may themselves
work with the users to create and evaluate prototypes; this represents, in effect, a
return of the old analyst/programmer role.

Otherwise, analysts and developers will have to form small joint teams to work
with the users.
A major issue for project leaders in a RAD environment is what may be called
expectation management. The users and also the developers must be kept
focused on the (limited) objectives of the stage in hand and must also be encouraged
to keep to the often-tight timescales for the stage. Users often also need convincing
that they can forego some feature in the current stage but that they will get it in a later
stage. There is often the additional difficulty that user management want something
different often less - from the coal-face users of the system and the project leader
must make sure that the views of both constituencies are considered and managed.
Users must be involved at all stages of a RAD project, from initial definition of
requirements however generalised through the development of prototypes to the
testing of the finished system increments.
Q6 What have RAD and extreme programming got in common? What are the claimed
advantages of these approaches?
Both RAD and XP have as their common aim, and as their primary claimed benefit,
the speedy delivery of system features and functionality to meet users needs. The
difference between the two approaches are mainly to do with scale and scope;
whereas RAD is about the development of entire systems, XP seems more concerned
with adding individual features. Both approaches involve developers working closely
with users to define the need (by using stories in the case of XP, by developing
prototypes in RAD) and the advocates of both also stress the need for proper
documentation of the results.
Q7 Why are approaches such as the Soft Systems Methodology, the Socio-Technical
Approach and Business Process Reengineering relevant to IS project managers?
The development of information systems does not take place in a vacuum and is not
solely a technical exercise. Information systems are created to meet business needs
and they have to be developed and implemented within the structure, processes and
culture of an organisation.
The Soft Systems Methodology takes a holistic view of systems, regarding a
business system (human activity system in the SSM terminology) as something that
takes place within a cultural and structural context. Similarly, the Socio-Technical
approach recognises that systems cannot be simply regarded as inanimate things, and
offers concepts for placing systems in their human and organisational context.
Finally, Business Process Reengineering is concerned with the radical redevelopment
of business systems so as to improve the effectiveness and efficiency with which
inputs are transformed into outputs valued by the customer. Many BPR solutions
involve the use of information and communications technology to promote and
support these improvements.
Chapter 7 The profile of a project

Q1 What work goes on prior to project start-up?

Before project start-up, work is needed to establish the objectives and scope of the
project. It is necessary to establish the dimensions of the triple constraint of time,
cost and scope/product/quality. Where the development work is to be undertaken by
an external supplier, there may also be a process of tendering and negotiating a
suitable form of contract for the project.
In addition, the project may be preceded by a feasibility study, which is designed to
establish the business case for the project and perhaps to explore alternative methods
of meeting the perceived business need.
Q2 Describe the products that typically result from the following project stages: Project
Start-up; Analysis of Requirements; Design Integration and Testing.
Typical products include:

Project Start-Up: Project Initiation Document; Project Plan; Quality Plan; Risk
Management Plan; Configuration Management Plan. Note that these various
plans may be combined into one document, especially for smaller projects.
Analysis of Requirements: Requirements Specification (covering the
requirements themselves plus definitions of the processing and data requirements
for the system).
Design: Technical Design (include overall architecture of the proposed system,
module specifications and database schema).
Integration: individual modules combined together to create a working system.
Testing: Test results (from integration, system and acceptance tests) and an
Acceptance Certificate from the users confirming that it meets their requirements
as defined in the Requirements Specification.
Q3 Explain the incremental approach to testing represented by the sequence: unit
(module) test; integration test; system test; acceptance test.
With the incremental approach to testing, each unit (module or program) of the system
is first tested to ensure that it does what it supposed to do as defined in the module
specifications. This testing is often carried out by the programmers who developed
the modules, although sometimes a peer review approach is used instead.
The integration test seeks to find out whether the modules, when fitted together,
operate as expected and interact without problems. The baseline here is provided by
the Technical Design and by the Requirements Specification. Integration testing is
often the responsibility of a specialist testing team.
In system testing, the developers are checking that the system provides the
functionality defined by the users in the Requirements Specification. As well as the
developers and testers, the business or systems analysts may be involved here to look
at the system from a user perspective.
Finally, the users are invited to conduct an acceptance test to check that what they
have asked for in the Requirements Specification has been provided. Often, the users
require help from the business or systems analysts in performing these tests and the
project manager may also become involved to manage the process; to ensure, for

example, that the users do not introduce into the tests any criteria that were not
mentioned in the Requirements Specification.
Sometimes, because of overruns in earlier stages, it is necessary to combine the
system and acceptance tests. Although unavoidable, this is not desirable since, by
definition, all of the bugs will not have been eliminated before the system testing
(that, after all, is the point of it) and too many problems can undermine the users
confidence in their new system.
Q4 From what product should the acceptance criteria for a project be derived and why?
The acceptance criteria should be derived from the Requirements Specification, which
is where the users stated needs are documented. The actual acceptance criteria may
not necessarily be defined in the Requirements Specification, which might thereby
become too large and unwieldy, but it is important to make the requirements as
specific and measurable as possible to avoid later arguments over acceptance; for
example, a response time of less than 2 seconds for 90% of transactions is a lot more
precise than a fast response time. Since the acceptance criteria are based on the
Requirements Specification, this emphasises the importance of that document.
Q5 Why is it important that the project team and the users develop and agree a process
model for a project?
Any project is a cooperative venture between the clients/users and the

suppliers/developers and it is important that both parties have a clear understanding of
what will happen, when and what are their respective responsibilities. A process
model provides a framework so that both parties can see where they will be involved
and what their roles will be at each stage. It also highlights the important milestones
in the project and enables the stakeholders to plan their time so as to be available
when they are required.
Chapter 8 Project planning: understanding the work

Q1 Give three reasons why it is essential to plan an IS project in detail before starting
work on it.
Only the simplest projects which probably means one developer working for one
user can get away without having a proper plan of work. Even then, both parties
will probably have reached some informal agreement about the order in which things
are to be done and this does constitute a basic plan. Most IS projects, however, are
much more complicated than this and, as complexity and the number of stakeholders
increases, it becomes more and more important to plan the project in detail. Without
having a detailed plan:
Roles and responsibilities are not defined properly.
The parties involved do not have a clear and shared understanding of the activities
and deliverables involved.
Dependencies, both between activities and on third parties outside of the project,
are not explored and can lead to difficulties during project execution.

It is probably true that, important though a good project plan is, a lot of the value in
planning is that it requires the project manager to think through how they want to
approach the project and thereby end up with a much clearer idea of the approach they
are going to take.
Q2 Ideally, the requirement for an IS project would be specified in some detail before
planning begins. If the requirement is not detailed enough, what steps can the project
manager take to improve the likelihood of the projects success?
If the requirements are not specified in enough detail, the project manager may need
to make some assumptions in order to get started. If so, these assumptions needed to
be clearly documented, preferably in the Project Initiation Document, and the
assumptions should be drawn to the attention of the users and, in particular, of the
sponsor. These assumptions then form part of the initial baseline for the project and,
should the work later prove more extensive or time-consuming than assumed, the
project manager will have a good case for approaching the sponsor for more time,
budget or resources to complete it.
Q3 In essence there are two basic ways of breaking down a project into plannable chunks:
the use of a work breakdown structure or a product breakdown structure. Contrast the
advantages and disadvantages of these approaches.
The work breakdown structure (WBS) concentrates on tasks and the product
breakdown structure (PBS) on deliverables from tasks. Both methods are used and, in
fact, they can be combined so that, at the top levels, the project is broken down by
product and then, once individual products have been identified, a work breakdown is
created.
The WBS is the more traditional approach, and is the basis for most of the readilyavailable project planning software, which makes it easy to adopt and to represent on
a computer. The advantage of the PBS is that it requires a concentration on ends
rather than means and it can be somewhat easier to apply in the early stages of
planning where the actual work is unclear but the required deliverables are better
understood. In addition, once the individual products have been identified, it is
possible to create for them product descriptions that provide, as it were, specifications
of work for the individuals or teams tasked with their development.
Q4 What do you understand by the term dependency? How can project dependencies be
represented for planning purposes?
Dependency occurs when, for example, task or deliverable A must be completed

before task or deliverable B can be started. In a complex project, the analysis of
dependencies helps to identify streams of work that can be performed in parallel, thus
shortening the overall duration of the project. The normal way that dependencies are
represented is on a dependency diagram, also known as a network diagram or a PERT
chart. Microsoft Project also shows dependencies on the bar/Gantt chart by vertical
connections between task bars but this can get somewhat confusing on a large or
complex project.
Q5 Define the terms product and work package and explain how these are related to
each other.

A product is an individual deliverable from a project and it may also form a work
package if it is assigned on its own to an individual or team. More commonly,
though, a group of related products perhaps products that need to be created together
may form a work package.
Q6 Network diagrams and bar charts have different parts to play in planning a project.
Where is each of these tools used and what does it show?
The network diagram analyses and displays the dependencies between the tasks or
deliverables on a project and it is used to identify the streams of work that can be
undertaken in parallel. The bar chart shows all of the tasks placed against a timeline
to show when they are to be done. The network diagram does not show this contrast
with the timeline very well, whereas on the bar chart the dependencies between tasks
is not necessarily self-evident. The network diagram has other uses, for example in
analysing the potential effect of slippages and risks on the achievement of the
projects deadlines.
Chapter 9 Project planning: estimating

Q1 Explain three reasons why estimating for IS projects has a poor reputation and a bad
track record. What can be done about these problems?
There are a number of reasons which could be advanced, including:

High degree of innovation: Most IS projects involve some innovation and many
involve a lot of it. In these circumstances, it is difficult for the estimators to find
precedents on which to base their assessments. This is often coupled with undue
optimism about what can be achieved by when. The answer to this is to divide the
project up into its innovative and less innovative components; for the latter,
experience and perhaps data from previous projects can be used and, for the
former, ranges rather than single-point estimates can be offered.
Too early commitment: Firm estimates are often given in IS projects before a
clear and agreed Requirements Specification still less a full Technical Design
is available. Short of refusing the give firm estimates at this stage which would
be the logical course of action project managers may again have to insist on
quoting a range of estimates, shortest, most likely and worst-case.
Lack of metrics: For some reason, people in the IS community are not good at
collecting and publishing metrics even when, as in the case of COBOL
programming, there should be decades of experience to draw on. In the absence
of industry- or organisation-wide metrics-collection initiatives, project managers
need to collect data from their own projects for later use, by themselves and
others.
Lack of specialist estimating skills: Unlike, say, civil engineering, where
specialist estimators are used, in IS almost anyone is presumed to be capable of
developing a set of estimates. Project managers should, ideally, insist on the
involvement of technical people with extensive experience of the technologies
involved. They should also get more than one opinion, and use more than one
estimating method, and cross-check the results.

Q2 The analogy method of estimating is often used to produce broad-brush estimates at
the start of a project. Why is this method particularly suited to this application?
Finding an analogous project on which to base estimates does not require the detailed
analysis and work breakdowns required of other methods and so can be used to
generate an estimate fairly quickly. This is particularly suitable at the start of a project
when the decision-makers are probable more interested in knowing what ballpark
they are in, rather than having an exact calculation of costs and timescales.
Q3 The analysis effort and programming methods both rest on the principle of
extrapolating the total development effort from detailed estimates of one phase of the
project. Describe the approach taken in each of these methods and show in what
circumstances each might best be employed.
With the analysis effort method, the stage of the project that forms the basis for the
estimates is the analysis of requirements. Estimates for this can be arrived at by
considering the stakeholders to be involved, the methods to be used (interviews or
workshops for example) and by allocating sensible amounts of effort to these. The
analysis effort method is probably the best choice where there is only a vague idea of
the actual requirement but where the stakeholders to be involved in the analysis work
can be identified.
The programming method requires specialists well-versed in the technologies to be
used to take a look at the requirements and then to assess the effort involved to create
the required programs. This could be done by estimating lines of code or perhaps by
categorising programs as large, medium or small or as complex, moderate or simple.
Clearly, this method is most relevant where a Requirements Specification perhaps
received as part of an invitation to tender is available that gives a good general idea
of the programs likely to be needed.
Q4 The Delphi technique aims to achieve a consensus estimate from the efforts of a
number of estimators. How is this achieved and what is the advantage of the Delphi
technique over, for example, a round-table discussion?
The chief problem with a round-table discussion is that the personalities and egos of
the estimators get caught up in what should be a rational, dispassionate process.
People may feel forced to defend their estimates high or low because to do
otherwise would be seen to involve a loss of face with respected technical
colleagues. The Delphi technique involves asking for estimates from a number of
people and then circulating the results anonymously for all to see. Because the
estimates are anonymous, estimators will not lose face by changing their minds and
seeing other peoples estimates may well cause re-thinks. The problem with the
Delphi technique is that people cannot ask questions about how others have arrived at
their estimates and they may thereby miss some important issues that others have
considered. Barry Boehm (see earlier) found that a combination of the Delphi
technique with well-run workshops tended to produce good results.
Q5 Describe how you would go about estimating for the following supporting project
activities and why you would take your chosen approach to each.
a) Project management

b) Team leading/supervision
c) Quality control
d) Familiarisation.
a) Project management effort is dependent on two things whether a full-time

project manager is to be used or not and the overall expected duration of the
project. If a full-time manager is required, then one simply multiplies the duration
of the project by four to get the number of days effort involved (see the main text
for a discussion of why only four days a week is available for each person over the
long run). If a half-time project manager is to be used, then the number of weeks
is multiplied by two and so on.
b) Team leading can be worked out using the rule of thumb that a team leader can
effectively supervise up to five programmers. So, one starts with the total
programming effort and divides by five to get the amount of team leading. With
some of the newer, high-productivity programming environments, a ratio of 1:4
for team leading may be more appropriate.
c) Quality control can be added as a percentage on top of each doing activity like
creating programs. In working out what percentage to use, it must be remembered
that quality control review often lead to rework which must also be included in the
estimates.
d) Familiarisation is best calculated as an allowance (a number of days) per team
member, based on their prior understanding of the business and technical
environment.
Q6 State three factors that could influence the estimates for an IS project and how you
would attempt to adjust the estimates for these factors.
Relevant factors include:

Staff experience: In IS, the productivity of people, especially developers, can vary
widely, largely but not entirely depending on their experience. Often, estimates
are made on the assumption that fully-experienced personnel will be assigned to
the project and then a team of newly-trained people is provided instead.
Experience does not just mean technical expertise either; equally important is
experience of the business area in which the proposed information system will
operate. In developing the estimates, therefore, it is important to find out exactly
who will be assigned to the project and/or to create alternative estimates based on
varying levels of skill within the project team.
Use of contract staff: These are often an unknown quantity. It is reasonable to
assume that people who can make a living freelancing in specific technologies
have a reasonable grip on those technologies but this cannot be guaranteed. In
addition, contractors may not be familiar with the methods and standards used in
the organisation and there may be a lot of rework required to get their work in line
with those of employed staff. Before committing to any estimates, it is wise to

interview any proposed contractors and to form an opinion as to whether any

adjustments to the timescale may be needed.
User involvement and support: The commitment of users and user management to
the project cannot be assured and many projects get behind schedule because users
cannot find time to review products such as the Requirements Specification. In
the pre-project stage, the project manager should try to form a view about the
users and their commitment to the project and should make sure that user
responsibilities are fully spelled out in the Project Initiation Document. In
addition, it is wise to take user dependencies into account in preparing the project
plan and to avoid, if possible, putting user tasks on the critical path (see chapter
10).
Installation and commissioning: This stage of a project is often either forgotten or
underestimated and can, in fact, turn out to be a considerable piece of work. Some
thought needs to be given to what form of implementation is required (gradual
cutover, big bang or parallel run with old system), that work should be planned
like any other and proper estimates produced and reviewed by people with
experience in the area.
Warranty: If a system is being developed under contract, it often carries a
warranty for a period of months, or perhaps for a year. If so, then an assessment
needs to be made of what claims there could be against the warranty and some
contingency should be built in to cover it.
Political pressure: Often, estimators come under pressure to reduce their estimates
so that some timescale or budgetary constraint can be met. Resisting this requires
a certain amount of willpower but it can be made easier if the estimates have been
developed on sound principles, so that the argument does not degenerate into one
persons guess against anothers.
Chapter 10 Scheduling and resourcing

Q1 Explain the difference between effort and elapsed time. What is the significance of this
difference for project planning purposes?
Effort is the total volume of work involved in a task and is best thought of as how
long it would take to accomplish if one person were assigned to it. Elapsed time, on
the other hand, is how long the task will take from start to finish and this will depend
on the effort involved, how many people are assigned to the task and what delays or
external dependencies are involved. (Creating and correcting an interview report may,
for instance, involve half a days effort but take two weeks elapsed time because the
interviewee is slow to review the document and send back corrections.) In planning,
estimates usually (and rightly) focus on effort but, when transferring the estimates to
the schedules (the dependency network and bar chart), elapsed time also has to be
considered. In particular, issues like fixed lead times for obtaining equipment have
to be taken into account.
Q2 Scheduling a project involves understanding the degree to which project tasks can be
partitioned. What is meant by this term and what effect does partitioning have on the
scheduling process?

Partitioning means that a task can be split between more than one person. If, say, it
takes one man ten days to dig a hole, partitioning it between two men will presumably
mean that the hole can be dug in five days. However, it would probably not be true
that ten men could dig it in one day, partly because they would get in each others way
and partly because some of the time would have to be used in co-ordinating their
efforts rather than actual digging. This leads to the important lesson that one cannot
go on partitioning a task indefinitely and, at some point, one arrives at a task that it is
not sensible to partition any more writing-up the results of an interview for example.
Q3 In long-term project planning, it is wise to assume that staff will be available for
project work for less than 100 per cent of the total available time. What factors will reduce
staff availability and what adjustments should be made for them?
Staff will be unavailable for project work due to:

Bank holidays
Leave
Training courses
Sickness
Other non-working time, such as attendance at company meetings.
The normal way of allowing for this is to schedule people for only four, rather than
five, days work over the duration of a project. For shorter-term planning, where
holidays and training courses are known about, slightly more than four days per week
may be planned for.
Q4 What do you understand by the term project milestone? How would you decide how
many milestones to show on your project plan?
A milestone is a point at which progress on the project can be measured. To be useful,

milestones should be attached to the completion of significant deliverables, such as
the acceptance of a Requirements Specification. There need to be sufficient
milestones on a project plan to allow for adequate control but not so many that their
significance is reduced.
Q5 The PRINCE2 project management method envisages a hierarchy of plans. Describe
this hierarchy.
At the top level, there would be a Project Plan that covers the main aspects of the
project but at a high level of aggregation. Each project stage should then be the
subject of a more detailed Stage Plan. Where different teams are involved in the
project, each may have a very detailed Team Plan for its activities.
Where it becomes evident to a manager in a PRINCE2 project that their part of the
work is likely to go outside its agreed tolerances, they need to complete an exception
report to explain the position and an Exception Plan showing how they propose to
adjust the work to deal with the situation. An Exception Plan can exist at any or all of
project, stage or team levels and, if approved, takes the place of the relevant Project,
Stage or Team Plan.
Chapter 11 Monitoring progress


Q1 How is effort monitored on a project? It is important that the effort to be spent on
activities is reassessed on a regular basis why is this so vital?
Effort is best measured by asking team members to keep timesheets, showing where
exactly on which tasks work has been done. This is important so that the project
manager can keep track of effort and re-evaluate what the final outturn of the project
is likely to be. In addition, the effort figures will provide valuable data for people
who may be trying to estimate similar projects in the future.
Q2 Staff time is usually the principal cost component of an IS project. Describe five other
areas where project costs could arise.
Project costs also arise from:

Contract labour, where invoices are submitted for the hours worked.
Bought-in items, such as hardware and packaged software, for which again
invoices will be received.
Project-specific training, either provided in-house or via external training
providers.
Project-specific accommodation, for example the leasing of office space.
Lodging and subsistence costs, where people need to work away from a base
location for any length of time.
Travel expenses, often arranged through third-party travel companies.
Consumables, such as stationery, cartridges for printers and so on.
Insurance, for the projects equipment but also to cover such issues as public
liabilities and professional indemnity.
Q3 Describe three methods than could be used to exercise quality control and explain the
advantages and disadvantages of each.
Methods include:
Self-checking: Quick, cheap and encourages people to take responsibility for their
own work. But people often have trouble spotting their own mistakes.
Peer review: Relatively inexpensive and provides a second pair of eyes. But
people may be reluctant to criticise their colleagues (or too eager to do so) and the
peer may be too like the author of the product to provide a truly objective view.
Team leader or management review: Provides a coaching opportunity and allows
the work to be examined from a different and perhaps wider perspective. The
manager may not be technically qualified to perform the review and excessive use
of the red pen can de-motivate staff; also the manager may become a bottleneck
in production.
Walkthrough: Very thorough, as it involves a number of people examining the
product from different perspectives. However, this method is labour-intensive and
therefore expensive and committee reviews can be difficult to schedule where
people have busy diaries.
Fagan inspection: More structured version of the walkthrough. Extremely
thorough but also extremely expensive and probably best used for very important
or critical deliverables.
External review: Provides a very objective review but external reviewers may not
be familiar enough with the specific project and raise irrelevant comments.

Q4 In what circumstances might you consider increasing the volume and/or frequency of
quality control checks? When might you decrease their volume or frequency?
Where a team member is inexperienced, or just unknown, the project manager may
increase the volume and/or frequency of quality control checks until they are satisfied
that the work is of a sufficient standard. Similarly, checks may be increased where
problems have been uncovered with a particular individual or area of work.
Where the existing pattern of checks is uncovering few or no problems, checks may
be decreased in frequency or volume and particular team members may be given more
freedom to work in their own way.
Q5 What does the term earned value analysis mean? What additional insights into the
dynamics of a project is afforded by the use of EVA.
Earned value means, in effect, the proportion of a projects total planned deliverable
that has been produced by a given point. Conventional measurement techniques have
tended to concentrate on effort, or other resources, expended, without considering
what has been achieved for that expenditure, whereas EVA takes into account both
expenditure and achievement.
Q6 Explain these terms: actual cost of work performed (ACWP); budgeted cost of work
performed (BCWP); budgeted cost of work scheduled (BCWS).
ACWP is the amount of effort (expressed as such or in monetary terms) that has
been expended in getting to a particular point in a project.
BCWP is the amount of effort (or cost) that should have been expended in getting
to a particular point.
BCWS is the amount of effort (or cost) that should have been expended at a
particular point in the project.
Chapter 12 Exercising control

Q1 What is meant by the term the triple constraint? What are the three elements of the
triple constraint and why is an understanding of their relative weight important in
exercising control over a project?
The term triple constraint refers to the fact that any project takes place within the
envelope of the time it is expected to take, the budget available and some
understanding of what has to be delivered, expressed as scope, product or quality.
It is important for a project manager to understand the balance between the three triple
constraint elements in her project and this will affect the choices she makes in taking
control actions. Would it, for example, be acceptable to cut corners in quality to keep
the costs down or must additional funds be found to ensure the quality of the
deliverables?
Q2 Your project is behind schedule and you are considering adding extra staff to the team.
What would be the potential advantages and disadvantages of this approach?
Provided that the slippage is spotted early enough, adding extra staff may be a feasible
strategy as there will be time for them to be trained and become familiar with the

project. Otherwise, adding extra people may actually be counterproductive, as
training them and/or bringing them up to speed on the project may distract the
existing staff from getting on with their work. However, if the slippage is diagnosed
as being due to a lack of expertise or experience within the project team, bringing in a
few experts may well enable the project to recover.
Q3 In what circumstances might you (a) increase or (b) decrease the amount of
supervision given to a team member?
Where a quality problem has been detected in an individuals work, or where they
seem inexperienced or unsure of themselves, it may be advisable for them to be
supervised more closely. However, this can prove demoralising to experienced and
capable people and the correct approach here may be to give them a lot of latitude to
exercise their professional judgement in how they go about their work.
Q4 Changes often bedevil IS projects. What steps are required to ensure that proper
change control is exercised on a project?
An effective change control system includes the following steps:

Identify the change and document it: Do not allow it to slip through unnoticed
and unmanaged.
Assess the change: In terms of its impact on the triple constraint factors of time,
cost and scope/product/quality. Also consider what would be the effect of the
change on the pattern of risk on the project.
Decide what to do. If the effect of the change is within the project managers
tolerances, s/he can make the decision, otherwise the issue will have to be decided
by the project sponsor.
Q5 Explain the difference between change control and configuration management and the
relationship between them.
Change control is the management of the scope of a project. Configuration

management is the control of the versions of its deliverables and how they fit together.
Good configuration management records enable a project manager to assess the extent
of the impact of a proposed change, in other words to see which deliverables are
likely to be affected and how.
Chapter 13 Reporting progress

Q1 What factors would you consider when deciding on the frequency with which you
would report progress to (a) senior IS management, and (b) customer management?
A major factor to consider when deciding the frequency of reporting to anyone is how
long the actual project is; obviously, if the project takes only two weeks, a monthly
reporting cycle is not going to be of much use!
Assuming a slightly longer project duration, however, then reports ought at the least
to be provided at the key milestones, when important deliverables should be finished.
For reports to the customers internal or external reports at key milestones may be
sufficient. However, the project manager will want to have a regular forum for

meeting customer management and raising any issues that have arisen on the project
so, if the milestones are a long way apart, perhaps a monthly reporting cycle may be
appropriate. For a very fast-moving project, it may be better to have a brief meeting
once a week just to concentrate on the main issues.
IS management will probably require more frequent reports, say once a week. These
should, though, be as succinct as possible and concentrate on the main achievements
and problems encountered during the last period or anticipated during the next one.
Q2 What is meant by the term exception reporting? What are the benefits and the
disadvantages of this type of reporting?
Exception reports concentrate on what has not gone according to plan, the idea being
that things going according to plan is what is supposed to happen and therefore can be
assumed unless informed otherwise. The great advantage of exception reporting is
that it makes for short, succinct reports that focus managements attention where it
should be on what is going wrong. However, because of this, pure exception
reporting tends to assume a rather negative cast and the recipients of the reports will
get the impression that everything is going wrong because that is all they are told
about! So, most managers tend to depart from the pure exception format to emphasise
the achievements, as well as the problems, of their team.
Q3 What are the benefits to the project manager in providing regular progress reports to
the project team members?
People working on a project like to have an understanding of how its doing and
where what they do fits in to the overall picture. On a large project, in particular,
team members can feel buried in their own work with little visibility of the big
picture. Also, where bad news such as delays and technical problems gets known
all too readily on the grapevine, better news about deliverables successfully
achieved or how pleased the clients are with progress often gets overlooked. In
addition to these morale-building aspects of reporting progress to team members, it is
also the case that solutions to problems often come from unlikely sources perhaps
someone who is not directly involved in the issue but who can offer a different and
useful perspective on it.
Q4 Explain the following terms used in the PRINCE2 project management method:
a) Project initiation
b) End stage assessment
c) Highlight report
d) Checkpoint.
a) Project initiation is a key control point in a PRINCE2 project as it is where the

Project Board gives formal authority to the project manager to start work. This
should be done on the basis of a Project Initiation Document which defines the

scope of the project and also, in PRINCE2, includes the Business Case and
initial Project Plan.
b) At the end of each stage of a PRINCE2 project, the project manager is required
to produce an End-Stage Report for the Project Board. This summarises what has
happened during the stage, the problems and how they have been overcome and
requests formal permission to commence the next stage. Thus, End-Stage
Assessments are an important part the mechanism by which the organisation keeps
control over projects and prevents them becoming runaways.
c) The Highlight Report is the regular report from the project manager to the Project
Board. It focuses on achievements since the last report, problems encountered,
issues and risks and work planned for the next reporting period. Essentially, it is
an exception report and provides the Project Board with a succinct summary of the
progress of the project. Highlight Reports are usually based on the relevant
Checkpoint Reports (see below).
d) The Checkpoint is the regular (probably weekly) meeting of a project or stage
team to review progress. Achievements and deliverables are considered, as are
problems and their potential solutions and any issues or risks that need to be
examined. Such meetings are documented in Checkpoint Reports, and these can
then be summarised to create the Project Boards Highlight Report (see above).
Chapter 14 Quality
Q1 How could the quality culture behaviours described in section 14.3 be applied in a
hospital?
The total quality management approach and culture are very readily applied to a
hospital. In general, people working there will be committed to is mission and will be
striving to find better ways to meeting their patients needs. A certain degree of
hierarchy is inevitable in the hospital a surgeon must, for instance, be in charge in
the operating theatre but modern hospitals are seeing a greater sharing of
responsibilities between, say, doctors and senior nurses and this is leading to more
egalitarian approach. Resources are usually a problem, especially in state-funded
hospitals but this does lead to a need to make sure that scarce resources are utilised
most efficiently.
Q2 Why do you suppose there are an increasing number of organisations concerned with
the development of quality practices for IS development?
Information systems often represent considerable expenditure for organisations and

this has been coupled with increasing scepticism about the value obtained for the
funds spent. At the same time, IS is often central to an organisations operations and
key to its growth and development. In these circumstances, managers will want to
ensure that the development and maintenance of the IS investment is carried out in the
most efficient and effective manner and that the resultant systems are fully fit for
purpose. Apart from these considerations, many organisations have to satisfy their
customers that their working practices conform to standards such as ISO9001 and this
will often include the information systems that support these practices.

Q3 What is the purpose of a Quality Plan? Who should create it?
The Quality Plan essentially defines how the work is to be carried out and it is
complementary to the Project Plan which is concerned with what is to be done, when
and by whom. The Quality Plan documents the methods and standards that will be
used to perform the work and also to check that it meets its defined quality standards.
The finished plan provides a source of reference for the project team to tell them how
they should be approaching their work. The Quality Plan should be created by the
project manager and provides him or her with an opportunity to really think through
what methods are most appropriate to this particular project.
Q4 Do you agree with what Dick Brandon said about sex in section 14.10? Do not take
this question too seriously!
Although the quotation had a humorous intent, it does highlight a serious issue. One
of the biggest problems that beset people trying to maintain and enhance systems
not to mention their initial development is a lack of enough detailed documentation.
Although one can inspect a code listing and find out what a program does, that is very
far from knowing why it works that way and what were the underlying business rules.
With very old systems, it can become a case of one step forwards, two steps back
because the whole underlying design concept has been totally lost due to a failure to
keep documentation up to date. On a more prosaic level, failing to keep the
configuration records of documents up to date can waste enormous amounts of time as
people do a lot of work only to discover that they have been working with a
superseded version.
Chapter 15 Risk management

Q1 Why is the use of risk management techniques becoming increasingly important in IS
projects?
IS projects like projects in many other disciplines are becoming increasingly

complex, with new technologies, demanding business goals and multi-party
contractual arrangements. As complexity increases, so does risk and the need to
manage it in a more formal and structured way. In addition to this, for projects
undertaken by external suppliers, there has been a gradual movement towards fixedprice contracting, which tends to shift the risk from the customer onto the supplier and
therefore causes the supplier to take risk much more seriously.
Q2 Describe a five-stage process for project risk management.
The main stages in project risk management are:

Plan the approach: Here, an approach is defined that is appropriate for the
particular project and which will give adequate control over project risk. The
approach is documented in the Risk Management Plan (if there is a separate
document) or as part of the Project or Quality Plan.
Identify risks: The likely risks are identified using peoples experience, debriefs
from other projects and checklists. The risks are documented in the risk register
(risk log).
Assess risks: Each risk is assessed in terms of its likelihood, scale of impact and
urgency. The assessments are added to the risk register.

Plan risk responses: Actions are identified to reduce the probability of the risk
occurring and/or to soften its impact if it does. An owner is assigned to take
charge of the actions. The planned responses are recorded in the risk register.
Carry out risk reduction: Hopefully, the risk actions will have dealt with the
problems but the risk register must also be reviewed regularly to check that the
actions have been successful and to identify any new or changed risks. New risks
are subjected to the same management process as described above.
Q3 Three factors that need to be assessed when considering risks are likelihood, impact
and urgency. Explain what is meant by each of these terms and show how each might be
assessed.
Likelihood refers to the probability of the risk occurring. It can be expressed in

percentage terms or, more practically, as either high, medium or low.
Impact (strictly, scale of impact) refers to the size of the hit the project would take if
the risk occurred. It can be assessed numerically (for example, a 10% increase in cost
or timescale) or as either large, moderate or small.
Urgency has two aspects, referring to the time when the risk will occur (if it does) and
the window of opportunity available to deal with it. Urgency can be expressed in
time terms (one month, for example) or simply as very urgent, urgent, less
urgent.
Q4 Risk actions are of two types: avoidance actions and mitigation actions. Describe the
relationship between these types of risk action and where each might be employed.
Avoidance actions are designed to reduce the likelihood of a risk occurring, ideally
reducing its probability to zero by eliminating it.
Mitigation actions are designed to reduce the impact of the risk if it occurs, sometimes
by identifying contingency plans that can be activated. A special form of mitigation is
risk transfer whereby the impact is made to fall on someone else, as is the case with
an insurance policy.
In practice, both types of risk action are usually required as, even if avoidance actions
are available (which sometimes they are not), they may fail and a fallback response is
required.
It is also worth considering that, if the costs of avoidance or mitigation are higher than
that of the perceived risk impact, a perfectly rational response may be to accept the
risk.
Q5 Describe the characteristics needed in a risk owner.
To be effective in their role, a risk owner needs:

Sufficient information about and understanding of the risk
The resources to do something about it
The authority to take the required action.

Chapter 16 Value engineering and value management
Q1 Explain the difference between value management and value engineering.
Value engineering is concerned with finding the cheapest method of achieving a

previously agreed objective. Value management is broader and also encompasses
trying to get an agreed value for the objectives themselves.
Q2 What is meant by the term value tree?
A value tree progressively decomposes the overall goals of a project into more
specific objectives that can be agreed by the projects stakeholders. These more
detailed objectives can then be used to identify and assess possible system solutions.
Q3 How can value management be used to compare different possible design solutions?
Once the bottom-level objectives for a project have been identified through such
techniques as a value tree (see above), each can be assigned a value, perhaps on a
scale from 1 to 10. The probable effectiveness of the possible solutions in achieving
these objectives can then be assessed and summed to find out which solution offers
the greatest value.
Q4 Once a project is under way, how can value management be used to evaluate proposed
changes?
When potential changes to a project have been identified, value management can be
used to assess the business benefit that implementing them would create and to
compare this benefit with the costs of making the change. Thus, value management
can supplement conventional approaches to change control.
Chapter 17 Selling the project

Q1 How would you assess the importance of sales skills to a project manager? Are they, in
your view, increasing or decreasing in importance? Why do you think there is this change?
Is it more important to understand selling or buying?
Opportunities arise all of the time for project managers to sell. This might be
winning some new business for which the client will pay with real money or with
an internal cross charge to the IS department. It might not be new business at all but
the constant sale of customer satisfaction throughout the project. Whichever it is, its
valuable. To put it in perspective however, its not the project managers main task;
being a good salesman but a poor deliverer on time, on budget and to quality is not a
good solution.
Being able to take a commercial view is increasingly important. Selling is part of this.
Technology is increasingly taken for granted and the ability to sell solutions often
distinguishes good from average performance.
Selling versus buying? These are the two faces of the commercial coin. It is not
realistic to expect to sell unless you know why and how people buy.

Q2 Persuading someone to buy is a complex process. Why is this? Is the process inherently
complex, or is it because so many people are involved?
Persuading is an influencing skill where you seek to get someone to agree with your
proposition by demonstrating that it is what is needed. It is complex because there is
never usually just one buyer. Typically a buying decision for something as significant
as a systems project will involve finance people, technical authorities, the ultimate
user and the project sponsor. A stakeholder analysis will probably show that there
are more stakeholders, but they may not be involved in the purchase decision.
The process is complex and it involves many people.
Q3 If selling is an asking process, how could you use it to help you sell some extra
functionality to a system under development?
If we use the buying cycle as a guide, wed be asking questions about whether or not
the proposed project without the extra functionality meets all the needs. Is
everyone satisfied? Was the original functionality a safe option that we could now
improve, now that it is seen more clearly? Can the unsatisfied people articulate the
implications of not getting this extra functionality?
In short wed ask about
The situation no extra functionality
The problems if nothing is done
The implications of not getting the extra functionality
The payoff or benefit from doing it, from meeting this new need.
Chapter 18 Managing stakeholders

Q1 Stakeholders have different interests or stakes in a project. How can you
determine where to put your management effort?
Ideally, all stakeholders will have closely similar criteria for judging the success of the
project, but this wont always be the case. To identify where to put stakeholder
management effort you should
Identify stakeholders
Discover their criteria for success
Analyse stakeholders ability to affect the project according to their power and
influence
Assign effort first to those with the most power and influence.
Q2 What is meant by the term managing expectations? Why is expectation management
an important part of the project managers job? What influences a customers
expectations?
We all have different expectations about the outcomes of a project or a change at

work. Some are very personal and secret I want to get a desk by the window and a
new PC, whereas some are business related I want to be able to satisfy customer

queries in full over the phone. The declared expectations will all be business related
or have some non-personal aspect to them. Managing expectations means managing
theses declared expectations towards the goals of the project and trying to ensure that
your most powerful stakeholders get their personal expectations met as well.
Q3Why is it important for the project manager to establish a network of contacts within the
IS organisation and also within the user organisation? In what circumstances can these
networks be useful?
Networking is the skill of knowing and building rapport with people who can help you in the
management of your project but who are not part of the project team. Traditional
management hierarchies are gradually disappearing and in flatter, decentralised organisations
it helps to know different people in different departments who can give you alternative views
and information, and bring influence to bear on your behalf. Youd certainly want to make
sure that you had connections into all of the stakeholder groups and into Finance and HR if
they were not identified as stakeholders.
Chapter 19 Managing suppliers
Q1 Describe three situations in which an IS project may need or wish to use
subcontractors.
Reasons for using subcontractors include:

Lack of skills or resources: The organisation may not possess the necessary skills
or may not have enough people with these skills, especially if it is undertaking a
lot of projects at the same time.
Pressure to reduce headcount: It may be more politically acceptable to have the
work done externally even at increased cost than to retain people on the
permanent establishment.
Relative costs: Sometimes, a subcontractor may be able to offer economies of
scale and hence lower costs than with an in-house team. A very contemporary
manifestation of this is to offshore work to places such as India where highlytrained personnel are employed at much lower rates than are the norm in Europe.
Specialised skills required: The project may call for very specialist skills indeed
and these may only be available from specific organisations.
Risk transfer: The organisation may wish to transfer some or all of the risk
(technical or commercial) to another party.
Q2 It is important that the contracts between the main contractor and the customer and
between the main contractor and subcontractors are back-to-back; what is meant by this
term?
The phrase back to back means that any contract terms applied to the prime
contractor are flowed down to subcontractors. This is important as, otherwise, the
main contractor may find themselves liable for things that they have entrusted to
others, with no legal redress for their subcontractors failings.

Q3 Subcontracts often include penalty clauses to give the main contractor protection in the
case of the suppliers poor performance. Why are penalty clauses not the complete answer
to safeguarding the main contractors position?
Penalty clauses only provide for monetary compensation to be paid in certain

specified circumstances. Apart from the difficulty of enforcing penalty clauses, they
seldom provide complete recompense for all the consequences of a suppliers failure
like business loss or public damaged as the result of late delivery or poor performance
of a system.
Q4 Describe four methods that can be used to monitor supplier performance.
Methods include:
Approval of designs: The organisation studies, comments on and finally approves
designs, specifications, drawings and so on.
Progress meetings: These should be regular and/or tied to the completion of
significant deliverables.
Witnessing tests: To check that subcontracted products meet their design
specifications.
Receipt of goods: Formally checking goods received to ensure that they are what
was ordered, in the right quantity and quality.
Checking invoices: To ensure that they are in accordance with contracts and
purchase orders and that the goods or services invoiced for have been provided.
Risk management: Checking on how the subcontractor manages risk and
assessing any risks that could impact on the organisation or main contractor.
Managing the customer interface: Ensuring that customers only talk to
subcontractors through the organisation or main contractor.
Q5 Explain how quality control can be applied to a subcontractors work.
Quality control of a subcontractors work starts with a clear, detailed and precise
specification of the goods required or the services to be performed. Detailed
acceptance criteria should also be agreed between the parties.
Two basic approaches to quality control can be used:
The black box approach where the inputs and outputs from the product are
checked to ensure that they conform to specifications; if they do, the buyer is not
concerned with how the product works.
The white box approach where not only inputs and outputs are checked but also
what goes on within.
In addition, the buyer may wish to see that the subcontractor works within and
conforms to some independent standard for quality management systems, such as
ISO9001.
Chapter 20 Leadership

Q1 Refer back to the introduction and consider again the leadership challenge at the end
of the section. What kind of project management would you need to deliver to have people
volunteer to work on your projects?
The leadership challenge is to assume that everyone working on your project is there
because they want to be. they are volunteers.
There are four things that followers demand of their leaders. These are
Honesty they must act with integrity at all times
Competence they can do the job
Vision goals and objectives are clear to everyone
Inspiration there is enthusiasm and passion for the job
To this we might add that the project manager maintains team spirit, considers
individual needs and sets high performance standards. Life is a challenge and its fun.
Q2 How can Maslow and Herzberg theories of motivation help you to organise your
project team and the way work is allocated?
We should assume that working in an IS project team meets the first two levels of
need in Maslows hierarchy physiological and safety/security needs. By his or her
own actions, the project manager can address needs for
Social interaction- is everyone part of the team. No one is left out.
Status and recognition people are rewarded for their achievements, even if it
is a simple public thankyou?
Achievement and challenging job - team members are pushed to develop and
achieve greater and greater things.
Herzberg found that the things that motivated people were achievement, recognition,
the kind of work people were given, their responsibility and advancement. These are
all in the projects managers gift. There is the opportunity to structure the work given
to team members to take advantage of the motivating forces in us all.
Q4 Think of a situation at home, at work, at university or in a club to which you belong. It

is a situation that involves you. You want to change the present circumstances and set a
new basis for the future. Using the behavioural commitments at the end of section 18.4,
what could you do to change things?
Clearly there isnt an answer to this question as the situation chosen determines what
youd actually do, but there are some general steps that you could follow:
Create a climate for change. Is there a burning platform a situation that is
so bad that people want to move from it? Or do you need to challenge the

process by constantly seeking out and proposing opportunities for

improvement?
Create a vision for the future that you and everyone can share
Encourage others to work together towards the new situation
Show everyone what things could be like through the way you behave
Celebrate the successes big and small along the way.
Chapter 21 Performance management

Q1 You are dissatisfied with the general level of performance of one of your team. The
quality of work is below your expectations. How will you deal with this?
You could take the following approach but remember that performance issues are
usually more complex than a simple checklist might suggest.
Are your expectations about the quality of work clear and well understood by
this team member? Is s/he new to the team?
Are there reasons that you know about that might be influencing the level of
performance? Home, family, travel issues or unfamiliarity with the kind of
work. Is it a question of competence or commitment?
This is a problem solving or coaching opportunity and not a disciplinary
situation.
Having prepared, establish with the individual the level of performance
expected, and the gap between the expected and actual performance.
Explore the reasons for the gap. Get the individuals point of view first.
Agree actions to eliminate the gap.
Summarise with precision. Fix a follow-up review.
Q2 A member of your team exhibits disruptive behaviour. Her work is good but she is not a
team player. The consequences are that she does not contribute to team effort and her
colleagues find her difficult to work with; the project team secretary has refused to work
with her at all. How could this serious problem have arisen? What can be done now?
This has been allowed to go on too long and is now a real drag on project
performance. Two things need to be addressed immediately. Firstly, it is not
acceptable for the project team secretary to refuse to work with her. You need to be
quite clear, in private, that this must stop. Dont get into a disciplinary frame of mind
however; you could usefully follow the process suggested for question 1.
Secondly, the disruptive team member needs to understand that the disruptive
behaviour that you have seen is unacceptable. The process already described could be
followed.

There are two further points.
Is the disruptive person really disruptive or does she just work differently?
Is her preferred team role one that makes others uncomfortable with her? Is
she being made the scapegoat for other peoples discomfort?
Are you giving clear leadership, being open and encouraging openness with
others?
Q3 Describe the process of setting objectives. What might be three objectives for a newly
appointed junior programmer?
A hierarchy of objectives cascades down from the overall aim of the project down to
the objectives for individual work packages.
They are agreed between the setter and the receiver of the objectives and may be
subject to negotiation.
Refer back to the use of SMART objectives.
For a newly appointed junior programmer they may include work that
Requires use of the competences s/he already has
Includes a measure of challenge (this is where your expectations should be
made clear)
Offers the opportunity to develop and for the achievement of this development
to be recognised and recorded.
Chapter 22 Project teams
Q1 Prepare an interview plan for the post of Business Analyst in your team.
1. Welcome/introductions/administrative things/agenda. Establish rapport.

2. Open questions about education and training received. Probe business
analysis qualifications subjects covered and level.
3. Open questions about previous jobs. How much was business analysis and
how much systems analysis. Reasons for leaving.
4. Open questions about interests, personal circumstances.
5. Our company, the IS/IT function, our job, our expectations, and challenges.
6. Anything youd like to ask me? Anything youd like to add?
7. What happens next.
8. Thank you and goodbye.
Q2 When you first assemble your project team, what can you do to build team spirit? What
behaviours are the different individuals likely to exhibit during this team-building process?
How do you demonstrate your leadership?

Some team development activity is valuable. It doesnt have to be building rafts out
of planks and string and getting wet! There are three aims.
For people to get to know each other in a work context and understand their
impact on each other
To establish some preliminary work processes and standards to get the team
started
For everyone to understand the overall aims and objectives of the project and
for the project manager to set his/her expectations, set the vision and set out
how the team will be managed.
Regular team meetings will emphasise your commitment to the team and enable you
to deal with team development issues as they arise.
Chapter 23 Managing the project climate

Q1 Consider a project manager with a team of 15 to 20 people: a mixture of analysts,
designers, programmers and support staff. The project also uses some specialist staff on a
part-time basis. How could the project manager influence the working environment of such
a team so as to get the best out of them?
This is a disparate project team made more complex to manage by the use of part-time
specialists. The size of the team means that there will probably be three or four teams
in the project each managed by a team leader. This effectively creates a management
team for the project. The project manager will concentrate on making sure that the
teams are managed in a consistent and collaborative way.
The overall team is small enough for the project manager to know everyone and to be
encouraging and supportive or, when needed, firm and critical about work
performance.
The climate is established by the project managers own leadership and by modelling
the way in which people are expected to behave. A useful model is the Leadership
Challenge model.
Q2 Conflict and stress arise naturally in IS project teams. Some people argue that a little
of both is useful, but everyone agrees that too much is destructive. How could you organise
your project team to minimise the destructive effect of conflict and stress?
Project teams dont run without some level of conflict and stress. Developing new
systems is a creative process that needs new ideas. From time to time it may however
get out of hand. To resolve it, you need to give those involved the chance to present
their case without interruption before exploring the matter further yourself. If the
conflicting parties cant then agree on a solution, you have to decide the issue
yourself.

You need to consider the circumstances that generated the conflict in the first place.
Do they include inbuilt confusion that will continue to generate conflict, or clearly
unfair or now outdated working practices?
Neither can stress be eliminated entirely. Often a stressful project delivery can be
energising and exciting with extra hours and weekend working accepted by everyone.
There is a limit to this however and at least one day a week should be work free.
Some stress relief activities can be organised on a team basis. On an individual basis,
take care not to let stress reduce performance. Provide help to reduce it and get help
to enable the individual to manage it. Above all, dont take on other peoples stress
yourself. If really big stress issues arise, get help from experts. It is not acceptable
for organisations to deliberately ignore workplace stress or for people to be so
pressured that they fall ill.
Finally, take care not be a source of stress yourself. Setting challenging objectives is
fine; constantly interfering and harrying the team is not!
Chapter 24 The project manager

Q1 How does the vision of the project manager in this chapter relate to the way you see
the job? Are there aspects of the job that do not appear in the vision? Why might that be?
The vision statement was written to define the feel of the job in a way that lets project
managers know what is expected of them in a qualitative way. Its not a job
description view. It is not a pedestrian step-by-step approach to the job. It tries to
communicate the emotion of the job. It is very personal.
The things missing are all related to the context within which the job is done. Is it a
UK job, and American job, an international job, a European job it doesnt say.
It does however imply a good deal about the culture within which the job exists. It is
goal orientated, requiring personal commitment and risk. It talks about challenge and
shaping events and winning through. It is to some extent an heroic view of the project
manager and this tells something of the organisation for which the vision was created
and its view of the kind of project managers they wanted.
It is neither everyones view of the project manager nor every organisations view but
it does illustrate how the spirit of the job can be captured in an unconventional way
and communicate the enthusiasm of project management.
Q2 Consider the skills and qualities of project managers described in the developmental
approach. Can you add to these? How far do you see yourself being proficient in these
skills? How could you develop further?
This is another question without an answer. You have to work it out for your self
and for your context. The self-management dimension may, for example, not always

require the innovative risk taking component. In the 1:1 interactions, managing
client relations may not be part of the job where you work.
What the developmental approach offers is a template for you to assess your type of
project management and an opportunity to measure yourself against it.

Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Project Management For Information Systems by James Cadle and Donald Yeates End of Chapter Questions and Answers Chapter 1 Managing Change

Diunggah oleh

Hak Cipta:

Format Tersedia

Project Management for Information Systems

by James Cadle and Donald Yeates

Several change issues will arise;