ORGANIZATIONAL PLANNING, Organizational Management Tools

<< Organizational Systems

Estimation - Concepts >>

Software Project Management (CS615)

LECTURE # 28

5. ORGANIZATION

5.7

ORGANIZATIONAL PLANNING

Organizational planning involves identifying, documenting, and assigning

project roles, responsibilities, and reporting relationships.

Roles, responsibilities, and reporting relationships may be assigned to

individuals or to groups. The individuals and groups may be part of the

organization performing the project, or they may be external to it. Internal

groups are often associated with a specific functional department such as

engineering, marketing, or accounting.

On most projects, the majority of organizational planning is done as part

of the earliest project phases.

However, the results of this process should be reviewed regularly

throughout the project to ensure continued applicability. If the initial

organization is no longer effective, then it should be revised promptly.

Organizational planning is often tightly linked with communications

planning since the project's organizational structure will have a major

effect on the project's communications requirements.

5.7.1

Inputs to Organizational Planning

Project interfaces. Project interfaces generally fall into one of three categories:

Organizational interfaces--formal and informal reporting relationships

among different organizational units. Organizational interfaces may be

highly complex or very simple. For example, developing a complex

telecommunications system may require coordinating numerous

subcontractors over several years, while fixing a programming error in a

system installed at a single site may require little more than notifying the

user and the operations staff upon completion.

Technical interfaces--formal and informal reporting relationships among

different technical disciplines. Technical interfaces occur both within

project phases (e.g., the site design developed by the civil engineers must

be compatible with the superstructure developed by the structural

202

Software Project Management (CS615)

engineers) and between project phases (e.g., when an automotive design

team passes the results of its work along to the retooling team that must

create the manufacturing capability for the vehicle).

Interpersonal interfaces--formal and informal reporting relationships

among different individuals working on the project. These interfaces often

occur simultaneously, as when an architect employed by a design firm

explains key design considerations to an unrelated construction

contractor's project management team.

ii.

Staffing requirements. Staffing requirements define what kinds of competencies

are required from what kinds of individuals or groups and in what time frames.

Staffing requirements are a subset of the overall resource requirements identified

during resource planning.

iii.

Constraints. Constraints are factors that limit the project team's options. A

project's organizational options may be constrained in many ways. Common

factors that may constrain how the team is organized include, but are not limited

to, the following:

Organizational structure of the performing organization--an

organization whose basic structure is a strong matrix means a relatively

stronger role for the project manager than one whose basic structure is a

weak matrix.

Collective bargaining agreements--contractual agreements with unions

or other employee groups may require certain roles or reporting

relationships (in essence, the employee group is a stakeholder).

Preferences of the project management team--if members of the project

management team have had success with certain structures in the past,

then they are likely to advocate similar structures in the future.

Expected staff assignment --how the project is organized is often

influenced by the competencies of specific individuals.

5.7.2

Tools and Techniques for Organizational Planning

Templates. Although each project is unique, most projects will resemble another

project to some extent. Using the role and responsibility definitions or reporting

relationships of a similar project can help expedite the process of organizational

planning.

ii.

Human resource practices. Many organizations have a variety of policies,

guidelines, and procedures that can help the project management team with

various aspects of organizational planning. For example, an organization that

views managers as "coaches" is likely to have documentation on how the role of

"coach" is to be performed.

203

Software Project Management (CS615)

iii.

Organizational theory. There is a substantial body of literature describing how

organizations can and should be structured. Although only a small subset of this

body of literature is specifically targeted toward project organizations, the project

management team should be generally familiar with the subject of organizational

theory so as to be better able to respond to project requirements.

iv.

Stakeholder analysis. The identification of stakeholders and the needs of the

various stakeholders should be analyzed to ensure that their needs will be met.

5.7.3

Outputs from Organizational Planning

Role and responsibility assignments. Project roles (who does what) and

responsibilities (who decides what) must be assigned to the appropriate project

stakeholders. Roles and responsibilities may vary over time. Most roles and

responsibilities will be assigned to stakeholders who are actively involved in the

work of the project, such as the project manager, other members of the project

management team, and the individual contributors. The roles and responsibilities

of the project manager are generally critical on most projects, but vary

significantly by application area. Project roles and responsibilities should be

closely linked to the project scope definition. A Responsibility Assignment

Matrix is often used for this purpose. On larger projects, RAM s may be

developed at various levels. For example, a high-level RAM may define which

group or unit is responsible for each component of the work breakdown structure,

while lower-level RAM s are used within the group to assign roles and

responsibilities for specific activities to particular individuals.

ii.

Staffing management plan. The staffing management plan describes when and

how human resources will be brought onto and taken off of the project team. The

staffing plan may be formal or informal, highly detailed or broadly framed, based

on the needs of the project. It is a subsidiary element of the overall project plan.

The staffing management plan often includes resource histograms. Particular

attention should be paid to how project team members (individuals or groups) will

be released when they are no longer needed on the project. Appropriate

reassignment procedures may:

Reduce costs by reducing or eliminating the tendency to "make work" to

fill the time between this assignment and the next.

Improve morale by reducing or eliminating uncertainty about future

employment opportunities.

iii.

Organization chart. An organization chart is any graphic display of project

reporting relationships. It may be formal or informal, highly detailed or broadly

framed, based on the needs of the project. For example, the organization chart for

a three- to four-person internal service project is unlikely to have the rigor and

detail of the organization chart for a 3,000-person disaster response team. An

204

Software Project Management (CS615)

Organizational Breakdown Structure (OBS) is a specific type of organization

chart that shows which organizational units are responsible for which work

packages.

iv.

Supporting detail. Supporting detail for organizational planning varies by

application area and project size. Information frequently supplied as supporting

detail includes, but is not limited to: Organizational impact--what alternatives are

precluded by organizing in this manner.

Job descriptions--written outlines by job title of the competencies,

responsibilities, authority, physical environment, and other characteristics

involved in performing a given job. Also called position descriptions.

Training needs--if the staff to be assigned is not expected to have the

competencies needed by the project, those competencies will need to be

developed as part of the project.

5.8

STAFF ACQUISITION

Staff acquisition involves getting the needed human resources (individuals or

groups) assigned to and working on the project. In most environments, the "best"

resources may not be available, and the project management team must take care

to ensure that the resources that are available will meet project requirements.

5.8.1

Inputs to Staff Acquisition

Staffing management plan. It includes the project's staffing requirement

ii.

Staffing pool description. When the project management team is able to influence

or direct staff assignments, it must consider the characteristics of the potentially

available staff. Considerations include, but are not limited to:

Previous experience--have the individuals or groups done similar or related

work before? Have they done it well?

Personal interests--are the individuals or groups interested in working on this

project?

Personal characteristics--are the individuals or groups likely to work well

together as a team?

Availability--will the most desirable individuals or groups be available in the

necessary time frames?

Competencies and proficiency--what competencies are required and at what

level?

iii.

Recruitment practices. One or more of the organizations involved in the project

may have policies, guidelines, or procedures governing staff assignments. When

they exist, such practices act as a constraint on the staff-acquisition process.

205

Software Project Management (CS615)

5.8.2

Tools and Techniques for Staff Acquisition

Negotiations. Staff assignments must be negotiated on most projects. For

example, the project management team may need to negotiate with:

Responsible functional managers to ensure that the project receives

appropriately competent staff in the necessary time frame.

Other project management teams within the performing organization to

assign scarce or specialized resources appropriately.

The team's influencing competencies play an important role in negotiating staff

assignments, as do the politics of the organizations involved. For example, a

functional manager may be rewarded based on staff utilization. This creates an

incentive for the manager to assign available staff who may not meet all of the

project's requirements.

ii.

Pre-assignment. In some cases, staff may be pre-assigned to the project. This is

often the case when a) the project is the result of a competitive proposal, and

specific staff was promised as part of the proposal, or b) the project is an internal

service project, and staff assignments were defined within the project charter.

iii.

Procurement. Project procurement management can be used to obtain the

services of specific individuals or groups of individuals to perform project

activities. Procurement is required when the performing organization lacks the in-

house staff needed to complete the project (e.g., as a result of a conscious decision

not to hire such individuals as full-time employees, as a result of having all

appropriately competent staff previously committed to other projects, or as a

result of other circumstances).

5.8.3

Outputs from Staff Acquisition

Project staff assigned. The project is staffed when appropriate people have been

reliably assigned to work on it. Staff may be assigned full time, part time, or

variably, based on the needs of the project.

ii.

Project team directory. A project team directory lists all the project team

members and other stakeholders. The directory may be formal or informal, highly

detailed or broadly framed, based on the needs of the project.

5.9

TEAM DEVELOPMENT

Team development includes both enhancing the ability of stakeholders to

contribute as individuals as well as enhancing the ability of the team to function

as a team. Individual development (managerial and technical) is the foundation

necessary to develop the team. Development as a team is critical to the project's

ability to meet its objectives.

206

Software Project Management (CS615)

Team development on a project is often complicated when individual team

members are accountable to both a functional manager and the project manager.

Effective management of this dual reporting relationship is often a critical success

factor for the project, and is generally the responsibility of the project manager.

Team development occurs throughout the project.

5.9.1

Inputs to Team Development

Project staff. The staff assignments implicitly define the individual competencies

and team competencies available upon which to build.

ii.

Project plan. The project plan describes the technical context within which the

team operates.

iii.

Staffing management plan.

iv.

Performance reports. Performance reports provide feedback to the project team

about performance against the project plan.

External feedback. The project team must periodically measure itself against the

expectations of those outside the project.

5.9.2

Tools and Techniques for Team Development

Team-building activities. Team-building activities include management and

individual actions taken specifically and primarily to improve team performance.

Many actions--such as involving non-management-level team members in the

planning process, or establishing ground rules for surfacing and dealing with

conflict-- may enhance team performance as a secondary effect. Team-building

activities can vary from a five-minute agenda item in a regular status review

meeting to an extended, off-site, professionally facilitated experience designed to

improve interpersonal relationships among key stakeholders. There is a

substantial body of literature on team building. The project management team

should be generally familiar with a variety of team-building activities.

ii.

General management skills. General management skills are of particular

importance to team development.

iii.

Reward and recognition systems. Reward and recognition systems are formal

management actions that promote or reinforce desired behavior. To be effective,

such systems must make the link between project performance and reward clear,

explicit, and achievable. For example, a project manager who is to be rewarded

for meeting the project's cost objective should have an appropriate level of

control over staffing and procurement decisions. Projects must often have their

own reward and recognition systems since the systems of the performing

207

Software Project Management (CS615)

organization may not be appropriate. For example, the willingness to work

overtime to meet an aggressive schedule objective should be rewarded or

recognized; needing to work overtime as the result of poor planning should not

be. Reward and recognition systems must also consider cultural differences. For

example, developing an appropriate team reward mechanism in a culture that

prizes individualism may be very difficult.

iv.

Co-location. Collocation involves placing all, or almost all, of the most active

project team members in the same physical location to enhance their ability to

perform as a team. Collocation is widely used on larger projects and can also be

effective for smaller projects (e.g., with a war room, where the team congregates

and posts schedules, updates, etc.). On some projects, collocation may not be an

option; where it is not viable, an alternative may be scheduling frequent face to

face meetings to encourage interaction.

Training. Training includes all activities designed to enhance the competencies

of the project team. Some authors distinguish among training, education, and

development, but the distinctions are neither consistent nor widely accepted.

Training may be formal (e.g., classroom training, computer-based training) or

informal (e.g., feedback from other team members). There is a substantial body of

literature on how to provide training to adults. If the project team members lack

necessary management or technical skills, such skills must be developed as part of

the project, or steps must be taken to re-staff the project appropriately. Direct and

indirect costs for training are generally paid by the performing organization.

5.9.3

Outputs from Team Development

Performance improvements. Team performance improvements can come from

many sources and can affect many areas of project performance; for example:

Improvements in individual skills may allow a specific person to perform

assigned activities more effectively.

Improvements in team behaviors (e.g., surfacing and dealing with conflict)

may allow project team members to devote a greater percentage of their

efforts to technical activities.

Improvements in either individual or team competencies may facilitate

identifying and developing better ways of doing project work.

ii.

Input to performance appraisals. Project staff should generally provide input to

the appraisals of any project staff members with whom they interact in a

significant way.

5.10

Organizational Management Tools

Management Development

Responsibility

208

Software Project Management (CS615)

Authority

Competence

Resource Distribution

Pre-requisites

Constraints

Calendar

ii.

Supervisory Training

Field/on site operations

Concept clearance

Procedural details

Resource management

Activity Scheduling

iii.

Team Building

Managers

Professionals

Technical support group

Logistical support group

Skill set evaluation

iv.

Vital Statistics

Historical facts

Technical data

Direct concerns

Lesson learned

Identification of missing links

Reliability of data

Relevance of data

Progress reporting

Mandatory periodic reports

Exception reports

Event reporting

Current status reporting

Reporting formats

Reporting frequency

Report recipient

Reporting officer

Reporting Media

Response analysis (of previous reporting)

Review of Reports

Signing of Reports

Tracking of Reports

Mitigations offered

Corresponding the dead lines

209

Software Project Management (CS615)

vi.

Compliance of Rule of Business

Financial

Procedural

Administrative

Justifications for deviations

Acceptance of derailments

vii.

Trade Offs

Trade off between DO or DON'T

Quality of job (in the light of constraints)

Limiting the scope/deliverables

Meeting targets with minimum standards

Unavoidable mandatory deliverables

viii.

Quality Assurance

Standard QA procedures

Self defined measures

Task-specific controls

ix.

Beneficiaries Concern

Acceptance

Enthusiasm

Adding comforts in terms of use, cost or time

Confidence building-The Reliability

5.11

Contractual Obligations

A contract is a mutually binding agreement that obligates the seller to provide the

specified product and obligates the buyer to pay for it.

A contract is a legal relationship subject to remedy in the courts. The agreement

may be simple or complex, usually (but not always) reflecting the simplicity or

complexity of the product.

Contracts may be called, among other names, a contract, an agreement, a

subcontract, a purchase order, or a memorandum of understanding. Most

organizations have documented policies and procedures specifically defining who

can sign such agreements on behalf of the organization, typically called a

delegation of procurement authority.

Although all project documents are subject to some form of review and approval,

the legally binding nature of a contract usually means that it will be subjected to a

more extensive approval process. In all cases, a primary focus of the review and

approval process should be to ensure that the contract language describes a

product or service that will satisfy the identified need. In the case of major

210

Software Project Management (CS615)

projects undertaken by public agencies, the review process may even include

public review of the agreement.

Types of Contracts

Owing to the rapid advances in technology during the last several decades, it has

become increasingly necessary for high technology organizations to specialize in

specific, well-defined areas. Specialization has not only defined many new

branches of engineering, it has also defined areas of expertise within the

engineering disciplines. This is especially true of software engineering.

Frequently, organizations that do not specialize in software development hire

other organizations that do so to develop software for them. Even organizations

that do develop their own software may decide to hire outside specialists in

specific areas. IBM hired Microsoft to develop the PC-DOS operating system,

because Microsoft had experience in developing microcomputer systems and IBM

had not.

The development of software is much less deterministic and more risky than other

areas of technology. This often leads to misunderstandings and disagreements that

could have been avoided if they had been anticipated and contained early enough.

To standardize our terminology, the organization to whom, a proposal is being

submitted will be referred to as the customer, and the organization submitting the

proposal will be referred to as the pro-poser. Other terms commonly used

elsewhere for the pro-poser include bidder, vendor or contractor and for the

customer requestor or issuer. The organization submitting the winning proposal,

after being selected, will be referred to as the developer.

a) The cost-plus contract

Cost-plus is a contractual relationship where the developer is paid for the cost of

the service provided and in addition is allowed an agreed profit margin.

This is rather like renting a car the customer pays for the time that the car is used

(by the hour, day, week etc.), and for any other expenses such as insurance and

gasoline. Thus, in a cost-plus contract the total cost of the projects is only known

after the project has been completed.

As an example, company Alpha may contract software company Beta to develop

a system, company Beta will be paid $80 by company Alpha for each hour

invested by their engineers in the project. In additional 20 percent may then be

added to cover managerial, secretarial and other services. Additional expenses

incurred by company Beta for the benefit of the project would then be reimbursed

by company Alpha. These expenses might cover such areas as:

211

Software Project Management (CS615)

Special purpose development equipment (computers, compilers, networks

etc.)

Travel expenses incurred by employees of company Beta for the benefit of

the project

Target equipment procured by company Beta for the use of company

Alpha

Services from other outside sources requested by company Beta for the

project

The customer company, Alpha, may require the developer, company Beta, to

receive prior authorization before incurring any single expense exceeding $250,

and any expense in excess of $6000 monthly total. Such authorization should

always be in writing. This defines a basic cost-plus contractual relationship

between the two companies.

In many cases, cost-plus can be the most appropriate way to contract development

work however, there are numerous potential problems. A conflict of interest may

arise due to the developer's lack of motivation to complete the project as quickly

as possible, or due to the customer's reluctance to authorize additional expenses.

Cost-plus is often appropriate for small undefined projects, when it is difficult to

identify the project's requirements in advance. In fact, in many cases the

requirements phase of a project is offered as a cost-plus contract, all the remaining

phases are contracted at a fixed price.

The requirements phase is then used to bring the rest of the project to a

sufficiently well-defined state from which it can then be contracted at a fixed

price. Occasionally, one company is awarded a cost-plus contract for the

requirements phase, and another company is awarded the remaining phases as a

fixed price contract.

Cost-plus may be preferred by the customer who wants to retain control of the

development process. In some cases, the developer is perceived as an extension of

the customer's organization, and the development activities are managed by the

customer. A cost-plus contract should cover the following issues:

List of persons to be assigned to the project

Work definition

The assignment percentage for each person

Hourly or daily work rate for each person

Administrative overhead

Authorized expenses to be reimbursed

Billing procedure

Payment procedure

Termination procedure

212

Software Project Management (CS615)

The assignment percentage refers to the amount of time each person will be

expected to devote to the project. This may be 100 percent for some engineers,

and 50-60 percent for experts in specific areas.

The assignment percentage may also be quoted in terms of maximum or

minimum, meaning that, for example, a quality assurance engineer will devote no

more than 20 hours a week to the project, and no fewer than 10 hours a week to

the project.

The billing rate may be a fixed rate for all persons assigned to the project, or

individual rates may be set for each person or class of people.

For example, for each hour worked on the project, the developer will bill $80,

irrespective of who, worked that hour. Or the contract may stipulate that design

engineers bill at $120 per hour, coders at $60 per hour, documentation writers at

$50 per hour, and so forth. The most difficult cost-plus contract billing rate

method is the individual billing method, where Frank Jones is billed at $90 per

hour, John Smith at $75 etc. This means that each time a person is replaced or

added to the project, the hourly rate must renegotiated.

For a software development organization, there can be real advantages in cost-

plus contracts these include:

No financial or business risk

Acquisition of knowledge and experience at the expense of another

organization

However, as in most cases, these advantages come with some disadvantages,

which include:

Low business profit

Possible staff discontent

Reduced control of staff and development work

Potential friction with the customer due to a lack of well-defined goals and

motivation factors

Contract continuity is not assured

Most employees prefer a clear definition of the hierarchy to which they belong. In

a cost-plus contract the employee works within the customer's hierarchy, but

belongs to the developer's hierarchy, and this can cause discontent.

In general, from the developer's perspective, a cost-plus contract is a solid, low

profit, no risk business relationship.

From the customer's perspective, the advantages of a cost-plus contract are:

213

Software Project Management (CS615)

Retention of control over development

No commitment needed for a full project contract

A possible reduced business risk (due to the ability to terminate the

contract at any time

The customer's possible disadvantages are:

Increased development costs

Customer's assumption of development risks

Increased involvement in development

Potential friction with the developer due to a lack of well-defined goals

and motivation factors

For the customer, the desirability of a cost-plus contract is difficult to establish.

Clearly is dependent on the type of project and the conditions under which it will

be developed, as we as on other non-technical business considerations.

b) The fixed price contract

A fixed price contract is a commitment by the developer to provide an agreed

product or service for an agreed fee, within an agreed schedule.

This is similar to purchasing a bus ticket, when the bus company agrees to take

the customer to a specific destination within a published timetable, and for an

agreed fee. Of course, travelers can elect to rent a car, instead of purchasing a bus

ticket, and then drive to their destinations themselves. However, this may turn out

to be more expensive, and requires of the traveler some prior skills and

knowledge, such driving skills and knowledge of the route to the destination. So

travelers (or customers) must decide between providing the service themselves

and contracting someone else to provide the service.

A fixed price contract can only be applied to a well-defined project. Both

customer and developer must be able to define the final deliverable product or

service. Once this has been achieved, one of the main weaknesses of the fixed

price contract will have been removed. The advantages of a fixed price contract

for the developer include:

Full control of the development process

Possible higher business profit

Commitment for a complete project

The commitment for a complete project is a significant advantage over cost-plus

contract that may end at any time, at the customer's discretion. Of course, fixed

price contracts also have some disadvantages for the developer, which include:

214

Software Project Management (CS615)

Assumption of business and development risks

Potential friction with the customer due to:

continuing requirement changes

project completion criteria

interpretation of requirements

A successful software organization will often prefer a fixed price contract. These

are usually the projects that build a company's professional reputation, and

generate profit to enable growth.

Unfortunately, these are also the projects that generate loss, and which often

severely harm a company. Stiff competition for an important contract

occasionally tempts a company to underbid, which ultimately generates losses for

the developer.

It is almost inevitable in any project that the developer will be requested to change

requirements during development. Such changes are usually associated with

additional cost the customer, and are invariably a cause of disagreement between

developer and customer.

This is often due to unclear or ambiguous requirements, which, in turn lead to

disagreement regarding the criteria for project completion. This, essentially,

returns the contract to insufficiently defined state.

From the customer's perspective, the advantages in a fixed price contract include:

A fixed budget for the project.

Most of the development risks are transferred to the developer

Minimal involvement in the development process

The disadvantages to the customer are:

Risk of late delivery by the developer

Reduced control of the development process

Potential friction with the developer due to:

high cost of requirement changes

unclear project completion criteria

interpretation of requirements

Even though the interests of the developer and the customer may be different,

fixed price contracts are still often preferred by both parties. If the project is

sufficiently detailed and clear and if the relationship between the two parties is

215

Software Project Management (CS615)

well defined, then fixed price contracts can be beneficial to both the developer

and the customer.

The Cost-Plus Vs Fixed Price

There is often a real or imagined conflict of interest between the developer and

the customer. The customer wants to spend less and the developer wants to earn

more. As we shall see, a good relationship between developer and customer need

not necessarily lead to this conflict of interest.

There are basically two types of contractual relationship between the customer

and the Developer:

Cost-plus (also called Time and material)

Fixed price

Most other relationships are some kind of combination of these two

Contract type selection:

Different types of contracts are more or less appropriate for different types of

purchases. Contracts generally fall into one of three broad categories:

Fixed-price or lump-sum contracts--this category of contract involves a

fixed total price for a well-defined product. To the extent that the product is

not well defined, both the buyer and seller are at risk--the buyer may not

receive the desired product or the seller may need to incur additional costs to

provide it. Fixed-price contracts may also include incentives for meeting or

exceeding selected project objectives, such as schedule targets.

Cost-reimbursable contracts--this category of contract involves payment

(Reimbursement) to the seller for its actual costs plus, typically, a fee

representing seller profit. Costs are usually classified as direct costs or

indirect costs. Direct costs are costs incurred for the exclusive benefit of the

project (e.g. salaries of full-time project staff). Indirect costs, also called

overhead costs, are costs allocated to the project by the performing

organization as a cost of doing business (e.g., salaries of corporate

executives). Indirect costs are usually calculated as a percentage of direct

costs. Cost-reimbursable contracts often include incentives for meeting or

exceeding selected project objectives, such as schedule targets or total cost.

Time and Material (T&M) contracts--T&M contracts are a hybrid type of

contractual arrangement that contains aspects of both cost-reimbursable and

fixed-price-type arrangements. T&M contracts resemble cost-type

arrangements in that they are open ended, because the full value of the

arrangement is not defined at the time of the award. Thus, T&M contracts can

216

Software Project Management (CS615)

grow in con-tract value as if they were cost-reimbursable-type arrangements.

Conversely, T&M arrangements can also resemble fixed-unit arrangements

when, for example, the unit rates are preset by the buyer and seller, as when

both parties agree on the rates for the category of "senior engineers."

Other Customer-Developer Relationships

Cost-plus and fixed price are two of the traditional contractual relationships

between developer and customer. There are many variations of these two

basic relationships, including various combinations that are tailored to suit

specific projects. Some of these relationships are associated with the roles of

customer and developer, and attempt to provide more incentives for the

developer to support the customer's objectives beyond contractual obligations.

Additional types of customer-developer relationship include:

Combinations of fixed price and cost-plus

Joint ventures

Royalty agreements

Long-term commitments

Joint ventures are instances where the customer-developer dividing line can

become hazy, and many of the previously discussed advantages and

disadvantages may not apply. There are many cases where some form of joint

venture may be desirable for both parties, such as when the developer wants to

retain rights to the product, or when the developer joins the customer in

funding part of the development effort.

One way the customer can offer the developer moderate participation in the

business aspect of the project is by substituting royalties as partial payment. This

generates an added dimension to the developer's interest in the success of the

project. The royalties are usually such that the failure of the project would

produce less revenue for the developer than a straightforward fixed price contract,

and the success of the project will increase the developer's revenue.

Long-term relationships are often important for the developer. In many cases,

long term commitments are also in the customer's interest. This occurs when the

developer, by being awarded the initial contract, gains, through acquired

knowledge, a major advantage over others for subsequent development work.

Clearly, when the developer successfully completes a large and complex project,

a significant advantage is then acquired over other companies with respect to

future extensions of the project. A long-term commitment may then be of mutual

interest to both parties, wherein the customer assures future services from the

developer and the developer assures a long term income commitment.

5.12

The statement of work (SOW)

217

Software Project Management (CS615)

The statement of work is the basis of the contract between the pro-poser and the

customer, and is often incorporated into the contract. The SOW contains a

detailed list of all work to be performed by the pro-poser for the benefit of the

customer.

It is a narrative description of products or services to be supplied by the project.

For internal projects, the project initiator or sponsor provides the statement of

work based on business needs, or product or service requirements.

For external projects, the statement of work can be received from the customer as

part of a bid document, for example, request for proposal, request for

information, request for bid, or as part of a contract. The SOW indicates a:

Business need - an organization's business need, can be based on needed

training, market demand, technological advance, legal requirement, or

governmental standard.

Product scope description - documents the product requirements and

characteristics of the product or service that the project will be undertaken

to create. The product requirements will generally have less detail during

the initiation process and more detail during later processes, as the product

characteristics are progressively elaborated. These requirements should

also document the relationship among the products or services being

created and the business need or other stimulus that causes the need.

While the form and substance of the product requirements document will

vary, it should always be detailed enough to support later project planning.

Strategic plan - all projects support the organization's strategic goals--the

strategic plan of the performing organization should be considered as a

factor in project selection decisions.

The SOW starts as a general list of required deliverables in the RFP. A more

detailed version t of the SOW is submitted as part of the proposal, and is still

considered only an initial description of the work to be performed. The blinding

version of the SOW is finalized during contract negotiations, or after the detailed

project requirements have been completed.

Following table presents an example of an SOW outline for a software project.

The list of items varies considerably, depending on the type of project being

developed; for example not all projects include the delivery of hardware

components, and not all projects require training or installation.

218

Software Project Management (CS615)

Table: A sample SOW outline for a software project

Referenced documents

14.

requirements specification

existing system description

customer's RFP

developer's proposal

vendor's and developer's technical literature

Software deliverables

15.

functionality (as documented in the requirements specification)

list of major software components

Equipment and hardware deliverables

16.

functionality (as documented in the requirements specification)

list of major hardware components

Training

17.

user courses

operator training

installation training

Market research

18.

Procurement

19.

Supervision of subcontractors

20.

Documentation

21.

development documentation

user documentation

maintenance documentation