Sri Vidya College of Engineering & Technology Lecturer Notes

UNIT IV

Creating Framework

Exercising control over a project and ensuring that targets are met is a matter of
regular monitoring - Finding out what is happening and comparing it with targets.
There may be a mismatch between the planned outcomes and the actual ones.
Replanning may then be needed to bring the project back on target. Alternatively, the
target could have to be revised.

Responsbility
The overall responsibility for ensuring satisfactory progress on a project is often
the role of project steering committee, project management board and Project Board.
Day to day responsibility is on project manager and team leaders.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

The concept of a reporting hierarchy is illustrated in the above Figure.

The main lesson here is that the details relating to project progress have to originate
with the people actually doing the work and have then to be fed up through the
management structure. At each management level there is going to be some
summarising and commentary before information is passed up to the next level. This
means that there is always a danger of ‘information overload’ as information passes
from the many to the few.

Assessing progress
 Some information used to assess project progress will be collectively routinely,
while other information will be triggered by specific events.
 Assessment is based on information collected at regular intervals
 Example whether particular report has been delivered or not

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Setting checkpoints
 Set a series of checkpoints in the activity plan
 Check points may be:-
 Monthly
 Specific events (production of a report)
Checkpoints – predetermined times when progress is checked
– Event driven: check takes place when a particular event has been
achieved
– Time driven: date of the check is pre-determined
Frequency of reporting
– The higher the management level, generally, the longer the gaps between
checkpoints

Taking snapshots
The frequency of progress reports will depend upon the size and degree of risk of the
project. Team leaders may want to assess progress daily whereas project manager may
find weekly or monthly reporting appropriate. In general, the higher level, the less
frequent and less detailed the reporting needs to be.
At the level of individual developers, however, strong arguments exist for the
formal weekly collection of information. If reporting is to be weekly then it makes
sense to have basic units of work that last about a week.
Major, or project level, progress reviews will generally take place at particular points
during the life of a project- commonly known as review points or control points.

A review is any activity in which a work product is distributed to reviewers who

examine it and give feedback.
 Reviews are useful not only for finding and eliminating defects, but also
for gaining consensus among the project team, securing approval from
stakeholders, and aiding in professional development for team members.
 Reviews help teams find defects soon after they are injected making them
cost less to fix than they would cost if they were found in test.
 All work products in a software project should be either reviewed or
tested.
• Software requirements specifications, schedules, design
documents, code, test plans, test cases, and defect reports should
all be reviewed.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.2 Collecting The Data

 Manager breaks long activities into more controllable activities of one or two
weeks’ duration.
 It is necessary to Gather information about partially completed activities and
forecasts of how much work is left to be completed. It can be difficult to make
such forecasts accurately.
 Example:-counting the number of records specifications or screen layouts
produced.
 In some cases, intermediate products can be used as in-activity milestones.
 How to deal with partial completions?
99% completion syndrome
Possible solutions:
 Control of products, not activities
 Subdivide into lots of sub-activities

Partial completion reporting

Projects have to be delivered on time and within budget, hence the concern with
monitoring achievements and costs.
Partial completion is where, for example, data is being collected at the end of
Week 2 of an activity that should take four weeks. We want to know if it is about
50% completed.
An example of the ’99% completion syndrome’ would be in the above case if the
developer reported at the end of weeks 1,2 and 3 that the task was respectively
25%, 50% and 75% complete. However at the end of week 4 it is reported that the
task is 99% complete. The same thing is reported at the end of week 5 and so on
until the task is actually completed.
Control on products implies that actual examination of intermediate allows us to
verify independently and objectively that sub-tasks have been completed.

 The employee fill the time sheet

 Many organizations use standard accounting systems with weekly
timesheets to charge staff time to individual jobs. The staff time booked
to a project indicates the work carried out and the charges to the project.
 Weekly timesheets are a valuable source of information about resources
used. They are often used to provide information about what has been
achieved.


MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
TIME SHEET

Staff : John smith week ending : 30/3/07

Rechargeable hours

Hours Scheduled Estimated

Activity %
project description this completion completion
code complete
week date date

P21 A243 Code mod A3 12 30 24/4/07 24/4/07

A234 Document take-on 20 90 6/4/07 4/4/07

P34

Total recharged hours 32

Non- Rechargeable hours

Hours
code description this Comment and authorization
week

Z99 Day in lieu 8 Authorized by RB

Total non-recharged hours 8

Red/amber/green (RAG) reporting

One popular way of overcoming the objections to partial completion reporting

is to avoid for estimated completion dates, but to ask instead for the team members’
estimates of the likelihood of meeting the planned target date. One way of doing this
is the traffic-light method. This consists of the following steps:

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
• Identify key tasks (first level)
• Break down into sub-tasks (second level)
• Assess each subtasks(second level) as:
Green – ‘on target’
Amber – ‘not on target but recoverable’
Red – ‘not on target and recoverable only with difficulty’
 Review all the second- level assessments to arrive at first- level assessments;
 Review first and second - level assessments to produce an overall assessment.

RAG reporting highlights those activities which need particular attention. The status
of a troubled activity might typically move from green to amber; if corrective action is
possible it might go back to green, otherwise it could switch to red. If there are lots of
instances where activities switch directly from green to red, this could indicate more
management control.
‘Critical tasks’ would be those on the critical path and/or reliant on critical resources.

Activity assessment sheet

Staff: Justin
Ref: IoE/P/13 Activity: code and test module C

Week number 13 14 15 16 17 18
Activity summary G A A R

components comments
Screen handling
G A A G
procedures
File update procedures G G R A

compilation G G G A

Test data runs G G G A

Program documentation G G A R

A traffic-light assessment of IoE/P/13

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.3 Visualizing Progress

Economic Assessment:
 After collecting data the project manager will represent the collected data
using static picture. We look at some methods of presenting a picture of
the project and its future.
 Some of these methods are:
1. Gantt charts
2. Slip charts
3. Ball charts
4. timeline

Gantt charts:
 Simplest ,oldest techniques for tracking the project progress
 Indicates scheduled activity dates and durations
 Reported progress is recorded on the chart (by shading activity bars)
 Note that the Gantt chart is named after Henry Gantt (1861-1919) and so should
not be written in capitals! You could ask students what they think GANTT
stands for before you tell them this to impress this on them. I really find Gantt
written as GANTT very, very annoying and threaten students with instant
failure of the module if they do this!

 The format of the Gantt chart here differs from the format used in Microsoft
project as the activities for each team member are grouped together. You could

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
input the details so that they came out in this format, but it would not occur
automatically.

Slip charts:

 Provide more striking visual indication of those activities that are not
progressing to schedule
 The more the slip line bends ,greater variation from the plan.
 A slip chart is a version of the Gantt chart where a line is drawn from top to
bottom. To the left of the line are all the completed activities and to the right
those activities ( or parts of activities) that have not been completed.
 The more jagged the line, the more it means that that there are some activities
that are lagging to various degrees and some that are ahead of themselves. A
very jagged line means that there is scope for re-planning to move resources
from those activities that are ahead to those that are behind.

Ball charts:

 To show whether targets have been met or not

 Circles indicate start date & competition date
 Whenever revisions are made the revised date is put in to the circle

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
 Circles, which represent the start or finish of activities, start with the initial
target dates. If these are modified then the second dates are changed. When the
event actually takes place, the colour of the circle is changed to green if it is on
target and to red if it has missed the target.
 The idea is that this chart is put on a wall in a prominent position as a constant
reminder to the project team of the current situation – hence it is often referred
to as ‘balls on the wall’.

Ball charts
Code and test module A
10/10/05 21/10/05
10/10/05 23/10/05

Code and test module B

14/10/05 27/10/05
17/10/05 31/10/05

Code and test module C

17/10/05
17/10/05 27/10/05
27/10/05

Green: On time
Red: Missed the target

The timeline:

 This records the way that targets have changed throughout the project.
 Planned time is plotted on the horizontal axis, and actual time on the vertical
axis. The bendy lines going from top to bottom represent the scheduled
completion date for each activity e.g.
 ‘analyse existing system’ – at start this was due finish on the Monday of week 3
and it did finish then
 ‘obtain user requirements’ was originally planned to finish on the Thursday of
week 5, but at the end of the first week it was rescheduled to finish on the
Tuesday of week 6.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.4 Cost Monitoring

• A project could be late because the staff originally committed, have not been
deployed
• In this case the project will be behind time but under budget
• A project could be on time but only because additional resources have been
added and so by over budget
• Need to monitor both achievements and costs

Cost Management

• Cost Management includes:

– Cost Estimation
– Cost Budgeting
– Cost Control
• Estimation & Budgeting – Main Tools & Techniques
– Estimation Techniques
– Reserve Analysis ( Risk, Unknown, Cost of Quality)
– Cost Baseline
– Funding Requirements & Cash Flow
• Cost Control.
– Performance Measurement Analysis: Planned value, Actual Cost, Cost
Variance, Cost Performance Index, Estimate to Complete
– Approved Change Requests

Estimating Schedule Activity

• Estimation Cost of the Resources Needed to complete the activity

• Includes variations to the cost estimate (Risk, Etc)
• Take into consideration Alternative Costing for the overall project time
period
– Cost of extended design effort VS. additional maintenance costs
• Cost estimates include ALL resources that will be charged to the project
including Inflation Forecast, Salary Increase, Contingency cost.
ROM (Rough Order of Magnitude, E.G: –50/+100%) is allowed in the first
stages. Refinement is required at later stages ( E.G: -10/+15%).

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Activity Estimating – Inputs & Tools

• Inputs
– External Factors: Marketplace Condition, External Cost Information
Databases
– Organization Assets: Historical Information, Estimating Policies and
Templates, Team Knowledge
– Project Factors: Scope, WBS, Management Plan, Schedule Plan,
Staffing Plan, Risk

• Tools
– Analogous Estimates
– Resource Cost Rates
– Parametric Estimates ( Function Points Etc)
– Vendor Bid Analysis
– Project Management Software

• Reserve Analysis (Contingency Allowance)

– Will Be Used at the Discretion of the Project Manager
– Budgeting Project Unknowns
• Risks
– Will Be budgeted according to their severity level and probabilities
– The budget will cover mitigation activities and workarounds and will
be implemented upon the project manager decision.
• Cost of Quality (COQ)
– Costs added to the project in order to ensure conformance with quality
standards
– Cost of Non Quality – Failure Cost/Rework. Costs that will added as a
result of bugs and non-quality project activities

Activity Estimating - Output

• Activity Cost Estimating – Most likely estimates of all the activity resources
• Estimate Details
– Basis for the estimate (how it was developed)
– Assumptions made
– Constraints
– Possible range of the estimate ( 100000$ -10%/+15%)
• Requested Changes ( If the estimate analysis recommends a change)

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
• CA – Control Account (the corporate accounting number that will incur the
cost of the activity)
• Cost Management Plan (Update)

Cost Baseline
• Aggregating the estimated costs of the individual scheduled activities to
establish a total COST BASELINE for measuring and budgeting the project
• Inputs: WBS, Activity Cost Estimate, Project Schedule, Resource Calendar,
Contracts, Cost Management Plan
• Tools & Techniques: Cost Aggregation, Reserve Analysis, Parametric
Estimating ( adjustment to the aggregate cost), Funding Limit Reconciliation
(can impact the schedule and overall cost)
• Output: Cost Baseline, Expected Cash Flow, Funding Requirements (including
Management Reserve), Requested Changes, Updated Cost Management Plan

Cost control
• Assuring the Potential Cost Overrun do not exceed the authorized funding
PERIODICALLY and in TOTAL
• Monitoring cost PERFORMANCE to detect and understand Variances from the
Baseline
• Detect Changes as they occur
• Prevent unapproved changes
• Ensuring Requested Changes are Agreed Upon
• Report Changes to Stakeholders
• Acting to bring expected overruns within acceptable limits
• Influencing factors that creates changes to the cost baseline

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.5 Earned Value analysis

Definition:
Earned value analysis is a method of performance measurement. Earned value
integrates cost, schedule and scope and can be used to forecast future performance and
project completion dates. It allows projects to be managed better – on time, on budget.

Three quantities form the basis for cost performance measurement using
Earned Value Management. They are
1. Budgeted Cost of Work Scheduled (BCWS) or Planned Value (PV)
2. Budgeted Cost of Work Performed (BCWP) or Earned Value (EV) and
3. Actual Cost of Work Performed (ACWP) or Actual Cost (AC).

The above quantities are defined below.

• Budgeted Cost of Work Scheduled (BCWS) or Planned Value (PV) – The sum of
budgets for all work packages scheduled to be accomplished within a given time
period.
• Budgeted Cost of Work Performed (BCWP) or Earned Value (EV) – The sum of
budgets for completed work packages and completed portions of open work
packages.
• Actual Cost of Work Performed (ACWP) or Actual Cost (AC) – The actual cost
incurred in accomplishing the work performed within a given time period. For
equitable comparison, ACWP is only recorded for the work performed to date
against tasks for which a BCWP is also reported.
From these three quantities we can determine our total program budget as well as
make a determination of schedule and cost performance and provide an estimated cost
of the project at its completion.

Baseline budget:
• Aggregating the estimated costs of the individual scheduled activities to
establish a total COST BASELINE for measuring and budgeting the project
• Inputs: WBS, Activity Cost Estimate, Project Schedule, Resource Calendar,
Contracts, Cost Management Plan
• Tools & Techniques: Cost Aggregation, Reserve Analysis, Parametric
Estimating ( adjustment to the aggregate cost), Funding Limit Reconciliation
(can impact the schedule and overall cost)
• Output: Cost Baseline, Expected Cash Flow, Funding Requirements (including
Management Reserve), Requested Changes, Updated Cost Management Plan

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Additional terms are defined to record cost and schedule performance and program
budget:

• Schedule Variance (SV) – The difference between the work actually performed
(BCWP) and the work scheduled (BCWS). The schedule variance is calculated in
terms of the difference in dollar value between the amount of work that should
have been completed in a given time period and the work actually completed.

• Cost Variance (CV) – The difference between the planned cost of work performed
(BCWP) and actual cost incurred for the work (ACWP). This is the actual dollar
value by which a project is either overrunning or under running its estimated cost.

Two Performance Ratios:

• Cost Performance Index (CPI) – The ratio of cost of work performed (BCWP) to
actual cost (ACWP). CPI of 1.0 implies that the actual cost matches to the
estimated cost. CPI greater than 1.0 indicates work is accomplished for less cost
than what was planned or budgeted. CPI less than 1.0 indicates the project is facing
cost overrun.
• Schedule Performance Index (SPI) – The ratio of work accomplished (BCWP)
versus work planned (BCWS), for a specific time period. SPI indicates the rate at
which the project is progressing.
• Estimate At Completion (EAC) – It is a forecast of most likely total project costs
based on project performance and risk quantification. At the start of the project
BAC and EAC will be equal. EAC will vary from BAC only when actual costs
(ACWP) vary from the planned costs (BCWP).

Earned Value Management Formula:

Name Formula
Cost Variance (CV) EV – AC
Schedule Variance (SV) EV – PV
Time Variance (TV) Difference between the time when the
achievement of the current earned value
was planned to occur and the time now
Cost Performance Index (CPI) EV / AC
Schedule Performance Index (SPI) EV / PV

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Earned value – an example

• Tasks
– Specify module 5 days
– Code module 8 days
– Test module 6 days
• At the beginning of day 20, PV = 19 days
• If everything but testing completed, EV = 13 days
• Schedule variance = EV-PV i.e. 13-19 = -6
• Schedule performance indicator (SPI) = EV/PV
i.e 13/19 = 0.68
• A negative schedule variance (SV) means that the project is behind schedule as does a SPI
that is less than 1.0.
• Actual cost (AC) is also known as Actual cost of work performed (ACWP)
• In previous example, if
• ‘Specify module’ actually took 3 days (planned 5 days)
• ‘Code module’ actually took 4 days (planned 8 days)
• Actual cost = 7 days
• Cost variance (CV) = EV-AC
i.e. 13-7 = 6 days
• Cost performance indicator (CPI) = EV/AC
i.e = 13/7 = 1.86
• Positive CV or CPI > 1.00 means project under budget or the work is completed better than
planned
•
An Earned value tracking chart

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Earned value chart with revised forecasts

This shows how the planned value (PV), earned value (EV) and actual cost (AC) can
be tracked over the lifetime of a project.
It also shows how the graph can be used to show adjustments to the final estimated
cost and duration. A revised assessment of the budget at completion (EAC estimate at
completion) can be produced by dividing the original estimated budget at completion
(BAC) by the current CPI.
Similarly a forecast of the actual duration of the project can be derived by dividing the
original estimated duration by the SPI.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.6 Prioritizing Monitoring - Getting Project Back To Target

After completion of earned value analysis, the progress report has to be sent to
the following members.

1. Project team
2. Quality assurance
3. IT management
4. Customer management
5. Users

IT Customer
management management

Progress
report

Quality
Users
assurance

Project team

Progress report should contain the following contents (typical)

 Period covered
 Narrative summary of progress
 Milestones achieved/deliverables completed
 Problems encountered (and solutions)
 Projected completion date
 Costs to date and predicted
 Changes identified and implemented

Prioritizing Monitoring:
We assumed that all aspects of a project will receive equal treatment in terms of
the degree of monitoring applied. The monitoring takes time and uses resources that
might sometimes be put to better use.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
In this section we list the priorities we might apply in deciding levels of
monitoring.
• Critical path activities
• Activities with no free float – if delayed later dependent activities are delayed
• Activities with less than a specified float
• High risk activities
• Activities using critical resource

Critical path activities – Any delay in an activity on the critical path will cause a
delay in the completion date for the project. By definition, if these are late then the
project as a whole will be delayed. Critical path activities are likely to have a very
high priority for close monitoring.

Activities with no free float – free float was defined in Lecture/Chapter 6. A project
with no free float will delay following dependent activities, although the project end
date may not be directly threatened.

Activities with less than a specified float – projects when being executed can be very
dynamic: some activities will take longer than estimated others less; this could lead to
the critical shifting. Activities with small floats are the most likely to find themselves
turned into activities on the critical path if their floats get eroded.

High risk activities – recall the calculation of activity standard deviations in Chapter
7. If the standard deviation for an activity is large, this indicates that there is a lot of
uncertainty about how long it will actually take.

Activities using critical resources – some resources may only be available for a
limited period and if the activities that need the resource are delayed the resource
could become unavailable.

Getting back on track

There are two main strategies to consider when drawing up plans to bring a project
back on target.
1. Try to shorten activities on critical path e.g.
– Work overtime
– Re-allocate staff from less pressing work
– Buy in more staff

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
2. Reconsider activity dependencies
– Over-lap the activities so that the start of one activity does not have to
wait for completion of another
– Split activities
Renegotiate the deadline (optional) – if not possible then

Shortening the critical path

The overall duration of a project is determined by the current critical peth, so
speeding up non-critical path activities will not bring forward a project completion
date. The idea is to try to get things done more quickly by adding more staff. Some
activities lend themselves to this more readily than others – it is often quite difficult to
do this with software development. It also increases costs.
There are several ways in which this might be done.
1. Adding resources;
2. Increase use of current resources;
3. Reallocate staff to critical activities;
4. Reduce scope;
5. Reduce quality.

Reconsidering activity dependencies – allowing activities to overlap often increases

the risk of quality shortfalls

Renegotiating the deadline – one way of doing this is to divide the deliverables into
‘tranches’ delivering the ones most valuable to the client on or before the deadline,
but delaying less valuable ones.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.7 Change Control

So far, we have assumed that the nature of the deliverables has not
changed. When a document such as the user requirements is being developed there
may be many different versions of the document as it undergoes cycles of
development and review. Any change control process at this point would be informal
and flexible. At some point what is assumed to be the final version will be created.
This is baselined, effectively frozen. Baselined products are the foundation for the
development of further products - for instance interface design documents may be
developed from baselined user requirements.

Changes in scope of a system

A common occurrence with IS development projects is for the size of the

system gradually to increase. One cause of this is changes to requirements that are
requested by users. The scope of a project needs to be carefully monitored and
controlled. One way is to re-estimate the system size in terms of SLOC or function
points at key milestones.

Configuration librarian’s role

Control of changes and documentation ought to be the responsibility of
someone who may variously be named the configuration librarian, the configuration
manager or the project librarian.

The role of configuration librarian:

• Identifying items that need to be subject to change control - it is unlikely,

for example, that a feasibility report would be subject to change control once
agreement has been obtained to start the project

• Management of a central repository of the master copies of software and

documentation

• Administering change procedures - It is important that someone ensures that

there is adherence to change control procedures.

• Maintenance of access records- A situation to be avoided is where two different

developers are making changes to the same software component.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Typical change control process

1. One or more users might perceive the need for a change - The user
community itself must come to a consensus about whether a proposal for a
change should go forward. A change deemed desirable by one part of the user
community could cause opposition with other users.

2. User management decide that the change is valid and worthwhile and pass
it to development management

3. A developer is assigned to assess the practicality and cost of making the

change
 2 and 3. This part of the process often involves a multipart form, initially
raised by a user representative and then completed with a response by the
developers.

4. Development management report back to user management on the cost of

the change; user management decide whether to go ahead - There could be a
change control board with user and developer representatives that oversees this
decision-making process
5. One or more developers are authorized to make copies of components to be
modified - The configuration librarian would control this release

6. Copies modified. After initial testing, a test version might be released to

users for acceptance testing - Note that it is a copy that is modified; the
original would still exist as the current operational version

7. When the development of new versions of the product has been completed
the user management will be notified and copies of the software will be
released for user acceptance testing.

8. When users are satisfied then operational release authorized – master

configuration items updated - The previous version of the configuration items
would be archived but preserved. If there are unforeseen problems with the new
version when it is made operational then a fall-back to the previous version
could be considered

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Change control and configuration management

Devise change
control
procedure

Identify change

Assess impact
of change

Decide what to
do

• Change control

– Set of procedures to ensure that changes made only after a consideration

of the full impacts.
• Configuration management

- Version control to ensure that all changes are properly recorded and
managed – and so that knock-on effects on other projects can be identified.

A definition of software Configuration Management

 “The process of identifying and defining the configuration
items in a system,
 controlling the release and change of these items throughout the
system life cycle,
 recording and reporting the status of configuration items and
change requests,
 verifying the completeness and correctness of configuration
items.”

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
 An engineering management procedure that includes
 configuration identification
 configuration control
 configuration status accounting
 configuration audit

Difference between version control and change control is

Version control is the management of changes to documents, computer
programs, large web sites, and other collections of information.
Change control is a formal process used to ensure that changes to a
product or system are introduced in a controlled and coordinated manner.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.8 Managing Contracts - Types of contract

Acquiring software from external supplier

This could be done via:

• a bespoke system - created specifically for the customer;
• off-the-shelf - bought ‘as is’ – this is sometimes referred to as shrink-wrapped
software;
• customized off-the-shelf (COTS) - a core system is customized to meet needs of
a particular customer.

ISO 12207 acquisition and supply process

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Part of the ISO 12207 standard relates to the process by which software can be
acquired from an external supplier. As can be seen from the diagram, there are two
parallel and complementary processes. The acquirer (who wants the software) has a
set of processes to carry out which interact with the processes for which the supplier
would be responsible.

Types of contract

1. Fixed price contracts

2. Time and materials contracts
3. Fixed price per delivered unit contracts

Note the difference between goods and services.

Often license to use software is bought rather than the software itself

Fixed price contracts

In this situation a price is fixed when the contract is signed. The customer knows that,
if there are no changes in the contract terms, this is the price they pay on completion.
Even though the supplier will have to add a margin to the price to deal with
contingencies, the cost could still be less than doing the work in-house as the supplier
may be able to exploit economies of scale and the expertise that the have from having
done similar projects in the past.
Advantages to customer:
• known expenditure
• supplier motivated to be cost-effective
Disadvantages:
• supplier will increase price to meet contingencies
• difficult to modify requirements
• upward pressure on the cost of changes
• threat to system quality

Time and materials contracts

The customer is charged at a fixed rate per unit of effort, for example per staff-
hour. Because suppliers appear to be given a blank cheque, this approach does not
normally find favour with customers. However, the employment of contract
developers may involve this type of contract.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Advantages to customer:
• easy to change requirements
• lack of price pressure can assist product quality
Disadvantages:
• Customer liability - the customer absorbs all the risk associated with
poorly defined or changing requirements
• Lack of incentive for supplier to be cost-effective

Fixed price per delivered unit contracts

Fixed price per delivered unit contract is often associates with function
point (FP) counting. The size of the system to be delivered is calculated or estimated
at the outset of the project. The size could be estimated in lines of cod, but FPs can be
more easily derived from requirements documents. A price per unit is also quoted.
The final price is the unit price multiplied by the number of units.

implementation
FP count Design cost/FP total cost/FP
cost/FP

Up to 2,000 $242 $725 $967

2,001- 2,500 $255 $764 $1,019

2,501-3,000 $265 $793 $1,058

3,001-3,500 $274 $820 $1,094

3,501-4,000 $284 $850 $1,134

These figures do come from a real source (RDI Technologies in the USA).
These are now several year old. The bigger the project, the higher the cost per
function point. Recall that function points were covered in Lecture/Chapter 5 on
software effort estimation.

Example
• Estimated system size 2,600 FPs
• Price
– 2000 FPs x $967 plus
– 500 FPs x $1,019 plus
MG6088/Software Project Management
Sri Vidya College of Engineering & Technology Lecturer Notes
– 100 FPs x $1,058
– i.e. $2,549,300
• What would be charge for 3,200 FPs?
2000 FPs at $967 = $1,934,000
500 FPs at $1019 = $509,500
500 FPs at $1058 = $529,000
200 FPs at $1094 = $218,800

total $3,191,300
Advantages for customer
• customer understanding of how price is calculated
• comparability between different pricing schedules
• emerging functionality can be accounted for
• supplier incentive to be cost-effective
Disadvantages
• difficulties with software size measurement - may need independent
FP counter
• Changing (as opposed to new) requirements: how do you charge?

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.9 Stages in Contract Placement

The tendering process

• Open tendering
– any supplier can bid in response to the invitation to tender
– all tenders must be evaluated in the same way
– government bodies may have to do this by local/international law
• Restricted tendering process
– bids only from those specifically invited
– can reduce suppliers being considered at any stage
• Negotiated procedure
– negotiate with one supplier e.g. for extensions to software already
supplied

Stages in contract placement

Requirements Analysis
The very first step in software development process is requirement analysis.
The requirements are gathered from user/customers by user management team and
managers and specified in requirement document.
MG6088/Software Project Management
Sri Vidya College of Engineering & Technology Lecturer Notes

Main sections in a requirement document

1. introduction
2. description of existing system and current environment
3. future strategy or plans
4. system requirements
– mandatory
– desirable features
5. Deadlines
– functions in software, with necessary inputs and outputs
– standards to be adhered to
– other applications with which software is to be compatible
– quality requirements e.g. response times
6. additional information required from bidders

The requirements document is sometimes referred to as the operational

requirement or OR. If a mandatory requirement cannot be met the proposed
application would have to be rejected regardless of how good it might be in other
ways. A shortfall in one desirable requirement might be compensated for by other
qualities or features.

Evaluation plan

• How are proposals to be evaluated?

• Methods could include:
– reading proposals
– interviews
– demonstrations
– site visits
– practical tests
 Off the shelf software clearly has an advantage here as there is actually product
that can be evaluated in existence.
 Need to assess value for money for each desirable feature
 Example:
 feeder file saves data input
 4 hours a month saved
 cost of data entry at RM20 an hour
 system to be used for 4 years
 if cost of feature RM1000, would it be worth it?

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
RM(4 x 20 x 12 x 4) would be saved i.e. RM3,840. The payback
period would be just over a year and so this feature would be
worth the additional cost.
Invitation to tender (ITT)

• Note that bidder is making an offer in response to ITT

• acceptance of offer creates a contract
• Customer may need further information
• Problem of different technical solutions to the same problem
• ISO 12207 refers to an ITT as a Request for Proposal or RFP.

Memoranda of agreement (MoA)

 Customer asks for technical proposals

 Technical proposals are examined and discussed
 Agreed technical solution in MoA
 Tenders are then requested from suppliers based in MoA
 Tenders judged on price
 Fee could be paid for technical proposals by customer

Evaluation of proposals

• Usability of existing package

Could try out a demo or ask existing users
• Usability of application to be built
You would have to make stipulation about the process e.g. on the development
of interface prototypes; you could also specify performance requirements
 Maintenance costs of hardware
this could be incorporated in a maintenance agreement and you could compare
the terms offered by different potential suppliers; another approach is ask to
current users of the hardware about their experience of it.
 Time taken to respond to support requests
this could once again be made a contractual matter and the terms offered by
different suppliers could be compared; suppliers could be asked to supply
evidence of their past performance (but they might refuse, or not tell the truth);
you could ask for references from current customers of the supplier;
 Training
once again references could be taken up; you could ask for the CV of the
trainer; you could even get them to give a short presentation

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

4.10 Typical Terms Of A Contract

Some of the major areas of contract document are as follows:

 Definitions
 Form of agreement
 Goods and services to be supplied
 Ownership of the software
 Environment
 Customer commitment
 Acceptance procedures
 Standards
 Project and quality management
 Timetable
 Price and payment method
 Miscellaneous legal requirements
Definitions
The terminology use in the contract document may need to be defined, e.g. who
is meant by the words ‘client’ and ‘supplier’.

Form of agreement
For example, is it a contract of sale, a lease, or a licence?

Goods and services to be supplied

Equipment and software to be supplied – this should include an actual list of the
individual pieces of equipment to be delivered, complete with specific model
numbers.
Services to be provided
 Training;
 Documentation;
 Installation;
 Conversion of existing files;
 Maintenance agreements;
 Transitional insurance arrangements.

Ownership of the software

Who has Ownership of the software? There may be two key issues here.
1. Whether the customer can sell the software to others
2. Whether the supplier can sell the software to others.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes
Where an off-the-shelf package is concerned, the supplier often simply grants a
licence for the customer to use the software. An escrow agreement can be included
in the contract so the up-to-date copies of the source code are deposited with a
third party. In the UK, the NCC Group provides an escrow service.

Environment
 Where physical equipment is to be installed, the demarcation line between the
supplier’s and customer’s responsibilities with regard to such matters as
accommodation and electrical supply needs to be specified.
 Where software is being supplied, the compatibility of the software with
existing hardware and operating system platforms would need to be confirmed.

Customer commitment
Even when work is carried out by external contracts, a development project still needs
the participation of the customer. The customer may have to provide accommodation
for the suppliers and perhaps other facilities such as telephone lines.

Acceptance procedures
Good practice is to accept a delivered system only after user acceptance tests.
Part of the contract would specify such details as the time that the customer will have
to conduct the tests, deliverables upon which the acceptance tests depend and the
procedure for signing off the testing as completed.

Standards
It covers the standard with which the goods and services should comply. For
example, a customer could require the supplier to conform to the ISO 12207 standard
relating to the software life cycle and its documentation.

Project and quality management

The arrangements for the management of the project must be agreed. These
include the frequency and nature of progress meetings and the progress information to
be supplied to the customer. The contract could require that appropriate ISO 9001
standards are followed.

Timetable
This provides a schedule of when the key parts of the project should be
completed. The timetable will commit both the supplier and the customer.

MG6088/Software Project Management

Sri Vidya College of Engineering & Technology Lecturer Notes

Price and payment method

Obviously the price is very important. What also needs to be agreed is when the
payments are to be made. The supplier’s desire to be able to meet costs as they are
incurred needs to be balanced by the customer’s requirement to ensure that goods and
services are satisfactory before parting with their money.

Miscellaneous legal requirements

This is legal small print. A contract may require clauses which deals with such
matters as the definition of terms used in the contract, the legal jurisdiction that will
apply to the contract, what conditions would apply to the subcontracting of the work,
liability for damage to third parties, and liquidated damages.

Contract management

Contracts should include agreement about how customer/supplier relationship is

to be managed e.g.
– decision points - could be linked to payment
– quality reviews
– changes to requirements

Acceptance

• When work is completed, customer needs to carry out acceptance testing.

• Contract may put a time limit to acceptance testing – customer must perform
testing bf time expired.
• Part or all payment to the supplier should depend on acceptance testing

MG6088/Software Project Management