lOMoARcPSD|40184581

SPM Unit 4 - AKTU NOTES

Software Project Management (Dr. A.P.J. Abdul Kalam Technical University)

 lOMoARcPSD|40184581

UNIT-IV
Software Project Management (KOE-068)
PROJECT MANAGEMENT AND CONTROL

4.1 Framework of Management and Control

4.1.1 Creating Framework

 After the project starts its execution, the project must be carefully monitored to ensure the
project’s progress.
 Monitoring process focuses on comparing the actual output with the expected one and
reviews the schedule to fit on target.
 Regular monitoring of the project is needed to have more control over the project.
Always the expected outcomes are compared with the actual ones and analyzed whether
there is any slack in the planned process.
 Project control is a continuous process of monitoring the progress of the project plan and
it also includes re-planning of activities if necessary.
 The experience gained from the current project can be taken as an input over future project
establishment of activities.
 Generally, revising the planning strategy is due to:
 Delay in completion of the project within the target time
 Quality factors
 Inadequate functionality in adopting newer techniques
 Actual estimation is above the estimated one.
 A typical project control cycle is depicted below:

Start
 lOMoARcPSD|40184581

Publish
Initial Plan

Gather
project
Information

Compare Publish
progress vs revised Plan
targets

Satisfactory Take
? NO remedial
action

YES
Project Completed ?
NO

YES
End Project

Review
project

Document
conclusions

End

Project Control Cycle

4.1.2 Project Reporting Structures
 lOMoARcPSD|40184581

 Project steering committee or the Project Board has the overall responsibility of the
project’s progress in achieving the target.
 Project manager has the day-to-day responsibility of governing the development of the
project. These managers assign individual responsibilities to different teams under a team
leader.

PROJECT BOARD

PROJECT MANAGER

TEAM LEADER TEAM LEADER TEAM LEADER

Team members Team members Team members

Project Reporting Structures

 The diagram represents a structure for a medium-sized project where team leaders can
directly report to the project managers.
 Every team consists of a group of team members assigned with specific tasks. These
members represent the respective team according to the work allocated.
 Team leaders organize and collect team related information and report to the project
manager.
 The project manager in-turn generates a project-level report of the progress of the project
and report to the steering committee.

4.1.3 Categories of Reporting

 lOMoARcPSD|40184581

 Reporting is broadly classified as formal and informal reporting. The basic types of reports
associated with formal and informal reporting includes regular and ad hoc types.
 Formal regular types can be oral or written. The standard oral communication of minutes
are kept whereas written type gets the reporting issues in a separate written format.
 Formal ad hoc are mostly received information of different levels towards the end of the
project and generate written reports.
 Informal, oral and ad hoc provides early warning to the system and must be backed up
by formal reporting procedures.

4.1.4 Progress Assessment

 Based on the information collected from various levels at regular intervals during the
development of the project measures the progress assessment.
 The information can however, measure the project’s objectives in determining whether
the project can produce deliverables or not.
 Every single activity will not yield a deliverable work product but a group of activities
can achieve the specified tangible product.
 Usually, the assessment process is carried out by the team members who are associated
with the project activities.
 Checkpoints can be used to check the initial activity plan which may govern specific
events in generating report or a deliverable.
 Team leaders will have to assess the project daily while the project leaders can do it on a
weekly basis. Higher level members generate less reporting than their subordinates.
 Review points or control points can be set at different points in the project life cycle to
review the progress of the project.

4.2 Collection of data project termination

 Collecting information of the project progress at regular instances provides much control
over the project.
 However, gathering of partial completion of activities can be used to calculate the
remaining work needed to complete.
 lOMoARcPSD|40184581

 Intermediate products that are achieved can specify a milestone in the development of the
project.

4.2.1 Partial Completion Reporting

 The staff time related to a specific project indicates the work that has to be carried out by
the particular staff.
 Every organization uses an accounting method to calculate the charges of their employees.
However, the information related to project schedule is not shown in this report.
 Timesheets can be maintained on a weekly basis to measure the staff involvement in the
development process.

WEEKLY TIME SHEET OF INDIVIDUAL TEAM MEMBER

Staff : Week Ending :

Worked Hours
Project Activity Description Hours Percentage Scheduled Estimated
Code this of Completio Completion
week Completio n
n

Total Worked Hours :

Non-worked hours
Code Description Hours Comment & Authorization
this
week

Total Non- Worked Hours :

Weekly Timesheet
 lOMoARcPSD|40184581

 Weekly timesheets contain the breakdown activities and holds information about the
scheduled and estimated completion time of individuals and do not contain the project
completion dates.
4.2.2 Reporting Risk
 Risk reporting uses a traffic light method concept and consists of the following steps:
 Identify the first level elements for assessment
 Break the first level elements into second level elements
 Assess the second level elements and mark the color as
Green – on target
Amber – not on target but recoverable
Red – not on target and difficult to recover
 Review all the second level elements to reach the first level assessments
 Review both first and the second level assessments to produce an overall
assessment
 This method only focuses on non-achievement factors and do not mention about any
delay in the development process.
 Assessment forms can be used to evaluate the overall status of the project.
 Critical activities denoted by red color must be reconsidered during the revision of
project schedule.

4.3 Visualizing Progress

Downloaded by Pranjal singh ([email protected])
 lOMoARcPSD|40184581

 Collected data cannot be represented as arrived. It has to be shown visually so that

everybody involved in the project work is pleased about its progress. Presenting effectively
plays a vital role in the future of the project

4.3.1 Categories of Visualizing Progress

 The techniques that are used in visualizing project progress are:
 Gantt chart
 Slip Chart
 Ball Chart
 lOMoARcPSD|40184581

 These are explained in detail in the following sections.

4.3.2 Gantt Chart Technique

 Gantt chart is the most simple and the oldest form of representing the progress of the
project.
 It consists of an activity bar that indicate the scheduled activity dates and the duration
along with the activity floats.
Planned Week 15 16 17 18
Work Days M T W T F M T W T F M T W T F M T W T F
Code & Test Module 1

Code & Test Module 2

Code & Test Module 3

Code & Test Module 4

Specify Overall System

Check Specifications

Review Meetings . . .
 The progress reports of the activity are normally represented as a shaded activity bar
which indicates the percentage of activity completion.
TODAY

Sample Gantt Chart

 For example in the figure, the code and test module activity of X is ahead of the
completion process whereas the third activity Z is lacking behind in its schedule
4.3.3 Slip Chart Technique
 lOMoARcPSD|40184581

 A Slip chart provides an alternative view of Gantt chart by providing a visual indication
of those activities which are not on schedule.
 The chart indicates that, the more there is a bend in the line the greater the variation in the
project plan.
 If the slip line deviates more towards the non-achievement of project objectives, then it
has to be reconsidered.
 The same figure used to represent Gantt chart is modified to Slip chart and depicted

TODAY
below:

Planned Week 15 16 17 18
Work Days M T W T F M T W T F M T W T F M T W T F
Code & Test Module 1

Code & Test Module 2

Code & Test Module 3

Code & Test Module 4

Specify Overall System

Check Specifications

Review Meetings . . .
Slip Chart

 Additional slip lines can be included at regular intervals as they are build p which
provides the project manager a clear idea about the projects progress.

4.3.4 Ball Chart Technique

 lOMoARcPSD|40184581

 Ball charts are represented in the form of circles that indicate the start and the end point
completion of activities.
 Initially, the circles contain the original scheduled dates and when revisions are done, the
second dates are introduced inside the circle until the activity is started or completed.
 Circles of bar chart will at most contain only two dates the original and the revised one or
the original and the actual dates.
 Ball charts are pictorially shown as below:

30/4/10 Code Module 1

30/4/10

9/5/10 Code Module 2

12/5/10

22/5/10 System
31/5/10
Integration

Ball Chart
 An activity is denoted by a red circle (colored darker in the figure) when the start and the
end dates are later than the target dates whereas green circle (colored lighter in the figure)
denotes that the activity is ahead of its schedule.
 The color to the circles reminds the project team about the status of each activity.
 In general, all the three types of chart techniques do not show clearly the slippage in the
project completion date for the project life cycle. This is overcome by timeline charts.

4.3.5 Timeline Charts

 Timeline usually records and displays the target changes during the project life cycle.
 The chart represents the planned time along the horizontal axis and the actual time along
the vertical axis.
 lOMoARcPSD|40184581

 A line down the horizontal axis represents the scheduled activity completion dates and
the slip in the line indicates a delay in the respective activities.
 This timeline chart is used to calculate the duration of execution of the project as a part of
post-implementation review.

Planned Time / Week Numbers

1 2 3 4 5 6 7 8 9
Actual Time / Week Number

MTWTF
MTWTF MTWTF ing system MTWTF MTWTF MTWTF MTWTF MTWTF MTWTF
1

User requirements

n offline layout

Issue Tender
Draft tender
2

4
5

7
8
9

Timeline Chart

4.4 Cost Monitoring

 An important component of project control is cost monitoring.

 Cost monitoring provides an indication of the effort that has been given to the project.
 Sometimes, more cost is incurred to complete the activities to keep the project on
schedule.
 A cumulative cost chart is depicted below:
 lOMoARcPSD|40184581

Cumulative Cost Chart

 The chart does a comparison between the actual and the planned expenditure.
 These charts become more useful for estimating future costs.
 When revision of estimated cost and completion date are done, the same can also be
expressed in the revised cumulative chart.
 lOMoARcPSD|40184581

Fig. Revised Cumulative Cost Chart

4.5 Earned Value Analysis

 An assigned value to each task or work package based on original cost forecasts yields
earned value for the project.

 The assigned value is the original budgeted cost value and termed as a planned value
(PV) or budgeted cost of work schedule (BCWS).
 Earned value(EV)denotes the total value credited to a project at any point. It is also
termed as budgeted cost of work performed (BCWP).

 Common methods used in assigning an earned value are:

 0/100 technique: Task value is assigned zero till completion and the budgeted
value is 100%.
 50/50 technique:Task value is assigned 50% and then increased to 100% once it
completes.
 Milestone technique:Task is assigned a value based on the achievement of
milestones as part of original plan.
 Out of all these method, the 0/100 technique is used because the other techniques are not
suitable for longer duration cost estimation.
 lOMoARcPSD|40184581

4.5.1 Baseline Budgets

 To setup an earned value analysis, the first step is to create a baseline budget. The baseline
budget shows the forecast growth of the project plan in earned value with respectto time.
 Common ways of measuring earned value in software development process is persons-
hours or work-days.
 An 0/100 technique can be used to get the creditability of earned value.
 A typical baseline budget chart is given below and it depicts the scheduled completion of
all activities involved in the development of the project.
 lOMoARcPSD|40184581

4.5.2 Monitoring Earned Value

 The next step in earned value analysis is to monitor the project progress.
 Monitoring process indicates the completion of tasks and includes the activity start and
milestone achievement of the project.
 The actual cost (AC)is calculated by the actual cost of each task and is also called as
actual cost of work performed (ACWP).
 Certain inferences can be obtained from the earned chart such as:
 Schedule variance (SV) : the difference between the earned value and the planned
value indicates the degree of the completed work with the planned.
 Cost variance (CV):the difference between the earned value and the actual cost
of a completed work results in cost variance. A positive CV value indicated that the
project is under control and a negative CV denotes that the actual cost incurred is
much more than the planned one.
 The diagram depicts the earned value analysis along with the schedule and cost
variance.
 lOMoARcPSD|40184581

4.5.3 Performance Ratios

 Performance ratios defines two index values namely Cost Performance Index (CPI) and
Schedule Performance Index (SPI).
 Cost performance index and Schedule performance index values are calculated by the
formulas,
CPI = Earned value / Actual Costs
SPI = Earned value / Planned value
For Forecasting
EAC (Estimated Time at completion)=BAC/CPI

Where BAC= Budget at Completion

TEAC (Time estimate at Completion)= SAC/SPI

Where SAC = Schedule at completion

 When these indices refers to a greater value it means that the work is completed better
than planned and if the value is less, it means that the work is more costlier than planned.

4.6 Project Tracking

4.6.1 Prioritizing Monitoring

 lOMoARcPSD|40184581

The list of priorities defined in the level of monitoring are:

 Critical path activities: These denote those activities in the critical path that are
delayed in project completion date.
 Activities with no free float: These delayed activities will have a delay in subsequent
ones but still stick on target. These activities can have a serious effect on the resource
schedule because the subsequent activities have to wait for its completion.

 Activities with less than a specified float: If there is a very little float in the activity
say less than one week, these activities must be monitored very closely.
 High risk activities: These high risks are identified in the risk management plan
itself and these results in over spending.
 Activities using critical resources: Critical activities are very expensive and are
available only for a limited period and require high level of monitoring.
4.6.2 Getting back Project on Target
 Projects are subjected to delays and unexpected events.
 The project manager must ensure that the project scheduled end dates are unaffected at
any circumstances.
 To maintain the project within the completed time, duration of some activity of the
project can be delayed or shorten to fit into the time limit.
 The strategies involved in getting back the project to target are;
 Critical path shortening
 Reconsidering precedence requirements
Critical Path Shortening
 Delayed projects can often be brought back on track by shortening activity times on the
critical path.
 Critical path is determined by the overall duration of the project.
 By increasing the resources for the critical path activities results in completion of the
activity before time and the resources can be prolonged for a longer duration.
 At the same time, the resources used must be effectively allocated to all the activities so
that no resources are idle at any point of time.
 Swapping of critical and non- critical activities can also be used to shorten the time limit
and bring the project back to target.
 One disadvantage of shortening critical path is that, it produces many more paths while
shortening which can become critical.

Reconsidering Precedence Requirements

 The project can be brought back to target by defining constraints to certain activities that
 lOMoARcPSD|40184581

affect the other activities for its completion.

 A precedence constraint activity can be sub-divided into a component that can start
immediately.
 Altering these constraints would have a major impact on the quality factors, the risk
involved, which can cause a delay in carrying out the activities.

4.7 Change Control

 Change control implies the authority to approve and rank the changes. It combines the
automated tool with human to provide a mechanism for control of change.
 Any changes or alteration done to a single document often implies changes to other
documents as well.
 Change request is evaluated to assess the technical aspect of configuration items and the
budget.
4.7.1 Role of Chang Control Manager
 The responsibilities of change control manager or the configuration librarian are:
 Identification of configuration items that are subjected to change control.
 All project documentation and software products must be maintained in the
central repository.
 A formal set of procedures have to be setup to have control over changes.
 Maintenance of library items in the repository

4.7.2 Change control Procedures

 Change control authority (CCA) makes the final decision on the status and the priority of
the change based on the change report.
 Guidelines of a change control procedures includes:
1. One or more users might perceive a need for a modification to a system and ask for a change request
to be passed to the development staff.
2. The user management consider the change request and if they approve it pass it to the development
management.
3. The development management delegate a member of staff to look at the request and to report on the
practicality and cost of carrying out the change. They would, as part of this, assess the products that
would be affected by the change.
4. The development management report back to the user management on the findings and the user
management decide whether, in view of the cost quoted, they wish to go ahead.
5. One or more developers are authorized to take copies of the master products that are to be modified.
6. The copies are modified. In the case of software components this would involve modifying the code
and recompiling and testing it.
7. When the development of new versions of the product has been completed the user management
Downloaded by Pranjal singh ([email protected])
 lOMoARcPSD|40184581

will be notified and copies of the software will be released for user acceptance testing.
8. When the user is satisfied that the products are adequate they will authorize their operational release.
The master copies of configuration items will be replaced.

4.7.3 System Scope Changes

 Any changes done leads to changes in the size of the system which gradually increases.
 The changes can be either from the management of from the user.

 For every change that is implemented, the scope of the developing project must be very
carefully monitored and controlled.
 The changes made should not make the system to be inconsistent by affecting the
estimating factors.

4.8 Software Configuration Management

Throughout development, software consists of a collection of items (such as programs,

data and documents) that can easily be changed. During software development, the design, code,
and even requirements are often changed, and the changes occur at any time during the
development. This easily changeable nature of software and the fact that changes often take place
require that changes be done in a controlled manner.
Software configuration management (SCM) is the discipline for systematically
controlling the changes that take place during development. Software configuration management
is a process independent of the development process largely because most development models
cannot accommodate change at any time during development. SCM canbe considered as having
three major components:
Software configuration identification
Configuration control
Status accounting and auditing
Configuration identification
The first requirement for any change management is to have clearly agreed-on basis for
change. That is, when a change is done, it should be clear to what changes has been applied. This
requires baselines to be established. A baseline change is the changing of the established baseline,
which is controlled by SCM.

After baseline changes the state of the software is defined by the most recent baseline and
the changes that were made. Some of the common baselines are functional or requirements
baseline, design baseline, and product or system baseline. Functional or requirement baseline is
generally the requirements document that specifies the functional requirements for the software.
 lOMoARcPSD|40184581

Design baseline consists of the different components in the software and their designs. Product
or system baseline represents the developed system.

It should be clear that a baseline is established only after the product is relatively stable.
Though the goal of SCM is to control the establishment and changes to these baselines, treating
each baseline as a single unit for the purpose of change is undesirable, as the change may be
limited to a very small portion of the baseline.
Configuration control
Most of the decisions regarding the change are generally taken by the configuration
control board (CCB), which is a group of people responsible for configuration management,
headed by the configuration manager. For smaller projects, the CCB might consist of just one
person. A change is initiated by a change request.
The reason for change can be anything. However, the most common reasons are requirement
changes, changes due to bugs, platform changes, and enhancement changes. The CR for change
generally consists of three parts. The first part describes the change, reason for change, the SCIs
that are affected, the priority of the change, etc.
The second part, filled by the CM, describes the decision taken by the CCB on this CR,
the action the CM feels need to be done to implement this change and any other comments the
CM may have. The third part is filled by the implementer, which later implements the change.
Status accounting and auditing
For status accounting, the main source of information is the CRs and FRs themselves. Generally,
a field in the CR/FR is added that specifies its current status. The status could be active, complete,
or not scheduled. Information about dates and efforts can also be added to the CR, the
information from the CRs/FRs can be used to prepare a summary, which can be usedby the
project manager and the CCB to track all the changes.
4.9 Managing Contracts
4.9.1 Introduction
 The acquisition and supply process are depicted for pre-contract and post-contract asfollows:
 The success of a contract requires considerable amount of time management.
 An ISO 12207 standard defined for acquisition and supply of software defines five major
processes namely,
 Acquisition
  Supply
 Operation
 Maintenance
 Development

ACQUIRER SUPPLIER

Initiation

Pre -
Request for proposal Initiation cont
ract

Contract Preparation Preparation of Response

Contract

Post
Planning
-
cont
ract
Supplier Monitoring Execution

Acceptance and Delivery and Completion

Completion

ISO 12207 Acquisition and Supply process

 The initiation activity starts with the acquirer describing the preparation for the invitation
to tender.
 lOMoARcPSD|40184581

 System requirements are broader and are not related to software alone but depends on the
changes in the organizational environment.
 Software requirements specifically relate to the software components within the delivered
system and can be extracted from broader system requirements.
 Request for proposal of the project contains the system requirements, scope of thesystem,
instruction for the bidders, list of software products, subcontractors detail and other
technical constraints.
 The criteria for selecting the supplier will have to done very carefully by the acquirer done
by joint reviews, verification and validation.
 As the supplier delivers, the acquirer conducts the review tests and is satisfied accepts the
software and sign-off as completed.

4.9.2 Supply Process

 The supplier process activities will need to undertake in response to the request of
supplier.
Initiation: The process is started when a request for a proposal from an acquirer and
the supplier initiates the work.
Response Preparation: The response is prepared with expert knowledge drawn from
various people.
Contract: Every activity is handled well, then the acquirer accepts the supplier and the
details of the contract are negotiated and signed.
Planning: A detailed plan is developed of how the work has to be carried out.
Execution and Control: The detailed plan can be executed and the development
process is invoked. The supplier must monitor and have control over the product
quality in identifying, analyzing and providing resolutions.
Review and Evaluation: The acquirer reviews the progress of product information
which are needed to be accessed.
Delivery and Completion: Post-delivery process has to be defined in view of the
management plans.

4.9.3 Types of Contract

 lOMoARcPSD|40184581

 Services are the external resources that are required for setting up a new system.
 Based on the supply of a completed software package the contracts can be classified as
 Bespoke system: This kind of system is developed for an individual that is created
from scratch.
 Off-the-shelf: This package denotes what the user buys as it is and called as
shrink-wrapped software.
 Customized off-the-shelf: This system represents a basic core system that is
modified based on the requirements of the client.
 Based on how the payment is made to the supplier, the contracts can be classified as,
 Fixed price contracts: Here, the price is fixed when the contract is signed. There
will be no changes in the contract terms and the payment must be made towards the
end of the work.
Advantages of Fixed price contracts
 Customer expenditure is well-known.
 Motivation of the supplier towards delivering the product with cost-
effective.
Disadvantages of Fixed price contracts
 Supplier absorbs the risk in original estimate and allows higher prices to
allow contingency which is added as a margin quoted in the tender.
 Requirements once defined are difficult to modify which can cause
friction between supplier and customer.
 Initially, the supplier will quote low price but as requirements are put
forward, the supplier demands a higher price.
 Threat to the quality of the system can occur if the price is fixed.
 Time and Materials contracts: Here, the customer is charged with a fixed rate per
unit of effort. This also estimates the overall cost based on the customer’s
requirements and it is not based on the final payment.
Advantages of Time and Materials contracts
 Changing requirements can be done very easily.
 The customer is not worried about the price pressure.
Disadvantages of Time and Materials contracts
 lOMoARcPSD|40184581

 Customer cannot include all the requirements needed by them.

 The supplier will not like to work in a system where the scope defined is
out of control.
 Fixed price per unit delivered contracts:This type of contract is based onfunction
point counting. Along with the size of the system which includes LOC, a price per
unit is also quoted. In this system, the scope grows during the development process.
Advantages of Fixed price per unit delivered contracts
 Unlike the time contract, the customer can understand the changing
requirements
 Pricing schedules can be compared.
 Supplier does not get affected by risk increasing functionality.
 Supplier has efficiency to deliver the cost-effective manner.
 Development contract includes both the analysis and design stages of the
project.
Disadvantages of Fixed price per unit delivered contracts
 It is very difficult to measure the software size.
 The requirement changes sometimes affect the transactions that are not
included in the function point count.
 Based on the approach used in contractor selection the contracts can be classified as
 Open tendering process: The request for proposal must be considered and
evaluated with the original conditions. Every supplier can bid to supply the goods
and services. The evaluation process can be time-consuming and also expensive in
open tendering process.
 Restricted tendering process: Here, bids can be made only by suppliers who have
been invited by the customer. This is an better approach than the open tendering
but has some risk factors.
 Negotiated procedure: In particular instances, the restricted tendering process
fails because of the defects which lead to additional payment towards the
completion of the project.
4.9.4 Stages in Contract Placement
 lOMoARcPSD|40184581

 The main stages in contract placement are given below:

 Requirement analysis
 Evaluation plan
 Invitation to tender
 Evaluation of proposals
Requirement analysis
 Preparation of an requirement document containing the following:
 Introduction
 Description of the existing system
 Current environment of the system
 Customer’s future plans
 System requirements based on either mandatory or desirable
 Deadlines have to be defined
 Additional information requires from the potential suppliers
Evaluation plan
 The evaluation plan contains:
 Preparing a plan to evaluate the submitted proposals.
 Checking for the mandatory requirements that have been defined to meet the
objectives.
 Evaluating the desirable requirements
 Validating the quality of the software system
 Cost incurred for the lifetime of the proposed system
Invitation to tender
 This is also termed as request for proposal and contains:
 System requirements
 Defining the scope of the system
 Instruction to the bidders
 List of the software products
 Control of the subcontractors resulting in MoA
 Technical constraints
 lOMoARcPSD|40184581

Evaluation of proposals
 This evaluation has to be done in a planned manner. The process of evaluation includes:
 Scrutiny of the proposal documents
 Questioning supplier representatives
 Giving demonstrations
 Visiting the site of the development process
 Conducting practical tests.

4.9.5 Typical Terms of Contract

 The contents of a typical terms of contract are listed below:
 Definitions: The exact meaning of who is a supplier and who is a customer.
 Forms of agreement: Categorizing whether the contract is sale, a lease, or alicense.
 Goods and services to be supplied: This contains the actual list of individual pieces
of equipment that has to be delivered with specific model numbers. The services
includes proper training, documentation, installation, conversion of existing files,
maintenance of agreements and insurance related issues.
 Ownership of the software: There are two possible ownership that can exists; one
with the customer and the other with the supplier. Supplier provides a license to the
user to use but that does not mean the ownership changes. Any assignment of
copyright must be in writing.
 Environment: The basic working environment facilities have to be provided by the
supplier and the customer such as electricity supply.
 Customer commitments:Customers have to provide with the basic accommodation
facilities even though the work is carried out by external contractors.
 Acceptance procedures: Various tests are conducted and the system is accepted
after the procedure for signing off the testing process is completed.
 Standards: Every product that is supplied must abide by the standards relating to
its development and its documentation.
 lOMoARcPSD|40184581

 Project and quality management: The quality that is expected by the management
for the project can be influenced by conducting review meetings and obtaining the
progress information of the project.
 Timetable: A schedule is drawn to describe the different tasks and activities that has
to be carried out during the development process.
 Price and payment method:Payment must be made based on the price that has been
defined in the agreement ensuring that the goods and services are satisfactory.
 Miscellaneous legal requirements: A contract must be defined within the legal
jurisdiction stating the liabilities that are applied to sub contractors involved in the
process. Liquidated damages can cause financial losses where the customer suffers
if the supplier is not able to oblige.
4.10 Contract Management

 Contract management studies and monitors the conversation between the supplier and the
customer while the contracted work is being carried out.
 Customer can make changes to the future direction of the project and make decisions.
 The entire project will require representative of the supplier and the customer to interact
with each other at different points in the development process.
 Activities involved in contract management include:
 Identifying customer approval;
 Negotiating successfully;
 Project deliverables;
 Managing change;
 Decision making;
 Legal obligations;
 Business laws.

Accepting the Contract

 Customer has to undergo acceptance testing towards the end of the process.
 Every contract would have defined a time limit for the acceptance testing and the result has
to be produced before the time expires.
 lOMoARcPSD|40184581

 Certain software suppliers are concerned with pre-acceptance testing where the user tests
the system than the developer.
 The supplier will not like to retain their staff to a specific project after its completion.
 Customer finds that the modifications needed by them are handled only by the junior level
staffs that are not aware of the delivered product.
 All the payment to the supplier solely depends on the acceptance testing.
 Every bug that is raised must be fixed within the period of warranty.