DEPARTMENT OF COMPUTER SCIENCE

UNIT-IV
Monitoring and control - Managing contracts.
4.1 Monitoring And Control
The purpose of project monitoring and control is to keep the team and management up
to date on the project's progress. If the project deviates from the plan, then the project
manager can take action to correct the problem. Project monitoring and control involves
status meetings to gather status from the team. When changes need to be made, change
control is used to keep the products up to date.
Monitoring and control cycle

Figure 12.1 Monitoring and control cycle

Responsibilities

Assessing progress
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
Collecting progress details
Need to collect data about:
• Achievements/ Milestones
• Costs
How to deal with partial completions?
99% completion syndrome
Possible solutions:
• Control of products, not activities

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

• Subdivide into lots of sub-activities

Red/Amber/Green (RAG) reporting
• Identify key tasks
• Break down into sub-tasks
• Assess subtasks as:
Green – ‘on target’
Amber – ‘not on target but recoverable’
Red – ‘not on target and recoverable only with difficulty’
• Status of ‘critical’ tasks is particularly important
Gantt charts

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

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
Earned value analysis
• Planned value (PV) or Budgeted cost of work scheduled (BCWS) – original estimate
of the effort/cost to complete a task (compare with idea of a ‘price’)
• Earned value (EV) or Budgeted cost of work performed (BCWP) – total of PVs for the
work completed at this time
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
Earned value analysis – actual cost
• Actual cost (AC) is also known as Actual cost of work performed (ACWP)

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

• 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
Recipients of progress reports
IT Customer
management management

Progress
report

Quality
Users
assurance

Project team

Prioritizing monitoring
We might focus more on monitoring certain types of activity e.g.
• 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 resources
Getting back on track
• Renegotiate the deadline – if not possible then
• Try to shorten activities on critical path e.g.
– Work overtime
– Re-allocate staff from less pressing work
– Buy in more staff
• 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
Change control
The role of configuration librarian:
• Identifying items that need to be subject to change control
• Management of a central repository of the master copies of software and
documentation

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

• Administering change procedures

• Maintenance of access records
Typical change control process
1. One or more users might perceive the need for a change
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
4. Development management report back to user management on the cost of the change;
user management decide whether to go ahead
5. One or more developers are authorized to make copies of components to be modified
6. Copies modified. After initial testing, a test version might be released to users for
acceptance testing
7. When users are satisfied then operational release authorized – master configuration
items updated

Change control
Devise change
control
procedure

Identify change

Assess impact
of change

Decide what to
do

Change control and configuration management

• 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.
4.2 Managing Contracts
Contract administration is the process of ensuring that the seller’s performance
meets contractual requirements. On larger projects with multiple product and service
providers, a key aspect of contract administration is managing the interfaces among the
various providers. The legal nature of the contractual relationship makes it imperative
that the project team be acutely aware of the legal implications of actions taken when
administering the contract.
Contract administration includes application of the appropriate project
management processes to the contractual relationship(s) and integration of the outputs
from these processes into the overall management of the project. This integration and
coordination will often occur at multiple levels when there are multiple sellers and

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

multiple products involved. The project management processes which must be applied
include:
• Project plan execution, authorize the contractor’s work at the appropriate time.
• Performance reporting, is, to monitor contractor cost, schedule, and technical
performance.
• Quality control, is to inspect and verify the adequacy of the contractor’s product.

• Change control, is , to ensure that changes are properly approved and that all those
with a need to know are aware of such changes.
Inputs to Contract Administration:
1. Contract. Contracts are described in previous Section
2. Work results. The seller’s work results—which deliverables have been completed
and which have not, to what extent are quality standards being met, what costs have
been incurred or committed, etc.—are collected as part of project plan execution
3. Change requests. Change requests may include modifications to the terms of the
contract or to the description of the product or service to be provided. If the seller’s work
is unsatisfactory, a decision to terminate the contract would also be handled as a change
request. Contested changes, those where the seller and the project management team
cannot agree on compensation for the change, are variously called claims, disputes, or
appeals.
4. Seller invoices. The seller must submit invoices from time to time to request
payment for work performed. Invoicing requirements, including necessary supporting
documentation, are usually defined in the contract.
Suggestions for Change Control in Contracts:
 Changes to any part of the project need to be reviewed, approved, and
documented by the same people in the same way that the original part of the plan
was approved.
 Evaluation of any change should include an impact analysis. How will the change
affect the scope, time, cost, and quality of the goods or services being provided?
 Changes must be documented in writing. Project team members should also
document all important meetings and telephone phone calls.
Project managers and teams should stay closely involved to make sure the new
system will meet business needs and work in an operational environment.
 Have backup plans.
 Use tools and techniques, such as a contract change control system, buyer
conducted performance reviews, inspections and audits, and so on.
Contract administration also has a financial management component. Payment
terms should be defined within the contract and should involve a specific linkage
between progress made and compensation paid.
Tools and Techniques for Contract Administration
Contract change control system: A contract change control system defines the
process by which the contract may be modified. It includes the paperwork, tracking
systems, dispute resolution procedures, and approval levels necessary for authorizing
changes. The contract change control system should be integrated with the overall
change control system .

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

1. Performance reporting: Performance reporting provides management with

information about how effectively the seller is achieving the contractual objectives.
Contract performance reporting should be integrated with the overall project
performance reporting.
2. Payment system: Payments to the seller are usually handled by the accounts
payable system of the performing organization. On larger projects with many or complex
procurement requirements, the project may develop its own system. In either case, the
system must include appropriate reviews and approvals by the project management
team.
Outputs from Contract Administration:
1. Correspondence: Contract terms and conditions often require written documentation
of certain aspects of buyer/seller communications, such as warnings of unsatisfactory
performance and contract changes or clarifications.
2. Contract changes: Changes (approved and unapproved) are fed back through the
appropriate project planning and project procurement processes, and the project plan or
other relevant documentation is updated as appropriate.
3. Payment requests: This assumes that the project is using an external payment
system. If the project has its own internal system, the output here would simply be
“payments.”
CONTRACT CLOSE-OUT
Contract close-out is similar to administrative closure in that it involves both
product verification (Was all work completed correctly and satisfactorily?) and
administrative close-out (updating of records to reflect final results and archiving of such
information for future use). The contract terms and conditions may prescribe specific
procedures for contract close-out. Early termination of a contract is a special case of
contract close-out.
Inputs to Contract Close-out:
Contract documentation: Contract documentation includes, but is not limited to, the
contract itself along with all supporting schedules, requested and approved contract
changes, any seller-developed technical documentation, seller performance reports,
financial documents such as invoices and payment records, and the results of any
contract-related inspections.
Tools and Techniques for Contract Close-out:
Procurement audits: A procurement audit is a structured review of the procurement
process from procurement planning through contract administration. The objective of a
procurement audit is to identify successes and failures that warrant transfer to other
procurement items on this project or to other projects within the performing organization.
Outputs from Contract Close-out:
1 Contract file: A complete set of indexed records should be prepared for inclusion with
the final project records.
2 Formal acceptance and closure: The person or organization responsible for contract
administration should provide the seller with formal written notice that the contract has
been completed. Requirements for formal acceptance and closure are usually defined in
the contract.
Using Software To Assist In Project Procurement Management

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

Word processing software helps write proposals and contracts, spreadsheets help
evaluate suppliers, databases help track suppliers, and presentation software
helps present procurement-related information. E-procurement software does
many procurement functions electronically. Organizations also use other Internet
tools to find information on suppliers or auction goods and services.
Established companies such as Oracle ,SAS, and Baan have developed new
software products to assist in procurement management .As with information or software
tool, organization must focus on using the information and tools to meet the project and
organizational needs. Organizations should often develop partnerships and strategic
alliances with other organizations to take advantage of potential cost savings.
Out Sourcing
Outsourcing software development and other information technology, or I.T.
services continues to grow in popularity. There are several important reasons for this.
Many companies that have not traditionally considered outsourcing may be surprised to
learn of the benefits that it could bring them. Even organizations with large software
teams may be candidates for outsourcing some of their projects.
Benefits of outsourcing
 To allow the client organization to focus on its core business

 To access skills and technologies

 To reduce both fixed and recurrent costs

 To provide flexibility

 To increase accountability

Information technology is rapidly becoming more complex and is constantly

changing. At the same time, many companies are finding that they increasingly need to
focus their attention on the areas of their strength due to rapidly increasing market
competition. For many of these companies, outsourcing I.T., at least projects that are
outside their area of expertise, can greatly strengthen their competitive advantage. It
also brings new energy to the organization to have projects that were causing ongoing
frustration, cost, and risk to now be in the hands of another organization with the
specialized skills and experience needed.
Organizations that only have budget to hire a few individuals often find that by
outsourcing their projects, they are still able to obtain access to a wide range of high
level skills. Outsourced development companies can apply the best skill for each phase
of a project. This flexibility and the availability of a larger talent pool provides optimum
results at the lowest cost.
Selecting the right outsourcing partner is key to realizing these benefits. Selecting
an organization of an appropriate size is important. An organization that is too large for
your project brings unnecessary costs and overhead. Selecting an organization with the
appropriate level of skills is also important. For projects that provide significant business
value and which you expect to be used long term, it is important to select an

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

organization whose people have true enterprise level experience. The organization's
vision, high-level design skills, and ability to understand and support your business goals
are also very important. This is often the greatest challenge with outsourcing overseas. It
takes more than technical skills for project success. The ideal outsource organization will
provide local individuals with these skills as well as overseas teams that they have
established relationships with.
This can provide small outsourced projects with the advantage of international
cost savings combined with the ease of management and all the other potential
advantages that outsourcing has to offer.
Outsourcing can provide tremendous benefit to organizations. It can reduce
complexity and cost while increasing project success. Selecting an organization with the
necessary level of skills and experience locally and who have their own established
international team provides an ideal formula for success. Together, this provides your
organization with the maximum efficiency and effectiveness.
Acquiring software from external supplier
This could be done via:
• a bespoke system - created especially for the customer
• off-the-shelf - bought ‘as is’
• customized off-the-shelf (COTS) - a core system is customized to meet needs of a
particular customer
ISO 12207 and Related Software Life-Cycle Standards
by Jim Moore, The MITRE Corporation, moorej@acm.org
This note describes ISO 12207, a high-level standard addressing all processes of the
software life cycle. It also traces the evolution of life-cycle standards, differentiates the
efforts of IEEE, ISO, and other organizations, and discusses the significance of 12207 to
international software acquisition.
The Institute of Electrical and Electronics Engineers (IEEE) is now voting on whether
the U.S. should adopt International Organization for Standardization (ISO) 12207, which
specifies software life-cycle processes. Because of the burgeoning of standards over the last
few years, it is important that software engineers understand what 12207 provides and how it
relates to other standards dealing with life-cycle processes.
Overview of ISO 12207
ISO 12207 offers a framework for software life-cycle processes from concept through
retirement. It is especially suitable for acquisitions because it recognizes the distinct roles of
acquirer and supplier. In fact, the standard is intended for two-party use where an agreement
or contract defines the development, maintenance, or operation of a software system. It is not
applicable to the purchase of commercial-off-the-shelf (COTS) software products.
In most cases, 12207 uses conventional standards language: "shall" to indicate
mandatory provisions, "should" for recommendations, and "may" for permissible actions.
Since the standard applies to both acquirer and supplier, one might expect it to place
mandatory requirements upon both parties. Its language, however, makes a subtle distinction:
those provisions that apply to the acquirer typically use the verb "will," denoting a
"declaration of purpose or intent by one party," not a requirement.

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

ISO 12207 provides a structure of processes using mutually accepted terminology,

rather than dictating a particular life-cycle model or software development method. Since it is
a relatively high-level document, 12207 does not specify the details of how to perform the
activities and tasks comprising the processes. Nor does it prescribe the name, format, or
content of documentation. Therefore, organizations seeking to apply 12207 may want to use
additional standards or procedures that specify those details.

The Evolution of Life-Cycle Standards

The Department of Defense is a pioneer in defining software development life cycles.
In the last few years, the DoD undertook an effort to unify DoD-STD-2167A (used by the
mission-critical community) and MIL-STD-7935 (used by the information systems
community) to create one life-cycle standard--MIL-STD-498.
Just as 498 was nearing approval, however, the DoD shifted its acquisition policies
toward more reliance on commercial standards. As a result, 498 was approved for an interim
period of only two years. The IEEE and the Electronics Industry Association (EIA) then
initiated a joint project to create a commercial replacement for 498. This effort produced one
standard with two names: an IEEE Trial Use Standard 1498 and an EIA Interim Standard 640.
Since both the IEEE and the EIA produced the standard, the American National Standards
Institute (ANSI) designated the document as ANSI Joint Standard 016.
Meanwhile, ISO 12207 was also underway. Whereas J-016 defined only the
development process, 12207 described four additional primary processes, as discussed above.
Furthermore, in 1992, the IEEE had completed its own life-cycle process standard, 1074,
providing detailed descriptions of development and maintenance activities as well as their
connections. In principle, one could use 1074 to construct processes that would comply with
the requirements of either J-016 or 12207. The challenge now is to "harmonize" or otherwise
converge these three different documents. Two current efforts will accomplish this goal.
First, the IEEE is balloting on the U.S. Adoption of ISO 12207. A yes vote would
provide a common basis of understanding for organizations who wish to acquire software
across international boundaries. Some parties contend that 12207 is essential if the U.S. is to
play a role in worldwide software acquisitions.
Second, the IEEE and the EIA are collaborating on another joint standard--the "U.S.
Industrial Implementation" of 12207--which will be structured around the process framework

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

of 12207 but add the "technical goodness" of J-016 to the development process. This standard
will be useful for defense, commercial, and international acquisitions.
The new joint standard is scheduled for completion in December 1996. The results of
this effort will then guide the planned revisions to 12207 and 1074, creating a harmonized
pair of standards: the former specifying requirements for the software life cycle and the latter
specifying how to construct a life-cycle model.
ISO 12207 acquisition and supply process

Types of contract
• Fixed price contracts
• Time and materials contracts
• Fixed price per delivered unit
Note: the difference between goods and services. Often license to use software is bought
rather than the software itself
Fixed price contracts
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
Stages in contract placement
 Requirement analysis
 Evaluation plan
 Invitation to tender
 Evaluation of proposals

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

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
Services to be provided in contracts:
1. Training
2. Documentation
3. Installation
4. Conversion of existing files
5. Maintenance agreements
6. Transitional insurance agreements
Acceptance

“When the work has been completed, the customer needs to take action to carry out
acceptance testing. The contract may put a time limit on how long acceptance testing can
take, so the customer must be organized to carry out this testing before the time for
requesting correction expires. “
• 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

QUESTION BANK
Unit-IV
TWO MARK:
1. What is the purpose of project monitoring and control?
2. Define Cost monitoring?
3. Define Earned value analysis – actual cost?
4. What is mean by Prioritizing monitoring?
5. Define Change control?
6. What is mean by Contract management?
7. Define Acceptance?
8. What are all the Stages in contract placement?
9. Give Advantages and disadvantages of fixed price contracts.
10. What are all the services to be provided in contracts?

SOFTWARE PROJECT
MANAGEMENT 13
DEPARTMENT OF COMPUTER SCIENCE

FIVE MARK:
1. Write a short note on Monitoring and control cycle?
2. Write a short note on Types of contract?
3. Write a short note on Cost monitoring?
4. Write a short note on Change control?
TEN MARK:
1. Give a brief explanation for Managing Contracts.
2. Briefly explain about Monitoring And Control.

---------------------------------------UNIT-IV Completed ----------------------------------------

SOFTWARE PROJECT
MANAGEMENT 13