Spread Knowledge

CS615 - Software Project Management - Lecture Handout 28

User Rating:  / 1

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management



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.

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 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.

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.

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.

Tools and Techniques for Organizational Planning

  1. 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.
  2. 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.
  3. 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.
  4. Stakeholder analysis. The identification of stakeholders and the needs of the various stakeholders should be analyzed to ensure that their needs will be met.

Outputs from Organizational Planning

  1. 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.
  2. 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.
  3. 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 Organizational Breakdown Structure (OBS) is a specific type of organization chart that shows which organizational units are responsible for which work packages.
  4. 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.


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.

Inputs to Staff Acquisition

  1. Staffing management plan. It includes the project’s staffing requirement
  2. 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?
  3. 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.

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.

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.

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 inhouse 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).

Outputs from Staff Acquisition

  1. 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.
  2. 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.


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.

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.

Inputs to Team Development

  1. Project staff. The staff assignments implicitly define the individual competencies and team competencies available upon which to build.
  2. Project plan. The project plan describes the technical context within which the team operates.
  3. Staffing management plan.
  4. Performance reports. Performance reports provide feedback to the project team about performance against the project plan.
  5. External feedback. The project team must periodically measure itself against the expectations of those outside the project.

Tools and Techniques for Team Development

  1. 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.
  2. General management skills. General management skills are of particular importance to team development.
  3. 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 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.
  4. 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.
  5. 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.

Outputs from Team Development

  1. 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.
  2. 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.

Organizational Management Tools

  1. Management Development
    • Responsibility
    • Authority
    • Competence
    • Resource Distribution
    • Pre-requisites
    • Constraints
    • Calendar
  2. Supervisory Training
    • Field/on site operations
    • Concept clearance
    • Procedural details
    • Resource management
    • Activity Scheduling
  3. Team Building
    • Managers
    • Professionals
    • Technical support group
    • Logistical support group
    • Skill set evaluation
  4. Vital Statistics
    • Historical facts
    • Technical data
    • Direct concerns
    • Lesson learned
    • Identification of missing links
    • Reliability of data
    • Relevance of data
  5. 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
  6. Compliance of Rule of Business
    • Financial
    • Procedural
    • Administrative
    • Justifications for deviations
    • Acceptance of derailments
  7. 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
  8. Quality Assurance
    • Standard QA procedures
    • Self defined measures
    • Task-specific controls
  9. Beneficiaries Concern
    • Acceptance
    • Enthusiasm
    • Adding comforts in terms of use, cost or time
    • Confidence building-The Reliability

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 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.

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:

  • 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

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 costplus 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:

  • 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.

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:

  • 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 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 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.

The statement of work (SOW)

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

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

Table: A sample SOW outline for a software project

  1. Referenced documents
    • requirements specification
    • existing system description
    • customer's RFP
    • developer's proposal
    • vendor's and developer's technical literature
  2. Software deliverables
    • functionality (as documented in the requirements specification)
    • list of major software components
  3. Equipment and hardware deliverables
    • functionality (as documented in the requirements specification)
    • list of major hardware components
  4. Training
    • user courses
    • operator training
    • installation training
  5. Market research
  6. Procurement
  7. Supervision of subcontractors
  8. Documentation
    • development documentation
    • user documentation
    • maintenance documentation
    • other technical documentation
  9. Testing
    • alpha testing
    • beta testing
    • acceptance tests (ATP)
  10. Installation
  11. Maintenance services
  12. Other services and deliverable items
  13. Method of delivery
    • software
    • documentation
    • hardware

The basic guideline for the preparation of the SOW is that any activity, service or product required by the customer, and agreed to by the developer, must be included. This means that there can be no binding work items that were informally understood or agreed to verbally, which do not appear in the SOW.

The formal SOW must include all and only the work to be performed. This condition prevents misunderstandings and disagreements later, after the project begins.

The statement of work (SOW) describes the procurement item in sufficient detail to allow prospective sellers to determine if they are capable of providing the item.
“Sufficient detail” may vary, based on the nature of the item, the needs of the buyer, or the expected contract form.

Some application areas recognize different types of SOW. For example, in some government jurisdictions, the term SOW is reserved for a procurement item that is a clearly specified product or service, and the term Statement of Objectives (SOO) is used for a procurement item that is presented as a problem to be solved.

The statement of work may be revised and refined as it moves through the procurement process. For example, a prospective seller may suggest a more efficient approach or a less costly product than that originally specified. Each
individual procurement item requires a separate statement of work. However, multiple products or services may be grouped as one procurement item with a single SOW.

The statement of work should be as clear, as complete, and as concise as possible.
It should include a description of any collateral services required, such as performance reporting or post-project operational support for the procured item.

In some application areas, there are specific content and format requirements for a SOW.

SOW Template

  1. Scope of work: Describe the work to be done in detail. Specify the hardware and software involved and the exact nature of the work.
  2. Location of Work: Describe where the work must be performed. Specify the location of hardware and software and where the people must perform the work.
  3. Period of Performance: Specify when the work is expected to start and end, working hours, number of hours that can be billed per week, where the work must be performed, and related schedule information. Optional “Compensation” section.
  4. Deliverables Schedule: List specific deliverables, describe them in detail, and specify when they are due.
  5. Applicable Standards: Specify any company or industry-specific standards that are relevant to performing the work. Often an Assumptions section as well.
  6. Acceptance Criteria: Describe how the buyer organization will determine if the work is acceptable
  7. Special Requirements: Specify any special requirements such as hardware or software certifications, minimum degree or experience level of personnel, travel requirements, documentation, testing, support, and so on.

Software built around a Scheduling Engine

These packages were originally created to manage one project at a time, but over the years have been enhanced to handle multiple projects.

Well known examples include:

  1. Primavera
  2. TurboProject
  3. OpenPlan
  4. Microsoft Project
  5. AutoPlan
  6. Project Scheduler 8
  7. CA SuperProject
  8. Timeline