One of initial concepts created and applied by early IT practitioners was the "V"

Model. It was created to ensure project teams had a mechanism with which they
could
accurately define and refine user requirements
design and build an application according to the authorized user requirements
validate that the application they had built adhered to the authorized business
requirements

the stages of our project and

how they relate to the process model. These stages are:
n Pre-project work including initial client contact, evaluation of tenders and
agreeing a form of contract.
n Start-up or Initiation stage this includes the Project Start-up stage on the
process model.
Development stage this includes the Development stage on the process model.
n Completion stage this includes the Delivery to Customer, Staff Training and
Familiarization, Acceptance Testing, System Commissioning and Customer
Takeover stages on the process model.
n Operational stage this includes the In-service Live Running, Warranty
Support and Maintenance, and Enhancements stages on the process model.
n Post-project review stage this involves auditing the project after it has
finished, to capture any lessons learned from it.
The main products resulting from the Start-up stage are as follows:
n Project initiation document (PID)
n Project plan
n Quality plan
n Risk management plan
n Project organization structure
n Project administrative procedures.
The format of a project initiation document (PID) will vary from organization
to organization and the PRINCE2 project management method has a
detailed product description for it. However, a simple but effective format for
a PID is given through the mnemonic OSCAR. Completing
the sections of the OSCAR format will ensure that the most important project
start-up issues are addressed.
The Development stage of the project is where most of the suppliers work is
carried out. Although the customers project director should exercise overall
control of the project, many of the activities are under the day-to-day control
of the supplier project manager.
The Development stage has several distinct parts and these have varying
amounts of user/customer involvement. The different parts of the Development
stage are set out below:
n Requirements definition
n Design
n Implementation
n Integration and testing
n System testing.
The Completion stage begins when the information system has been completed
by the supplier and has been subjected to the full rigours of a system test and
every error and problem eradicated.
There are a number of steps in the Completion stage:
n Delivery to the customer of all the elements of the system including software
and documentation.
n Training and familiarization for the end-users, system administrators and
operators.
n Carrying out of acceptance tests by the customer on the delivered products.

n Acceptance by the customer.

n System commissioning.
n Final takeover by the customer.
The Operational stage takes over when live running begins. This stage does not
form part of the project as such, unless some type of guarantee or support
arrangement has been negotiated between the customer and supplier. Business
requirements change, however, and it is likely that the system will require
maintenance and enhancement. Faults will arise during live running that were
not discovered during testing of the system.
Some time after live running has started, usually at about six months, a
postimplementation
review should be carried out. This reconsiders the business
case produced at the beginning of the project and assesses whether the business
objectives of the system have been met.
We have considered the use of a generic process model and identified the
likely stages of a project. These stages are:
n Pre-project work, which is concerned with establishing the requirements,
identifying and selecting a supplier and agreeing a contract.
Start-up or Initiation stage, which is more concerned with pure project
management
than with direct delivery of IS products. The start of a project was
looked at under the following headings:
What? The objectives, scope, constraints and interfaces.
Why? The need for every project to have a business case.
Who? The project organization to define the roles and responsibilities on
the project.
How and when? The plans that need to be developed to ensure that the
project has a firm base.
n Development stage, which is concerned with the traditional analysis, design,
programming and testing aspects of system development.
n Completion stage, which is where the finished product is delivered by the
supplier, and tested and accepted by the customer.
n Operational stage, where the information system goes into live running.
PART TWO: Project Execution
Project planning: understanding
the work
Learning outcomes
When you have finished reading this chapter, you will be able to:
n Demonstrate your understanding of the need for project planning
n Prepare a work breakdown structure
n Prepare a product breakdown structure
n Describe the difference between product descriptions and work packages
n Describe the importance of dependencies in project planning
n Prepare a network diagram
n Calculate a projects critical path
n Draw a Gantt chart for sequential and parallel activities.
In this chapter and the two that follow we examine some of the steps involved
in planning an IS project
The starting point for a good project plan is a proper understanding of the
requirement: what is it exactly that the project is supposed to achieve?
Having looked at the objectives of the project, it is time to consider what needs
to be done to meet those objectives: what are we trying to produce and how
shall we go about it? There are two basic approaches to this: the work breakdown

structure and the product breakdown structure

Work breakdown is the more traditional approach and has been widely used
in many industries for a long time. The basic idea is to take the overall work
the project and to break it down progressively into smaller and smaller
chunks until we end up with individual tasks, or work packages, that we can
estimate sensibly and assign to team members.

In recent years another approach to project planning has emerged based

upon the idea of considering the products that will result from the project.

Work Breakdown Structure:

Product Breakdown Structure:

Product descriptions and work packages

Once the bottom level of the PBS has been reached, we are in a position to
create a description of each project. There are two main reasons for doing this:
n It encourages us to think through exactly what we want this product for
n It provides, as it were, a detailed specification of work for the project team
member who will ultimately be asked to develop it, leaving them in no
doubt about what is required from them.
At some point, the project manager has to assign specific pieces of work
work packages to individuals. All that then needs to be
done is to add three sections to the product description:
n Effort estimated.
n Date required.
n Allocated to.

Dependencies are fundamental to planning a project and, later, in understanding

the effects of any problems encountered. In essence, understanding
dependencies is simple. If activity B can begin
only when activity A is complete, then we have a dependency.
We can analyse dependencies using a network diagram, also known as a
dependency diagram or PERT chart.

This now shows those activities that are on the critical path of the project:
in other words, those that, if they are delayed, will delay the whole project. For
example, Conduct interviews will take eight days whereas Investigate other
systems
will take only four days; so a delay of up to four days in Investigate other systems
will not delay the start of the three successor activities.
Another widely used planning tool is the bar chart, often called a Gantt chart
after HL Gantt, an industrial engineer who pioneered their use during the First
World War. Bar charts provide a highly visual way of illustrating the sequence

of activities in a project but, because they do not show dependencies very

readily,
they are less useful for managing progress on a project.

Project planning: estimating

Learning outcome
When you have finished reading this chapter, you will be able to:
n Suggest reasons why it is difficult to estimate accurately for IS projects
n Identify six different estimating methods
n List some of the tasks not amenable to normal estimating methods
n Propose practical tips for improving the quality of estimating.
Before we look at estimating methods, therefore, it might be as well to
consider the special features of IS projects that make estimating for them so
difficult.
The first, and perhaps most important, characteristic is that IS projects tend
to be one-off affairs. The project is undertaken to achieve some specific business
objective, very often to secure some competitive advantage, and this means
that there will always be a degree of innovation involved.
The second feature of IS projects is that the initial estimates are often prepared
long before there is a detailed specification of the requirement on which
to base them.
A third aspect of IS estimating is that it is seldom performed by professional
estimators.
Estimating methods compared
In the following sections, we examine a number of the most commonly used
methods for preparing estimates for IS projects.
Analogy method
The analogy method is one of the oldest, but one of the most reliable, of
methods and depends on finding a project similar to the current one which
has already been undertaken in the organization.
Analysis effort method
The analysis effort method is most suited to producing the initial estimates
for a project, probably before detailed analysis has begun. The general idea is
to estimate the effort required to perform the analysis work for an assumed

number of project functions and then to derive the estimates for subsequent
project stages via the use of ratios to the analysis effort.
Programming method
The programming method starts at a different point from the analysis effort
method, namely that of examining the programming effort required and
deriving values for the rest of the project tasks. The simplest way of assessing
the programs is to decide if each is likely to
be small, medium or large. Suitable figures might be:
Small program
5 days
Medium program
10 days
Large program
15 days
Direct estimation based on project breakdown
This is the most detailed estimating technique and depends upon having
a breakdown of the work to be performed. The two principal methods for
breaking down the work using a work breakdown structure or a product
breakdown structure
The Delphi technique
The Delphi technique is based on the idea of obtaining estimates from suitably
qualified people and then synthesizing them to produce the final estimate. Since
people have differing levels of experience of estimating, and of the underlying
hardware and software to be used, the approach has a number of stages:
n Each estimator is given a specification of the work activity, task or whatever
and asked to provide their estimate for it. These are filled in anonymously.
n The estimates are then summarized anonymously and the summary is
circulated to each estimator.
n Estimators reconsider their own estimates in the light of the summary and
provide a revised estimate if they wish.
CoCoMo
The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model.
Function point analysis
The technique of function point analysis was developed in the USA by AJ
Albrecht and JE Gaffney. Its objective is to be able to estimate for the size of a
software system or, to be more accurate, the amount of effort required to
develop it based on some observable features of the product to be developed.
To use a metaphor for this, consider asking a builder for an estimate to build
a house based on the number of floors, the total floor area and the number of
rooms. Although this is not much information, if we said two floors, 65 square
metres, 12 rooms, it is obvious that we are talking about neither a garden shed
nor Buckingham Palace and the builder might be able to give a ballpark
estimate. The equivalent parameters in function point estimating are inputs,
outputs and files accessed.
PERT estimating
There is one other approach to estimating which we would like to introduce
here because it provides a simple way of allowing for the fact that, in the real
world, tasks seldom work out exactly as planned. PERT stands for Programme
Evaluation and Review Technique.

Estimating for supporting activities

Whilst one reason that some projects go over time or budget is because activities
were underestimated, the more usual reason is because activities were missed
out altogether. It is relatively easy to identify the main tasks of the project such
as conducting interviews, writing code and performing system tests, but there
are scores of other activities which seem insignificant by themselves but which
can amount to a lot of time over the length of a project. Example: Proportional
activities - There is a long-established, and generally quite reliable, rule of thumb
that a team leader should be capable of running a team of up to five people.

10. Project planning: scheduling and resourcing

Learning outcomes
By the time you have finished reading this chapter, you will be able to:
n Explain the difference between effort and elapsed time in the scheduling
process
n From a simple network produce Gantt bar charts for single and multiple
person teams
n Define a project milestone
n State the importance of using project milestones
n Show how bar charts and milestones can be used to prepare resource
requirements
n List the headings for a comprehensive plan.