ZeePedia

ORGANIZATIONAL PLANNING, Organizational Management Tools

<< Organizational Systems
Estimation - Concepts >>
img
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
i.
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
img
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
i.
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
img
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
i.
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
img
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
i.
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
img
Software Project Management (CS615)
5.8.2
Tools and Techniques for Staff Acquisition
i.
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
i.
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
img
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
i.
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.
v.
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
i.
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
img
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.
v.
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
i.
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
i.
Management Development
­  Responsibility
208
img
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
v.
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
img
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
img
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
img
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
img
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
img
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
img
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
img
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
img
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
img
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
img
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
·
other technical documentation
Testing
22.
·
alpha testing
·
beta testing
·
acceptance tests (ATP)
Installation
23.
Maintenance services
24.
Other services and deliverable items
25.
Method of delivery
26.
·
software
·
documentation
·
hardware
219
img
Software Project Management (CS615)
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.
5.12.1 SOW Template
i.
Scope of work: Describe the work to be done in detail. Specify the hardware and
software involved and the exact nature of the work.
ii.
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.
iii.
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.
220
img
Software Project Management (CS615)
iv.
Deliverables Schedule: List specific deliverables, describe them in detail, and
specify when they are due.
v.
Applicable Standards: Specify any company or industry-specific standards that
are relevant to performing the work. Often an Assumptions section as well.
vi.
Acceptance Criteria: Describe how the buyer organization will determine if the
work is acceptable
vii.
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.
5.13
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
221
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration