MG6088 SOFTWARE PROJECT MANAGEMENT

UNIT 1
INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

Software Definition
 Software is instructions (computer programs) that when executed provide desired features,
Function and performance
 Data structures that enable the programs to adequately manipulate information.
 Documents that describe the operation and use of the programs.
 Software is a program that is the product of a project

Project Definition
 Project is a specific plan or design
 Project is a planned undertaking/activity
 Project is a large undertaking e.g. a public works scheme
 Project determines how to carry out a task before starting the task
 Project is a new endeavor to accomplish a unique purpose.
 In the broadest sense, a project is a specific, finite task to be accomplished. Any activity that
results in a deliverable or a product.
 Projects always begin with a problem. The project is to provide the solution to this problem.
 When the project is finished it must be evaluated to determine whether it satisfies the objectives
and goals.
Jobs versus projects

„Jobs‟ – repetition of very well-defined and well understood tasks with very little uncertainty
„Exploration‟ – e.g. finding a cure for cancer: the outcome is very uncertain
„Projects‟ – in the middle!

Characteristics of projects
A task is more „project-like‟ if it is:
 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 predetermined time span
 Work is carried out for someone other than yourself
 Work involves several specialisms
 Work is carried out in several different phases
 Resources that are available for use on the project are constrained.
 Project is large and/or complex
Management Definition
  Management can be defined as all activities and tasks undertaken by one or more persons for the
purpose of planning and controlling the activities of others in order to achieve objectives or
complete an activity that could not be achieved by others acting independently.
 Management is to manage to forecast and plan to organize, to command, to co-ordinate and to
control.
 “Management is getting things done through the efforts of other people”.
 “It is process towards the attainment of desired goals”.

This involves the following activities:

 Planning is deciding what is to be done
 Organizing is making arrangements
 Staffing is selecting the right people for the job
 Directing is giving instructions
 Monitoring is checking on progress
 Controlling is taking action to remedy hold-ups
 Innovating is coming up with solutions when problems emerge
 Representing is liaising with clients, users, developers and other stakeholders

PROJECT MANAGEMENT
 Project management is the discipline of planning, organizing, and managing resources to bring
about the successful completion of specific projects goals and objectives.
 A project is a planned undertaking to present results at a specified time. Here „ undertaking‟
means „making‟ new product or „changing‟ old product.
 Task : A piece of work assigned or done as part of one's duties.
 Activity : Activity definition refers to the process of parsing a project into a number of individual
tasks which must be completed before the deliverables can be considered completed.
 Activity definitions rely on a number of specific input processes.
 Activities can be subdivided into tasks.
 Phase: a group of activities/tasks, producing a significant deliverable work product.
 Project : A unique, goal-oriented, time-bound and constrained undertaking.
 System: an organized element acting as a whole.

SOFTWARE PROJECT MANAGEMENT

 Software project management is the art and science of planning and leading software projects. It
is a sub-discipline of project management in which software projects are planned, monitored and
controlled.

PROGRAMME
 A programme is a portfolio comprised of multiple projects that are managed and coordinated as
one unit with the objective of achieving (often intangible) outcomes and benefits for the
organization.
 A programme is a group of related projects managed to obtain collective benefits ,often with a
strategic goal, which may involve a series of repetitive or cyclic undertaking
 A programme is a group of related projects managed in a coordinated way

PROCESS
Process is a structured set of activities required to develop a software system
• Specification;
• Design;
• Validation;
• Evolution.
A software process model is an abstract representation of a process. It presents a description of a process
from some particular perspective.
PROJECT Vs PROCESS
• Process is a repetitive collection of interrelated tasks aimed at achieving a certain goal.
• Project is a unique endeavor with a beginning and an end undertaken to achieve a goal.
 • Process is a set of related resources and activities transforming inputs into outputs (from example
Risk management process_
• Project: Is an endeavor with a defined start date and end date, to meet specific objectives.

Difference between a Project and a Programme

Project Programme

Objectives Outputs – tangible; relatively easy to Outcomes – often intangible; difficult to

describe, define and measure; tending quantify; benefits often based on changes to
towards objective. organizational culture and behaviors; introducing
new capabilities into the organization; tending
towards subjective.
Scope Strictly limited; tightly defined; not Not tightly defined or bounded; likely to change
subject to change during the life of the during the life cycle of the program.
project.
Duration Relatively short term; typically three to Relatively long term typically eighteen months
six months. to three years.
Risk profile Project risk is relatively easy to identify
Program risk is more complex and potentially the
and manage. The project failure would impact on the organization if a risk materializes
result in relatively limited impact on the
will be greater relative to project risk.
organization relative to program risk. Programme failure could result in material
financial, reputational or operational loss.
Nature of the Clearly defined. Ill-defined; often disagreement between key
problem stakeholders on the nature and definition of the
problem.
Nature of the A relatively limited number of potential A significant number of potential solutions with
solution and solutions. disagreement between stakeholders as to the
Stake holders preferred solution.
Relationship to Environment within which the project Environment is dynamic; and programme
environment takes place is understood and relatively objectives need to be managed in the context of
stable. the changing environment within which the
organization operates.
Resources Resources to deliver the project can be Resources are constrained and limited; there is
reasonably estimated in advance. competition for resources between projects.

Software Vs other types of project

 İnvisibility- Software can't be rep-resented with geometric models ,
 Complexity- The proposed model is based on the widely known and accepted
 Confirmity- The controlling document for a software
 Flexibility- project management performance
Invisibility:
 When a physical object such as a bridge or road is being constructed the progress being made
can actually be seen. With Software, progress is not immediately visible.
 One way of perceiving software project management is as the process of making visible that
which is invisible.
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
individual can be inconsistent.
 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.
Activities covered by project management

Feasibility Study
 Whether a prospective project can be started?
 Gather the information about the requirements of the proposed system.
 Identify the probable development and operational costs of the system
 Estimate the benefits of the new system
 Evaluate with a strategic plan with the proper identification of development tasks prioritized.
Planning
 Formulate an outline plan for the whole project
 Detailed plan for the initial stage of the project
 Develop detailed planning for the rest of the phases as and when they arise.
Project execution
 Projects can be executed in the same order of the project life cycle.
The software development life-cycle (ISO 12207)
  Requirement Analysis: Starts with requirements elicitation which investigates what the potential
users and their managers and employers as features and qualities of the new system.
 Architecture Design: This maps the requirements to the components of the system that is to be
built.
 Detailed Design: Each software component is made up of a number of software units that can be
separately coded and tested. The detailed design of these units is carried out separately.
 Code and Test: This could refer to writing code for each software unit in a procedural language.
 Integration: Individual components are collected together and tested if they meet the overall
requirements. Putting the components together
 Qualification Testing: System including software components has to be tested carefully to ensure
that all the requirements have been fulfilled.
 Installation: It is the process of making the new system operational. It Includes setting up
standing data, setting system parameters, installing on operational hardware platforms, user
training etc
 Acceptance Support: Including maintenance and enhancement

Plan, Methods and Methodologies

 A Plan for an activity must be based on some idea of a method of work.
 A method relates to a type of activity .
 Plan takes that method and coverts it to real activities and identifying for each activity its start
and end dates, who will carry it out, What tools and materials will be used.
 Groups of methods or techniques are often referred to as methodologies.

Software projects can be categorized into

Information systems vs Embedded systems
 In the information systems, the system interfaces with the organization
 In embedded systems, the system interfaces with the machine
Objective vs product driven
 A project might create a product as per the details specified by the client.
 The client has the responsibility for justifying the product.
Open Vs. closed systems
  Open systems are those that interact with the environment and are affected by outside changes.
 Closed systems is an isolated system that has no interaction with its external environment

Problems with software Projects

 Poor estimates and plan
 Lack of quality standards
 Lack of guidance about making organizational decision
 Lack of techniques to make progress visible
 Poor role definition – who does what?
 Incorrect success criteria

Objectives
 The project details should be clearly defined that are accepted by all the employees of an
organization.
 The project authority must be identified where there is more than one group.
 This authority is held by a project steering committee that has the overall responsibility for
setting, monitoring and modifying the objectives.
 Could be one person - or a group
 Project Board
 Project Management Board
 Steering committee

Objectives should be SMART

S – specific, that is, concrete and well-defined
M –measurable, that is, satisfaction of the objective can be objectively judged
A – achievable, that is, it is within the power of the individual or group concerned to meet the target
R – relevant, the objective must relevant to the true purpose of the project
T – time constrained: there is defined point in time by which the objective should be achieved

Goals/sub-objectives
These are steps along the way to achieving the objective. Informally, these can be defined by
completing the sentence…
Objective X will be achieved
IF the following goals are all achieved
A……………
B……………
C…………… etc
 Often a goal can be allocated to an individual.
 Individual may have the capability of achieving goal, but not the objective on their own e.g.
 Objective – user satisfaction with software product
 Analyst goal – accurate requirements
 Developer goal – software that is reliable

Measures of effectiveness
 How do we know that the goal or objective has been achieved?. By a practical test, that can be
objectively assessed.
 Mean time between failures(mtbf)
 E.g. for user satisfaction with software product: Repeat business – they buy further products from
us, Number of complaints – if low etc etc
Performance measures
 Measure the characteristics of a system that has been delivered.
 Unambiguous specification of the quality requirements of a proposed system is needed.
Predictive measures
 They indicate what the performance of the final system is likely to be.
Stakeholders
 Persons who have a stake / interest in the project.
 Stakeholders can be individuals working on a project, groups of people or organizations, or even
segments of a population.
 A stakeholder may be actively involved in a project‟s work, affected by the project‟s outcome, or
in a position to affect the project‟s success.
 Stakeholders can be an internal part of a project‟s organization, or external, such as customers,
creditors, unions, or members of a community.
They could be:
Internal to the project team
 They are under the direct control of the project leader
External to the project team, but within the same organization
 The persons involved in providing assistance from other sources to carry out the system‟s testing
and functionality.
External to both the project team and the organization
 Customers, investors who will benefit from the system or the sub-contractors who will carry out
work for the project

The Business Case

 The business case should be established at the time of the project‟s feasibility study.
 The quantification of benefits will often require the formulation of a business model which
explains how the new application can generate the claimed benefits.

Requirement specification
Functional requirements
 These define the total functionality of the system.
 SADT and information engineering are designed to provide functional requirements.
Quality requirements
 The attributes of the system which the user expects to be present in the system.
 Response time, the ease of using the system and its reliability
Resource requirements
 It deals with the identification of the cost which the organization is ready to spend for developing
a project.

Management control

 It is a set of policies and procedures designed to keep operations going according to plan”
 The management has to know about all the activities of an organization.
 The local managers may have to collect required data.
 Data processing has to be done so that raw data is transformed into useful information.
 This helps in taking decisions / plans.
 The project manager has to find out the impact on staff while taking decisions.
 This results in modeling the consequences of a potential solution.
  The progress details are to be updated.

Information and control in organizations

 Hierarchical Information and control systems
 Larger projects are to have a hierarchical management structure.
 Management information flows up the organizational structure and control flows down
 Project team members will each have a group who allocates them work and to whom they report
progress.
 The group leader will report to a manager at the next higher level
 There might be problems that cannot be resolved at a particular level.
 They will have to be reported to the next higher level of management.
 The information will have to be summarized to avoid overloaded information at the higher levels.
 Levels of decision making and information
 Each decision made in a project environment should be based on adequate information.
 Decisions are grouped at strategic, tactical and operational levels.
 Strategic decision making is about deciding objectives.
 Tactical decision making ensures that the objectives are fulfilled.
 The project leader will have to formulate a plan of action to meet those objectives
 The project leader monitors the progress to verify whether the objectives are likely to be met ad
take necessary action.
 Operational decisions relate to day – to –day work implementing the project

‘Step Wise’ Project Planning

Stepwise covers only the planning stages of a project and not monitoring and control
Step 0
 It deals with making a decision as to whether a project is worth doing.
 If so, project evaluation must be done on an individual basis or as part of strategic planning.

Step 1 Identify project scope and objectives

1.1 Identify objectives and measures of effectiveness
 „how do we know if we have succeeded?‟
1.2 Establish a project authority
 a single person or group with unity of purpose
 to avoid being pulled in different directions
1.3 Identify all stakeholders in the project and their interests
 „who will be affected/involved in the project?‟
1.4 Modify objectives in the light of stakeholder analysis
 „do we need to do things to win over stakeholders?‟
1.5 Establish methods of communication with all parties
 „how do we keep in contact?‟
 including external authorities/providers
 might lead to making a communications plan

Step 2 Identify project infrastructure

2.1 Establish link between project and any strategic plan
 „why did they want the project?‟
 assign priorities to the projects to be carried out .
 Eg.Hardware and S/W standards
 These strategic decisions must be during strategic business plan
2.2 Identify installation standards and procedures
 „what standards do we have to follow‟
 Development procedures
 Document the products created at each stage
 Change control and configuration management standards
 Any changes to requirements are implemented in a safe and orderly way.
 Quality standards and procedures manual
 Quality checks that need to be done at each point of the project life cycle
 Measurement programme-certain statistics have to collected at various stages of a project.
 Project Manager should be aware of project planning and control stds
2.3. Identify project team organization
 „where do I fit in?
 Business analyst and software developers are in different group
Step 3 Analysis of project characteristics
To ensure that appropriate methods are used for the project.
3.1 Distinguish the project as either objective or product-based.
 objective driven will give you more freedom but often there is a specified product you have to
build to form a solution
3.2 Analyse other project characteristics (including quality based ones)
 what is different about this project?
 Eg.Information system or Embedded System or safety critical system
3.3Identify high level project risks
 „what could go wrong?‟
 „what can we do to stop it?‟
 Risk can be attributed to the operational or development environments
3.4Take into account user requirements concerning implementation
 some organizations (such as government) might require use of the waterfall method
3.5Select general life cycle approach
 waterfall? Increments? Prototypes?
3.6 Review overall resource estimates
 After Risk is identified and project approach is identified ,re-estimate the effort and other
resources to implement the project.
 Eg. Function point Estimate
 „does all this increase the cost?‟
Step 4 Identify project products and activities
4.1 Identify and describe project products - „what do we have to produce?‟
Products
 The result of an activity
 Could be (among other things)
o physical thing („installed pc‟),
o a document („logical data structure‟)
o a person („trained user‟)
o a new version of an old product („updated software‟)
 The following are NOT normally products:
o activities (e.g. „training‟)
o events (e.g. „interviews completed‟)
o resources and actors (e.g. „software developer‟) - may be exceptions to this
 Products CAN BE deliverable or intermediate
Product description (PD)
• Product identity
• Description - what is it?
• Derivation - what is it based on?
• Composition - what does it contain?
• Format
• Relevant standards
• Quality criteria
Create a PD for „test data‟
4.2 Document Generic product flows

Step 4.3 Recognize product instances

 The PBS and PFD will probably have identified generic products e.g. „software modules‟
 It might be possible to identify specific instances e.g. „module A‟, „module B‟ …
 But in many cases this will have to be left to later, more detailed, planning
4.4. Produce ideal activity network
 Identify the activities needed to create each product in the PFD
 More than one activity might be needed to create a single product
 Hint: Identify activities by verb + noun but avoid „produce…‟ (too vague)
 Draw up activity network
An ‘ideal’ activity
Step 4.5 Add check-points if needed

Step 5: Estimate effort for each activity

5.1 Carry out bottom-up estimates
 distinguish carefully between effort and elapsed time
5.2. Revise plan to create controllable activities
 long activities (say 12 weeks) make a project difficult to control
 after 6 weeks are we 50% complete?
 can be hard to tell
 better to break down into smaller subtasks
 conversely, some very short, connected activities might be better bundled together, with a simple
checklist
 roughly aim for activities to match the length of the reporting period
 if you have progress meetings every 2 weeks, try to identify activities which take two weeks

Step 6: Identify activity risks

6.1.Identify and quantify risks for activities
 look at the assumptions in the plan, such as:
 time required
 availability of staff/resources
 these generate uncertainty
 simple way to handle:
 create a most likely estimate for time/effort
 create a second estimate with a safety margin such that the target has a 95% chance of being met
 look at the damage that could be caused by a risk
 pick out the most important ones
6.2. Plan risk reduction and contingency measures
  risk reduction: activity to stop risk occurring
 contingency: action if risk does occur
6.3 Adjust overall plans and estimates to take account of risks
 e.g. add new activities which reduce risks associated with other activities e.g. training, pilot
trials, information gathering
Step 7: Allocate resources
7.1 Identify and allocate resources to activities
 what type of staff is needed for activity?
 who is (provisionally) available when required?
7.2 Revise plans and estimates to take into account resource constraints
 where there is conflict establish an order of priority
 note effects upon project duration
 a GANNT chart can help resolve conflict and maximize productivity...

LT = lead tester

Week
Gantt charts TA = testing assistant
APRIL
commencing MARCH
5 12 19 26 2 9 16

Plan testing

Select subjects

Design
questionnaire

Book machine

Conduct tests

Analyse results

Draft changes

28

Step 8: Review/Publicise plan

8.1 Review quality aspects of the project plan
 Sometimes undertaking one activity can reveal that an earlier activity was not properly
completed:
 will have to be reworked
 will require effort and resources
 can lead to loss of control of project
 need to be sure that a completed task is truly completed
 need quality criteria for each task
 tick off when complete
 the list from step 1.1 will help form these
8.2 Document plans and obtain agreement
 make sure everyone understands and agrees
 specify this task in a communications plan if need be (as mentioned in step 1.5)
Steps 9 and 10: Execute Plan / Lower Levels of Planning
 During the project draw up plans for activities in greater detail as they become due
 Detail has to wait as more information becomes available
 Especially if you are using an iterative development approach
 It maintain provisional plans for more important later tasks
 Its planning in great detail too soon could be a waste of time

UNIT-I PROJECT EVALUATION

Project evaluation is normally carried out in step 0 of stepwise

Project evaluation is a step by step process of collecting, recording and organizing information
about
– Project results
 – short - term outputs (immediate results of activities or project deliverables)
– Long – term outputs (changes in behaviour, practice or policy resulting from the
result.

Why is project evaluation important?

- What progress has been made?
- Were the desired outcomes achieved? Why?
- Whether the project can be refined to achieve better outcomes?
- do the project results justify the project inputs?

What are the challenges in monitoring and evaluation?

- getting the commitment to do it.
- establishing base lines at the beginning of the project.
- identifying realistic quantitative and qualitative indicator.
- finding the time to do it and striking to it.
- getting feedback from your stakeholders.
- reporting back to your stakeholders.

STRATEGIC ASSESSMENT

WHAT IS STRATEGIC PLANNING?

Strategic planning is defined as an organization‟s process of defining its strategy/ policy,
or direction and making decisions on allocating its resources to pursue this strategy, including its
capital and people
- What do we do?
- For whom do we do it?
- How do we excel?

STRATEGIC ASSESSMENT is the first criteria for project evaluation

– For evaluating and managing the projects, the individual projects should be seen as
components of a programme.
Programme management:
• D.C. Ferns defined ―a programme as a group of projects that are managed in a co-
ordinated way to gain benefits that would not be possible were the projects to be
managed independently.
• A programme is a ―collection of projects that all contribute to the same overall
organization goal.
• Effective programme management requires that there is a well defined programme goal
and that all the organization‟s projects are selected and tuned to contribute to this goal
• Evaluating of project is depends on:
• How it contributes to programme goal.
• It is viability [capability of developing or useful].
• Timing.
• Resourcing - software available to develop projects
• For successful strategic assessment, there should be a strategic plan which defines:
• Organization‟s objectives.
• Provides context for defining programme
• Provides context for defining programme goals.
• Provide context for accessing individual project.

• In large organization, programme management is taken care by programme director and

programme executive, rather than, project manager, who will be responsible for the
strategic assessment of project.
• Any potential software system will form part of the user organization‟s overall
information system and must be evaluated within the context of existing information
system and the organization‟s information strategy.
• If a well – defined information system does not exist then the system development and
the assessment of project proposals will be based on a more ―piece meal approach.
• Piece meal approach is one in which each project being individually early in its life cycle.
• Typical issues and questions to be considered during strategic assessment

Types of programme
• Strategic
• Business cycle programmes
• Infrastructure programmes
• Research and development programmes
• Innovative partnerships

Strategic
• Several projects together implement a single strategy. For example, merging two
organizations will involve many different activities e.g. physical re-organization of
offices, redesigning the corporate image, merging ICT systems etc. Each of these
activities could be project within an overarching programme.

Business cycle programmes

• A portfolio of project that are to take place within a certain time frame e.g. the next
financial year

Infrastructure programmes
• In an organization there may be many different ICT-based applications which share
the same hardware/software infrastructure

Research and development programmes

• In a very innovative environment where new products are being developed, a range of
products could be developed some of which are very speculative and high-risk but
potentially very profitable and some will have a lower risk but will return a lower
profit. Getting the right balance would be key to the organization‟s long term success

Innovative partnerships
• e.g. pre-competitive co-operation to develop new technologies that could be exploited
by a whole range of companies

Programme managers versus project managers

Programme manager
 – Many simultaneous projects
– Personal relationship with skilled resources
– Optimization of resource use
– Projects tend to be seen as similar
Project manager
– One project at a time
– Impersonal relationship with resources
– Minimization of demand for resources
– Projects tend to be seen as unique
Creation of Programme
Programme Mandate describing
– The new services/capabilities that the programme should deliver
– How an organization will be improved
– Fit with existing organizational goals
• A programme director appointed a champion(selected by sponsoring group)for the
scheme
The programme brief –
• equivalent of a feasibility study
• It has the following section
• Vision stmt-new capacity needed by the orgn
• Benefits
• Risks and issues
• Estimated cost, time scales and effort
The vision statement –
– explains the new capability that the organization will have
– Worth of the pgm
– Setting small team
– Program manager
The blueprint – explains the changes to be made to obtain the new capability
Business model
Organization Structure
Information s/m, equipment and non staff requirement
Data and info requirements
Cost, perormance and service level requirements

Benefit Profiles: Estimate when the expected benefits will sart to realize following the
implementation of enhanced capability

Programme Portfolio: Preliminary list of the projects that the progreamme will need inorder
to achieve its objective.

Stake holders map: Identifying the groups of people with an interest in the project and its
outcome and their particular interest may be drawn up.

Communication Strategy: Shows how the appropriate information flow between stake holders
can be setup and maintained
Programme preliminary planning
• Project portfolio
• Cost estimate for ecah project
• Benefits expected
 • Risk identified
• Resources needed to manage, support and monitor the programme

Aids to programme management

• Dependency diagrams
• Delivery planning

Dependency diagrams
• It specify the physical and technical dependencies between projects.
Eg. Dependency diagrams merging of 2 organizations

Delivery planning
– Programme may be subdivided into tranches or identifiable stages.
– A tranche is group of projects that will deliver their products as one step in
the programme.
Eg. Delivery Planning
Delivering tranches of project deliverables
Advantages of Tranche
Deliverables of each of the projects combine to provide a coherent new capability or
set of benefits for the client.

• Portfolio management
– Strategic and operational assessment carried by an organization on behalf of
customer is called portfolio management [third party developers]
– They make use of assessment of any proposed project themselves.
– They ensure for consistency with the proposed strategic plan.
– They proposed project will form part of a portfolio of ongoing and planned projects
– Selection of projects must take account of possible effects on other projects in the
portfolio( example: competition of resource) and the overall portfolio profile(
example:
specialization versus diversification).

----------------------------------------------------------------------------------------------------------------
-----

EVALUATION OF INDIVIDUAL PROJECT:

1. Technical assessment
 It is the second criteria for evaluating the project. 
 Technical assessment of a proposed system evaluates functionality against available: 
Hardware
Software
• Limitations
– Nature of solutions produced by strategic information systems
plan Cost of solution. Hence undergoes cost-benefit analysis

Economic
Assessment
1. Cash –benefit analysis
It is the most common way for carrying out the economical assessment.
It focuses on whether the estimated income and other benefits exceed the estimated costs.
It comprises of two steps,
 Identifying and estimating all the cost and benefits of carrying out the project and
operating the delivered application
– Development costs: Development costs include the salaries and other
employment costs of the staff involved in the development project and all
associated costs.
– Set-up: Setup costs include the costs of putting the system into place. These
consists of mainly the costs of the new hardware
– Operational costs: It consists of the costs of operating the system once it has
been installed.
 Expressing these costs and benefits in common units.

2. Cash flow forecasting

 As important as estimating the overall costs and benefits of a project is the forecasting
of the cash flow that will take place and their timing. 

 A cash flow forecast will indicate when expenditure and income will take place. 

 The following diagram shows typical product life cycle cash flow 

 We need to spend money, such as staff wages during the development stages of a
project. Such expenditure cannot be deferred until is received. It is important that we
know that we can fund the development expenditure either from the company‟s own
resources or by borrowing from the bank.

 In any event, it is vital to have some forecast of when expenditure such as the
payment of salaries and bank interest will take place and when any income is to be
expected, such as payment on completion or possibly, stage payments.

 Accurate cash flow forecasting is not easy, as it generally needs to be done early in
the project life cycle and many items to be estimated. The following table illustrates
cash flow forecasts for a project.

Year Cash-flow
 0 -100,000
1 10,000
2 10,000
3 10,000
4 20,000
5 100,000
Net profit 50,000

project cash flow projections

In each case it is assumed that the cash flows take at the end of the each year. For short –term
projects or where candidates projects demonstrate significant seasonal cash flow patterns it
can be advisable to produce quarterly, or even monthly, cash flow forecasts.

COST-BENEFITS EVALUATION TECHNIQUES

Various cost-benefits Evaluation Techniques are
• Net profit

• Payback period

• Return on investment

• Net present value

• Internal rate of return

1. Net profit
• Difference between total cost and total income
• Pros: Easy to calculate
• Cons
• Does not show profit relative to size investment
• Does not consider timing of payments
• Not very useful other than for "back of envelope" evaluations

Year Cash-flow
0 -100,000
1 10,000
2 10,000
3 10,000
4 20,000
5 100,000
 Net profit 50,000
2.Payback Period

• The payback measures the length of time it takes a company to recover in cash its
initial investment
• The length of time it takes the project to generate cash equal to the investment and
pay the company back.
• It is calculated by dividing the capital investment by the net annual cash flow.
• If the net annual cash flow is not expected to be the same, the average of the net
annual cash flows may be used.
• The payback period is the time taken to recover the initial investment.Or
• is the length of time required for cumulative incoming returns to equal the cumulative
costs of an investment
• Cash Payback Period = Capital Investment / Average annual net cash flow
Year 1:10,000
Year 2: 10,000
Year 3: 10,000
Year 4: 20,000
Year 5: 1,00,000
10,000+10,000+10,000+20,000+1,00,000=1,50,000
The payback period for the project is year 5

• The shorter the payback period, the sooner the company recovers its cash
investment.

• When net annual cash flows are different, the cumulative net annual cash flows are
used to determine the payback period

Advantages and Disadvantages

Advantages of payback period are:

 Payback period is very simple to calculate.

 It can be a measure of risk inherent in a project. Since cash flows that occur later in
a project's life are considered more uncertain, payback period provides an indication
of how certain the project cash inflows are.

 For companies facing liquidity problems, it provides a good ranking of projects that
would return money early.
Disadvantages of payback period are:
 Payback period does not take into account the time value of money which is a
serious drawback since it can lead to wrong decisions. A variation of payback
method that attempts to remove this drawback is called discounted payback period
method.

 It does not take into account, the cash flows that occur after the payback period.

3. Return on investment
• It provides a way of comparing the net profitability to the investment required. Or
 • A performance measure used to evaluate the efficiency of an investment or to
compare the efficiency of a number of different investments
• Disadvantages
• It takes no account of the timing of the cash flows.
• Rate of returns bears no relationship to the interest rates offered or changed by bank.

• ROI = average annual profit * 100

total investment
average annual profit = net profit
total no. of years
• average annual profit
= 50,000/5
= 10,000
• ROI = 10,000/100,000 X 100 = 10%

4. Net present value

• A project evaluation technique that takes into account the profitability of a project and
the timing of the cash flows that are produced
• Sum of all incoming and outgoing payments, discounted using an interest rate, to a
fixed point in time (the present)
• It is a discounted cash flow technique
• Consider the timing and amount of cash flows. To use the net present value method,
you will need to know the cash inflows, the cash outflows, and the company's
required rate of return on its investments.
• The required rate of return becomes the discount rate used in the net present value
calculation.

Discount factor
• Discount factor = 1/(1+r)t
• r is the interest rate (e.g. 10% is 0.10)
• t is the number of years

• In the case of 10% rate and one year

• Discount factor = 1/(1+0.10) = 0.9091

• In the case of 10% rate and two years

• Discount factor = 1/(1.10 x 1.10) =0.8294

• In the case of 10% rate and three years

• Discount factor = 1/(1.10 x 1.10 x 1.10) =0.7513

• In the case of 10% rate and four years

• Discount factor = 1/(1.10 x 1.10 x 1.10 x 1.10) =0.6830

• In the case of 10% rate and five years

• Discount factor = 1/(1.10 x 1.10 x 1.10 x 1.10 x 1.10) =0.6209
Year Cash-flow Discount Discounted
factor cash flow
 0 -100,000 1.0000 -100,000

1 10,000 0.9091 9,091

2 10,000 0.8264 8,264

3 10,000 0.7513 7,513

4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

NPV 618

Advantages
• Takes into account profitability
• Considers timing of payments Considers economic situation through discount
rate Disadvantage Discount rate can be difficult choose

5. Internal rate of return (IRR)

• Internal rate of return (IRR) is the discount rate that would produce an NPV of 0 for
the project

• The internal rate of return (IRR) determines the interest yield of the proposed capital
project at which the net present value equals zero, which is where the present value of
the net cash inflows equals the investment.

• If the IRR is greater than the company's required rate of return, the project may be
accepted.

• To determine the internal rate of return requires two steps. First, the internal rate of
return factor is calculated by dividing the proposed capital investment amount by the
net annual cash inflow.

• Then, the factor is found in the Present Value of an Annuity of 1 table using the
service life of the project for the number of periods.

• The discount rate that the factor is the closest to is the internal rate of return.

• Can be used to compare different investment opportunities

IRR=(rate giving positive NPV)+(difference between rates*(positive NPV/difference

between NPV))

Calculate NPV with Discount Factor =10%

 Year Cash- Discount Discounted
flow factor cash flow
0 -9000 1.0000 -9000
1 2000 0.9091 1818.2
2 3000 0.8264 2479.2
3 3000 0.7513 2253.9
4 4000 0.6830 2732
NPV 283.3

Calculate NPV with discount factor 12%

Year Cash- Discount Discounted
flow factor cash flow
0 -9000 1.0000 -9000
1 2000 0.8928 1785.6
2 3000 0.7971 2391.6
3 3000 0.7117 2135.4
4 4000 0.6355 2542
NPV -145.4

IRR=10+(2*(283.3/(283.3-(-145.4))))
=10+(2*(283.3/428.7))
=11.8

• Advantage: Calculates figure which is easily to interest rates

• Disadvantage : Difficult to calculate (iterative)

RISK EVALUATION

Risk evaluation is meant to decide whether to proceed with the project or not, and whether
the project is meeting its objectives.
Risk Occurs:
• When the project exceed its original specification
• Deviations from achieving it objectives and so on.
Every project involves risk. The project risks which prevent the project being completed
successfully and the business risk that the delivered products are nor profitable. Risk
evaluation consists of
 Risk identification and ranking 
 Risk and NPV 
 Cost benefit analysis 
  Risk profile analysis 

Risk identification and ranking

• Identify the risk and give priority.
• Could draw up draw a project risk matrix for each project to assess risks
• Project risk matrix used to identify and rank the risk of the
project Example of a project risk matrix

Risk and net present value

 Where a project is relatively risky it is common practice to use a higher discount rate
to calculate the NPV. The risk premium be an additional 2 % for an safe project or 5 %
for a fairly risky project
 Projects may be categorized as high, medium or low risk using a scoring method and
risk premiums designated for each category.

Cost-benefit analysis
 A rather more sophisticated approach to the evaluation of risk is to consider each
possible outcome, probability of its occurring and the corresponding value of the
outcome.
 Rather than a single cash flow forecast for a project, we will then have a set of cash
flow forecasts, each with an associated probability of occurring.
 The value of the project is then obtained by summing of the cost or benefit for each
possible outcome weighted by its corresponding probability.
 Drawback: Does not take full account of worst-case scenarios.(averaging out the
negative and positive outcomes of the scenarios)
Sales Annual Sales income Probability Expected value

i P i*p

High 8,00,000 0.1 80,000

Medium 6,50,000 0.6 3,90,000

Low 1,00,000 0.3 30,000

Expected 5,00,000
Income

Risk profile analysis

• An approach which attempts to overcome some of the objections to cost benefit
averaging is the construction of risk profiles using sensitivity analysis.
• This makes use of ―risk profiles‖ using sensitivity analysis.
• It compares the sensitivity of each factor of project profiles by varying parameters
which affect the project cost benefits.
• Eg:
• Vary the original estimates of risk plus or minus 5% and re-calculate the expected
cost benefits.
• P1 depart far from p2,have large variation
• P3 have much profitable than expected
 • All three projects have the same expected profit
• Compare to p2, p1 is less risky.

Decision tree
Decision tree provide tools for evaluating expected outcomes and choosing between
alternate strategies. A decision tree is a decision support tool that uses a tree-like graph or
model of decisions and their possible consequences, including chance event outcomes,
resource costs, and utility. It is one way to display an algorithm.

Decision trees method for risk evaluation:-

1. An alternative would be to replace the whole of the system.

2. The decision is influenced by the likelihood of org expanding their market.
3. There is a strong rumour that they could benefit from their main competitor going out
of business: in this case they could pick up a huge amount of new business, but the
invoicing system could not cope.
4. However replacing the system immediately would mean other important projects
would have to be delayed.
5. The NPV of extending the invoicing system is assessed as £75,000 if there is no
sudden expansion.
6. If there were a sudden expansion then there would be a loss of £100,000.
7. If the whole system were replaced and there was a large expansion there would be a
NPV of £250,000 due to the benefits of being able to handle increased sales.
 8. If sales did not increase then the NPV would be -£50,000.
9. The decision tree shows these possible outcomes and also shows the estimated
probability of each outcome.
10. The value of each outcome is the NPV multiplied by the probability of its occurring.
11. The value of a path that springs from a particular decision is the sum of the values of
the possible outcomes from that decision. If it is decided to extend the system the sum
of the values of the outcomes is £40,000 (75,000 x 0.8 – 100,000 x 0.2) while for
replacement it would be £10,000 (250,000 x 0.2 – 50,000 x 0.80).
12. Extending the system therefore seems to be best option.

Benefit Management

• Providing an organization with a capability does not guarantee that this will provide
benefits envisaged – need for benefits management
• This has to be outside the project – project will have been completed
• Therefore done at programme level
“It encompasses the identification, optimization and tracking of the expected benefits from a
business change in order to ensure that they are actually achieved”
To carry out benefit Management,
• Define expected benefits
• Analyse balance between costs and benefits
• Plan how benefits will be achieved
• Allocate responsibilities for their achievement
• Monitor achievement of benefits
Three categories of Benefit
• Direct Benefit: Directly obtained benefit by making use of/ operating the system.
• Assessable indirect benefits: These benefits are obtained due to updation/upgrading
the performance of the current system.
• Intangiable benefits: These benefits are long term, difficult to quantify, It also referred
as indirect benefits
Benefits can be of many different types,
• Mandatory requirement: Governmental or European legislation might make certain
changes mandatory.
• Improved quality of service: An insurance company for example, might want to settle
claims by customer more quickly
• Increased productivity: The same, or even more, work can be done at less cost in staff
time.
• More motivated workforce: This might be because of an improved rewards system, or
through job enlargement or job enrichment.
 • Internal management benefits: (Better decision making) To take an insurance
example, better analyusis of insurance claims could pinpoint those categories of
business which are most risky and alow an insurance company to adjust premiums to
cover this.
• Risk reduction: The insurance for example might also be applicable here, but
measures to protect an organisation‟s networks and databases from intrusion and
external malicious attack would be even more pertinent.
• Economies: The reduction of cost, other than those related to staff – procurement
policies might be put in place which encourage the consolidation of purchasing in
order to take advantage of bulk buying at discount
• Revenue enhancement/acceleration: The sooner the bill reaches the customer, the
sooner they can pay them.
• Strategic fit: A change might not directly benefit a particular group within the
organisation but has to be made inorder to obtain some strategic advantage for the
organization as the whole.
Quantifying benefits
Benefits can be:
• Quantified and valued – that is, a direct financial benefit is experienced
• Quantified but not valued e.g. a decrease in customer complaints by x%
• Identified but not easily quantified – e.g. public approval for a organization in the
locality where it is based
Disbenefit: Increased sales might mean that more money has to be spent on expensive
overtime working.
MG6088 SOFTWARE PROJECT MANAGEMENT
UNIT 1
INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

Software Definition
 Software is instructions (computer programs) that when executed provide desired features,
Function and performance
 Data structures that enable the programs to adequately manipulate information.
 Documents that describe the operation and use of the programs.
 Software is a program that is the product of a project

Project Definition
 Project is a specific plan or design
 Project is a planned undertaking/activity
 Project is a large undertaking e.g. a public works scheme
 Project determines how to carry out a task before starting the task
 Project is a new endeavor to accomplish a unique purpose.
 In the broadest sense, a project is a specific, finite task to be accomplished. Any activity that
results in a deliverable or a product.
 Projects always begin with a problem. The project is to provide the solution to this problem.
 When the project is finished it must be evaluated to determine whether it satisfies the objectives
and goals.
Jobs versus projects

„Jobs‟ – repetition of very well-defined and well understood tasks with very little uncertainty
„Exploration‟ – e.g. finding a cure for cancer: the outcome is very uncertain
„Projects‟ – in the middle!

Characteristics of projects
A task is more „project-like‟ if it is:
 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 predetermined time span
 Work is carried out for someone other than yourself
 Work involves several specialisms
 Work is carried out in several different phases
 Resources that are available for use on the project are constrained.
 Project is large and/or complex
Management Definition
  Management can be defined as all activities and tasks undertaken by one or more persons for the
purpose of planning and controlling the activities of others in order to achieve objectives or
complete an activity that could not be achieved by others acting independently.
 Management is to manage to forecast and plan to organize, to command, to co-ordinate and to
control.
 “Management is getting things done through the efforts of other people”.
 “It is process towards the attainment of desired goals”.

This involves the following activities:

 Planning is deciding what is to be done
 Organizing is making arrangements
 Staffing is selecting the right people for the job
 Directing is giving instructions
 Monitoring is checking on progress
 Controlling is taking action to remedy hold-ups
 Innovating is coming up with solutions when problems emerge
 Representing is liaising with clients, users, developers and other stakeholders

PROJECT MANAGEMENT
 Project management is the discipline of planning, organizing, and managing resources to bring
about the successful completion of specific projects goals and objectives.
 A project is a planned undertaking to present results at a specified time. Here „ undertaking‟
means „making‟ new product or „changing‟ old product.
 Task : A piece of work assigned or done as part of one's duties.
 Activity : Activity definition refers to the process of parsing a project into a number of individual
tasks which must be completed before the deliverables can be considered completed.
 Activity definitions rely on a number of specific input processes.
 Activities can be subdivided into tasks.
 Phase: a group of activities/tasks, producing a significant deliverable work product.
 Project : A unique, goal-oriented, time-bound and constrained undertaking.
 System: an organized element acting as a whole.

SOFTWARE PROJECT MANAGEMENT

 Software project management is the art and science of planning and leading software projects. It
is a sub-discipline of project management in which software projects are planned, monitored and
controlled.

PROGRAMME
 A programme is a portfolio comprised of multiple projects that are managed and coordinated as
one unit with the objective of achieving (often intangible) outcomes and benefits for the
organization.
 A programme is a group of related projects managed to obtain collective benefits ,often with a
strategic goal, which may involve a series of repetitive or cyclic undertaking
 A programme is a group of related projects managed in a coordinated way

PROCESS
Process is a structured set of activities required to develop a software system
• Specification;
• Design;
• Validation;
• Evolution.
A software process model is an abstract representation of a process. It presents a description of a process
from some particular perspective.
PROJECT Vs PROCESS
• Process is a repetitive collection of interrelated tasks aimed at achieving a certain goal.
• Project is a unique endeavor with a beginning and an end undertaken to achieve a goal.
 • Process is a set of related resources and activities transforming inputs into outputs (from example
Risk management process_
• Project: Is an endeavor with a defined start date and end date, to meet specific objectives.

Difference between a Project and a Programme

Project Programme

Objectives Outputs – tangible; relatively easy to Outcomes – often intangible; difficult to

describe, define and measure; tending quantify; benefits often based on changes to
towards objective. organizational culture and behaviors; introducing
new capabilities into the organization; tending
towards subjective.
Scope Strictly limited; tightly defined; not Not tightly defined or bounded; likely to change
subject to change during the life of the during the life cycle of the program.
project.
Duration Relatively short term; typically three to Relatively long term typically eighteen months
six months. to three years.
Risk profile Project risk is relatively easy to identify
Program risk is more complex and potentially the
and manage. The project failure would impact on the organization if a risk materializes
result in relatively limited impact on the
will be greater relative to project risk.
organization relative to program risk. Programme failure could result in material
financial, reputational or operational loss.
Nature of the Clearly defined. Ill-defined; often disagreement between key
problem stakeholders on the nature and definition of the
problem.
Nature of the A relatively limited number of potential A significant number of potential solutions with
solution and solutions. disagreement between stakeholders as to the
Stake holders preferred solution.
Relationship to Environment within which the project Environment is dynamic; and programme
environment takes place is understood and relatively objectives need to be managed in the context of
stable. the changing environment within which the
organization operates.
Resources Resources to deliver the project can be Resources are constrained and limited; there is
reasonably estimated in advance. competition for resources between projects.

Software Vs other types of project

 İnvisibility- Software can't be rep-resented with geometric models ,
 Complexity- The proposed model is based on the widely known and accepted
 Confirmity- The controlling document for a software
 Flexibility- project management performance
Invisibility:
 When a physical object such as a bridge or road is being constructed the progress being made
can actually be seen. With Software, progress is not immediately visible.
 One way of perceiving software project management is as the process of making visible that
which is invisible.
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
individual can be inconsistent.
 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.
Activities covered by project management

Feasibility Study
 Whether a prospective project can be started?
 Gather the information about the requirements of the proposed system.
 Identify the probable development and operational costs of the system
 Estimate the benefits of the new system
 Evaluate with a strategic plan with the proper identification of development tasks prioritized.
Planning
 Formulate an outline plan for the whole project
 Detailed plan for the initial stage of the project
 Develop detailed planning for the rest of the phases as and when they arise.
Project execution
 Projects can be executed in the same order of the project life cycle.
The software development life-cycle (ISO 12207)
  Requirement Analysis: Starts with requirements elicitation which investigates what the potential
users and their managers and employers as features and qualities of the new system.
 Architecture Design: This maps the requirements to the components of the system that is to be
built.
 Detailed Design: Each software component is made up of a number of software units that can be
separately coded and tested. The detailed design of these units is carried out separately.
 Code and Test: This could refer to writing code for each software unit in a procedural language.
 Integration: Individual components are collected together and tested if they meet the overall
requirements. Putting the components together
 Qualification Testing: System including software components has to be tested carefully to ensure
that all the requirements have been fulfilled.
 Installation: It is the process of making the new system operational. It Includes setting up
standing data, setting system parameters, installing on operational hardware platforms, user
training etc
 Acceptance Support: Including maintenance and enhancement

Plan, Methods and Methodologies

 A Plan for an activity must be based on some idea of a method of work.
 A method relates to a type of activity .
 Plan takes that method and coverts it to real activities and identifying for each activity its start
and end dates, who will carry it out, What tools and materials will be used.
 Groups of methods or techniques are often referred to as methodologies.

Software projects can be categorized into

Information systems vs Embedded systems
 In the information systems, the system interfaces with the organization
 In embedded systems, the system interfaces with the machine
Objective vs product driven
 A project might create a product as per the details specified by the client.
 The client has the responsibility for justifying the product.
Open Vs. closed systems
  Open systems are those that interact with the environment and are affected by outside changes.
 Closed systems is an isolated system that has no interaction with its external environment

Problems with software Projects

 Poor estimates and plan
 Lack of quality standards
 Lack of guidance about making organizational decision
 Lack of techniques to make progress visible
 Poor role definition – who does what?
 Incorrect success criteria

Objectives
 The project details should be clearly defined that are accepted by all the employees of an
organization.
 The project authority must be identified where there is more than one group.
 This authority is held by a project steering committee that has the overall responsibility for
setting, monitoring and modifying the objectives.
 Could be one person - or a group
 Project Board
 Project Management Board
 Steering committee

Objectives should be SMART

S – specific, that is, concrete and well-defined
M –measurable, that is, satisfaction of the objective can be objectively judged
A – achievable, that is, it is within the power of the individual or group concerned to meet the target
R – relevant, the objective must relevant to the true purpose of the project
T – time constrained: there is defined point in time by which the objective should be achieved

Goals/sub-objectives
These are steps along the way to achieving the objective. Informally, these can be defined by
completing the sentence…
Objective X will be achieved
IF the following goals are all achieved
A……………
B……………
C…………… etc
 Often a goal can be allocated to an individual.
 Individual may have the capability of achieving goal, but not the objective on their own e.g.
 Objective – user satisfaction with software product
 Analyst goal – accurate requirements
 Developer goal – software that is reliable

Measures of effectiveness
 How do we know that the goal or objective has been achieved?. By a practical test, that can be
objectively assessed.
 Mean time between failures(mtbf)
 E.g. for user satisfaction with software product: Repeat business – they buy further products from
us, Number of complaints – if low etc etc
Performance measures
 Measure the characteristics of a system that has been delivered.
 Unambiguous specification of the quality requirements of a proposed system is needed.
Predictive measures
 They indicate what the performance of the final system is likely to be.
Stakeholders
 Persons who have a stake / interest in the project.
 Stakeholders can be individuals working on a project, groups of people or organizations, or even
segments of a population.
 A stakeholder may be actively involved in a project‟s work, affected by the project‟s outcome, or
in a position to affect the project‟s success.
 Stakeholders can be an internal part of a project‟s organization, or external, such as customers,
creditors, unions, or members of a community.
They could be:
Internal to the project team
 They are under the direct control of the project leader
External to the project team, but within the same organization
 The persons involved in providing assistance from other sources to carry out the system‟s testing
and functionality.
External to both the project team and the organization
 Customers, investors who will benefit from the system or the sub-contractors who will carry out
work for the project

The Business Case

 The business case should be established at the time of the project‟s feasibility study.
 The quantification of benefits will often require the formulation of a business model which
explains how the new application can generate the claimed benefits.

Requirement specification
Functional requirements
 These define the total functionality of the system.
 SADT and information engineering are designed to provide functional requirements.
Quality requirements
 The attributes of the system which the user expects to be present in the system.
 Response time, the ease of using the system and its reliability
Resource requirements
 It deals with the identification of the cost which the organization is ready to spend for developing
a project.

Management control

 It is a set of policies and procedures designed to keep operations going according to plan”
 The management has to know about all the activities of an organization.
 The local managers may have to collect required data.
 Data processing has to be done so that raw data is transformed into useful information.
 This helps in taking decisions / plans.
 The project manager has to find out the impact on staff while taking decisions.
 This results in modeling the consequences of a potential solution.
  The progress details are to be updated.

Information and control in organizations

 Hierarchical Information and control systems
 Larger projects are to have a hierarchical management structure.
 Management information flows up the organizational structure and control flows down
 Project team members will each have a group who allocates them work and to whom they report
progress.
 The group leader will report to a manager at the next higher level
 There might be problems that cannot be resolved at a particular level.
 They will have to be reported to the next higher level of management.
 The information will have to be summarized to avoid overloaded information at the higher levels.
 Levels of decision making and information
 Each decision made in a project environment should be based on adequate information.
 Decisions are grouped at strategic, tactical and operational levels.
 Strategic decision making is about deciding objectives.
 Tactical decision making ensures that the objectives are fulfilled.
 The project leader will have to formulate a plan of action to meet those objectives
 The project leader monitors the progress to verify whether the objectives are likely to be met ad
take necessary action.
 Operational decisions relate to day – to –day work implementing the project

‘Step Wise’ Project Planning

Stepwise covers only the planning stages of a project and not monitoring and control
Step 0
 It deals with making a decision as to whether a project is worth doing.
 If so, project evaluation must be done on an individual basis or as part of strategic planning.

Step 1 Identify project scope and objectives

1.1 Identify objectives and measures of effectiveness
 „how do we know if we have succeeded?‟
1.2 Establish a project authority
 a single person or group with unity of purpose
 to avoid being pulled in different directions
1.3 Identify all stakeholders in the project and their interests
 „who will be affected/involved in the project?‟
1.4 Modify objectives in the light of stakeholder analysis
 „do we need to do things to win over stakeholders?‟
1.5 Establish methods of communication with all parties
 „how do we keep in contact?‟
 including external authorities/providers
 might lead to making a communications plan

Step 2 Identify project infrastructure

2.1 Establish link between project and any strategic plan
 „why did they want the project?‟
 assign priorities to the projects to be carried out .
 Eg.Hardware and S/W standards
 These strategic decisions must be during strategic business plan
2.2 Identify installation standards and procedures
 „what standards do we have to follow‟
 Development procedures
 Document the products created at each stage
 Change control and configuration management standards
 Any changes to requirements are implemented in a safe and orderly way.
 Quality standards and procedures manual
 Quality checks that need to be done at each point of the project life cycle
 Measurement programme-certain statistics have to collected at various stages of a project.
 Project Manager should be aware of project planning and control stds
2.3. Identify project team organization
 „where do I fit in?
 Business analyst and software developers are in different group
Step 3 Analysis of project characteristics
To ensure that appropriate methods are used for the project.
3.1 Distinguish the project as either objective or product-based.
 objective driven will give you more freedom but often there is a specified product you have to
build to form a solution
3.2 Analyse other project characteristics (including quality based ones)
 what is different about this project?
 Eg.Information system or Embedded System or safety critical system
3.3Identify high level project risks
 „what could go wrong?‟
 „what can we do to stop it?‟
 Risk can be attributed to the operational or development environments
3.4Take into account user requirements concerning implementation
 some organizations (such as government) might require use of the waterfall method
3.5Select general life cycle approach
 waterfall? Increments? Prototypes?
3.6 Review overall resource estimates
 After Risk is identified and project approach is identified ,re-estimate the effort and other
resources to implement the project.
 Eg. Function point Estimate
 „does all this increase the cost?‟
Step 4 Identify project products and activities
4.1 Identify and describe project products - „what do we have to produce?‟
Products
 The result of an activity
 Could be (among other things)
o physical thing („installed pc‟),
o a document („logical data structure‟)
o a person („trained user‟)
o a new version of an old product („updated software‟)
 The following are NOT normally products:
o activities (e.g. „training‟)
o events (e.g. „interviews completed‟)
o resources and actors (e.g. „software developer‟) - may be exceptions to this
 Products CAN BE deliverable or intermediate
Product description (PD)
• Product identity
• Description - what is it?
• Derivation - what is it based on?
• Composition - what does it contain?
• Format
• Relevant standards
• Quality criteria
Create a PD for „test data‟
4.2 Document Generic product flows

Step 4.3 Recognize product instances

 The PBS and PFD will probably have identified generic products e.g. „software modules‟
 It might be possible to identify specific instances e.g. „module A‟, „module B‟ …
 But in many cases this will have to be left to later, more detailed, planning
4.4. Produce ideal activity network
 Identify the activities needed to create each product in the PFD
 More than one activity might be needed to create a single product
 Hint: Identify activities by verb + noun but avoid „produce…‟ (too vague)
 Draw up activity network
An ‘ideal’ activity
Step 4.5 Add check-points if needed

Step 5: Estimate effort for each activity

5.1 Carry out bottom-up estimates
 distinguish carefully between effort and elapsed time
5.2. Revise plan to create controllable activities
 long activities (say 12 weeks) make a project difficult to control
 after 6 weeks are we 50% complete?
 can be hard to tell
 better to break down into smaller subtasks
 conversely, some very short, connected activities might be better bundled together, with a simple
checklist
 roughly aim for activities to match the length of the reporting period
 if you have progress meetings every 2 weeks, try to identify activities which take two weeks

Step 6: Identify activity risks

6.1.Identify and quantify risks for activities
 look at the assumptions in the plan, such as:
 time required
 availability of staff/resources
 these generate uncertainty
 simple way to handle:
 create a most likely estimate for time/effort
 create a second estimate with a safety margin such that the target has a 95% chance of being met
 look at the damage that could be caused by a risk
 pick out the most important ones
6.2. Plan risk reduction and contingency measures
  risk reduction: activity to stop risk occurring
 contingency: action if risk does occur
6.3 Adjust overall plans and estimates to take account of risks
 e.g. add new activities which reduce risks associated with other activities e.g. training, pilot
trials, information gathering
Step 7: Allocate resources
7.1 Identify and allocate resources to activities
 what type of staff is needed for activity?
 who is (provisionally) available when required?
7.2 Revise plans and estimates to take into account resource constraints
 where there is conflict establish an order of priority
 note effects upon project duration
 a GANNT chart can help resolve conflict and maximize productivity...

LT = lead tester

Week
Gantt charts TA = testing assistant
APRIL
commencing MARCH
5 12 19 26 2 9 16

Plan testing

Select subjects

Design
questionnaire

Book machine

Conduct tests

Analyse results

Draft changes

28

Step 8: Review/Publicise plan

8.1 Review quality aspects of the project plan
 Sometimes undertaking one activity can reveal that an earlier activity was not properly
completed:
 will have to be reworked
 will require effort and resources
 can lead to loss of control of project
 need to be sure that a completed task is truly completed
 need quality criteria for each task
 tick off when complete
 the list from step 1.1 will help form these
8.2 Document plans and obtain agreement
 make sure everyone understands and agrees
 specify this task in a communications plan if need be (as mentioned in step 1.5)
Steps 9 and 10: Execute Plan / Lower Levels of Planning
 During the project draw up plans for activities in greater detail as they become due
 Detail has to wait as more information becomes available
 Especially if you are using an iterative development approach
 It maintain provisional plans for more important later tasks
 Its planning in great detail too soon could be a waste of time

UNIT-I PROJECT EVALUATION

Project evaluation is normally carried out in step 0 of stepwise

Project evaluation is a step by step process of collecting, recording and organizing information
about
– Project results
 – short - term outputs (immediate results of activities or project deliverables)
– Long – term outputs (changes in behaviour, practice or policy resulting from the
result.

Why is project evaluation important?

- What progress has been made?
- Were the desired outcomes achieved? Why?
- Whether the project can be refined to achieve better outcomes?
- do the project results justify the project inputs?

What are the challenges in monitoring and evaluation?

- getting the commitment to do it.
- establishing base lines at the beginning of the project.
- identifying realistic quantitative and qualitative indicator.
- finding the time to do it and striking to it.
- getting feedback from your stakeholders.
- reporting back to your stakeholders.

STRATEGIC ASSESSMENT

WHAT IS STRATEGIC PLANNING?

Strategic planning is defined as an organization‟s process of defining its strategy/ policy,
or direction and making decisions on allocating its resources to pursue this strategy, including its
capital and people
- What do we do?
- For whom do we do it?
- How do we excel?

STRATEGIC ASSESSMENT is the first criteria for project evaluation

– For evaluating and managing the projects, the individual projects should be seen as
components of a programme.
Programme management:
• D.C. Ferns defined ―a programme as a group of projects that are managed in a co-
ordinated way to gain benefits that would not be possible were the projects to be
managed independently.
• A programme is a ―collection of projects that all contribute to the same overall
organization goal.
• Effective programme management requires that there is a well defined programme goal
and that all the organization‟s projects are selected and tuned to contribute to this goal
• Evaluating of project is depends on:
• How it contributes to programme goal.
• It is viability [capability of developing or useful].
• Timing.
• Resourcing - software available to develop projects
• For successful strategic assessment, there should be a strategic plan which defines:
• Organization‟s objectives.
• Provides context for defining programme
• Provides context for defining programme goals.
• Provide context for accessing individual project.

• In large organization, programme management is taken care by programme director and

programme executive, rather than, project manager, who will be responsible for the
strategic assessment of project.
• Any potential software system will form part of the user organization‟s overall
information system and must be evaluated within the context of existing information
system and the organization‟s information strategy.
• If a well – defined information system does not exist then the system development and
the assessment of project proposals will be based on a more ―piece meal approach.
• Piece meal approach is one in which each project being individually early in its life cycle.
• Typical issues and questions to be considered during strategic assessment

Types of programme
• Strategic
• Business cycle programmes
• Infrastructure programmes
• Research and development programmes
• Innovative partnerships

Strategic
• Several projects together implement a single strategy. For example, merging two
organizations will involve many different activities e.g. physical re-organization of
offices, redesigning the corporate image, merging ICT systems etc. Each of these
activities could be project within an overarching programme.

Business cycle programmes

• A portfolio of project that are to take place within a certain time frame e.g. the next
financial year

Infrastructure programmes
• In an organization there may be many different ICT-based applications which share
the same hardware/software infrastructure

Research and development programmes

• In a very innovative environment where new products are being developed, a range of
products could be developed some of which are very speculative and high-risk but
potentially very profitable and some will have a lower risk but will return a lower
profit. Getting the right balance would be key to the organization‟s long term success

Innovative partnerships
• e.g. pre-competitive co-operation to develop new technologies that could be exploited
by a whole range of companies

Programme managers versus project managers

Programme manager
 – Many simultaneous projects
– Personal relationship with skilled resources
– Optimization of resource use
– Projects tend to be seen as similar
Project manager
– One project at a time
– Impersonal relationship with resources
– Minimization of demand for resources
– Projects tend to be seen as unique
Creation of Programme
Programme Mandate describing
– The new services/capabilities that the programme should deliver
– How an organization will be improved
– Fit with existing organizational goals
• A programme director appointed a champion(selected by sponsoring group)for the
scheme
The programme brief –
• equivalent of a feasibility study
• It has the following section
• Vision stmt-new capacity needed by the orgn
• Benefits
• Risks and issues
• Estimated cost, time scales and effort
The vision statement –
– explains the new capability that the organization will have
– Worth of the pgm
– Setting small team
– Program manager
The blueprint – explains the changes to be made to obtain the new capability
Business model
Organization Structure
Information s/m, equipment and non staff requirement
Data and info requirements
Cost, perormance and service level requirements

Benefit Profiles: Estimate when the expected benefits will sart to realize following the
implementation of enhanced capability

Programme Portfolio: Preliminary list of the projects that the progreamme will need inorder
to achieve its objective.

Stake holders map: Identifying the groups of people with an interest in the project and its
outcome and their particular interest may be drawn up.

Communication Strategy: Shows how the appropriate information flow between stake holders
can be setup and maintained
Programme preliminary planning
• Project portfolio
• Cost estimate for ecah project
• Benefits expected
 • Risk identified
• Resources needed to manage, support and monitor the programme

Aids to programme management

• Dependency diagrams
• Delivery planning

Dependency diagrams
• It specify the physical and technical dependencies between projects.
Eg. Dependency diagrams merging of 2 organizations

Delivery planning
– Programme may be subdivided into tranches or identifiable stages.
– A tranche is group of projects that will deliver their products as one step in
the programme.
Eg. Delivery Planning
Delivering tranches of project deliverables
Advantages of Tranche
Deliverables of each of the projects combine to provide a coherent new capability or
set of benefits for the client.

• Portfolio management
– Strategic and operational assessment carried by an organization on behalf of
customer is called portfolio management [third party developers]
– They make use of assessment of any proposed project themselves.
– They ensure for consistency with the proposed strategic plan.
– They proposed project will form part of a portfolio of ongoing and planned projects
– Selection of projects must take account of possible effects on other projects in the
portfolio( example: competition of resource) and the overall portfolio profile(
example:
specialization versus diversification).

----------------------------------------------------------------------------------------------------------------
-----

EVALUATION OF INDIVIDUAL PROJECT:

1. Technical assessment
 It is the second criteria for evaluating the project. 
 Technical assessment of a proposed system evaluates functionality against available: 
Hardware
Software
• Limitations
– Nature of solutions produced by strategic information systems
plan Cost of solution. Hence undergoes cost-benefit analysis

Economic
Assessment
1. Cash –benefit analysis
It is the most common way for carrying out the economical assessment.
It focuses on whether the estimated income and other benefits exceed the estimated costs.
It comprises of two steps,
 Identifying and estimating all the cost and benefits of carrying out the project and
operating the delivered application
– Development costs: Development costs include the salaries and other
employment costs of the staff involved in the development project and all
associated costs.
– Set-up: Setup costs include the costs of putting the system into place. These
consists of mainly the costs of the new hardware
– Operational costs: It consists of the costs of operating the system once it has
been installed.
 Expressing these costs and benefits in common units.

2. Cash flow forecasting

 As important as estimating the overall costs and benefits of a project is the forecasting
of the cash flow that will take place and their timing. 

 A cash flow forecast will indicate when expenditure and income will take place. 

 The following diagram shows typical product life cycle cash flow 

 We need to spend money, such as staff wages during the development stages of a
project. Such expenditure cannot be deferred until is received. It is important that we
know that we can fund the development expenditure either from the company‟s own
resources or by borrowing from the bank.

 In any event, it is vital to have some forecast of when expenditure such as the
payment of salaries and bank interest will take place and when any income is to be
expected, such as payment on completion or possibly, stage payments.

 Accurate cash flow forecasting is not easy, as it generally needs to be done early in
the project life cycle and many items to be estimated. The following table illustrates
cash flow forecasts for a project.

Year Cash-flow
 0 -100,000
1 10,000
2 10,000
3 10,000
4 20,000
5 100,000
Net profit 50,000

project cash flow projections

In each case it is assumed that the cash flows take at the end of the each year. For short –term
projects or where candidates projects demonstrate significant seasonal cash flow patterns it
can be advisable to produce quarterly, or even monthly, cash flow forecasts.

COST-BENEFITS EVALUATION TECHNIQUES

Various cost-benefits Evaluation Techniques are
• Net profit

• Payback period

• Return on investment

• Net present value

• Internal rate of return

1. Net profit
• Difference between total cost and total income
• Pros: Easy to calculate
• Cons
• Does not show profit relative to size investment
• Does not consider timing of payments
• Not very useful other than for "back of envelope" evaluations

Year Cash-flow
0 -100,000
1 10,000
2 10,000
3 10,000
4 20,000
5 100,000
 Net profit 50,000
2.Payback Period

• The payback measures the length of time it takes a company to recover in cash its
initial investment
• The length of time it takes the project to generate cash equal to the investment and
pay the company back.
• It is calculated by dividing the capital investment by the net annual cash flow.
• If the net annual cash flow is not expected to be the same, the average of the net
annual cash flows may be used.
• The payback period is the time taken to recover the initial investment.Or
• is the length of time required for cumulative incoming returns to equal the cumulative
costs of an investment
• Cash Payback Period = Capital Investment / Average annual net cash flow
Year 1:10,000
Year 2: 10,000
Year 3: 10,000
Year 4: 20,000
Year 5: 1,00,000
10,000+10,000+10,000+20,000+1,00,000=1,50,000
The payback period for the project is year 5

• The shorter the payback period, the sooner the company recovers its cash
investment.

• When net annual cash flows are different, the cumulative net annual cash flows are
used to determine the payback period

Advantages and Disadvantages

Advantages of payback period are:

 Payback period is very simple to calculate.

 It can be a measure of risk inherent in a project. Since cash flows that occur later in
a project's life are considered more uncertain, payback period provides an indication
of how certain the project cash inflows are.

 For companies facing liquidity problems, it provides a good ranking of projects that
would return money early.
Disadvantages of payback period are:
 Payback period does not take into account the time value of money which is a
serious drawback since it can lead to wrong decisions. A variation of payback
method that attempts to remove this drawback is called discounted payback period
method.

 It does not take into account, the cash flows that occur after the payback period.

3. Return on investment
• It provides a way of comparing the net profitability to the investment required. Or
 • A performance measure used to evaluate the efficiency of an investment or to
compare the efficiency of a number of different investments
• Disadvantages
• It takes no account of the timing of the cash flows.
• Rate of returns bears no relationship to the interest rates offered or changed by bank.

• ROI = average annual profit * 100

total investment
average annual profit = net profit
total no. of years
• average annual profit
= 50,000/5
= 10,000
• ROI = 10,000/100,000 X 100 = 10%

4. Net present value

• A project evaluation technique that takes into account the profitability of a project and
the timing of the cash flows that are produced
• Sum of all incoming and outgoing payments, discounted using an interest rate, to a
fixed point in time (the present)
• It is a discounted cash flow technique
• Consider the timing and amount of cash flows. To use the net present value method,
you will need to know the cash inflows, the cash outflows, and the company's
required rate of return on its investments.
• The required rate of return becomes the discount rate used in the net present value
calculation.

Discount factor
• Discount factor = 1/(1+r)t
• r is the interest rate (e.g. 10% is 0.10)
• t is the number of years

• In the case of 10% rate and one year

• Discount factor = 1/(1+0.10) = 0.9091

• In the case of 10% rate and two years

• Discount factor = 1/(1.10 x 1.10) =0.8294

• In the case of 10% rate and three years

• Discount factor = 1/(1.10 x 1.10 x 1.10) =0.7513

• In the case of 10% rate and four years

• Discount factor = 1/(1.10 x 1.10 x 1.10 x 1.10) =0.6830

• In the case of 10% rate and five years

• Discount factor = 1/(1.10 x 1.10 x 1.10 x 1.10 x 1.10) =0.6209
Year Cash-flow Discount Discounted
factor cash flow
 0 -100,000 1.0000 -100,000

1 10,000 0.9091 9,091

2 10,000 0.8264 8,264

3 10,000 0.7513 7,513

4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

NPV 618

Advantages
• Takes into account profitability
• Considers timing of payments Considers economic situation through discount
rate Disadvantage Discount rate can be difficult choose

5. Internal rate of return (IRR)

• Internal rate of return (IRR) is the discount rate that would produce an NPV of 0 for
the project

• The internal rate of return (IRR) determines the interest yield of the proposed capital
project at which the net present value equals zero, which is where the present value of
the net cash inflows equals the investment.

• If the IRR is greater than the company's required rate of return, the project may be
accepted.

• To determine the internal rate of return requires two steps. First, the internal rate of
return factor is calculated by dividing the proposed capital investment amount by the
net annual cash inflow.

• Then, the factor is found in the Present Value of an Annuity of 1 table using the
service life of the project for the number of periods.

• The discount rate that the factor is the closest to is the internal rate of return.

• Can be used to compare different investment opportunities

IRR=(rate giving positive NPV)+(difference between rates*(positive NPV/difference

between NPV))

Calculate NPV with Discount Factor =10%

 Year Cash- Discount Discounted
flow factor cash flow
0 -9000 1.0000 -9000
1 2000 0.9091 1818.2
2 3000 0.8264 2479.2
3 3000 0.7513 2253.9
4 4000 0.6830 2732
NPV 283.3

Calculate NPV with discount factor 12%

Year Cash- Discount Discounted
flow factor cash flow
0 -9000 1.0000 -9000
1 2000 0.8928 1785.6
2 3000 0.7971 2391.6
3 3000 0.7117 2135.4
4 4000 0.6355 2542
NPV -145.4

IRR=10+(2*(283.3/(283.3-(-145.4))))
=10+(2*(283.3/428.7))
=11.8

• Advantage: Calculates figure which is easily to interest rates

• Disadvantage : Difficult to calculate (iterative)

RISK EVALUATION

Risk evaluation is meant to decide whether to proceed with the project or not, and whether
the project is meeting its objectives.
Risk Occurs:
• When the project exceed its original specification
• Deviations from achieving it objectives and so on.
Every project involves risk. The project risks which prevent the project being completed
successfully and the business risk that the delivered products are nor profitable. Risk
evaluation consists of
 Risk identification and ranking 
 Risk and NPV 
 Cost benefit analysis 
  Risk profile analysis 

Risk identification and ranking

• Identify the risk and give priority.
• Could draw up draw a project risk matrix for each project to assess risks
• Project risk matrix used to identify and rank the risk of the
project Example of a project risk matrix

Risk and net present value

 Where a project is relatively risky it is common practice to use a higher discount rate
to calculate the NPV. The risk premium be an additional 2 % for an safe project or 5 %
for a fairly risky project
 Projects may be categorized as high, medium or low risk using a scoring method and
risk premiums designated for each category.

Cost-benefit analysis
 A rather more sophisticated approach to the evaluation of risk is to consider each
possible outcome, probability of its occurring and the corresponding value of the
outcome.
 Rather than a single cash flow forecast for a project, we will then have a set of cash
flow forecasts, each with an associated probability of occurring.
 The value of the project is then obtained by summing of the cost or benefit for each
possible outcome weighted by its corresponding probability.
 Drawback: Does not take full account of worst-case scenarios.(averaging out the
negative and positive outcomes of the scenarios)
Sales Annual Sales income Probability Expected value

i P i*p

High 8,00,000 0.1 80,000

Medium 6,50,000 0.6 3,90,000

Low 1,00,000 0.3 30,000

Expected 5,00,000
Income

Risk profile analysis

• An approach which attempts to overcome some of the objections to cost benefit
averaging is the construction of risk profiles using sensitivity analysis.
• This makes use of ―risk profiles‖ using sensitivity analysis.
• It compares the sensitivity of each factor of project profiles by varying parameters
which affect the project cost benefits.
• Eg:
• Vary the original estimates of risk plus or minus 5% and re-calculate the expected
cost benefits.
• P1 depart far from p2,have large variation
• P3 have much profitable than expected
 • All three projects have the same expected profit
• Compare to p2, p1 is less risky.

Decision tree
Decision tree provide tools for evaluating expected outcomes and choosing between
alternate strategies. A decision tree is a decision support tool that uses a tree-like graph or
model of decisions and their possible consequences, including chance event outcomes,
resource costs, and utility. It is one way to display an algorithm.

Decision trees method for risk evaluation:-

1. An alternative would be to replace the whole of the system.

2. The decision is influenced by the likelihood of org expanding their market.
3. There is a strong rumour that they could benefit from their main competitor going out
of business: in this case they could pick up a huge amount of new business, but the
invoicing system could not cope.
4. However replacing the system immediately would mean other important projects
would have to be delayed.
5. The NPV of extending the invoicing system is assessed as £75,000 if there is no
sudden expansion.
6. If there were a sudden expansion then there would be a loss of £100,000.
7. If the whole system were replaced and there was a large expansion there would be a
NPV of £250,000 due to the benefits of being able to handle increased sales.
 8. If sales did not increase then the NPV would be -£50,000.
9. The decision tree shows these possible outcomes and also shows the estimated
probability of each outcome.
10. The value of each outcome is the NPV multiplied by the probability of its occurring.
11. The value of a path that springs from a particular decision is the sum of the values of
the possible outcomes from that decision. If it is decided to extend the system the sum
of the values of the outcomes is £40,000 (75,000 x 0.8 – 100,000 x 0.2) while for
replacement it would be £10,000 (250,000 x 0.2 – 50,000 x 0.80).
12. Extending the system therefore seems to be best option.

Benefit Management

• Providing an organization with a capability does not guarantee that this will provide
benefits envisaged – need for benefits management
• This has to be outside the project – project will have been completed
• Therefore done at programme level
“It encompasses the identification, optimization and tracking of the expected benefits from a
business change in order to ensure that they are actually achieved”
To carry out benefit Management,
• Define expected benefits
• Analyse balance between costs and benefits
• Plan how benefits will be achieved
• Allocate responsibilities for their achievement
• Monitor achievement of benefits
Three categories of Benefit
• Direct Benefit: Directly obtained benefit by making use of/ operating the system.
• Assessable indirect benefits: These benefits are obtained due to updation/upgrading
the performance of the current system.
• Intangiable benefits: These benefits are long term, difficult to quantify, It also referred
as indirect benefits
Benefits can be of many different types,
• Mandatory requirement: Governmental or European legislation might make certain
changes mandatory.
• Improved quality of service: An insurance company for example, might want to settle
claims by customer more quickly
• Increased productivity: The same, or even more, work can be done at less cost in staff
time.
• More motivated workforce: This might be because of an improved rewards system, or
through job enlargement or job enrichment.
 • Internal management benefits: (Better decision making) To take an insurance
example, better analyusis of insurance claims could pinpoint those categories of
business which are most risky and alow an insurance company to adjust premiums to
cover this.
• Risk reduction: The insurance for example might also be applicable here, but
measures to protect an organisation‟s networks and databases from intrusion and
external malicious attack would be even more pertinent.
• Economies: The reduction of cost, other than those related to staff – procurement
policies might be put in place which encourage the consolidation of purchasing in
order to take advantage of bulk buying at discount
• Revenue enhancement/acceleration: The sooner the bill reaches the customer, the
sooner they can pay them.
• Strategic fit: A change might not directly benefit a particular group within the
organisation but has to be made inorder to obtain some strategic advantage for the
organization as the whole.
Quantifying benefits
Benefits can be:
• Quantified and valued – that is, a direct financial benefit is experienced
• Quantified but not valued e.g. a decrease in customer complaints by x%
• Identified but not easily quantified – e.g. public approval for a organization in the
locality where it is based
Disbenefit: Increased sales might mean that more money has to be spent on expensive
overtime working.

Powered by TCPDF (www.tcpdf.org)