SOFTWARE PROJECT MANAGEMENT

Project Definition – Contract Management – Activities Covered By Software Project

Management – Overview Of Project Planning – Stepwise Project Planning.

A. Objectives
When you have completed this chapter you will be able to:
 define the scope of ‘software project management’;
 distinguish between software and other types of development project;
 understand some problems and concerns of software project managers;
 define the usual stages of a software project;
 explain the main elements of the role of management;
 appreciate the need for careful planning, monitoring and control;
 identify the stakeholders of a project and their objectives and ways of defining the success
in meeting those objectives.

B. Project Definition:
The dictionary definitions put a clear emphasis on the project being a planned activity. The
definition of a project as being planned assumes that to a large extent we can determine how we are
going to carry out a task before we start. There may be some projects of an exploratory nature
where this might be quite difficult. Planning is in essence thinking carefully about something before
you do it – and even in the case of uncertain projects this is worth doing as long as it is accepted
that the resulting plans will have provisional and speculative elements. Other activities, relating, for
example, to routine maintenance, might have been performed so many times that everyone involved
knows exactly what needs to be done. In these cases, planning hardly seems necessary, although
procedures might need to be documented to ensure consistency and to help newcomers to the job.
The types of activity that will benefit most from conventional project management are likely to lie
between these two extremes – see Figure 1.1. There is a hazy boundary between the non-routine
project and the routine job. The first time you do a routine task it will be like a project. On the other
hand, a project to develop a system similar to previous ones that you have developed will have a
large element of the routine.
The characteristics which distinguish projects can be summarized as follows.

1
 non-routine tasks are involved;
 planning is required;
 specific objectives are to be met or a specified product is to be
created;
 the project has a pre-determined time span;
 work is carried out for someone other than yourself;
 work involves several specialisms;
 work is carried out in several phases;
 the resources that are available for use on the project are
constrained;
 The project is large or complex.

2
The more any of these factors apply to a task, the more difficult that task will be. Project size is
particularly important. A project that employs 200 project personnel is going to be trickier to
manage than one with just two people. The examples and exercises used in this book usually relate
to smaller projects. This is just to make them more manageable from a learning point of view: the
techniques and issues discussed are of equal relevance to larger projects.

C. Software projects versus other types of project

Many of the techniques of general project management are applicable to software project
management, but Fred Brooks pointed out that the products of software projects have certain
characteristics which make them different. One way of perceiving software project management is
as the process of making visible that which is invisible.
Invisibility When a physical artefact such as a bridge or road is being constructed the progress
being made can actually be seen. With software, progress is not immediately visible.
Complexity Per dollar, pound or euro spent, software products contain more complexity than other
engineered artefacts.
Conformity The ‘traditional’ engineer is usually working with physical systems and physical
materials like cement and steel. These physical systems can have some complexity, but are
governed by physical laws that are consistent. Software developers have to conform to the
requirements of human clients. It is not just that individuals can be inconsistent. Organizations,
because of lapses in collective memory, in internal communication or in effective decision-making
can exhibit remarkable ‘organizational stupidity’ that developers have to cater for.
Flexibility The ease with which software can be changed is usually seen as one of its strengths.
However, this means that where the software system interfaces with a physical or organizational
system, it is expected that, where necessary, the software will change to accommodate the other
components rather than vice versa. This means the software systems are likely to be subject to a
high degree of change.

D. Contract management and technical project management

Many organizations contract out IT development to outside specialist developers. In such cases, the
client organization will often appoint a ‘project manager’ to supervise the contract. This project

3
manager will be able to delegate many technically oriented decisions to the contractors. For
instance, the project manager will not be concerned about estimating the effort needed to write
individual software components as long as the overall project is fulfilled within budget and on time.
On the supplier side, there will need to be project managers who are concerned with the more
technical management issues.

E. Activities covered by software project management

A software project is not only concerned with the actual writing of software. In fact, where a
software application is bought in ‘off the shelf’, there may be no software writing as such. This is
still fundamentally a software project because so many of the other elements associated with this
type of project are present. Usually there are three successive processes that bring a new system into
being – see Figure 1.2.

1. The feasibility study This is an investigation into whether a prospective

project is worth starting. Information is gathered about the requirements of the proposed
application. The probable developmental and operational costs, along with the value of the benefits
of the new system, are estimated. With a large system, the feasibility study could be treated as a

4
project in its own right – and have its own planning sub-phase. The study could be part of a
strategic planning exercise examining and prioritizing a range of potential software developments.
Sometimes an organization has a policy where a group of projects is planned as a programme of
development.

2. Planning If the feasibility study produces results which indicate that the
prospective project appears viable, planning of the project can take place. However, for a large
project, we would not do all our detailed planning right at the beginning. We would formulate an
outline plan for the whole project and a detailed one for the first stage. More detailed planning of
the later stages would be done as they approached. This is because we would have more detailed
and accurate information upon which to base our plans nearer to the start of the later stages.

3. Project execution The project can now be executed. The execution of a project often contains
design and implementation sub-phases. Students new to project planning often find it difficult to
separate planning and design, and often the boundary between the two can be hazy. Essentially,
design is thinking and making decisions about the precise form of the products that the project is to
create. In the case of software, this could relate to the external appearance of the software, that is,
the user interface, or the internal architecture. The plan lays down the activities that have to be
carried out in order to create these products. Planning and design can be confused because at the
most detailed level, planning decisions are influenced by design decisions. For example, if a
software product is to have five major components, then it is likely that there will be five groups of
activities that will create them. Individual projects are likely to differ considerably but a classic
project life cycle is shown in Figure 1.3. The stages in the life cycle are described in a little more
detail below:

Requirements analysis This is finding out in detail what the users require of the system that the
project is to implement. Some work along these lines will almost certainly have been carried out
when the project was evaluated, but now the original information obtained needs to be updated and
supplemented. Several different approaches to the users’ requirements may be explored.

5
small system which satisfies some, but not all, of the users’ needs at a low price might be compared
to a system with more functions but a higher price.

Specification Detailed documentation of what the proposed system is to do.

Design A design has to be drawn up which meets the specification. As noted

earlier, this design will be in two stages. One will be the external or user design concerned with
the external appearance of the application. The other produces the physical design which tackles the
way that the data and software procedures are to be structured internally.

Coding This may refer to writing code in a procedural language such as C or

Ada, or could refer to the use of an application-builder such as Microsoft Access. Even where
software is not being built from scratch, some modification to the base package could be required to
meet the needs of the new application.

Verification and validation Whether software is developed specially for the current application or
not, careful testing will be needed to check that the proposed system meets its requirements.

Implementation/installation Some system development practitioners refer to the whole of the

project after design as ‘implementation’ (that is, the implementation of the design) while others

6
insist that the term refers to the installation of the system after the software has been developed. In
this latter case it includes setting up operational data files and system parameters, writing user
manuals and training users of the new system.

Maintenance and support Once the system has been implemented there is a
continuing need for the correction of any errors that may have crept into the
system and for extensions and improvements to the system. Maintenance and support activities may
be seen as a series of minor software projects. In many environments, most software development is
in fact maintenance.

F. Plans, methods and methodologies

A plan for an activity must be based on some idea of a method of work. To take a simple example,
if you were asked to test some software, even though you do not know anything about the software
to be tested, you could assume that you would need to:
 analyse the requirements for the software;
 devise and write test cases that will check that each requirement has been satisfied;
 create test scripts and expected results for each test case;
 compare the actual results and the expected results and identify discrepancies.

While a method relates to a type of activity in general, a plan takes that method (and perhaps
others) and converts it to real activities, identifying for each activity:

 its start and end dates;

 who will carry it out;
 what tools and materials will be used.

‘Material’ in this context could be information, for example, a requirements

document. With complex procedures, several methods may be deployed, in sequence or in parallel.
The output from one method might be the input to another. Groups of methods or techniques are
often referred to as methodologies. Object oriented design, for example, can be seen as a
methodology made up of several component methods.

7
G. Some ways of categorizing software projects

It is important to distinguish between the main types of software project because what is
appropriate in one context may not be so in another. For example, some have suggested that the
object-oriented approach, while useful in many contexts, might not be ideal for designing
applications to be built around relational databases.

1. Information systems versus embedded systems

A distinction may be made between information systems and embedded systems. Very crudely, the
difference is that in the former case the system interfaces with the organization, whereas in the latter
case the system interfaces with a machine. A stock control system would be an information system
that controls when the organization reorders stock. An embedded, or process control, system might
control the air-conditioning equipment in a building. Some systems may have elements of both so
that the stock control system might also control an automated warehouse.

2. Objectives versus products

Projects may be distinguished by whether their aim is to produce a product or to meet certain
objectives. A project might be to create a product the details of which have been specified by the
client. The client has the responsibility for justifying the product. On the other hand, the project
may be required to meet certain objectives. There could be several ways of achieving these
objectives. A new information system might be implemented to improve some service to users
inside or outside an organization. The level of service that is the target would be the subject of an
agreement rather than the characteristics of a particular information system. Service level
agreements are becoming increasingly important as organizations contract out functions to external
service suppliers.

8
Many software projects have two stages. The first stage is an objectives-driven project which results
in a recommended course of action and may even specify a new software system to meet identified
requirements. The next stage is a project actually to create the software product.

H. Management Definition:
The Open University Software Project Management module suggested that management involves
the following activities:

 Planning – deciding what is to be done;

 Organizing – making arrangements;
 Staffing – selecting the right people for the job, etc.;
 Directing – giving instructions;
 Monitoring – checking on progress;
 Controlling – taking action to remedy hold-ups;
 Innovating – coming up with new solutions;
 Representing – liaising with users, etc.

I. Introduction to Step Wise project planning

This chapter describes a framework of basic steps in project planning upon which the following
chapters build. Many different techniques can be used in project planning and this chapter gives an
overview of the points at which these techniques can be applied during project planning.

The framework described is called the Step Wise method to help to distinguish it from other
methods such as PRINCE2. PRINCE2 is a set of project management standards that were originally
sponsored by what is now the Office of Government Commerce (OGC) for use on British
government ICT and business change projects. The standards are now also widely used on non-
government projects in the United Kingdom. Step Wise
should be compatible with PRINCE2. It should be noted, however, that Step Wise covers only the
planning stages of a project and not monitoring and control.

9
In Table 1.1 we outline the general approach that might be taken to planning these projects. Figure
1.4 provides an outline of the main planning activities. Steps 1 and 2 ‘Identify project scope and
objectives’ and ‘Identify project infrastructure’ could be tackled in parallel in some cases. Steps 5
and 6 will need to be repeated for each activity in the project.

10
Fig 1.4 An overview of Step Wise Project planning

11
Step Activities within step

0 Select project
1 Identify project scope and objectives
1.1 Identify objectives and measures of effectiveness in meeting
them
1.2 Establish a project authority
1.3 Identify stakeholders
1.4 Modify objectives in the light of stakeholder analysis
1.5 Establish methods of communication with all parties
2 Identify project infrastructure
2.1 Establish relationship between project and strategic planning
2.2 Identify installation standards and procedures
2.3 Identify project team organization
3 Analyse project characteristics
3.1 Distinguish the project as either objective- or product-driven
3.2 Analyse other project characteristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning
implementation
3.5 Select general life-cycle approach
3.6 Review overall resource estimates
4 Identify project products and activities
4.1 Identify and describe project products (including quality
criteria)
4.2 Document generic product flows
4.3 Recognize product instances
4.4 Produce ideal activity network
4.5 Modify ideal to take into account need for stages and
checkpoints
5 Estimate effort for each activity

12
5.1 Carry out bottom-up estimates
5.2 Revise plan to create controllable activities
6 Identify activity risks
6.1 Identify and quantify activity-based risks
6.2 Plan risk reduction and contingency measures where
appropriate
6.3 Adjust plans and estimates to take account of risks
7 Allocate resources
7.1 Identify and allocate resources
7.2 Revise plans and estimates to take account of resource
constraints
8 Review/publicize plan
8.1 Review quality aspects of project plan
8.2 Document plans and obtain agreement
9/10 Execute plan/lower levels of planning
This may require the reiteration of the planning process at a lower level

Table1.1 An Outline of Step Wise Project planning activities

A major principle of project planning is to plan in outline first and then in more detail as the time to
carry out an activity approaches. Hence the lists of products and activities that are the result of Step
4 will be reviewed when the tasks connected with a particular phase of a project are considered in
more detail. This will be followed by a more detailed iteration of Steps 5 to 8 for the phase under
consideration.

Step 0: Select project

This is called Step 0 because in a way it is outside the main project planning process. Proposed
projects do not appear out of thin air –some process must decide to initiate this project rather than
some other. While a feasibility study might suggest that there is a business case for the project, it

13
would still need to be established that it should have priority over other projects. This evaluation of
the merits of projects could be part of project portfolio management.

Step 1: Identify project scope and objectives

The activities in this step ensure that all the parties to the project agree on the objectives and are
committed to the success of the project. We have already looked at the importance of the correct
definition of objectives.

Step 1.1: Identify objectives and practical measures of the effectiveness in meeting those
objectives

Step 1.2: Establish a project authority

We have already noted that a single overall project authority needs to be
established so that there is unity of purpose among all those concerned.

Step 1.3: Stakeholder analysis – identify all stakeholders in the project and their interests
Essentially all the parties who have an interest in the project need to be identified.

Step 1.4: Modify objectives in the light of stakeholder analysis

In order to gain the full cooperation of all concerned, it might be necessary to modify the project
objectives. This could mean adding new features to the system which give a benefit to some
stakeholders as a means of assuring their commitment to the project. This is potentially dangerous
as the system size may be increased and the original objectives obscured. Because of these dangers,
it is suggested that this process be done consciously and in a controlled manner.

Step 1.5: Establish methods of communication with all parties

For internal staff this should be fairly straightforward, but a project leader implementing for
example, a payroll system would need to find a contact point with BACS (Bankers Automated
Clearing Scheme), for instance. This step could lead to the first draft of a communications plan

14
Step 2: Identify project infrastructure
Projects are never carried out in a vacuum. There is usually some kind of existing infrastructure into
which the project must fit. Where project managers are new to the organization, they must find out
the precise nature of this infrastructure. This could be the case where the project manager works for
an outside organization carrying out the work for a client.

Step 2.1: Identify relationship between the project and strategic planning
We know how project portfolio management supported the selection of the projects to be carried
out by an organization. Also, how programame management can ensure that a group of projects
contribute to a common organizational strategy. There is also a technical framework within which
the proposed new systems are to fit. Hardware and software standards, for example, are needed so
that various systems can communicate with each other. These technical strategic decisions should
be documented as part of an enterprise architecture process. Compliance with the enterprise
architecture should ensure that successive ICT projects create software and other components
compatible with those created by previous projects and also with the existing hardware and
software platforms.

Step 2.2: Identify installation standards and procedures

Any organization that develops software should define their development procedures. As a
minimum, the normal stages in the software life cycle to be carried out should be documented
along with the products created at each stage. Change control and configuration management
standards should be in place to ensure that changes to requirements are implemented in a safe and
orderly way. The procedural standards may lay down the quality checks that need to be done at
each point of the project life cycle or these may be documented in a separate quality standards and
procedures manual. The organization, as part of its monitoring and control policy, may have a
measurement programme in place which dictates that certain statistics have to be collected at
various stages of a project. Finally the project manager should be aware of any project planning and
control standards. These will relate to how the project is controlled: for example, the way that the
hours spent by team members on individual tasks are recorded on timesheets. control.

Step 2.3: Identify project team organization

15
Project leaders, especially in the case of large projects, might have some control over the way that
their project team is to be organized. Often, though, the organizational structure will be dictated to
them. For example, a high-level managerial decision might have been taken that software
developers and business analysts will be in different groups, or that the development of business-to-
consumer web applications will be done within a separate group from that responsible for
‘traditional’ database applications.
If the project leader does have some control over the project team organization then this would best
be considered at a later stage (see Step 7: Allocate resources).

Step 3: Analyse project characteristics

The general purpose of this part of the planning operation is to ensure that the appropriate methods
are used for the project.

Step 3.1: Distinguish the project as either objective- or product-driven

This has already been discussed. As development of a system advances it tends to become more
product-driven, although the underlying objectives always remain and must be respected.

Step 3.2: Analyse other project characteristics (including quality-based ones)

For example, is an information system to be developed or a process control system, or will there be
elements of both? Will the system be safety critical, where human life could be threatened by a
malfunction?

Step 3.3: Identify high-level project risks

Consideration must be given to the risks that threaten the successful outcome of the project.
Generally speaking, most risks can be attributed to the operational or development environment, the
technical nature of the project or the type of product being created.

Step 3.4: Take into account user requirements concerning implementation

The clients may have their own procedural requirements. For example, an organization might
mandate the use of a particular development method.

16
Step 3.5: Select development methodology and life-cycle approach
The development methodology and project life cycle to be used for the project will be influenced by
the issues raised above. The idea of a methodology, that is, the group of methods to be used in a
project, was already discussed. For many software developers, the choice of methods will seem
obvious: they will use the ones that they have always used in the past.. While the setting of
objectives involves identifying the problems to be solved, this part of planning is working out the
ways in which these problems are to be solved. For a project that is novel to the planner, some
research into the methods typically used in the problem domain is worthwhile. For example,
sometimes, as part of a project, a questionnaire survey has to be conducted. There are lots of books
on the techniques used in such surveys and a wise move would be to look at one or two of them at
the planning stage.

Step 3.6: Review overall resource estimates

Once the major risks have been identified and the broad project approach has been decided upon,
this would be a good point at which to re-estimate the effort and other resources required to
implement the project. Where enough information is available an estimate based on function points
might be appropriate.

Step 4: Identify project products and activities

The more detailed planning of the individual activities now takes place. The longer-term planning is
broad and in outline, while the more immediate tasks are planned in some detail.

Step 4.1: Identify and describe project products (or deliverables)

Identifying all the things the project is to create helps us to ensure that all the activities we need to
carry out are accounted for. Some of these products will be handed over to the client at the end of
the project – these are deliverables. Other products might not be in the final configuration, but are
needed as intermediate products used in the process of creating the deliverables. These products
will include a large number of technical products, such as training material and operating
instructions. There will also be products to do with the management and the quality of the project.
Planning documents would, for example, be management products. The products will form a

17
hierarchy. The main products will have sets of component products which in turn may have sub-
component products and so on. These relationships can be documented in a Product Breakdown
Structure (PBS) – see Figure 1.5. In this example the products have been grouped into those relating
to the system as a whole, and those related to individual modules. A third ‘group’, which happens to
have only one product, is called ‘management products’ and consists of progress reports. The
asterisk in the progress reports indicates that there will be new instances of the entity ‘progress
report’ created repeatedly throughout the project. Note that in Figure 1.5 the only boxes that
represent tangible products are those at the bottom of the hierarchy that are not further subdivided.
Thus there are only six individual product types shown in the diagram. The boxes that are higher up
– for example ‘module products’ – are simply the names of groups of items. Some products are
created from scratch, for example new software components. A product could quite easily be a
document, such as a software design document. It might be a modified version of something that
already exists, such as an amended piece of code. A product could even be a person, such as a
‘trained user’, a product of the process of training. These specify that products at the bottom of the
PBS should be documented by Product Descriptions which contain:

• the name/identity of the product;

• the purpose of the product;
• the derivation of the product (that is, the other products from which it is derived);

18
 Fig 1.5 A fragment of a Product Breakdown Structure for a system development task

• the composition of the product;

• the form of the product;
• the relevant standards;
• the quality criteria that define whether the product is acceptable.

19
 Fig 1.6 A Product Breakdown Structure (PBS) for the products needed to produce an invitation to
tender (ITT)

Step 4.2: Document generic product flows

Some products will need one or more other products to exist first before they can be created. For
example, a program design must be created before the program can be written and the program
specification must exist before the design can be commenced. These relationships can be portrayed
in a Product Flow Diagram (PFD). Figure 1.7 gives an example. Note that the ‘flow’ in the diagram
is assumed to be from top to bottom and left to right.

In the example in Figure 1.7, ‘user requirements’ is in an oval which means that it is used by the
project but is not created by it. It is often convenient to identify an overall product at the bottom of
the diagram, in this case ‘integrated/tested software’, into which all the other products feed. PFDs
should not have links between products which loop back iteratively. This is emphatically
notbecause iterations are not recognized. On the contrary, the PFD allows for looping back at any
point. For example, in the PFD shown in Figure 1.7, say that during integration testing it was found
that a user requirement had been missed in the overall system specification. If we go back to overall

20
system specification and change it we can see from the PFD that all the products that follow it
might need to be reworked. A new

Fig 1.7 A fragment of a Product Flow Diagram (PFD) for a software development task

module might need to be designed and coded, test cases would need to be added to check that the
new requirements had been successfully incorporated, and the integration testing would need to be
repeated. The form that a PFD takes will depend on assumptions and decisions about how the
project is to be carried out. These decisions may not be obvious from the PFD and so a textual
description explaining the reasons for the structure can be helpful.

Step 4.3: Recognize product instances

Where the same generic PFD fragment relates to more than one instance of a particular type of
product, an attempt should be made to identify each of those instances. In the example in Figure
1.5, it could be that in fact there are just two component software modules in the software to be
built.

21
Step 4.4: Produce ideal activity network

In order to generate one product from another there must be one or more activities that carry out the
transformation. By identifying these activities we can create an activity network which shows the
tasks that have to be carried out and the order in which they have to be executed.

The activity networks are ‘ideal’ in the sense that no account has been taken of resource constraints.
For example, in Figure 1.8, it is assumed that resources are available for both software modules to
be developed in parallel. A good rule is that activity networks are never amended to take account of
resource constraints.

Fig 1.8 An example of an activity network

Step 4.5: Modify the ideal to take into account need for stages and checkpoints

The approach to sequencing activities described above encourages the formulation of a plan which
will minimize the overall duration, or ‘elapsed time’, for the project. It assumes that an activity will

22
start as soon as the preceding ones upon which it depends have been completed. There might,
however, be a need to modify this by dividing the project into stages and introducing checkpoint
activities. These are activities which draw together the products of preceding activities to check that
they are compatible. This could potentially delay work on some elements of the project – there has
to be a trade-off between efficiency and quality. The people to whom the project manager reports
could decide to leave the routine monitoring of activities to the project manager. However, there
could be some key activities, or milestones, which represent the completion of important stages of
the project of which they would want to take particular note. Checkpoint activities are often useful
milestones.

Step 5: Estimate effort for each activity

Step 5.1: Carry out bottom-up estimates

Some overall estimates of effort, cost and duration will already have been done (see Step 3.6). At
this point, estimates of the staff effort required, the probable elapsed time and the non-staff
resources needed for each activity will need to be produced. The method of arriving at each of these
estimates will vary depending on the type of activity.
The difference between elapsed time and effort should be noted. Effort is the amount of work that
needs to be done. If a task requires three members of staff to work for two full days each, the effort
expended is six days. Elapsed time is the time between the start and end of a task. In our example
above, if the three members of staff start and finish at the same time then the elapsed time for the
activity would be two days.
The individual activity estimates of effort should be summed to get an overall bottom-up estimate
which can be reconciled with the previous top-down estimate.
The activities on the activity network can be annotated with their elapsed times so that the overall
duration of the project can be calculated.

Step 5.2: Revise plan to create controllable activities

23
The estimates for individual activities could reveal that some are going to take quite a long time.
Long activities make a project difficult to control. If an activity involving system testing is to take
12 weeks, it would be difficult after six weeks to judge accurately whether 50 per cent of the work
is completed. It would be better to break this down into a series of smaller subtasks.

There might be a number of activities that are important, but individually take up very little time.
For a training course, there might be a need to book rooms and equipment, notify those attending,
register students on the training system, order refreshments, copy training materials and so on. In a
situation like this it would be easier to bundle the activities into a single merged activity ‘make
training course arrangements’ which could be supplemented with a checklist.

In general, try to make activities about the length of the reporting period used for monitoring and
controlling the project. If you have a progress meeting every two weeks, then it would convenient
to have activities of two weeks’ duration on average, so that progress meetings would normally be
made aware of completed tasks each time they are held.

Step 6: Identify activity risks

Step 6.1: Identify and quantify activity-based risks
Risks inherent in the overall nature of the project have already been considered in Step 3. We now
want to look at each activity in turn and assess the risks to its successful outcome. Any plan is
always based on certain assumptions. Say the design of a component is planned to take five days.
This is based on the assumption that the client’s requirement is clear and unambiguous. If it is not
then additional effort to clarify the requirement would be needed.
The possibility that an assumption upon which a plan is based is incorrect constitutes a risk. In this
example, one way of expressing the uncertainty would be to express the estimate of effort as a
range of values.

A project plan will be based on a huge number of assumptions, and so some way of picking out the
risks that are most important is needed. The damage that each risk could cause and the likelihood of
it occurring have to be gauged. This assessment can draw attention to the most serious risks. The
usual effect if a problem materializes is to make the task longer or more costly.

24
Step 6.2: Plan risk reduction and contingency measures where appropriate
It may be possible to avoid or at least reduce some of the identified risks. On the other hand,
contingency plans specify action that is to be taken if a risk materializes. For example, a
contingency plan could be to use contract staff if a member of the project team is unavailable at a
key time because of serious illness.

Step 6.3: Adjust overall plans and estimates to take account of risks
We may change our plans, perhaps by adding new activities which reduce risks. For example, a new
programming language might mean we schedule training courses and time for the programmers to
practise their new programming skills on some non-essential work.

Step 7: Allocate resources

Step 7.1: Identify and allocate resources
The type of staff needed for each activity is recorded. The staff available for the project are
identified and are provisionally allocated to tasks.

Step 7.2: Revise plans and estimates to take into account resource constraints
Some staff may be needed for more than one task at the same time and, in this case, an order of
priority is established. The decisions made here may have an effect on the overall duration of the
project when some tasks are delayed while waiting for staff to become free. Ensuring someone is
available to start work on an activity as soon as the preceding activities have been completed might
mean that they are idle while waiting for the job to start and are therefore used inefficiently. The
product of Steps 7.1 and 7.2 would typically be a Gantt chart – see Figure 1.9. The Gantt chart
gives a clear picture of when activities will actually take place and highlights which ones will be
executed at the same time. Activity networks can be misleading in this respect.

25
 Fig 1.9 Gantt chart showing when staff will be carrying out tasks

Step 8: Review/publicize plan

Step 8.1: Review quality aspects of the project plan
A danger when controlling any project is that an activity can reveal that an earlier activity was not
properly completed and needs to be reworked. This, at a stroke, can transform a project that appears
to be progressing satisfactorily into one that is badly out of control. It is important to know that
when a task is reported as completed, it really is – hence the importance of quality reviews. Each
task should have quality criteria. These are quality checks that have to be passed before the activity
can be ‘signed off’ as completed.

26
Step 8.2: Document plans and obtain agreement
It is important that the plans be carefully documented and that all the parties to the project
understand and agree to the commitments required of them in the plan. This may sound obvious,
but it is amazing how often this is not done.

Steps 9 and 10: Execute plan/lower levels of planning

Once the project is under way, plans will need to be drawn up in greater detail for each activity as it
becomes due. Detailed planning of the later stages will need to be delayed because more
information will be available nearer the start of the stage. Of course, it is necessary to make
provisional plans for the more distant tasks, because thinking about what needs to be done can help
unearth potential problems, but sight should not be lost of the fact that these plans are provisional.

J. Conclusion
This chapter has presented a framework into which the techniques described in the other parts of the
book should slot. It is suggested that any planning approach should have the following elements:

 the establishment of project objectives;

 the analysis of the characteristics of the project;
 the establishment of an infrastructure consisting of an appropriate organization and set of
standards, methods and tools;
 the identification of the products of the project and the activities needed to generate those
products;
 the allocation of resources to activities;
 the establishment of quality controls.

Project planning is an iterative process. As the time approaches for particular activities to be carried
out they should be replanned in more detail.

27
 UNIT II

PROJECT EVALUATION
Strategic Assessment – Technical Assessment – Cost Benefit Analysis –Cash Flow
Forecasting – Cost Benefit Evaluation Techniques – Risk Evaluation.

STRATEGIC ASSESSMENT

SAM(model)decomposes a strategic problem into clearly defined components in which all

alternatives, factors, weights, and probabilities are depicted. Next, objective information and
subjective judgements of experts are integrated by utilising several methods of problem structuring
and information processing.

This decomposition and evaluation is not intended to replace the Decision-makers, rather, it
provides a systematic approach to support, supplement, and ensure the internal consistency of their
judgements through a series of logically sound techniques.

SAM divides the decision making environment into three parts:

 Internal environment: the set of relevant factors that form the profile of the internal
operations of the organisation,
 Task environment: The set of relevant factors that have direct transactions with the
organisation. The influence between these factors is reciprocal, and
 General environment: The set of relevant factors that can exert considerable influence on the
organisation. The organisation, however, has little or no impact on such factors.

The process consists of eight steps and uses an algebraic model together with a *software version
("Expert Choice") of Saaty's Analytical Hierarchy process (AHP) to calculate risk adjusted strategic
values for each alternative. The eight steps are:

1. Generate strategic alternatives. (Brainstorming etc.) Alternatives are the set of potential
means by which the stated objectives may be obtained. There must be at least two mutually
exclusive alternatives in the set to permit a choice to be made.
2. Identify the relevant (those which can be exploited by the strategic alternatives)
opportunities and threats and group them into internal, task and general sets of
environmental factors.
3. Define environmental weights (using AHP)
4. Calculate the initial weights associated with the opportunities and threats.
5. Develop subjective probabilities for each alternative.
6. Calculate the overall importance weight for the opportunities and threats.
7. Measure the Decision-Maker's risk-aversion constant for the opportunities and threats (using
certainty equivalence rather than gain or loss equivalence)
8. Calculate the risk adjusted strategic value for each alternative.

28
TECHNICAL ASSESSMENT

Assessment (analysis and normative evaluation) of a particular technical device, system, or

procedure with regard to a defined set of criteria, goals or objectives

COST BENEFIT ANALYSIS

Cost-benefit analysis (CBA), sometimes called benefit-cost analysis (BCA), is an economic

decision-making approach, used particularly in government and business. CBA is used in the
assessment of whether a proposed project, programme or policy is worth doing, or to choose
between several alternative ones. It involves comparing the total expected costs of each option
against the total expected benefits, to see whether the benefits outweigh the costs, and by how
much.

Cost–benefit analysis is often used by governments and others, e.g. businesses, to evaluate the
desirability of a given intervention. It is an analysis of the cost effectiveness of different alternatives
in order to see whether the benefits outweigh the costs (i.e. whether it is worth intervening at all),
and by how much (i.e. which intervention to choose). The aim is to gauge the efficiency of the
interventions relative to each other and the status quo.

Valuation

The costs of an intervention are usually financial. The overall benefits of a government intervention
are often evaluated in terms of the public's willingness to pay for them, minus their willingness to
pay to avoid any adverse effects. The guiding principle of evaluating benefits is to list all parties
affected by an intervention and place a value, usually monetary, on the (positive or negative) effect
it has on their welfare as it would be valued by them. Putting actual values on these is often
difficult; surveys or inferences from market behavior are often used.

One source of controversy is placing a monetary value of human life, e.g. when assessing road
safety measures or life-saving medicines. However, this can sometimes be avoided by using the
related technique of cost-utility analysis, in which benefits are expressed in non-monetary units
such as quality-adjusted life years. For example, e.g. road safety can be measured in terms of 'cost
per life saved', without placing a financial value on the life itself.

Another controversy is the value of the environment, which in the 21st century is sometimes
assessed by valuing it as a provider of services to humans, such as water and pollination. Monetary
values may also be assigned to other intangible effects such as loss of business reputation, market
penetration, or long-term enterprise strategy alignments.

Time

CBA usually tries to put all relevant costs and benefits on a common temporal footing using time
value of money formulas. This is often done by converting the future expected streams of costs and

29
benefits into a present value amount using a suitable discount rate. Empirical studies suggest that in
reality, people do discount the future like this.

There is often no consensus on the appropriate discount rate to use - e.g. whether it should be small
(thus putting a similar value on future generations as on ourselves) or larger (e.g. a real interest rate
or market rate of return, on the basis that there is a theoretical alternative option of investing the
cost in financial markets to get a monetary benefit). The rate chosen usually makes a large
difference in the assessment of interventions with long-term effects, such as those affecting climate
change, and thus is a source of controversy. One of the issues arising is the equity premium puzzle,
that actual long-term financial returns on equities may be rather higher than they should be; if so
then arguably these rates of return should not be used to determine a discount rate, as doing do
would have the effect of largely ignoring the distant future.

Risk and uncertainty

Risk associated with the outcome of projects is also usually taken into account using probability
theory. This can be factored into the discount rate (to have uncertainty increasing over time), but is
usually considered separately. Particular consideration is often given to risk aversion - that is,
people usually consider a loss to have a larger impact than an equal gain, so a simple expected
return may not take into account the detrimental effect of uncertainty.

Uncertainty in the CBA parameters (as opposed to risk of project failure etc.) is often evaluated
using a sensitivity analysis, which shows how the results are effected by changes in the parameters.

CASH FLOW FORECASTING

Cash flow forecasting is a key aspect of financial management of a business, planning its future
cash requirements to avoid a crisis of liquidity.

Definition

In the context of corporate finance, cash flow forecasting is the modeling of a company or entity’s
future financial liquidity over a specific timeframe. Cash usually refers to the company’s total bank
balances, but often what is forecast is treasury position which is cash plus short-term investments
minus short-term debt. Cash flow is the change in cash or treasury position from one period to the
next.

Methods

The direct method of cash flow forecasting schedules the company’s cash receipts and
disbursements (R&D). Receipts are primarily the collection of accounts receivable from recent
sales, but also include sales of other assets, proceeds of financing, etc. Disbursements include
payroll, payment of accounts payable from recent purchases, dividends and interest on debt. This

30
direct R&D method is best suited to the short-term forecasting horizon of 30 days or so because this
is the period for which actual, as opposed to projected, data is available.

The three indirect methods are based on the company’s projected income statements and balance
sheets. The adjusted net income (ANI) method starts with operating income (EBIT or EBITDA)
and adds or subtracts changes in balance sheet accounts such as receivables, payables and
inventories to project cash flow. The pro-forma balance sheet (PBS) method looks straight at the
projected book cash account; if all the other balance sheet accounts have been correctly forecast,
cash will be correct, too. Both the ANI and PBS methods are best suited to the medium-term (up to
one year) and long-term (multiple years) forecasting horizons. Both are limited to the monthly or
quarterly intervals of the financial plan, and need to be adjusted for the difference between accrual-
accounting book cash and the often-significantly-different bank balances.

The third indirect approach is the accrual reversal method (ARM), which is similar to the ANI
method. But instead of using projected balance sheet accounts, large accruals are reversed and cash
effects are calculated based upon statistical distributions and algorithms. This allows the forecasting
period to be weekly or even daily. It also eliminates the cumulative errors inherent in the direct,
R&D method when it is extended beyond the short-term horizon. But because the ARM allocates
both accrual reversals and cash effects to weeks or days, it is more complicated than the ANI or
PBS indirect methods. The ARM is best suited to the medium-term forecasting horizon.

Uses

A cash flow projection is an important input into valuation of assets, budgeting and determining
appropriate capital structures in LBOs and leveraged recapitalizations.

Entrepreneurial

Definition

In the context of entrepreneurs or managers of small and medium enterprises, cash flow forecasting
may be somewhat simpler, planning what cash will come into the business or business unit in order
to ensure that outgoing can be managed so as to avoid them exceeding cashflow coming in.
Entrepreneurs need to learn fast that "Cash is king" and therefore they must become good at
cashflow forecasting.

Methods

The simplest method is to have a spreadsheet that shows cash coming in from all sources out to at
least 90 days, and all cash going out for the same period. This requires that the quantity and timings
of receipts of cash from sales are reasonably accurate, which in turn requires judgement honed by
experience of the industry concerned, because it is rare for cash receipts to match sales forecasts
exactly, and it is also rare for suppliers all to pay on time. These principles remain constant whether
the cash flow forecasting is done on a spreadsheet or on paper or on some other IT system.

31
A danger of using too much corporate finance theoretical methods in cash flow forecasting for
managing a business is that there can be non cash items in the cashflow as reported under financial
accounting standards. This goes to the heart of the difference between financial accounting and
management accounting.

Uses

The point of making the forecast of incoming cash is to manage the outflow of cash so that the
business remains solvent.

Cost – benefit evaluation techniques

We will take a brief look at some common methods for comparing projects on the basis of their
cash flow forecasts.

Net Profit
The net profit of a project is the difference between the total costs and the total income over the life
of the project. Project 2 in table 1. shows the greatest net profit but this is at the expense of a large
investment.

Payback Period
The payback period is the time taken to break even or pay back the initial investment. Normally, the
project with the shortest payback period will be chosen on the basis that an organization will wish
to minimize the time that a project is ‘indebt’.
The advantage of the payback period is that it is simple to calculate and is not particularly sensitive
to small forecasting errors. Its disadvantage as a selection technique is that it ignores the overall
profitability of the project-in fact, it totally ignores any income once the project has broken even.
Thus the fact that projects 2 and 4 are, overall, more profitable than project 3 is ignored.

Return on Investment
The return on investment (ROI), also known as the accounting rate of return (ARR), provides a way
of comparing the net profitability to the investment required. There are some variations on the
formula used to calculate the return on investment, but a straightforward common version is
ROI = (average annual profit /total investment) * 100

32
E.g. Calculating the ROI for project 1, the net profit is 50,000 and the total investment is 100,000.
The return on investment is therefore calculated as

ROI = (average annual profit /total investment) * 100

= (10,000 / 100,000) *100 = 10%
Advantages:
The return on investment provides a simple, easy to calculate measure of return on capital and is
therefore quite popular.
Disadvantages:
Net profitability, it takes no account of the timing of the cash flows. It is tempting to compare the
rate of return with the current interest rates. However, this rate of return bears no relationship to the
interest rates offered or charged by banks since it takes no account of the timing of the cash flows or
of the compounding of interest. It is potentially misleading.

Net Present Value

The calculation of net present value (NPV) is a project evaluation technique that takes into account
the profitability of a project and the timing of the cash flows that are produced. It does so by
discounting future cash flows by a percentage known as the discount rate. This is based on the view
that receiving 100 today is better than having to wait until neat year to receive it, because the 100
next year is worth less than 100 now. We could, for example, invest the 100 in a bank today and
have 100 plus the interest in a year’s time. If we say that the present value of 100 in a year’s time is
91, we mean that 100 in a year’s time is the equivalent of 91 now.
The equivalence of 91 now and 100 in a year’s time means we are discounting the future income by
approximately 10% - that is, we could need an extra 10% to make it worthwhile waiting for a year.
An alternative way of considering the equivalence of the two is to consider that, if we received 91
now and invested for a year at an annual interest rate of 10%, it would be worth 100 in a year’s
time. The annual rate by which we discount future earnings is known as the discount rate: 10% in
the above example. Similarly, 100 received in 2 year’s time would have a present value of
approximately 83 – In other words, 83 invested at an interest rate of 10% would yield
approximately 100 in 2 year’s time.
The present value of any future cash flow may be obtained by applying the following formula
Present value = value in a year t / (1+r)t

33
Where r is the discount rate, expressed as a decimal value and t is the number of years into the
future that the cash flow occurs.
Alternatively, and rather more easily, the present value of a cash flow may be calculated by
multiplying the cash flow by the appropriate discount factor. A small table of distant factors is
given in table 2.

Table 2. Table of NPV discount factors

The NPV for a project is obtained by discounting each cash flow and summing the discounted
values. It is normally assumed that any initial investment takes place immediately and is not
discounted. Later cash flows are normally assumed to take place at the end of each year and are
discounted by the appropriate amount.
It is interesting to note that the net present values for projects 1 and 3 are significantly different –
even though they both yield the same net profit and both have the same return on investment. The
difference in NPV reflects the fact that, with project 1, we must wait longer for the bulk of the
income.
The main difficulty with NPV for deciding between projects is selecting an appropriate discount
rate. Some organization have a standard rate but, where this is not the case, then the discount rate
should be chosen to reflect available interest rates plus some premium to reflect the fact that
software projects are inherently more risky than lending money to a bank. The exact discount rate is
used for all projects being compared. However, it is important to check that the ranking of projects
is not sensitive to small changes in the discount rate.

Internal Rate of Return

One disadvantage of NPV as a measure of profitability is that, although it may be used to compare
projects, it might not be directly comparable with earnings from other investments or the costs of
borrowing capital. Such costs are usually quote as a percentage interest rate. The internal rate of
return (IRR) attempts to provide a profitability measure as a percentage return that is directly
comparable with interest rates. Thus, a project that showed an estimated IRR of 10% or if the
capital could not be invested elsewhere for a return greater than 10%.
The IRR is calculated as that percentage discount rate that would produce NPV of zero. It is most
easily calculated using a spreadsheet or other computer program that provides functions for

34
calculating the IRR. Microsoft Excel for example, provide IRR functions which provided with an
initial guess seed value, will search for and return an IRR.
Manually it must be calculated by trial and error or estimated using the technique illustrated in
fig.2. This technique consists of guessing two values and using the resulting NPVs to estimate the
correct value. Note that the technique will provide only an approximate value but, in many cases
that will be sufficient to dismiss a project has a small IRR or indicate that it is worth making a more
precise evaluation.

The IRR is a convenient and useful measure of the value of a project in that it’s a single percentage
figure that may be directly compared with rates of return other projects or interest rates quoted
elsewhere.
Table 3. illustrates the way in which a project with an IRR of 10% may directly compared with
other interest rates. The cash flow for the project is shown in column (a). Columns (b) to (e) show
that if we were to invest 100,000 now an annual interest rate of 10% in, say a bank, we could
withdraw the same amounts as we would earn from the project at the end of

Table 3. A Project cash flow treated as an investment at 10%

each year, column (e), and we would be left with a net balance of zero at the end of each year,
column (e), and we would be left with a net balance of zero at the end. In other words, investing in
a project that has an IRR of 10% can produce exactly the same cash flow as lending the money to a
bank at a 10% interest rate. We can therefore reason that a project with an IRR greater than current
interest rates will provide a better rate of return than lending the investment to a bank. We can also
say that it will be worth borrowing to finance the project if it has an IRR greater than the interest
rate charged on the loan.
One deficiency of IRR is that it does not indicate the absolute size of the return. A project with an
NPV of 100,000 and an IRR of 15% can be more attractive than once with an NPV of 10,000 and
an IRR of 18% - the return on capital is lower but the net benefits greater.
An often quoted objection to the internal rate of return is that, under certain conditions, it is possible
to find more than one rate that will produce a zero NPV. This is not a valid objection since, if there
are multiple solutions, it is always appropriate to take the lowest value and ignore the others.
Spreadsheets will normally always return the lowest value if provided with zero as a seed value.
The NPV and IRR are not, however, a complete answer to economic project evaluation.

35
  A total evaluation must also take into account the problems of funding the cash flows – will
we, for example, be able to repay the interest on any borrowed money and pay development
staff salaries at the appropriate time?
 Write a project’s IRR might indicate a profitable project, future earnings from a project
might be far less reliable than earnings from, say investing with a bank. To take account of
the risk inherent in investing in a project, we might require that a project earn a ‘risk
premium’ or we might undertake a more detailed risk analysis as described in the following
sections.
 We must also consider any one project within the financial and economic framework of the
organization as a whole.
RISK EVALUATION

INTRODUCTION
In the previous chapter consideration was given to the identification of risk without considering
evaluation. In the forthcoming chapter it is intended to deal with some techniques for evaluating
risk. Although these two steps in the risk management process are dealt with separately in practice
this seldom happens. Risk are generally identified and evaluated at the same time and
considerations also given to control whilst viewing the risk. In this chapter a brief consideration will
be given to both qualitative and quantitative methods of evaluating risk. The former is more
common in organisations as, generally, insufficient data is available to carry out a quantitative
evaluation of risk. Both methods are valid methods of evaluating risk.

SUBJECTIVE AND OBJECTIVE METHODS OF EVALUATING RISK

There are two basic methods of evaluating risk, the subjective or qualitative method and the
objective method. Both are valid. The former allows an individual or group to provide opinions on
the riskiness of a particular situation without resorting to past data. Individuals who are conversant
with the system are asked to express their views on the extent of the risk involved in a particular
situation. Quantitative methods rely on the examination of past data and assume that this can be
projected into the future to establish a means of measurement of the risk concerned. The problem
with this is the availability of the data and its validity. In most organisations detailed information is
not kept of all losses that have occurred and, in any event, some risks are so rare that they have not
occurred therefore cannot be measured. To remedy this latter point information can be obtained
from industry at large to try to obtain the necessary data, but again questions can be raised as to its
validity. Despite this if record keeping is maintained accurately some effort can be made to
objectively measure risk.

WHY EVALUATE RISKS?

Although there are difficulties with measuring risk we need to carry out this task for the purpose of
prioritisation. It is necessary to ascertain which risks are greater than others to aid the decision
concerning which risks to handle. Large risks require urgent treatment whilst those that are minor

36
may require no handling at all. Also there may be budgetary restrictions that may impact on the
risks that can be handled. In view of this risks need to be measured in some form or another.

Risk involves two elements, frequency and severity. The first concerns the number of times a loss
could occur. For example a flood can happen within a particular area once every ten years or a
person could cut herself on a particular type of machine once every week. The event, once it occurs,
could involve different amounts of damage. Thus a flood in one year could affect the majority of
households in the area whilst in another year it is comparatively minor and affects very few people.
In calculating the size of the risk this should be taken into account. A further point that is often
omitted from risk evaluation is the cost of doing something about the risk. This is often necessary in
order to assist management in deciding what steps can be taken to deal with the risk.

QUANTITATIVE METHODS OF EVALUATING RISK

Frequency

The probability of a risk occurring involves its relative frequency. It is a measurement between zero
and one with the two extremes being total certainty. So that one represents certainty that an event
will occur whilst zero indicates that the loss is impossible. In reality zero and one are not measures
of probability because they represent certainty. The idea of a probability measurement is to measure
uncertainty that is represented at a figure greater than zero but less than one. The closer to one the
more likely an event is to occur whilst the closer to zero the less likely.

The relative frequency of an event is calculated from past data that has been adjusted to take into
account any changes that have occurred in the environment. Thus when evaluating road accidents in
Ireland the data obtained over the last ten years must be adjusted to take into account the increased
number of cars on the road. Other factors such as the relative severity of winters may have to be
considered. For example in one year there could have been a very severe winter which caused road
accidents to increase substantially as compared with other years. To establish whether there have
been any dramatic changes the information available about the area being considered should be
examined. The purpose of this is to ascertain whether there has been an unusual increase in the
number of times an event has occurred in a particular time period. If this is the case then an attempt
should be made to try to ascertain why this happened to see whether any adjustments have to be
made.

To calculate the probability of an event the number of times the event of interest occurred during a
particular time period should be ascertained and this is divided by the exposure to the event of
interest. This provides a probability of that event occurring. Thus an operators working on a
particular machine could have been injured five times during the past year. The machine has been
operating for eight hours a day for 340 days of the year, a total of 2720 hours. This is the exposure
to injury. If the number of accidents, five, is divided by the exposure, 2720, this gives the
probability of an accident occurring of 5/2720 or 0.0018 in any one working hour. This could be
compared with other events to ascertain the relative riskiness of this particular operation.

There are a number of problems involved in using this method in addition to the validity of the data.
The first is to decide what represents the exposure to the accident. Is it the number of hours the
machine is operating or the number of times an operator carries out a particular task? If
37
consideration is given to the probability of an aircraft crashing should the exposure be the number
of times it takes off and lands, these being the most dangerous parts of the flight, or should it be
hours in the air starting from take off. Normally the number of hours that the engine is switched on
is used in the case of aircraft. This therefore covers taxiing as well as take-off, flight and landings.
The reason this figure is used is because it is easily ascertainable as the engine hours are
automatically recorded for the purposes of routine maintenance. In other cases the most obvious
method of measuring exposure may not be available. For example the probability of an accident on
the road depends on the number of hours a particular driver is actually at the wheel of his or her car.
In some countries this data is unavailable whilst in others it is a requirement for licensing purposes.
Thus the most suitable data may not be available. Once a means of measuring exposure has been
decided upon this should be used throughout the risk evaluation process for the particular class of
risk.

Another decision to be made concerns the data being collected about the accidents. All incidents
where a possible accident could have occurred should be recorded in addition to those events where
an actual loss happened. Thus if a person is walking along a road and notices that the pavement is
broken and steps over it is an event which could have led to an accident but didn’t and theoretically
should have been recorded. Similarly when a car entering a roundabout just misses you this is also
an event which should be recorded. All these events are seldom recorded consequently data is
incomplete. It might also be too difficult to collect this information and a decision made not to do
so. Thus a decision will have to be made as to what data to collect and in calculating probabilities it
must be borne in mind the level of data being used when making decisions.

Severity

Severity involves the extent of the possible loss, how much damage has been caused by the event of
interest. If personal injuries are involved there is some difficulty in evaluating the injury concerned.
For example how do you value the loss of an arm or the death of an individual? Damages awarded
in a court of law could be used as a basis although these are uncertain, as they are dependent on a
whole variety of factors. Economists have made attempts to value life by asking individual what
they would forego to remain alive but most of these attempts have been fairly artificial.

Evaluating property is also not so simple as it sounds. Questions concerning whether the market
price of the actual item concerned is to be used or its replacement value have to be considered. In
considering the value of buildings the replacement cost is quite often very different from the market
value. In this case questions as to whether the organisation would be prepared to move to a new site
should its existing building be destroyed or whether they wish to rebuild the existing structure
would have to be considered. A further point in considering the evaluation of property is the
question of depreciation and obsolescence. If plant is old and requires replacing with modern
machinery it may be of little value due to its obsolescence and this should be brought into the
calculations

Furthermore values change over time and this will also have to be taken into account. If a loss
occurred five years ago and payments were made these will have to be adjusted to take into account
the time value of money when calculating possible future losses. Also the time value of money in
the future will have to be taken into account so that when calculating the possibility of losses in the

38
future the change of value in money is also taken into account. This is usually done by applying the
rate of inflation over the period in question to past losses and expected inflation to future
occurrences and then use the concept of present value to bring the values back to today’s date.

EXPECTED VALUE

The concept of expected value is one method used to compare risks. This takes into account both
the severity and frequency of a particular occurrence. Thus the probability of a fire occurring during
a particular year may be 0.01 and the damage arising is calculated at £10,000 the expected loss is
0.01 x 10,000 giving an expected value of £100. This means to say that, on average, one would be
expected to pay £100 per annum for a particular loss.

In calculating expected value all eventualities should be taken into account. Taking the example of
a fire a table is drawn up showing all the losses that could possibly occur and categorising the result
into bands as shown in table 1.

You will note that as all possibilities are covered the total of the column representing probabilities
equals one. The expected value is calculated by multiplying the probability by the mid point of the
value as shown in table two.

Table 1 Record of fire damage.

Value of damage Probability of occurrence
0 0.97
>0 < 1,000 0.02
>1000 <2000 0.003
>2000 <3000 0.005
>3000 <4000 0.001
>4000<5000 0.001

TABLE 2. EXPECTED VALUE CALCULATION

Value Mid-point Probability Probability x mid
point
0 0 0.97 0.0
>0 < 1,000 500 0.02 10.0
>1000 <2000 1500 0.003 45.0
>2000 <3000 2500 0.005 12.5
>3000 <4000 3500 0.001 3.5
>4000<5000 4500 0.001 4.5
Total 1 75.5

This means that on average, in the long run, the organisation can expect, per unit of exposure, an
expected loss of £75.5 per annum. This could be compared with another situation to where the

39
expected value has been calculated to ascertain which is the highest risk in terms of frequency in
severity.

In some cases the expected loss could turn out to be the same or similar although the raw figures are
quite different. To compare these instances the concept of the standard deviation can be used. This
is the average difference between the basic data and the expected loss. If table three is considered
you will note that the data is different but the expected loss is similar.
Table 3 Expected value calculations.
Mid-point Probability
Value Probability x mid-point
0 0 .999931 0
>0 <10000 5000 0.004 20
>1000<20000 15000 0.002 30
>20000<30000 25000 0.0005 12.5
>30000<40000 35000 0.0003 10.5
>40000<50000 45000 0.0001 4.5
1 77.5

The standard deviation is calculated by squaring the mid-point of the range of values and
multiplying this by the probability of the event occurring and deducting this from the expected
value which has been squared. Totalling this figure and then finding the square root. This is
depicted in tables four and five.

Table 4 Standard deviation of example 1.

Probability x Square of Expected value Difference
mid-point Probability x mid- squared
point
0 0 6006.25 6006.25
20 400 6006.25 5606.25
30 900 6006.25 5106.25
12.5 156.25 6006.25 5850
10.5 110.25 6006.25 5896
4.5 20.25 6006.25 5986
Total = Variance 34450.75
Square root of =Standard 185.609132
variance deviation

TABLE 5 STANDARD DEVIATION OF EXAMPLE 2

Mid-point x Previous column Expected value Difference
probability squared squared
0 0 5700.25 5700.25
10 100 5700.25 5600.25
45 2025 5700.25 3675.25
12.5 156.25 5700.25 5544

40
 3.5 12.25 5700.25 5688
4.5 20.25 5700.25 5680
Total = variance 31887.75
Square root Standard 178.5714
deviation

The standard deviation in the second example is less than that in the first and therefore it can be said
to be less uncertain or less risky. Therefore in making a decision the first case would be dealt with
before the second.

In calculating the se figures the mean of the values could be used rather than midpoints. The mean
is basically an average and is calculated by totalling all the numbers involved and dividing them by
the number of unknowns. Thus the mean of the four number 34, 45, 50, 23 is 152/ 4 = 38. When
using small samples the means of calculating the mean is by taking the sum of the members of the
sample and dividing them by the number in the sample less one.

Qualitative risk assessment

Due to the lack of data and problems with its validity qualitative methods are often used to measure
risk. There are a number of ways this could occur. One way is to state that the risk in a particular
circumstance is high, medium or low. The problem with this is that there is some difficulty in
defining what is meant by these terms. One person's high could be another's low. Furthermore if
this terminology were used for the severity it would be difficult to combine with the frequency to
provide a risk score. If it encompasses both frequency and severity then only maximum losses are
considered.

A method that has been applied successfully is to use a scoring mechanism for both severity and
frequency. Each risk is scored between 1 and 5 for severity and frequency, five representing the
highest and one the lowest.

In order to ensure that everybody involved in the organisation knows what the symbols used to
measure risk mean a definition of the numbers one to five is adopted. An example is given in
diagrams six and seven, the former referring to severity and the latter frequency. In considering a
risk a number for severity is allocated and placed on the form referred to in the previous chapter.
DIAGRAM 6 - SEVERITY OF RISK
SEVERITY Affect on Affect on property Personal injury
Objectives
1 Does not affect Less than 20% of Minor cuts and
objectives the firm's property bruises
damaged.
2 Reduces the Between 20% and Injuries which
possibility of 40% of the firm's would mean at least
achieving the property damaged three days off work
organisational
objectives by 25%
3 Reduce the Between 40% and Injuries involving
possibility of 75% of the firm's at least 18 months

41
 achieving the property being recovery period
organisational damaged and at least 3 days
objectives by 50% off work. Loss of a
finger or toe.
4 Reduces the Between 75 and Loss of one eye,
possibility of less than 100% of loss of hearing in
achieving the organisation's one ear, a limb,
organisational property being hands or foot.
objectives by 75% damaged
5 Reduces the Total loss of all Paraplegia, death
possibility of property.
achieving
organisational
objectives by 100%
DIAGRAM 7 - FREQUENCY OF RISK
FACTOR Possible frequency of occurrence
1 Happens in excess of once every 50 years
2 Happens in excess of every 5 years but
less than 50 years
3 Happens less than once a year but more
than once every five years
4 Happens more than once a year but less
than once a week
5 Happens more than once a week

In the same way frequency has to be measured. In order to do this we need to know how often the
risk could occur. Is it monthly, weekly, annually, or every 100 years? If a risk has high severity but
low frequency different action will have to be taken from one which has high severity and
frequency. As discussed above it is necessary to combine frequency and severity to calculate an
expected loss. That is to say a figure that takes into account how often the loss could occur and how
much it will cost needs to be developed. In order to be able to achieve this records should be
available either within the organisation or the industry to ascertain how often the risk occurs.
Unfortunately this information is seldom available consequently other means of calculating severity
has to be found. Knowledgeable people in the industry are quite often able to advise how often
particular losses occur from their own experience. This is subjective but better than nothing. It must
be born in mind that organisations differ in their approach to risk, Places who take more care are
less likely to have accidents than those who do not so the frequency of accidents in one organisation
could be less than another within the same industry.

Once again the figures one to five could be used as a way of measuring the frequency of events. In
order to do this it must be agreed what each figure represents with five being high severity and one
being low. Diagram seven is an example of a table showing how the measurements one to five can
be allocated. One could represent a frequency of one accident in excess of every ten years whilst
five could be one accident per day.

42
Once the severity and frequency have been measured this can be used to produce an expected loss
or risk factor. For example if a risk has a frequency of one and a severity of five this could be
multiplied together to produce a risk factor of five. Another risk could have a frequency of four and
a severity of five giving a risk factor of twenty. This means that the second risk is higher than the
first and should be dealt with as soon as possible, or at least before the initial one is dealt with. If
each risk is measured in this fashion using the form referred to earlier then risks can be prioritised.
In the event of two risks having the same risk factor, but different severity or frequency, a decision
can be made based on the level of the most important factor in the view of the organisation. Thus a
risk could have a severity of two and a frequency of four and another a severity of four and a
frequency of two, both giving a risk factor of eight. A decision will have to be made as to whether
the severity or the frequency is the most important. If it is severity then the second risk will take
priority.

A third factor that needs to be taken into account is the cost of implementing loss control work in
order to reduce risk. This again can be measured by using the numbers one to five. Low cost is one
and high cost is five. This can be included in the calculation by dividing the risk factor by the cost
giving a costed risk factor. Again the numbers one to five will have to be defined and an example is
given in diagram eight. Thus if a risk has a severity of five, a frequency of two and a cost of three
then the risk factor is five multiplied by two giving ten. This is divided by three giving three point
three. This can be compared with a risk that has a severity of three and a frequency of two with a
cost of one giving a risk factor of six and a costed risk factor of six. This means that the company
could carry out risk reduction on the first risk before deciding whether the second can be dealt with.
DIAGRAM 8 - COST
Factor Cost
1 Less than 5,000
2 Between 5,000 and 25,000
3 Between 25,000 and 50,000
4 Between 25,000 and 100,000
5 More than 100,000

This leads to a hierarchy of decision making. A list is formulated indicating the costed risk factor
together with the number of risks that it represents and the accrued cost of work to be carried out.
Diagram nine depicts an example. The first risk has a costed risk factor of twenty that includes a
cost of reduction of £5000. This is entered in the last column in diagram nine. The second item has
a cost risk factor of six and there are two risks at this level. Each would cost £25,000 to reduce
giving a total cost of £55,000. This procedure is used right through the list until a final accumulated
cost is calculated, in this case £255,000. If the organisation has a budget of £100,000 to spend on
risk reduction this means that the first three risks can be handled provided a further £5,000 can be
obtained.
Diagram 9 - Hierarchy of risks

Severity Frequency Cost Costed risk Number Accumulated

(S) (F) (C) factor of risks cost
(S*F/C)
4 5 1 20 1 5,000
3 4 2 6 2 55,000

43
2 4 3 2.7 1 105,000
1 3 2 1.5 2 155,000
5 1 5 1 1 255,000

The main problem with this method of measuring risk is its subjectivity. Judgements are made
concerning the levels of the three factors involved in measuring risk. Although agreement has been
reached on what the numbers one to five mean there could be disagreements in fitting a risk into
one of these categories. Despite this the method is useful for prioritising risk.

44
 UNIT III
ACTIVITY PLANNING
Objectives – Project Schedule – Sequencing and Scheduling Activities –Network
Planning Models – Forward Pass – Backward Pass – Activity Float – Shortening Project
Duration – Activity on Arrow Networks – Risk Management – Nature Of Risk – Types Of
Risk – Managing Risk – Hazard Identification – Hazard Analysis – Risk Planning And
Control.

Identifying Project Activities :

Every project is a group of several activities. The expected project outcome can be achieved only
when all required activities are identified, planned for, and implemented. The WBS is an useful tool
that enables the project manager to identify all the activities and put them in proper sequence.

The WBS helps the project manager to have a clear vision of the entire project and overall
processes required to achieve project objectives. The WBS which breaks down the project into
several activities, can be used both as a planning and a reporting tool. The project manager should
ensure that the WBS is flexible and that changes can be incorporated when needed. While
sequencing the activities, the project manager can use one of two approaches: a top-down approach
or a bottom-up approach.
Identifying Project Activities - An Overview
Activity Definition
Work Breakdown Structure
Factors Considered in Developing a WBS
Uses of WBS
Developing a WBS
Top-down Approach
Bottom-up Approach
Test for Completeness of Decomposition of Activities
Measurable
Bounded
Deliverable
Simplicity in Estimating Cost/Time
Acceptable Duration Limit
Activity Independence
Approaches to Defining Deliverables in the WBS
Noun-type Approaches
Verb-type Approaches
Organizational Approaches
Representing the WBS

45
PROJECT SCHEDULE

Scheduling is an inexact process in that it tries to predict the future. While it is not possible to know
with certainty how long a project will take, there are techniques that can increase your likelihood of
being close. If you are close in your planning and estimating, you can manage the project to achieve
the schedule by accelerating some efforts or modifying approaches to meet required deadlines.

One key ingredient in the scheduling process is experience in the project area; another is experience
with scheduling in general. In every industry area there will be a body of knowledge that associates
the accomplishment of known work efforts with a time duration. In some industries, there are books
recording industry standards for use by cost and schedule estimators. Interviewing those who have
had experience with similar projects is the best way to determine how long things will really take.

When preparing a schedule estimate, consider that transition between activities often takes time.
Organizations or resources outside your direct control may not share your sense of schedule
urgency, and their work may take longer to complete. Beware of all external dependency
relationships. Uncertain resources of talent, equipment, or data will likely result in extending the
project schedule.

Experience teaches that things usually take longer than we think they will, and that giving away
schedule margin in the planning phase is a sure way to ensure a highly stressed project effort.
People tend to be optimistic in estimating schedules and, on average, estimate only 80% of the time
actually required.

Failure to meet schedule goals is most often due to unrealistic deadlines, passive project execution,
unforeseen problems, or things overlooked in the plan.

The Gantt Chart

46
Taking its name from early project management innovator Henry L. Gantt, the basic Gantt chart is
an easy way to document schedules. It is a horizontal-bar schedule showing activity start, duration,
and completion. It shows the connection between events and the calendar, and provides a graphical
analog of the activity duration.

The Gantt schedule can illustrate the relationship between work activities having duration, events
without duration that indicate a significant completion, and milestones that represent major
achievements or decision points. Various annotations can be used to communicate the progress of
the project effort compared to the baseline plan, as well to depict in a graphical way areas where
there are modified expectations from the baseline plan.

Once a Gantt schedule has been established for a project, progress should be periodically plotted
against the baseline schedule. If different functional areas are involved in a project, each area may
need its own detailed schedules to support the project master schedule. In such cases it is important
that working schedules be linked to a common master schedule in a way that they can be easily
updated. Each activity or event on the schedule should have a responsible individual assigned, so
there is clear ownership and so schedule status can be updated without a lot of fuss.

NETWORK PLANNING MODELS

FORWARD PASS

Figure  9-20.—Example  of  forward-pass  calculations. Early finish (EF)— Earliest time an
activity may  be  finished; Late start (LS)— Latest time an activity may be started and still remain
on schedule; and Late finish (LF)— Latest time an activity may be finished and still remain on
schedule. The main objective of forward-pass computations is  to  determine  the  duration  of  the
network.  The forward pass establishes the early start and finish of each activity and determines the
longest path through the network (critical path). The  common  procedure  for  calculating  the
project duration is to add activity durations successively, as shown in figure 9-20, along chains of
activities until a merge  is  found. At  the  merge,  the  largest  sum entering the activity is taken at
the start of succeeding activities. The addition continues to the next point of merger,  and  the  step
is  repeated.  The  formula  for forward-pass calculations is as follows: ES = EF of preceding
activity EF = ES + activity duration The   backward-pass latest possible start and computations
47
provide  the finish times that may take place  without  altering  the  network  relationships. These
values are obtained by starting the calculations at  the  last  activity  in  the  network  and  working
backward, subtracting the succeeding duration of an activity  from  the  early  finish  of  the  activity
being calculated.  When  a  “burst”  of  activities  emanating from the same activity is encountered,
each path is calculated.  The  smallest  or  multiple  value  is  recorded as the late finish. The
backward  pass  is  the  opposite  of  the  forward pass. During the forward pass, the early start is
added to the activity duration to become the early finish of that activity. During the backward pass,
the activity duration is subtracted from the late finish to provide the late start time of that activity.
This late start time then becomes the late finish of the next activity within the  backward  flow  of
the  diagram. LS = LF – activity duration Figure 9-21 shows a network with forward- and
backward-pass  calculations  entered. Figure  9-21.—Examp1e  of  forword-  and  backward-
pass  calculations. 9-21

BACKWARD PASS

ACTIVITY FLOAT

A number of different activity schedules can be developed from the critical path scheduling
procedure described in the previous section. An earliest time schedule would be developed by
starting each activity as soon as possible, at ES(i,j). Similarly, a latest time schedule would delay
the start of each activity as long as possible but still finish the project in the minimum possible time.
This late schedule can be developed by setting each activity's start time to LS(i,j).

Activities that have different early and late start times (i.e., ES(i,j) < LS(i,j)) can be scheduled to
start anytime between ES(i,j) and LS(i,j) as shown in Figure 10-6. The concept of float is to use part
or all of this allowable range to schedule an activity without delaying the completion of the project.
An activity that has the earliest time for its predecessor and successor nodes differing by more than
its duration possesses a window in which it can be scheduled. That is, if E(i) + Dij < L(j), then some
float is available in which to schedule this activity.

48
 Figure 10-6  Illustration of Activity Float

Float is a very valuable concept since it represents the scheduling flexibility or "maneuvering room"
available to complete particular tasks. Activities on the critical path do not provide any flexibility
for scheduling nor leeway in case of problems. For activities with some float, the actual starting
time might be chosen to balance work loads over time, to correspond with material deliveries, or to
improve the project's cash flow.

Of course, if one activity is allowed to float or change in the schedule, then the amount of float
available for other activities may decrease. Three separate categories of float are defined in critical
path scheduling:

1. Free float is the amount of delay which can be assigned to any one activity without delaying
subsequent activities. The free float, FF(i,j), associated with activity (i,j) is:

(10.9)

2. Independent float is the amount of delay which can be assigned to any one activity without
delaying subsequent activities or restricting the scheduling of preceding activities.
Independent float, IF(i,j), for activity (i,j) is calculated as:

49
 (10.10)

3. Total float is the maximum amount of delay which can be assigned to any activity without
delaying the entire project. The total float, TF(i,j), for any activity (i,j) is calculated as:

(10.11)

Each of these "floats" indicates an amount of flexibility associated with an activity. In all cases,
total float equals or exceeds free float, while independent float is always less than or equal to free
float. Also, any activity on a critical path has all three values of float equal to zero. The converse of
this statement is also true, so any activity which has zero total float can be recognized as being on a
critical path.

The various categories of activity float are illustrated in Figure 10-6 in which the activity is
represented by a bar which can move back and forth in time depending upon its scheduling start.
Three possible scheduled starts are shown, corresponding to the cases of starting each activity at the
earliest event time, E(i), the latest activity start time LS(i,j), and at the latest event time L(i). The
three categories of float can be found directly from this figure. Finally, a fourth bar is included in
the figure to illustrate the possibility that an activity might start, be temporarily halted, and then re-
start. In this case, the temporary halt was sufficiently short that it was less than the independent
float time and thus would not interfere with other activities. Whether or not such work splitting is
possible or economical depends upon the nature of the activity.

As shown in Table 10-3, activity D(1,3) has free and independent floats of 10 for the project shown
in Figure 10-4. Thus, the start of this activity could be scheduled anytime between time 4 and 14
after the project began without interfering with the schedule of other activities or with the earliest
completion time of the project. As the total float of 11 units indicates, the start of activity D could
also be delayed until time 15, but this would require that the schedule of other activities be
restricted. For example, starting activity D at time 15 would require that activity G would begin as
soon as activity D was completed. However, if this schedule was maintained, the overall completion
date of the project would not be changed.

Example 10-3: Critical path for a fabrication project

As another example of critical path scheduling, consider the seven activities associated with the
fabrication of a steel component shown in Table 10-4. Figure 10-7 shows the network diagram
associated with these seven activities. Note that an additional dummy activity X has been added to
insure that the correct precedence relationships are maintained for activity E. A simple rule to
observe is that if an activity has more than one immediate predecessor and another activity has at
least one but not all of these predecessor activity as a predecessor, a dummy activity will be

50
required to maintain precedence relationships. Thus, in the figure, activity E has activities B and C
as predecessors, while activity D has only activity C as a predecessor. Hence, a dummy activity is
required. Node numbers have also been added to this figure using the procedure outlined in Table
10-1. Note that the node numbers on nodes 1 and 2 could have been exchanged in this numbering
process since after numbering node 0, either node 1 or node 2 could be numbered next.
TABLE 10-4  Precedences and Durations for a Seven Activity Project
Activity Description Predecessors Duration
A Preliminary design --- 6
B Evaluation of design A 1
C Contract negotiation --- 8
D Preparation of fabrication plant C 5
E Final design B, C 9
F Fabrication of Product D, E 12
G Shipment of Product to owner F 3

Figure 10-7  Illustration of a Seven Activity Project Network

The results of the earliest and latest event time algorithms (appearing in Table 10-1) are shown in
Table 10-5. The minimum completion time for the project is 32 days. In this small project, all of the
event nodes except node 1 are on the critical path. Table 10-6 shows the earliest and latest start
times for the various activities including the different categories of float. Activities C,E,F,G and the
dummy activity X are seen to lie on the critical path.

TABLE 10-5  Event Times for a Seven Activity Project

Node Earliest Time E(i) Latest Time L(j)
0 0 0
1 6 7
2 8 8
3 8 8

51
 4 17 17
5 29 29
6 32 32

TABLE 10-6  Earliest Start, Latest Start and Activity Floats for a Seven Activity Project
Latest start time Free float
Activity Earliest start time ES(i,j) LS(i,j) Independent float Total float
A (0,1) 0 1 0 0 1
B (1,3) 6 7 1 0 1
C (0,2) 0 0 0 0 0
D (2,4) 8 12 4 4 4
E (3,4) 8 8 0 0 0
F (4,5) 17 17 0 0 0
G (5,6) 29 29 0 0 0
X (2,3) 8 8 0 0 0

SHORTENING PROJECT DURATION

The critical path is the place to look when you want to shorten a schedule. By definition, the critical
path is the sequence of tasks that is nothing but back-to-back work, with no slack, which you can
subtract to reduce the duration. Figure 1 shows that shortening the Build Ship Infrastructure task
won't do anything to shorten the overall project duration. Because the Build Improbability Drive
task is longer, it determines when the Assemble Components task starts, regardless of how little
time it takes to build the ship.

Figure 1: The tasks on the critical path are the only ones that can shorten the duration of a project.

52
ACTIVITY ON ARROW NETWORKS

The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a
model for project management designed to analyze and represent the tasks involved in completing a
given project. It is commonly used in conjunction with the critical path method or CPM.

Implementation

The first step to scheduling the project is to determine the tasks that the project requires and the
order in which they must be completed. The order may be easy to record for some tasks (e.g. When
building a house, the land must be graded before the foundation can be laid) while difficult for
others (There are two areas that need to be graded, but there are only enough bulldozers to do one).
Additionally, the time estimates usually reflect the normal, non-rushed time. Many times, the time
required to execute the task can be reduced for an additional cost or a reduction in the quality.

In the following example there are seven tasks, labeled A through G. Some tasks can be done
concurrently (A and B) while others cannot be done until their predecessor task is complete (C
cannot begin until A is complete). Additionally, each task has three time estimates: the optimistic
time estimate (O), the most likely or normal time estimate (M), and the pessimistic time estimate
(P). The expected time (TE) is computed using the formula (O + 4M + P) ÷ 6.

Time estimates Expected time

Activity Predecessor
Opt. (O) Normal (M) Pess. (P)
A — 2 4 6 4.00
B — 3 5 9 5.33
C A 4 5 7 5.17
D A 4 6 10 6.33
E B, C 4 5 7 5.17
F D 3 4 8 4.50

53
G E 3 5 8 5.17

Once this step is complete, one can draw a Gantt chart or a network diagram.

A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2)
the slack is the black lines connected to non-critical activities, (3) since Saturday and
Sunday are not work days and are thus excluded from the schedule, some bars on the Gantt
chart are longer if they cut through a weekend.

A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack
is not specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and
f), (3) since weekends are indicated by a thin vertical line, and take up no additional space
on the work calendar, bars on the Gantt chart are not longer or shorter when they do or don't
carry over a weekend.

RISK MANAGEMENT

54
Project risk management is an important aspect of project management. Risk Management is one
of the nine knowledge areas defined in PMBOK. Project Risk can be defined as unforeseen event or
activity that can impact the project progress, result or outcome in a positive or negative way. A risk
can be assesed using two factors: impact and probability.

If the probability is 1, it is an issue. This means that risk is already materialized. if the probability is
zero, this means that risk will not happen and should be removed from the risk register.

NATURE OF RISK

Risk is endemic, it exists in different contexts and understood in a variety of ways. We speak of
children being at risk or the risk of fire in a building or a bridge collapsing. If the many
understandings of risk are studied it can be argued that the term can be viewed as being on a
continuum of meaning ranging from the engineer’s view that risk can be measured using probability
to the view that risk is danger which is culturally determined (Holzheu, 1993)i. The common factors
that unite the many views as to the nature of risk are the fear of something going wrong together
with conditions of uncertainty. In other words the downside of life. If we are to be able to manage
risk its nature as viewed from different perspectives needs to be understood. In this chapter it is
intended to review the nature of risk.

TYPES OF RISK

Risk Low Medium High Very High

Schedule flaw Product will be Product has Product is most Product has
materializes useful three or four useful on an multiple
whenever put possible annual cycle or components
into production implementation must meet a cross-reliant on
dates legislated data; components
deadline must be released
according to
policy, academic
or legislated
deadline
 
People Leave the <5 5–9 10–14 >15
Project
 
Knowledge of Expert Familiar New to U of S Leading Edge to
Technology most universities
 
Knowledge of Replacement New processes, New processes, New processes,
products and does not with both developing developing

55
requirements involve business owner internal expertise internal expertise
developing during business and business with consultant without
course of the process change analyst having support consultant
project   experience with support
  implementing
  the product
Complexity Well defined; Well defined; Multiple Solution is
  no controversy some areas of approaches will unknown or
  or technical uncertainty can achieve the goal; vaguely defined
glitches be addressed choice to be made
expected early in the during course of
project project
 
Visibility of Project Affects Affects support Affects students, Affects students,
  department and technical instructors and faculty, staff in
support or personnel and support personnel many processes
technical instructors in in several used by all
personnel some colleges colleges colleges and
departments
Cost of Project Minimal impact Known & viable Contingency plan Contingency plan
Failure to the college or contingency plan is possible but cannot be
  department acting on it is not identified or is
desirable too costly to be
realistic
 
Project Consider splitting
Management the project for
Guidelines clarity and
success

MANAGING RISK

In project management, risk management includes the following activities:

 Planning how risk will be managed in the particular project. Plans should include risk
management tasks, responsibilities, activities and budget.
56
  Assigning a risk officer - a team member other than a project manager who is responsible
for foreseeing potential project problems. Typical characteristic of risk officer is a healthy
skepticism.
 Maintaining live project risk database. Each risk should have the following attributes:
opening date, title, short description, probability and importance. Optionally a risk may have
an assigned person responsible for its resolution and a date by which the risk must be
resolved.
 Creating anonymous risk reporting channel. Each team member should have possibility to
report risk that he/she foresees in the project.
 Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the
mitigation plan is to describe how this particular risk will be handled – what, when, by who
and how will it be done to avoid it or minimize consequences if it becomes a liability.
 Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent
for the risk management.

HAZARD IDENTIFICATION

After establishing the context, the next step in the process of managing risk is to identify potential
risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can
start with the source of problems, or with the problem itself.

 Source analysis[citation needed] Risk sources may be internal or external to the system that is the
target of risk management.

Examples of risk sources are: stakeholders of a project, employees of a company or the weather
over an airport.

 Problem analysis Risks are related to identified threats. For example: the threat of losing
money, the threat of abuse of privacy information or the threat of accidents and casualties.
The threats may exist with various entities, most important with shareholders, customers and
legislative bodies such as the government.

When either source or problem is known, the events that a source may trigger or the events that can
lead to a problem can be investigated. For example: stakeholders withdrawing during a project may
endanger funding of the project; privacy information may be stolen by employees even within a
closed network; lightning striking an aircraft during takeoff may make all people on board
immediate casualties.

The chosen method of identifying risks may depend on culture, industry practice and compliance.
The identification methods are formed by templates or the development of templates for identifying
source, problem or event. Common risk identification methods are:

 Objectives-based risk identificationOrganizations and project teams have objectives. Any

event that may endanger achieving an objective partly or completely is identified as risk.
 Scenario-based risk identification In scenario analysis different scenarios are created. The
scenarios may be the alternative ways to achieve an objective, or an analysis of the

57
 interaction of forces in, for example, a market or battle. Any event that triggers an undesired
scenario alternative is identified as risk Taxonomy-based risk identification The taxonomy
in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the
taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the
questions reveal risks.
 Common-risk checking In several industries, lists with known risks are available. Each risk
in the list can be checked for application to a particular situation.[
 Risk charting[ This method combines the above approaches by listing resources at risk,
threats to those resources, modifying factors which may increase or decrease the risk and
consequences it is wished to avoid. Creating a matrix under these headings enables a variety
of approaches. One can begin with resources and consider the threats they are exposed to
and the consequences of each. Alternatively one can start with the threats and examine
which resources they would affect, or one can begin with the consequences and determine
which combination of threats and resources would be involved to bring them about.

HAZARD ANALYSIS

A hazard is defined in FAA Order 8040.4 as a "Condition, event, or circumstance that could lead to
or contribute to an unplanned or undesirable event." Seldom does a single hazard cause an accident.
More often, an accident occurs as the result of a sequence of causes. A hazard analysis will consider
system state, for example operating environment, as well as failures or malfunctions.

While in some cases safety risk can be eliminated, in most cases a certain degree of safety risk must
be accepted. In order to quantify expected accident costs before the fact, the potential consequences
of an accident, and the probability of occurrence must be considered. Assessment of risk is made by
combining the severity of consequence with the likelihood of occurrence in a matrix. Risks that fall
into the "unacceptable" category (e.g., high severity and high probability) must be mitigated by
some means to reduce the level of safety risk.

IEEE STD-1228-1994 Software Safety Plans prescribes industry best practices for conducting
software safety hazard analyses to help ensure safety requirements and attributes are defined and
specified for inclusion in software that commands, controls or monitors critical functions. When
software is involved in a system, the development and design assurance of that software is often
governed by DO-178B. The severity of consequence identified by the hazard analysis establishes
the criticality level of the software. Software criticality levels range from A to E, corresponding to
severities of Catastrophic to No Safety Effect. Higher levels of rigor are required for level A and B
software and corresponding functional tasks and work products is the system safety domain are
used as objective evidence of meeting safety criteria and requirements.

Recently a leading edge commercial standard was promulgated based on decades of proven system
safety processes in DoD and NASA. ANSI/GEIA-STD-0010-2009 (Standard Best Practices for
System Safety Program Development and Execution) is a demilitarized commercial best practice
that uses proven hostistic, comprehensive and tailorable approaches for hazard prevention,

58
elimination and control. It is centered around the hazard analysis and functional based safety
process.

Severity Definition
Catastrophic Results in multiple fatalities and/or loss of the system
Reduces the capability of the system or the operator ability to cope with adverse
conditions to the extent that there would be:

 Large reduction in safety margin or functional capability

 Crew physical distress/excessive workload such that operators cannot be relied
Hazardous
upon to perform required tasks accurately or completely
 Serious or fatal injury to small number of occupants of aircraft (except
operators)
 Fatal injury to ground personnel and/or general public

Reduces the capability of the system or the operators to cope with adverse operating
conditions to the extent that there would be:

 Significant reduction in safety margin or functional capability

 Significant increase in operator workload
 Conditions impairing operator efficiency or creating significant discomfort
Major  Physical distress to occupants of aircraft (except operator)

including injuries

 Major occupational illness and/or major environmental damage, and/or major

property damage

Does not significantly reduce system safety. Actions required by operators are well
within their capabilities. Include:

 Slight reduction in safety margin or functional capabilities

Minor  Slight increase in workload such as routine flight plan changes
 Some physical discomfort to occupants or aircraft (except operators)
 Minor occupational illness and/or minor environmental damage, and/or minor
property damage

No Safety Has no effect on safety

RISK PLANNING AND CONTROL.

Risk management is the planned control of risk. It involves monitoring the success of a project,
analyzing potential risks, and making decisions about what to do about potential risks.

Integrating formal risk management with project management is a new phenomenon in the software
engineering and product management community. It requires that project managers be involved in a
project from the concept phase to the product's retirement.

59
Risk Management Roles

Projects support a business's goals and objectives, have defined, unique scopes of work, agreed-
upon starting and ending dates, and committed resources. Project managers should develop new
roles and responsibilities in risk management. These roles ensure responsibility for overall risk
management and should be defined in a project management plan document. The following
describes three key players in project risk management.

Software Project Manager: The Project Manager is the person who is directly accountable to the
sponsor and program manager for successful execution of a project. The term "Project Manager"
refers to both project leader and project manager throughout the rest of this article. The Software
Project Manager (SPM) determines the responsibilities for risk management within in a given
project. The SPM has overall responsibility for ensuring risk management occurs on the project,
and directs or approves risk management planning efforts and all substantive changes to the risk
control plans. The SPM assumes overall responsibility for all risk management actions associated
with risks assigned to the project.

Software Development Manager: The Software Development Manager (SDM) coordinates risk
management planning to ensure that risks are identified, risk assessment data is prepared, and
control plans are complete. The SDM supports the SPM in reporting risk status to senior
management and the customer. The SDM should prepare and maintain the risk plans and coordinate
all subsequent risk statusing and reporting actions as well as evaluate risk control action
effectiveness and recommend control actions. The SDM should coordinate the continuous review of
the risk plan to keep the set of risk issues and associated risk assessment data and control plans
current with project conditions.

Risk Owner: The Risk Owner is the individual identified by the SDM as the responsible individual
for overseeing the risk. The Risk Owner identifies and assesses "own" risk to produce probability
and impact information. He or she should develop risk mitigation and contingency plans and
provide status data for respective risk issues and assist in evaluating risk control action
effectiveness. The Risk Owner also documents threshold criteria of high and medium risk and
supports identification of new risks.

UNIT IV
MONITORING AND CONTROL
Creating Framework – Collecting The Data – Visualizing Progress – Cost Monitoring –
Earned Value – Priortizing Monitoring – Getting Project Back To Target – Change
Control – Managing Contracts – Introduction – Types Of Contract – Stages In Contract
Placement – Typical Terms Of A Contract – Contract Management – Acceptance.

60
COLLECTING THE DATA

Data collection is a term used to describe a process of preparing and collecting data - for example
as part of a process improvement or similar project. The purpose of data collection is to obtain
information to keep on record, to make decisions about important issues, to pass information on to
others. Primarily, data is collected to provide information regarding a specific topic.

Data collection usually takes place early on in an improvement project, and is often formalised
through a data collection plan. which often contains the following activity.

1. Pre collection activity – Agree goals, target data, definitions, methods

2. Collection – data collection
3. Present Findings – usually involves some form of sorting analysis and/or presentation.

Prior to any data collection, pre-collection activity is one of the most crucial steps in the process. It
is often discovered too late that the value of their interview information is discounted as a
consequence of poor sampling of both questions and informants and poor elicitation techniques.
After pre-collection activity is fully completed, data collection in the field, whether by interviewing
or other methods, can be carried out in a structured, systematic and scientific way.

A formal data collection process is necessary as it ensures that data gathered is both defined and
accurate and that subsequent decisions based on arguments embodied in the findings are valid. The
process provides both a baseline from which to measure from and in certain cases a target on what
to improve.

Types of data collection

 1-By mail questionnaires

 2-By personal interview.

Other main types of collection include census, sample survey, and administrative by-product and
each with their respective advantages and disadvantages. A census refers to data collection about
everyone or everything in a group or population and has advantages, such as accuracy and detail
and disadvantages, such as cost and time. A sample survey is a data collection method that includes
only part of the total population and has advantages, such as cost and time and disadvantages, such
as accuracy and detail. Administrative by-product data is collected as a byproduct of an
organization’s day-to-day operations and has advantages, such as accuracy, time simplicity and
disadvantages, such as no flexibility and lack of control

VISUALIZING PROGRESS

61
Progress hardly ever happens in a straight line. The picture to the left shows a real life example of
an improvement process.

The red line shows the actual values found. As you see, it constantly fluctuates.

The blue line is the trend line which shows that over time there is a slow but steady improvement.

The arrows show the following: Arrow 1: fast first results, quick progress. Arrow 2: rather heavy
fall back. Arrow 3: quick improvement again. Arrow 4: serious fall back again after which
improvement picks up again.

It would be very easy to get discouraged when focusing too much on the fluctuations, at point 2 and
4 for instance.

Two things are important to remember: 1) It is normal for progress to show this kind of fluctuation,
and 2) The trendline is an important line to watch.

This line shows you that there is actual growth overall. The trendline is a very motivating line to
watch.

EARNED VALUE

Earned value management (EVM) is a project management technique for measuring project
performance and progress in an objective manner

Project tracking without EVM

62
63
It is helpful to see an example of project tracking that does not include earned value performance
management. Consider a project that has been planned in detail, including a time-phased spend plan
for all elements of work. Figure 1 shows the cumulative budget (cost) for this project as a function
of time (the blue line, labeled PV). It also shows the cumulative actual cost of the project (red line)
through week 8. To those unfamiliar with EVM, it might appear that this project was over budget
through week 4 and then under budget from week 6 through week 8. However, what is missing
from this chart is any understanding of how much work has been accomplished during the project.
If the project were actually completed at week 8, then the project would actually be well under
budget and well ahead of schedule. If, on the other hand, the project is only 10% complete at week
8, the project is significantly over budget and behind schedule. A method is needed to measure
technical performance objectively and quantitatively, and that is what EVM accomplishes.

Project tracking with EVM

Consider the same project, except this time the project plan includes pre-defined methods of
quantifying the accomplishment of work. At the end of each week, the project manager identifies
every detailed element of work that has been completed, and sums the PV for each of these
completed elements. Earned value may be accumulated monthly, weekly, or as progress is made.

Earned value (EV)

Figure 2 shows the EV curve (in green) along with the PV curve from Figure 1. The chart indicates
that technical performance (i.e., progress) started more rapidly than planned, but slowed
significantly and fell behind schedule at week 7 and 8. This chart illustrates the schedule
performance aspect of EVM. It is complementary to critical path or critical chain schedule
management.

64
Figure 3 shows the same EV curve (green) with the actual cost data from Figure 1 (in red). It can
be seen that the project was actually under budget, relative to the amount of work accomplished,
since the start of the project. This is a much better conclusion than might be derived from Figure 1.

Figure 4 shows all three curves together – which is a typical EVM line chart. The best way to read
these three-line charts is to identify the EV curve first, then compare it to PV (for schedule
performance) and AC (for cost performance). It can be seen from this illustration that a true
understanding of cost performance and schedule performance relies first on measuring technical
performance objectively. This is the foundational principle of EVM.

GETTING PROJECT BACK TO TARGET

Here are a few guidelines on avoiding deadline-imposed project fiascos.

1. Distinguish between deadline and target date

Most "deadlines" are really target dates. The difference lies in what happens if the date is not met:

 When a deadline is missed, there's no longer any point in completing the commitment.1 For
example:
o submitting a contest entry
o publishing next year's Christmas catalog
 When a target date is missed, the consequences may be every bit as dire as for a missed
deadline, but you still have to finish the job. (Think of Microsoft.) If "target date" sounds
too indefinite for you, then substitute "completion date" or "delivery date".

2. Derive target dates rationally

A target date is a result of a detailed project plan that makes visible the work that has to be done.
The critical path through a network of tasks determines the earliest possible project completion
date, assuming unlimited resources. The actual target date may be later, depending upon the
project's priority and the availability of people and other resources.

If that derived target date is disappointing or unacceptable, then we have three choices:

1. We can reduce the scope of the project.

2. We can defer certain parts of it to a follow-on (release 2) project.
3. We can accept the disappointing target date and strongly support the project team in meeting
that target.

On the other hand there are two things we must never do:

1. We must never pressure the project planner to massage the estimates to fit a predetermined
completion date.

65
 2. We must never pressure the project team to work harder in order to meet what everyone
views as an impossible commitment.

While either of those approaches may give the temporary illusion of a tough-minded no-nonsense,
results-oriented manager, in the end they're a sure recipe for a painful project fiasco

That doesn't mean, of course, that an organization shouldn't ever go all out to achieve some
extremely ambitious and marginally unrealistic goal. When the rewards justify it, there's nothing
wrong with chartering a team to work on a "best efforts" basis. When a super-competent team has
high esprit de corps and doesn't fear the consequences of failure, they may pull off the occasional
miracle. Then:

 If the effort succeeds, it should be viewed as the miracle that it is. The team should be
generously rewarded, but under no circumstances should the miracle embolden management
to get in the habit of making unrealistic commitments.
 If the effort fails, no stigma whatever should be attached to anyone involved. The project
team should be thanked and perhaps even rewarded for its great effort.

3. Distinguish between urgency and priority

Of course, everyone knows that priority is relative. To raise the priority of one job or project is
implicitly to lower the priorities of all the others.

Without abusing the concept of priority, however, we often want to designate a project's degree of
importance. When the benefits of success are huge or the penalties for failure are dire, we designate
the project as "urgent" or "critical". Such a designation may help the project to get a higher priority
or to tap otherwise unavailable funds or manpower. Such a designation, however, can never
compress the critical path or increase the number of hours in a day.

4. Avoid arbitrary, self-imposed target dates

Whether it's a target date or a true deadline, it has only two legitimate sources: the rational result of
a project plan or some external event over which we have no control (e.g. Christmas). I'm
sometimes surprised, however, to discover that a target date arose entirely arbitrarily out of some
management edict unrelated to any real-world event.

In one case, we later found out that a manager two levels up had a goal on his own annual
objectives list that turned into a project "deadline". In another, a Theory-X manager confided: "You
have to keep the pressure on or they won't work hard." Needless to say, morale in those
organizations couldn't get any lower, and the projects failed anyway.

5. Never reward meeting a deadline

A successful project is one that:

1. meets agreed-upon objectives

66
 2. is completed by an agreed-upon target date
3. is completed within an agreed-upon budget
4. complies with applicable standards and constraints

CHANGE CONTROL

Change control within Quality management systems (QMS) and Information Technology (IT)
systems is a formal process used to ensure that changes to a product or system are introduced in a
controlled and coordinated manner. It reduces the possibility that unnecessary changes will be
introduced to a system without forethought, introducing faults into the system or undoing changes
made by other users of software. The goals of a change control procedure usually include minimal
disruption to services, reduction in back-out activities, and cost-effective utilization of resources
involved in implementing change.

Change control is currently used in a wide variety of products and systems. For Information
Technology (IT) systems it is a major aspect of the broader discipline of change management.
Typical examples from the computer and network environments are patches to software products,
installation of new operating systems, upgrades to network routing tables, or changes to the
electrical power systems supporting such infrastructure.

The process

There is considerable overlap and confusion between change management, configuration

management and change control. The definition below is not yet integrated with definitions of the
others.

Certain experts describe change control as a set of six steps]:

1. Record / Classify
2. Assess
3. Plan
4. Build / Test
5. Implement
6. Close / Gain Acceptance

Record/classify

The client initiates change by making a formal request for something to be changed. The change
control team then records and categorizes that request. This categorization would include estimates
of importance, impact, and complexity.

67
Assess

The impact assessor or assessors then make their risk analysis typically by answering a set of
questions concerning risk, both to the business and to the process, and follow this by making a
judgment on who should carry out the change. If the change requires more than one type of
assessment, the head of the change control team will consolidate these. Everyone with a stake in the
change then must meet to determine whether there is a business or technical justification for the
change. The change is then sent to the delivery team for planning.

Plan

Management will assign the change to a specific delivery team, usually one with the specific role of
carrying out this particular type of change. The team's first job is to plan the change in detail as well
as construct a regression plan in case the change needs to be backed out.

Build/test

If all stakeholders agree with the plan, the delivery team will build the solution, which will then be
tested. They will then seek approval and request a time and date to carry out the implementation
phase.

Implement

All stakeholders must agree to a time, date and cost of implementation. Following implementation,
it is usual to carry out a post-implementation review which would take place at another stakeholder
meeting.

Close/gain acceptance

When the client agrees that the change was implemented correctly, the change can be closed.

MANAGING CONTRACTS
INTRODUCTION

Contract management or contract administration is the management of contracts made with

customers, vendors, partners, or employees. Contract management includes negotiating the terms
and conditions in contracts and ensuring compliance with the terms and conditions, as well as
documenting and agreeing on any changes that may arise during its implementation or execution. It
can be summarized as the process of systematically and efficiently managing contract creation,
execution, and analysis for the purpose of maximizing financial and operational performance and
minimizing risk.

68
Common commercial contracts include employment letters, sales invoices, purchase orders, and
utility contracts. Complex contracts are often necessary for construction projects, goods or services
that are highly regulated, goods or services with detailed technical specifications, intellectual
property (IP) agreements, and international trade.

A study has found that for "42% of enterprises...the top driver for improvements in the management
of contracts is the pressure to better assess and mitigate risks" and additionally,"nearly 65% of
enterprises report that contract lifecycle management (CLM) has improved exposure to financial
and legal risk.

TYPES OF CONTRACT

1)Fixed price contracts:-

--price is fixed when the contract is signed

--Customer knows that when there is no changes in the contract terms they have to pay the
price.

--for this type customer requirement must be fixed and known.

2) Time and material contracts

Customer is charged at a fixed rate per unit of effort.

Payment is based on the unit of effort applied.

Fixed price per unit delivered contracts

Size of system to be delivered is to be calculated.

Basis for the calculation is in terms of line of code.

Another way of categorizing contracts

Open tendering process

Any supplier can bid to supply goods and services.

 Restricted tendering process

There are bids only from supplier who have been invited by the customer.

Stages in contract placement

69
 Requirement analysis

-- Before potential supplier is approached there must be clear set of requirements.

--requirement defines functions, standards clearly.

--Each requirement must be defined as compulsory or optional.

Evaluation plan

--after requirement list is drawn

--now there is need to evaluate the proposal.

--First check for all compulsory requirements

--check the quality standards

--cost also taken into account

Invitation to tender

--Deadline must be specified

Evaluation of proposals

--check the document that it contains all requirements

--interviewing suppliers

--demonstrations

--site visits

--practical tests

Typical terms of a contract

Definition-Form of agreement-lease, license, Sale

Goods and services to be supplied

Ownership of software

Environment

70
 Acceptance Standards

Time table

Price and payment method

Legal requirements

Contract Management-STEPS

There must be communication between supplier and customer while the contracted work is
carried out.

This interaction leads to changes which vary the terms of contract.

When the contract is negotiated, certain points in project may be identified where customer
approval is needed.

Example :-a project to develop the large system could be divided into increments ,for each
increment there is interface design phase, customer has to approve the interface first

For each decision point, the deliverable to be presented by suppliers.

Most changes to requirement may emerge .This vary the contract terms.

Acceptance

When the work is completed, customer needs to tack action to carry out acceptance testing.

The contract may put a time limit on how long acceptance testing can take.

UNIT V
MANAGING PEOPLE AND ORGANIZING TEAMS
Introduction – Understanding Behavior – Organizational Behaviour: A Background –
Selecting The Right Person For The Job – Instruction In The Best Methods – Motivation
– The Oldman – Hackman Job Characteristics Model – Working In Groups – Becoming
A Team –Decision Making – Leadership – Organizational Structures – Stress –Health
And Safety – Case Studies.

INTRODUCTION:

71
Organizational behavior is an academic discipline concerned with describing, understanding,
predicting, and controlling human behavior in an organizational environment.

"Understanding one individual's behavior is a challenging problem in and of itself. A group, made
up of different individuals and multiple relationships among those individuals, is even more
complex…. In the fact of this overwhelming complexity, organizational behavior must be managed.

Ultimately the work of organizations gets done through the behavior of people, individually or
collectively, on their own or in collaboration with technology. Thus, central to the management task
is the management of organizational behavior.

To do this, there must be the capacity to understand the patterns of behavior at individual, group,
and organization levels, to predict what behavior responses will be elicited by different managerial
actions, and finally to use understanding and prediction to achieve control."

The Behavioral Sciences

Organizational behavior scientists study four primary areas of behavioral science: individual
behavior, group behavior, organizational structure, and organizational processes.

They investigate many facets of these areas like personality and perception, attitudes and job
satisfaction, group dynamics, politics and the role of leadership in the organization, job design, the
impact of stress on work, decision-making processes, the communications chain, and company
cultures and climates.

They use a variety of techniques and approaches to evaluate each of these elements and its impact
on individuals, groups, and organizational efficiency and effectiveness. "The behavior sciences,"
stated Gibson, Ivancevich, and Donnelly in Organizations: Behavior, Structure, Processes, "have
provided the basic framework and principles for the field of organizational behavior.

Each behavioral science discipline provides a slightly different focus, analytical framework, and
theme for helping managers answer questions about themselves, nonmanagers, and environmental
forces."

Organizational Behavior and Corporate Culture

The terms "corporate culture" and "organizational behavior" are sometimes used interchangeably,
but in reality, there are differences between the two.

Corporate culture encompasses the shared values, attitudes, standards, and beliefs and other
characteristics that define an organization's operating philosophy.

Organizational behavior, meanwhile, can be under-stood in some ways as the academic study of
corporate culture and its various elements, as well as other important components of behavior such
as organization structure and organization processes.

72
Organizational behavior, said Gibson, Ivancevich, and Donnelly, is "the field of study that draws on
theory, methods, and principles from various disciplines to learn about individual perceptions,
values, learning capacities, and actions while working in groups and within the total organization;
analyzing the external environment's effect on the organization and its human resources, missions,
objectives, and strategies.…

Effective managers know what to look for in terms of structure, process, and culture and how to
under-stand what they find. Therefore, managers must develop diagnostic skills; they must be
trained to identify conditions symptomatic of a problem requiring further attention. Problem
indicators include declining profits, declining quantity or quality of work, increases in absenteeism
or tardiness, and negative employee attitudes. Each of these problems is an issue of organizational
behavior."

RIGHT PERSON FOR RIGHT JOB

How do you as a manager, supervisor or team leader choose a winner? One very successful
interviewing technique is behavioral interviewing---selecting the right person for the right job using
a job-related rather than a gut feel approach. A job-related approach is asking for a behavioral
example of skills and traits that are required for a position.

A behavioral example is a description, by the job applicant, of a specific event that shows in
detail how she did something or handled a problem or made a decision. The rationale for
asking for behavioral examples is the notion that the best predictor of what individuals will do
in the future is what they have done in the past.

The key to behavioral questions is that you ask for specific examples of past performance.
Behavioral questions typically contain phrases like:

 "Tell me about a time when....."

 "Give me an example of......"
 "How did you.....?"
 "Describe a situation in which you......"

Note how the following question has been rephrased so that it will elicit a behavioral example.
Original: "Have you had experience training new supervisors?" Revised: "Tell me about a time
when you had to hire and train a new supervisor. How did you go about it? Would you do anything
differently?"

Instruction in the best methods

When new members of the team are recruited, the TL will need to plan their induction into
the team very carefully.

The TL should be aware of the need to assess continually the training needs of their team
members.

73
MOTIVATION

Motivation is the driving force by which humans achieve their goals. Motivation is said to be
intrinsic or extrinsic. The term is generally used for humans but it can also be used to describe the
causes for animal behavior as well. This article refers to human motivation. According to various
theories, motivation may be rooted in a basic need to minimize physical pain and maximize
pleasure, or it may include specific needs such as eating and resting, or a desired object, goal, state
of being, ideal, or it may be attributed to less-apparent reasons such as altruism, selfishness,
morality, or avoiding mortality. Conceptually, motivation should not be confused with either
volition or optimism. Motivation is related to, but distinct from, emotion
Intrinsic and extrinsic motivation
Intrinsic motivation refers to motivation that is driven by an interest or enjoyment in the task
itself, and exists within the individual rather than relying on any external pressure. Intrinsic
motivation has been studied by social and educational psychologists since the early 1970s. Research
has found that it is usually associated with high educational achievement and enjoyment by
students. Explanations of intrinsic motivation have been given in the context of Fritz Heider's
attribution theory, Bandura's work on self-efficacy, and Deci and Ryan's cognitive evaluation theory
Students are likely to be intrinsically motivated if they:
 attribute their educational results to internal factors that they can control (e.g. the amount of
effort they put in),
 believe they can be effective agents in reaching desired goals (i.e. the results are not
determined by luck),
 are interested in mastering a topic, rather than just rote-learning to achieve good grades.
Extrinsic motivation comes from outside of the individual. Common extrinsic motivations are
rewards like money and grades, coercion and threat of punishment. Competition is in general
extrinsic because it encourages the performer to win and beat others, not to enjoy the intrinsic
rewards of the activity. A crowd cheering on the individual and trophies are also extrinsic
incentives.
Social psychological research has indicated that extrinsic rewards can lead to overjustification and a
subsequent reduction in intrinsic motivation. In one study demonstrating this effect, children who
expected to be (and were) rewarded with a ribbon and a gold star for drawing pictures spent less
time playing with the drawing materials in subsequent observations than children who were
assigned to an unexpected reward condition and to children who received no extrinsic reward.
Self-determination theory proposes that extrinsic motivation can be internalised by the individual if
the task fits with their values and beliefs and therefore helps to fulfill their basic psychological
needs.

OLDHAM HACKMAN MOTIVATION MODEL

The job characteristics model, designed by Hackman and Oldham, is based on the idea that the task
itself is key to employee motivation. Specifically, a boring and monotonous job stifles motivation to
perform well, whereas a challenging job enhances motivation. Variety, autonomy and decision
authority are three ways of adding challenge to a job. Job enrichment and job rotation are the two
ways of adding variety and challenge.

74
Hackman and Oldham’s job characteristics theory proposes that high motivation is related to
experiencing three psychological states whilst working:
1. Meaningfulness of work
That labour has meaning to you, something that you can relate to, and does not occur just as a set of
movements to be repeated. This is fundamental to intrinsic motivation, i.e. that work is motivating
in an of itself (as opposed to motivating only as a means to an end).
2. Responsibility
That you have been given the opportunity to be a success or failure at your job because sufficient
freedom of action has given you. This would include the ability to make changes and incorporate
the learning you gain whilst doing the job.
3. Knowledge of outcomes
This is important for two reasons. Firstly to provide the person knowledge on how successful their
work has been, which in turn enables them to learn from mistakes. The second is to connect them
emotionally to the customer of their outputs, thus giving further purpose to the work (e.g. I may
only work on a production line, but I know that the food rations I produce are used to help people in
disaster areas, saving many lives).
In turn, each of these critical states are derived from certain characteristics of the job:
1. Meaningfulness of work
The work must be experienced as meaningful (his/her contribution significantly affects the overall
effectiveness of the organization). This is derived from:
o Skill variety
Using an appropriate variety of your skills and talents: too many might be overwhelming, too few,
boring.
o Task Identity
Being able to identify with the work at hand as more whole and complete, and hence enabling more
pride to be taken in the outcome of that work (e.g. if you just add one nut to one bolt in the same
spot every time a washing machine goes past it is much less motivating than being the person
responsible for the drum attachment and associated work area (even as part of a group).
o Task Significance
Being able to identify the task as contributing to something wider, to society or a group over and
beyond the self. For example, the theory suggests that I will be more motivated if I am contributing
to the whole firm’s bonus this year, looking after someone or making something that will benefit
someone else. Conversely I will be less motivated if I am only making a faceless owner wealthier,
or am making some pointless item (e.g. corporate give-away gifts).
2. Responsibility
Responsibility is derived from autonomy, as in the job provides substantial freedom, independence
and discretion to the individual in scheduling the work and in determining the procedures to be used
in carrying it out)
3. Knowledge of outcomes
This comes from feedback. It implies an employee awareness of how effective he/she is converting
his/her effort into performance. This can be anything from production figures through to customer
satisfaction scores. The point is that the feedback offers information that once you know, you can
use to do things differently if you wish. Feedback can come from other people or the job itself.

75
Hackman & Oldham proposed the Job Characteristics Model, which is widely used as a framework
to study how particular job characteristics impact on job outcomes, including job satisfaction. The
model states that there are five core job characteristics (skill variety, task identity, task significance,
autonomy, and feedback) which impact three critical psychological states (experienced
meaningfulness, experienced responsibility for outcomes, and knowledge of the actual results), in
turn influencing work outcomes (job satisfaction, absenteeism, work motivation, etc.).[6] The five
core job characteristics can be combined to form a motivating potential score (MPS) for a job,
which can be used as an index of how likely a job is to affect an employee's attitudes and
behaviors----. A meta-analysis of studies that assess the framework of the model provides some
support for the validity of the JCM.

ABOUT GROUPS AND TEAMS

The terms ‘groups’ and ‘teams’ are generally used interchangeably. However, there are
differences, and a team can be regarded as a group of people who come together for a
defined task. It may mean that that they then disband once the task is complete. For the
purposes of this guide therefore, we see groups as the more generic term and teams as
task specific. In order for teams to work well, they need to understand how people work
in groups.

How do Groups Function as Teams?

Groups are very often formed just for a particular task and may not have
worked together before, so you might feel a little awkward with each other.
Since you will probably be working within a time limit, it is important therefore
to understand a little about how groups function in order to be an effective
functioning team as soon as possible. John Adair (1986) developed a classic
model of how teams function.

Develop a team spirit

If you are to work together effectively and enjoy the process, it is important to
develop a team spirit. Look at the list, tick where you are as a team.

What can you do to become a team….

We’ve got to know each other

We have done/intend to do something socially together

We feel confident enough to disclose some personal information about ourselves

As a team we have identified our strengths and weaknesses.

We have identified our preferences about how we like to work with others

76
We ensure all members feel part of the team

We all feel free enough to express our feelings.

We realise that planning is important, so we have donethat and taken all points of view on board.

What can you do to avoid becoming a team...

We’ve not got to know each other, but we do chat a little about other things and feel that is enough

We’ve never met up socially as we have nothing in common

We don’t feel confident enough to disclose ourselves

We’ve not looked at the strengths and weaknesses and see no point in it.

We are quite happy to allow an individual to dominate if he/she wants to.

Some members of the group tend to exclude other members – but that is just how things are.

We avoid expressing our feelings, as things could go wrong, so we keep it formal and neutral.

Someone in the group usually takes control and says what has to be done – we are quite happy
with that. If not, we just get on with what our task is and then put it altogether at the end – it usually
works out OK.

All members feel supported by the team.

We don’t need to feel supported by team members, we have our other friends for that.

Maintain the team

Make sure you have procedures for communicating, checking the work is done,
ironing out problems (with tasks or people). Check your timing, ensure you
are all working towards the plan. You may want to set up sub groups. Get
everyone’s email address and identify good meeting times and places. It is
important to be alert to how the team is getting along.

Becoming a team

Team development stages

Forming (member of group know each other & make ground rules about behaviour)
Storming (want to be leader)
Norming (conflicts settles)
Performing (emphasis is now on task)

77
 Adjourning (the group disbands)
Group performance
Additive tasks
Compensatory tasks
Disjunctive tasks
Conjunctive tasks

DECISION MAKING

Decision making can be regarded as the mental processes (cognitive process) resulting in the
selection of a course of action among several alternative scenarios. Every decision making process
produces a final choice. The output can be an action or an opinion of choice.
Problem Analysis vs Decision Making
It is important to differentiate between problem analysis and decision making. The concepts are
completely separate from one another. Problem analysis must be done first, then the information
gathered in that process may be used towards decision making.[4]
Problem Analysis
• Analyze performance, what should the results be against what they actually are
• Problems are merely deviations from performance standards
• Problem must be precisely identified and described
• Problems are caused by some change from a distinctive feature
• Something can always be used to distinguish between what has and hasn't been effected by a
cause
• Causes to problems can be deducted from relevant changes found in analyzing the problem
• Most likely cause to a problem is the one that exactly explains all the facts
Decision Making
• Objectives must first be established
• Objectives must be classified and placed in order of importance
• Alternative actions must be developed
• The alternative must be evaluated against all the objectives
• The alternative that is able to achieve all the objectives is the tentative decision
• The tentative decision is evaluated for more possible consequences
• The decisive actions are taken, and additional actions are taken to prevent any adverse
consequences from becoming problems and starting both systems (problem analysis and decision
making) all over again
• There are steps that are generally followed that result in a decision model that can be used to
determine an optimal production plan
Decision-Making Steps
When in an organization and faced with a difficult decision, there are several steps one can take to
ensure the best possible solutions will be decided. These steps are put into seven effective ways to
go about this decision making process (McMahon 2007).
The first step - Outline your goal and outcome. This will enable decision makers to see exactly
what they are trying to accomplish and keep them on a specific path.
The second step - Gather data. This will help decision makers have actual evidence to help them
come up with a solution.

78
The third step - Brainstorm to develop alternatives. Coming up with more than one solution ables
you to see which one can actually work.
The fourth step - List pros and cons of each alternative. With the list of pros and cons, you can
eliminate the solutions that have more cons than pros, making your decision easier.
The fifth step - Make the decision. Once you analyze each solution, you should pick the one that
has many pros (or the pros that are most significant), and is a solution that everyone can agree with.
The sixth step - Immediately take action. Once the decision is picked, you should implement it
right away.
The seventh step - Learn from, and reflect on the decision making. This step allows you to see
what you did right and wrong when coming up, and putting the decision to use.

LEADERSHIP:

Leadership has been described as the “process of social influence in which one person can enlist
the aid and support of others in the accomplishment of a common task”. Definitions inclusive of
nature of leadership have also emerged. Alan Keith of Genentech states that, "Leadership is
ultimately about creating a way for people to contribute to making something extraordinary
happen." According to Ken "SKC" Ogbonnia, "effective leadership is the ability to successfully
integrate and maximize available resources within the internal and external environment for the
attainment of organizational or societal goals

Styles

Leadership style refers to a leader's behaviour. It is the result of the philosophy, personality and
experience of the leader.

Autocratic or authoritarian style

Under the autocratic leadership style, all decision-making powers are centralized in the leader, as
with dictator leaders.

They do not entertain any suggestions or initiatives from subordinates. The autocratic management
has been successful as it provides strong motivation to the manager. It permits quick decision-
making, as only one person decides for the whole group and keeps each decision to himself until he
feels it is needed to be shared with the rest of the group.

Participative or democratic style

The democratic leadership style favors decision-making by the group as shown, such as leader gives
instruction after consulting the group.

They can win the co-operation of their group and can motivate them effectively and positively. The
decisions of the democratic leader are not unilateral as with the autocrat because they arise from
consultation with the group members and participation by them.[45]

79
Laissez-faire or free rein style

A free-rein leader does not lead, but leaves the group entirely to itself as shown; such a leader
allows maximum freedom to subordinates, i.e., they are given a free hand in deciding their own
policies and methods.

Different situations call for different leadership styles. In an emergency when there is little time to
converge on an agreement and where a designated authority has significantly more experience or
expertise than the rest of the team, an autocratic leadership style may be most effective; however, in
a highly motivated and aligned team with a homogeneous level of expertise, a more democratic or
laissez-faire style may be more effective. The style adopted should be the one that most effectively
achieves the objectives of the group while balancing the interests of its individual members.[45]

Toxic leadership

A toxic leader is someone who has responsibility over a group of people or an organization, and
who abuses the leader-follower relationship by leaving the group or organization in a worse-off
condition than when s/he first found them.

Organizational Structures:

PRINCE2 is a process-driven project management method which contrasts with reactive/adaptive

methods such as Scrum. PRINCE2 2009 defines 40 separate activities and organizes these into
seven processes:

1.Starting up a project

In this process the project team is appointed and a project brief (describing, in outline, what the
project is attempting to achieve and the business justification for doing so) is prepared. In addition
the overall approach to be taken is decided and the next stage of the project is planned. Once this
work is done, the project board is asked to authorize the next stage, that of initiating the project.

Key activities include: appointing an executive and a project manager; designing and appointing a
project management team; preparing a project brief; defining the project approach; and planning the
next stage (initiation).

2.Initiating a project

This process builds on the work of the start up process, and the project brief is augmented to form a
Business case. The approach taken to ensure quality on the project is agreed together with the
overall approach to controlling the project itself (project controls). Project files are also created as is
an overall plan for the project. A plan for the next stage of the project is also created. The resultant
information can be put before the project board for them to authorize the project itself.

Key activities include: planning quality; planning a project; refining the business case and risks;
setting up project controls; setting up project files; and assembling a Project Initiation Document.

80
3. Directing a project

This process dictates how the Project Board (which comprises such roles as the executive sponsor
or project sponsor) should control the overall project. As mentioned above, the project board can
authorise an initiation stage and can also authorize a project. Directing a Project also dictates how
the project board should authorize a stage plan, including any stage plan that replaces an existing
stage plan due to slippage or other unforeseen circumstances. Also covered is the way in which the
board can give ad hoc direction to a project and the way in which a project should be closed down.

Key activities include: authorising initiation; authorising a project; authorising a stage or exception
plan; giving ad-hoc direction; and confirming project closure.

4. Controlling a stage

PRINCE2 suggests that projects should be broken down into stages and these sub-processes dictate
how each individual stage should be controlled. Most fundamentally this includes the way in which
work packages are authorised and received. It also specifies the way in which progress should be
monitored and how the highlights of the progress should be reported to the project board. A means
for capturing and assessing project issues is suggested together with the way in which corrective
action should be taken. It also lays down the method by which certain project issues should be
escalated to the project board.

Key activities include: authorising work package; assessing progress; capturing and examining
project issues; reviewing stage status; reporting highlights; taking corrective action; escalating
project issues; and receiving a completed work package.

5. Managing stage boundaries

The Controlling a Stage process dictates what should be done within a stage, Managing Stage
Boundaries (SB) dictates what should be done towards the end of a stage. Most obviously, the next
stage should be planned and the overall project plan, risk log and business case amended as
necessary. The process also covers what should be done for a stage that has gone outside its
tolerance levels. Finally, the process dictates how the end of the stage should be reported.

Key activities include: planning a stage; updating a project plan; updating a project business case;
updating the risk log; reporting stage end; and producing an exception plan.

6.Managing product delivery

The Managing product delivery process has the purpose of controlling the link between the Project
Manager and the Team Manager(s) by placing formal requirements on accepting, executing and
delivering project work. The Objectives of the Managing Product Delivery process are:
- To ensure that work on products allocated to the team is authorised and agreed,
- Team Manager(s), team members and suppliers are clear as to what is to be produced and what is
the expected effort, cost and timescales,
- The planned products are delivered to expectations and within tolerance,

81
- Accurate progress information is provided to the Project Manager at an agreed frequency to ensure
that expectations are managed.

The key activities are: Accept a work package, execute a work package and deliver a work package.

7.Closing a project

This covers the things that should be done at the end of a project. The project should be formally
de-commissioned (and resources freed up for allocation to other activities), follow on actions
should be identified and the project itself be formally evaluated.

Key activities include: decommissioning a project; identifying follow-on actions; and project
evaluation review.

ISO 12207 is an ISO standard for software lifecycle processes. It aims to be the standard that
defines all the tasks required for developing and maintaining software.

The ISO 12207 standard establishes a process of lifecycle for software, including processes and
activities applied during the acquisition and configuration of the services of the system. Each
Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks
and 224 Outcomes (the new "ISO/IEC 12207:2008 Systems and software engineering – Software
life cycle processes" defines 43 system and software processes).

The set of processes, activities and tasks can be adapted according to the software project. These
processes are classified in three types: basic, for support and organizational. The support and

82
organizational processes must exist independently of the organization and the project being
executed. The basic processes are instantiated according to the situation.

Primary lifecycle processes

The primary lifecycle processes contain the core processes involved in creating a software product.
These processes are divided into five different main processes:

 Acquisition
 Supply
 Development
 Operation
 Maintenance

Because the primary lifecycle processes cover a very large area a scope was defined. This entry
explains all the primary lifecycle processes but will explain the Acquisition and Development
processes more extensively.

Acquisition

Acquisition covers the activities involved in initiating a project. The acquisition phase can be
divided into different activities and deliverables that are completed chronologically.

 Initiation: during this activity the following tasks are completed

o The need is described why to acquire, develop, or enhance a product;
o System requirements are defined and approved if applicable;
o The global software requirements are defined;
o Evaluation of other options, like a purchase of an off-the-shelf product or
enhancement of an existing product;
o If an off-the-shelf product is purchased, the software requirements of this product
need to be analyzed.
o An acquisition plan is developed, this plan will be used further on during the
acquisition phase
o Acceptance criteria are defined.
 Request for proposal preparation: during this activity the following tasks are completed
o Acquisition requirements, like System requirements and technical constraints such as
target environment, are defined.
o Required ISO/IEC 12207 process for the project are defined and changed
accordingly if needed.
o Contract milestones for reviewing and supplier's progress audits are defined.
 Prepare Contract: during this activity the following tasks are completed
o Selection procedure for suppliers are developed;
o Suppliers, based on the developed selection procedure, are selected;
o The tailor-made ISO/IEC 12207 standard must be included in the contract;
 Negotiate changes: during this activity the following tasks are completed
o Negotiations are held with the selected suppliers;

83
  Update contract: during this activity the following tasks are completed
o Contract is updated with the result from the negotiations in the previous activity.
 Supplier monitoring: during this activity the following tasks are completed
o Activities of the suppliers according to the agreements made are monitored;
o Work together with suppliers to guarantee timely delivery if needed.
 Acceptance and completion: during this activity the following tasks are completed
o Acceptance tests and procedures are developed;
o Acceptance and testing on the product is conducted;
o Configuration management on the delivered product is conducted;

Supply

During the supply phase a project management plan is developed. This plan contains information
about the project such as different milestones that need to be reached. This project management
plan is needed during the next phase which is the development phase.

Development

During the development phase the software product is designed, created and tested and will result in
a software product ready to be released to the customer. Throughout time many people have
developed means of developing a software application. The choice of developing method often
depends on the present situation. The development method which is used in many projects is the V-
model. Techniques that can be used during the development are UML for designing and TMap for
testing. This entry contains the most important steps of the V-model.

 Define functional requirements: during this activity the following tasks are completed
o Gather the functional requirements, or demands, for the product that is to be created.
 Create High level design: during this activity the following tasks are completed
o A basic layout[disambiguation needed] of the product is created. This means the setup of
different modules and how they communicate with each other. This design does not
contain very much detail about the modules.
 Create Module design
o The different modules present in the High level design are designed separately. The
modules are designed in as much detail as possible.
 Coding
o The code is created according to the high level design and the module design.
 Execute Module test
o The different modules are tested for correct functioning. If this is the case the project
can move to the next activity, else the project returns to the module design phase to
correct any errors.
 Execute Integration test
o The communication between modules is tested for correct functioning. If this is the
case the project can move to the next activity, else the project falls back to the high
level design to correct any errors.
 Execute System test

84
 o This test checks whether all functional requirements are present in the product. If
this is the case the product is completed and the product is ready to be transferred to
the customer. Else the project falls back to the software requirements activity and the
functional requirements have to be adjusted.

Operation

The operation and maintenance phases occur simultaneously, the operation-phase consists of
activities like assisting users in working with the created software product.

Maintenance

The maintenance-phase consists of maintenance-tasks to keep the product up and running. The
maintenance includes any general enhancements, changes and additions, which might be required
by the end-users.These defects and deficiencies are usually documented by the developing
organisation to enable future solutions and known issues addressing in any future maintenance
releases.

Deliverables

The different deliverables that are developed per activity are explained in this chapter.

Acquisition

Acquisition covers the activities involved in initiating a project. The acquisition phase can be
divided into different activities and deliverables that are completed chronologically.

 Initiation: during this activity the following deliverables are developed:

o Initiation documents;
 Request for proposal preparation: during this activity the following deliverables are
developed:
o Request for proposal;
 Prepare Contract: during this activity the following deliverables are developed:
o Contract: this is a draft agreement between the company and suppliers, set up by the
company.
 Negotiate Changes: during this activity the following deliverables are developed:
o Input from the suppliers: suppliers can react on the draft agreement submitted by the
company, this reaction will result in input from the suppliers
 Update Contract: during this activity the following deliverables are developed:
o Final Contract;
 Supplier monitoring: during this activity the following deliverables are developed:
o Supplier Monitor Report: this report covers the advances of the suppliers involved
based on different milestones.
 Acceptance and completion: during this activity the following deliverables are developed:

85
 o Acquisition report: this report covers the acceptance and completion of the
acquisition phase.

Development

During the development phase the software product is designed, created and tested and will result in
a software product ready to be sold to the customer.

 Define Software Requirements: during this activity the following deliverables are
developed:
o Software Requirements: this is a collection of different functional requirements;
 High level design: during this activity the following deliverables are developed:
o High level design;
 Module design: during this activity the following deliverables are developed:
o Module design;
 Coding: during this activity the following deliverables are developed:
o Code;
 Module test: during this activity the following deliverables are developed:
o Module test report, this test report contains the test-results which are formed after a
module test of the application. Based on this test-report the project-team can decide
which action to undertake further.
 Integration test: during this activity the following deliverables are developed:
o Module test report, this test report contains the test-results which are formed after an
integration test of the application. Based on this test-report the project-team can
decide which action to undertake further.
 System test: during this activity the following deliverables are developed:
o System test report;

ISO 12207 and Related Software Life-Cycle Standards

The Institute of Electrical and Electronics Engineers (IEEE) is now voting on whether the U.S.
should adopt International Organization for Standardization (ISO) 12207, which specifies software
life-cycle processes. Because of the burgeoning of standards over the last few years, it is important
that software engineers understand what 12207 provides and how it relates to other standards
dealing with life-cycle processes.

Overview of ISO 12207

ISO 12207 offers a framework for software life-cycle processes from concept through retirement. It
is especially suitable for acquisitions because it recognizes the distinct roles of acquirer and
supplier. In fact, the standard is intended for two-party use where an agreement or contract defines
the development, maintenance, or operation of a software system. It is not applicable to the
purchase of commercial-off-the-shelf (COTS) software products.

86
The ISO is currently developing such guides and assessment procedures to complement 12207; the
IEEE Software Engineering Standards Committee is also planning to reorganize its collection of
standards to complement 12207.

ISO 12207 describes five "primary processes"-- acquisition, supply, development, maintenance, and
operation. It divides the five processes into "activities," and the activities into "tasks," while placing
requirements upon their execution. It also specifies eight "supporting processes"--documentation,
configuration management, quality assurance, verification, validation, joint review, audit, and
problem resolution--as well as four "organiza-tional processes"--management, infrastructure,
improvement, and training.

EUROMETHOD

Euromethod was a method for managing procurement processes of Information Services. It focuses
on contract management.

Where can Euromethod be used?

Euromethod can be used in any project regarding an information system, where there is:

A customer.

A supplier (external or internal to the organisation).

A contract (formal or informal) between the customer and the supplier.

The information system is that aspect of the organisation which provides, uses, and distributes the
information . It includes the associated organisational resources such as human, technical and

87
financial resources. It is thus effectively a human system, possibly containing a computer system
that automates selected elements of the information system.

Euromethod addresses any kind of information system possibly including any kind of computer
system (distributed or not, having data bases or not, real time or not, with knowledge base or not,
office automation or not, etc.).

Examples of projects regarding the information system:

Business design of a new or modified information system

(including the organisational procedures).

Technical design of a new or modified information system.

Development of new bespoke software.

Development and installation of a new computer system

(including new application software).

Installation of a package based system.

Maintenance of application software.

Re-engineering of application software.

Analysis of the changes required to an information system.

Analysis of the changes required to application software.

Documentation of an existing information system.

Euromethod can be used by both the customer organisation and the supplier organisation.

When can Euromethod be used?

Euromethod can be used in the procurement process, once the overall goal of the procurement has
been established.

One part of the procurement process is the tendering process.

Euromethod can be used in the preparation of the call for tender and in the tendering process up to
the signing of the contract. The determination of the goal of the procurement is not part of
Euromethod. Euromethod assists in the definition of the requirements to the project. This includes
the planning of deliveries.

Euromethod can be used during the project for the interactions existing between the customer and
the supplier, such as the approval (or acceptance) of deliverables, the selection of solutions, the
approval of project status, etc.

88
Euromethod can be used in the completion process of the project, e.g. for the approval of final
deliverables.

Euromethod gives its full value when it is used consistently throughout the whole process, both by
the customer and the supplier.

The Principles of EM are:

 
Euromethod addresses a variety of changes to information systems, considering
information systems as totalities of organisational, human and technical
IS adaptation.  elements. This variety of changes, which include system development, is
captured by the concept of information system adaptation. 
Euromethod applies to any information system adaptation that can be
Variety of characterized by a well understood initial and final state. As a consequence,
Contracts.  Euromethod can be reapplied at various stages during the life of the same
information system.

Customer- Euromethod supports the understanding, planning and management of the

Supplier contractual relationships between a customer and a supplier of information
Relationship system adaptations. 
Euromethod supports the development of a strategy and a plan for information
Situation system adaptation that is tailored to the specific characteristics of a problem
Driven. situation.
Euromethod focuses on the key decisions to be taken by the customer and the
Focus on supplier, on their related transactions and on the key roles played by people
Decisions (organisational actors) during these transactions.
Euromethod is focused on the deliverables which are exchanged between the
Focus on customer and the supplier. The deliverables constitute the key planning
Deliverables.  elements to support decision making and management of progress. 
Euromethod provides valuable concepts and guidelines to supplement
Method information system development methods. Guidelines are offered to bridge
Bridging.  between Euromethod concepts, on the one hand, and development method
concepts on the other. 

Information System Adaptation

Euromethod addresses procurement and development of information system with a broad view on
both the products and processes considered.

89
 The information system.

On the product side, information systems are considered as totalities of organisational, human and
technical elementsas illustrated on Figure 2. Information systems contain information resources.
These resources are used in processes performed by various actors within the organisation.
Different kinds of technologies, one of the most important being computer systems, are developed
to support the involved actors and to automate part of the processes involved. As a consequence, the
scope of Euromethod is wider than software development: it is concerned with improving the
information system in all its aspects.

On the process side, Euromethod addresses a variety of information system changes including their
modification (correction, enhancement, improvement, etc.) and automation to fulfill the changing
needs of the organisation. This variety of changes, for the purpose of Euromethod is captured
within the concept of IS-adaptation .

Variety of Contracts
Euromethod applies to any IS-adaptation that can be characterized by an initial state and a final
state. As a consequence, Euromethod can be reapplied at various stages during the life of the same
information system as illustrated below:

Customer-Supplier Relationship
Euromethod supports the understanding, planning and management of the contractual relationships
between a customer and a supplier of IS-adaptations. Figure 4 summarizes this fundamental view
on IS-adaptation.

90
 Figure 4: The two levels of a Customer-Supplier Relationship.

A distinction is made between two levels of customer-supplier relations: the relationship at a

contractual level and the relationship at a project level. The main focus of Euromethod is on the
contractual level starting with the call for tender, proceeding through the signing of a contract,
eventually entering into the actual production of a set of deliverables, and finally ending when the
contract is terminated. From this point of view Euromethod is designed to:

Enhance the customer-supplier relationships in IS-adaptation contracts (focusing on the

relationship at the contractual level).

Bridge the cultural difference between the parties involved in the contractual
relationship, e.g. between procurers on the one hand, and project managers and developers
on the other (focusing on the relationship between the contractual level and the project
level).

Situation Driven
Euromethod supports the development of a strategy and a plan for IS adaptation that is tailored to
the specific characteristics of a problem situation. The problem is the IS-adaptation and the problem
situation is its context.

A problem situation is expressed using a set of situational factors, and these properties of the
problem situation are used to predict the risks and thus determine the appropriate problem solving
strategies for their containment or reduction.

In this sense, Euromethod applies a situation driven approach to IS adaptation. It does so through
guidelines for:

91
 The identification of important situational factors.

The assessment of the complexity, uncertainty and risks.

The definition of a strategy for the IS-adaptation.

This IS-adaptation strategy is designed for the reduction or containment of risks inherent in the
problem situation and it places specific requirements on the delivery plan of the contract.

Focus on Decisions
In the course of a procurement of an information system, the customer and the supplier execute
transactions where they exchange products and take decisions on the basis of the information
contained in those products.

Three processes are considered:

The tendering process which starts with a call for tender and usually ends with the
signing of the contract.

The production process where the IS adaptation is performed, i.e. the deliverables are
produced.

The completion process where the contract is technically and commercially terminated.
During the tendering and the completion processes a set of specific types of transactions are used to
provide a simple and general model. In contrast, during the production process a set of general
types of transactions are used to provide the means to create, in each specific application of
Euromethod, a tailored model of the production process. This model focuses on key decisions to be
taken by the customer. These decisions are crucial for the customer since they will determine the
properties of the new information system. They are as important for the supplier insofar as they are
shaping the objectives of the project, its costs and chances of success.

The process followed by the customer and the supplier during the production process will consist of
transactions in which decisions about the information system and the way it is produced are
approved or made. The main decision points have to be approved by the customer or made in co-
operation with them, and the sequence of the related transactions is specified in the delivery plan.

Euromethod is providing assistance in planning these decision points and customer-supplier

transactions. It also gives some help in determining the right products that must be delivered to
support a certain decision.

Focus on Deliverables

Euromethod focuses on deliverables with less concern for the supplier's activities in which they are
produced. The deliverables constitute the key planning elements to support decision making and
management of progress.

92
 For the customer, the deliverables are more important than the way in which they are produced by
the supplier. "What" is more important than "How". Some of these deliverables are stated as the
objective of the contract. It is crucial that there is a mutual understanding between the customer and
supplier regarding the goal, and the meaning of these deliverables. In addition, other deliverables
need to be included to provide the customer with sufficient information on intermediate results,
plans, and progress made. 

Method Bridging
The organisational setting will contain standards and rules that have to be followed, and the
development methods to be applied in the production process will guide the actions through specific
process models and product profiles. In this sense, Euromethod provides valuable concepts and
guidelines to supplement information system development methods and local standards and rules.

Euromethod offers guidelines to bridge between its own concepts, on the one hand, and the
concepts of development methods on the other. These guidelines can be used in applications of
Euromethod to specific IS-adaptations. In a different context, these guidelines can serve as a
framework to achieve some level of conceptual harmonization between different development
methods.

BS6079-1

BS6079-1:2010 aims to help you and your organisation achieve a desired outcome of a project
efficiently and effectively. It also aims to contribute to the learning within projects and so
continually improve your organisation’s project management capability.

The principles provided in this standard are as relevant to small organisations and for small projects
as they are to major organisations with multimillion pound projects spanning several years.

BS6079-1:2010 aims to draw attention to the management challenges encountered in different

project environments and to present possible approaches to these.

This part of BS6079 gives principles and guidance on:

 Sponsorship
 Management
 Planning
 Undertaking of projects
 Application of project management techniques

93
 Key Features and Benefits:

 BS6079-1:2010 has been fully revised and updated to take into account the latest in
best practice and technology within the field of project management. Using this standard will
bring your current project management processes into line with current best practice, leading to
cost and time savings.
 The advice and guidance in this standard is suitable no matter the size, type or
location of your organisation. Making the best practices within it widely applicable.
 Functions as a memory-jogger for experienced managers as well as a desk reference
for experienced practitioners. Ideal source of vital information when something important slips
your mind.

STRESS

Workplace stress is the harmful physical and emotional response that occurs when there is a poor
match between job demands and the capabilities, resources, or needs of the worker

The following economic factors may lead to workplace stress:

 Pressure from investors, who can quickly withdraw their money from company stocks.
 The lack of trade and professional unions in the workplace.
 Inter-company rivalries caused by the efforts of companies to compete globally
 The willingness of companies to swiftly lay off workers to cope with changing business
environments.

Bullying in the workplace can also contribute to stress.

Signs of Workplace Stress

Stress-related problems include mood disturbance, psychological distress, sleep disturbance, upset
stomach, headache, and problems in relationships with family and friends. The effects of job stress
on chronic diseases are more difficult to ascertain because chronic diseases develop over relatively
long periods of time and are influenced by many factors other than stress. Nonetheless, there is
some evidence that stress plays a role in the development of several types of chronic health
problems--including cardiovascular disease, musculoskeletal disorders, and psychological
disorders.[1]

Health and Safety

A combination of organizational change and stress management is often the most useful approach
for preventing stress at work.[1]

How to Change the Organization to Prevent Job Stress[13]

 Ensure that the workload is in line with workers' capabilities and resources.

94
 Design jobs to provide meaning, stimulation, and opportunities for workers to use their
skills.
 Clearly define workers' roles and responsibilities.
 Give workers opportunities to participate in decisions and actions affecting their jobs.
 Improve communications-reduce uncertainty about career development and future
employment prospects.
 Provide opportunities for social interaction among workers.
 Establish work schedules that are compatible with demands and responsibilities outside the
job.
 Combat workplace discrimination (based on race, gender, national origin, religion or
language).
 Bringing in an objective outsider such as a consultant to suggest a fresh approach to
persistent problems.[14]
 Introducing a participative leadership style to involve as many subordinates as possible to
resolve stress-producing problems.[15]


95
i