The contract review process and its stages

• Several situations can lead a software company to sign

a contract with a customer. The most common are:
1.Participation in a tender.
2. Submission of a proposal according to the
customer’s RFP.
3. Receipt of an order from a company’s customer.
4. Receipt of an internal request or order from
another department in the organization.
• Contract review is the SQA component devised to
guide review drafts of proposal and contract
documents.
• The review process itself is conducted in two stages:
■ Stage One -Review of the proposal draft prior to
submission to the potential customer (“proposal draft
review”).
■ Stage Two - Review of contract draft prior to
signing (“contract draft review”).
• The processes of review can begin once the relevant
draft document has been completed.
• The individuals who perform the review thoroughly
examine the draft while referring to a comprehensive
range of review subjects
• After the completion of a review stage it is required that
the necessary changes, additions and corrections are
introduced by the proposal team and by the legal
department.
 Contract review objectives
The two contract review stages have different
objectives are
1.Proposal draft review objectives
2.Contract draft review objectives
1. Proposal draft review objectives
The nine proposal draft review objectives that make sure the
following activities have been satisfactorily carried out:
1.1. Customer requirements have been clarified and documented.
1.2. Alternative approaches for carrying out the project have been
examined.
1.3. Formal aspects of the relationship between the customer and
the software firm have been specified.
1.4. Identification of development risks.
1.5. Adequate estimation of project resources and timetable have
been prepared.
1.6. Examination of the firm’s capacity with respect to the project.
1.7. Examination of the customer’s capacity to fulfill his
commitments.
1.8. Definition of partner and subcontractor participation
conditions.
1.9. Definition and protection of proprietary rights.
1.1 Customer requirements have been
clarified and documented
• RFP documents and similar technical
documents can be too general and imprecise
for the project’s purposes.
• As a result, additional details should be
obtained from the customer.
• Clarifications of vague requirements and their
updates should be recorded in a separate
document that is approved by both the
customer and the software firm.
1.2 Alternative approaches for carrying
out the project have been examined
• Often, promising and suitable alternatives on
which to present a proposal have not been
adequately reviewed (if at all) by the proposal
team.
• This stipulation refers especially to
alternatives encompassing software reuse,
and partnerships or subcontracting with firms
that have specialized knowledge or staff that
can qualify for meeting the proposal’s terms.
 1.3 Formal aspects of the relationship
between the customer and the software
firm have been specified
The proposal should define formalities that
include:
■ Customer communication and interface
channels
■ Project deliverables and acceptance
criteria
■ Formal phase approval process
■ Customer design and test follow-up
method
■ Customer change request procedure.
1.4 Identification of development risks
• Development risks, such as insufficient
professional know-how regarding the project’s
professional area or the use of required
development tools, need to be identified and
resolved.
• For a comprehensive description of
identification of software risk items and
methods for risk management actions.
 1.5 Adequate estimation of project
resources and timetable.
• Resources estimation refers to professional
staff as well as the project’s budget, including
subcontractors’ fees.
• Scheduling estimates should take into account
the time requirements of all the parties
participating in the project.
 1.6 Examination of the company’s
capacity with respect to the project.
• This examination should consider professional
competence as well as the availability of the
required team members and development
facilities on the scheduled time.
 1.7 Examination of the customer’s
capacity to meet his commitments.
• This examination refers to the customer’s
financial and organizational capacities, such as
personnel recruitment and training,
installation of the required hardware, and
upgrading of its communications equipment.
 1.8 Definition of partner and
subcontractor participation.
• This covers quality assurance issues, payment
schedules, distribution of project
income/profits, and cooperation between
project management and teams
 1.9 Definition and protection of
proprietary rights.
• This factor is of vital importance in cases
where reused software is inserted into a new
package or when rights for future reuse of the
current software need to be decided.
• This item also refers to the use of proprietary
files of data crucial for operating the system
and security measures.
 2.Contract draft review objectives
• The three contract draft review objectives that
make sure the following activities have been
satisfactorily carried out:
1. No unclarified issues remain in the
contract draft.
2. All understandings reached subsequent
to the proposal are correctly documented.
3. No “new” changes, additions, or
omissions have entered the contract draft.
 Implementation of a contract review
• Contract reviews vary in their magnitude,
depending on the characteristics of the
proposed project.
• This complexity may be either technical or
organizational. Accordingly, different levels of
professional effort are justified for the various
contract reviews.
• Special professional efforts are required for
major proposals.
 Factors affecting the extent of a
contract review
• Project magnitude, usually measured in man-month
resources.
• Project technical complexity.
• Degree of staff acquaintance with experience in the
project area. Acquaintance with the project area is
frequently linked with software reuse possibilities; in
cases where a high proportion of software reuse is
possible, the extent of the review is reduced.
• Project organizational complexity. The greater the
number of organizations taking part in the project,
the greater the contract review efforts required.
 Who performs a contract review?
• The task of contract review can be completed by
various individuals, listed here in ascending order,
according to the complexity of the project:
■ The leader or another member of the
proposal team.
■ The members of the proposal team.
■ An outside professional or a company staff
member who is not a member of the proposal team.
■ A team of outside experts.
 Implementation of a contract review
for a major proposal
• Major proposals are proposals for projects
characterized by at least some of the
following: very large-scale project, very high
technical complexity, new professional area
for the company, and high organizational
complexity.
• Implementation of a contract review process
for a major project usually involves substantial
organizational difficulties.
The difficulties of carrying out contract
reviews for major proposals
• Almost everybody agrees that contract review is a
major procedure for reducing the risks of major
project failures.
• Several substantial, fundamental, and inherent
difficulties in performing the contract review exist,
especially for those situations requiring a review of a
major proposal.
Time pressures
Proper contract review requires
substantial professional work.
The potential contract review team
members are very busy.
Time pressures
Both stages of the contract review, proposal draft review
and contract draft review are usually performed when the
tender team is under considerable time pressures. As a result,
each stage of the contract review has to be completed within
a few days to allow for the subsequent corrections of
documents to take place.
Proper contract review requires substantial professional
work.
Professional performance of each stage of the contract
review requires investment of substantial professional
expertise
The potential contract review team members are very busy.
The potential members of the contract review team are
often senior staff members and experts who usually are
committed to performing their regular tasks at the very time
that the review is needed.
 Recommended avenues for
implementing major contract reviews
• The contract review should be scheduled.
• A team should carry out the contract review.
• A contract review team leader should be appointed.
The activities of the team leader include:
– Recruitment of the team members
– Distribution of review tasks among the team’s members –
Coordination between the members of the review team –
Coordination between the review team and the proposal team
– Follow-up of activities, especially compliance with the
schedule
– Summarization of the findings and their delivery to the
proposal team.
 Contract review subjects
• Contract reviews examine many subjects, based
on the contract review objectives.
• Checklists are useful devices for helping review
teams to organize their work and achieve high
coverage of the relevant subjects.
• It is clear that many of the subjects on these lists
are irrelevant for any specific project.
• At the same time, even a comprehensive checklist
may exclude some important subjects relevant to
a given project proposal.
 Contract reviews for internal projects
• A substantial number, if not the majority, of software projects are
internal projects — “in-house” projects – carried out by one unit
of an organization for another unit of the same organization.
• In such cases, the software development unit is the supplier, while
the other unit can be considered the customer.
• Frequently, internal software development projects are not based
on what would be considered a complete customer–supplier
relationship.
• In many cases, these projects are based on general agreements,
with goodwill playing an important role in the relationships
between the two units.
• It follows that the developing unit will perform only a short and
“mild” contract review, or none at all.
• Unfortunately ,loose relationships are usually
characterized by insufficient examination of the project’s
requirements, its schedule, resources and development
risks. As a result, the following problems are likely to
arise:
(1) Inadequate definition of project
requirements.
(2) Poor estimates of required resources.
(3) Poor timetable/scheduling.
(4) Inadequate awareness of development risks.
• As this list indicates, we can easily conclude that in-house
projects performed for internal customers are more
prone to failure than are outside-contracted projects.
• The potential disadvantages of the loose relationships
evidenced by internal projects
 • It could be concluded that the customer–supplier
relationship and contract review which proved to
be fruitful for external projects should be applied
for internal projects as well.
• The chances of avoiding the abovementioned
potential problems can be considerably improved
by implementing procedures that will define:
■ An adequate proposal for the internal
project
■ Applying a proper contract review process
for internal projects
■ An adequate agreement between the
internal customer and the internal supplier.