Software project

management
Unit 2
CHAPTER 5: Managing Domain Processes
Domain processes are the interrelated activities specific to the functioning of
the organization for which a software project is developed. The measure of
quality for a software project is based on how well the software solves specific
domain-related problems.
Defining the Process Domain
Domain processes are the interrelated activities that are specific to the functioning
of the organization for which a software project is developed.
The measure of quality for a software project is based on how well the software
solves specific domain-related problems.
There are six classes of product domains

● Consumer
● Business
● Industrial
● Real-time
● Really timely
● Scientific
Individuals buy consumer products for personal use.This use could be at
home, while traveling, or at work.
● The majority of software products are targeted at the business product
domain.Here the key is providing a cost-effective product to the business
customer that will improve overall business profits.
● Industrial products are a specific subclass of business products. These are
software tools that are purchased for the specific purposes of machine
automation, factory automation and integration, and embedded control
software.
● Real-time products are used to control processes that have a defined and
finite time budget. Real-time systems are used for data collection of events
that last less than a microsecond.
● Really timely, as opposed to real-time, software products must execute within
a time budget that does not irritate the end user. Examples of this are the
software that runs ATM machines and does credit card verification while
ordering over the Internet.
Scientific products simulate real-world activities using mathematics. Real-world
objects are turned into mathematical models. Executing formulas simulates
the actions of the real-world objects.
Four classes of product systems look at ways that the software product will be
built and delivered from the developer's perspective. the selection of one or more of
these product system classes.
● New software product
● Re-engineering of existing product
● Component integration
● Heroic maintenance
A new software product starts with a set of requirements and moves through
its development life cycle to delivery.
Re-engineering existing product is simply that. This product already exists in a
form that may use outmoded software technology or be hosted on obsolete
Hardware.
Taking available commercial-off-the-shelf (COTS) products and integrating
them into a product is component integration.
Heroic maintenance occurs when a company wants to wring the last bit of
revenue out of an existing software product that has been passed over for re-
engineering.
The first matrix to be developed by the project manager involves identifying the product domain type
The third part of defining the process domain is the
product component Classes
This set of classes is also viewed from the perspective of the end-user.
There are six members of the class

Software
Hardware
People
Database
Documentation
Procedures

If a project is to develop a "pure" software product, the end-user has an expectation that he will get an
installation set of media or an access key to a remote site to download the product.The developed
software is hosted on hardware.
People are a critical part of many software products.

Database products, although most definitely software, are separated as a

distinct class because of the expectations that accompany the purchase of this

class of complex software.

Documentation is almost always a part of the product. In some cases, it may

be books and manuals purchased.

Procedures or business rules are a final component class. In situations in which

the customer is buying systems and software used for decision support,

equipment control, and component integration, it is important for the customer

to understand the procedure deliverables.

This matrix is a table of the product component classes matched with the classes
of product systems.
The third matrix that the project manager produces to define the domain is to

link the product domains to the delivered components.

Project Selection Models
Selection of projects is a key business process and is essential to the ongoing

economic health of the organization. This process involves the project

managers, product line managers and business unit executives, and all the

stakeholders in and out of the business organization.

Within the business organization are the employees and the organization's

management. The majority of the stakeholder entities reside outside the

Organization.
Project selection must be based on sound strategy and usually involves more

than one stakeholder department.

Project Portfolio Management

Projects have a defined start point and an end point based on the deliverables
produced. While projects are executing, they are part of the organization's project
portfolio. A project portfolio is a group of projects carried out under the
sponsorship and/or management of an organization. They are grouped together
for these reasons:
 ● They are part of the same product family.
● They compete for scarce resources.
● Project deliverables and interim development artifacts are interdependent.
● There are multiple and conflicting organization objectives in making selection.
● Selection criteria are qualitative or quantitative, based on specific organization
objectives.
● Political objectives play a role.

Different models can be used for portfolio selection. The models must be linked to
corporate strategy, as opposed to simple profit maximization or furthering of a
single product.
Portfolio models define a strategic domain process within an organization. This

differs from company to company, absolutely must involve executive

management, and determines direction, focus, and budget allocations for the

projects that will build the organization's products.

Portfolio models consider relative value of projects and resource interactions.

There are three classes of portfolio models to understand.

The first is a pure economic return model that uses financial measures of internal
rate of return, net present value, marginal cost of capital, return on investment and
assets and invested capital, and weighted average cost of capital
Cost-benefit models are the second class of portfolio evaluation models.

Employing benefit/cost analysis techniques, these models compare project

alternatives when some benefits are not tangible.

Market research models are the third class and are used almost exclusively for

new products. Inadequate market analysis has been determined to be the

number-one cause of product failure.

the class of portfolio model to implement has been decided upon, the

method for scoring the results of the model must be determined. A weighted

scoring technique measures the amount of model conformance defined based

on the class of the portfolio model chosen.

The Delphi scoring model is an excellent method to be used along with

weighted scoring to take advantage of experts' decisions for validation of the

organization's unique portfolio model.

Understanding Financial Processes

The final domain process for the project manager to understand is the financial
aspect of the project.The understanding that the project manager needs is one of
the interrelationships among the various ways that a financial evaluation is done
on a project or business unit.
Any project selection or portfolio analysis criteria decision that influences product
prices, per-unit costs, volume, or efficiency will impact profit margin or turnover ratio.
And any decision that affects the amount and type of debt and equity used will
impact the financial structure as well as cost.
CHAPTER 6 : Selecting a Project Team
The selection of a project team occurs early in the life cycle of a software

development project. The selection of team members, the stages of team

building that occur, and the way in which the team morphs all support and

affect the remainder of the activities in the life cycle.

Many project teams exhibit behavioral characteristics of a single personality.

Team members may be added or deleted as the project leader discovers conflicts,
but such changes come with a price:

Any change in membership will require the group to go through team formation
stages all over again before the team can perform.
A team personality is complete with spoken and unspoken rules and constantly

shifting relationships. As new members join the team and existing ones depart,

the character of the team changes.

6.1 Selecting a Project Team

The IEEE-CS/ACM joint task force on Software Engineering Ethics and

Professional Practices (SEEPP) has developed a code of ethics for software

engineers. It contains eight sets of guiding principles:

1. Public Software engineers shall act consistently with the public interest.
2.Client and employer Software engineers shall act in a manner that is in the best
interests of their client and employer, and that is consistent with the public interest.

3.Product Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.

4.Judgment Software engineers shall maintain integrity and independence in their

professional judgment.

5.Management Software engineering managers and leaders shall subscribe to

and promote an ethical approach to the management of software development
and maintenance.

6.profession Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7.Colleagues Software engineers shall be fair to and supportive of their

colleagues.

8.self Software engineers shall participate in lifelong learning regarding the

practice of their profession, and promote an ethical approach to the practice of

the profession.
Colleagues Software engineers shall be fair to and supportive of their

colleagues.

Self Software engineers shall participate in lifelong learning regarding the

practice of their profession, and promote an ethical approach to the practice of

the profession.
A leader(project leader) must understand at least one model of determining individual and

team personalities thoroughly to be able to assess the health of relationships

on project teams.

Understanding several models gives the leader even more Insight.

project teams are required to meet the technological challenges.

As IBM's Fred Brooks pointed out in his landmark paper "No Silver Bullet" in 1987,
no single tool will solve all the problems of the day, technical or otherwise.

To explores methods and approaches to aid a project or program

manager in understanding the developing personality of a project team. It will

also provide guidance on the selection, structure, motivation, and maintenance

of a project team.
6.2 The Whole Is the Sum of the Parts
The personality of a project is comprised of individuals who, in turn, have

complex personalities.

Taibi Kahler suggests, Observing people is like observing holograms.

A team is made up of independent images, just as is each person. Several models

are available from the behavioral sciences to help us with the composite.

Management theory contains several personality models that explain how the
team's collective unconstructive traits may be controlled.
Individual Personality Type
Starting with the individual, several personality models have been derived

from Carl Jung's theory of "psychological types."

The Myers-Briggs Type Indicator (MBTI)-

the Fundamental Interpersonal Relations Orientation Behavior (FIRO-B) model,

the Keirsey Temperament Sorter,

The Kahler Process Communication Model (PCM), and

the WorkStyle Patterns™

the Enneagram

Inventory from the McFletcher Corporation

1.Identifies four bipolar dimensions of behavior, measuring self-reported
preferences on each one, which allows for 16 different personality descriptions,
identified by 4-letter codes.

2.According to Schutz, all humans possess three basic needs, to a greater or

lesser degree. They are the needs for inclusion, control, and affection.

3.Closely related to MBTI is the Keirsey Temperament Sorter, derived from the

work of David Keirsey in his book Please Understand Me.It is accessible via

the Internet, does not require professional administration, and offers the

personality test instrument in four languages

4.The Kahler Process Communication Model (PCM) is a six-part description
based on transactional analysis, which analyzes personalities by observing how
one conducts transactions with others

5.The Enneagram, a centuries-old nine-part model with roots in the Middle East,

measures nine basic defensive styles and gives breakthrough feedback and

strategies for managing individual stress. The nine parts to the Enneagram

model are related as

Model Usage
Results are often obtained from using any one of these models, revealing the
reasons why certain people do or don't work well together. It is important for a
project manager to gain some skill in recognizing personality patterns and
predicting their interaction. Mostly, the models mentioned divide personalities into
patterns of behavior describing a map of an individual's personality.

Cultural Influences

Cultural patterns are another dimension to individual and team

personalities.The cultural diversity of many modern companies is well
known, and global project teams are becoming more common. Cultural
patterns vary by country and region, and affect team members' expectations
Personal Motivation
Kahler suggests that understanding a person's "home-base" psychological

needs , in addition to the phase of life in which he is currently operating

(environment), will give rise to an understanding of what motivates the person

individually and in teams.

6.3 Parts Need to Work Together

the importance of choosing a good team (when possible) and preparing the
members for the project. A large number of projects fail because the team never
"jells.
Hire for Trait and Train for Skill

It is much easier to start with a positive, jelled team that might deteriorate

later than to start with a dysfunctional team in the first place.

McFletcher WorkStyle Patterns Inventory

A useful instrument for explaining behavior is the WorkStyle Patterns Inventory (WSPI)
from the McFletcher Corporation. The purpose of the assessment is to identify how a
person prefers to approach work versus the approach that the position or current
assignment requires, and it may be administered by a facilitator certified by McFletcher.

McFletcher defines two kinds of stress: personal and organizational. Personal stress
usually occurs because you want to perform more activities of a specific kind than the
position requires. Organizational stress can be observed through misunderstandings of
work expectations, product quality and customer service problems, missed deadlines,
The Skill Gap
A leader's ability to quickly assess a person's personality characteristics will go well
beyond the one-sided balance sheet of accomplishments called a Resumé.

skill of programmers could impact a technical project schedule. He seeded a

Fortran program with bugs and then timed a sampling of ITT's programmers on

how long it took them to find all the seeded errors,All of the participants

were Fortran programmers by trade. The results were astonishing. The

differences in technical skill performance varied by 20 to 1. That is, it took the

worst programmer 20 times longer to find the bugs than the best programmer.
Understand Group Dynamics
A leader must recognize how teams form to be able to lead them properly. A

well-known model of team formation,

This model depicts the process of how a group decides on its operating profile.

The profile is different for every group and is time- and place-dependent.

Every team experiences this cycle and often repeats it many times during the

course of a project. Each time a new member joins the team or an old member

departs, the team norms must be recalibrated for the new team situation.
Recognize Teamicide
Teamicide is the result of group dynamics in the organizational environment

that become stuck in the storming stage, causing the members to retreat into

the roots of their personalities, often destructively,

"Teamicide," referring to it as the inhibition of team formation and the disruption of

project sociology. They list teamicide techniques as environmental things that a
leader should watch for to avoid killing teamwork.

Defensive management-Allow the staff to make their own decisions,

even if they sometimes make a mistake.

Bureaucracy- Avoid turning developers into bureaucrats. Allow the team

to believe in its own goals, and express your belief in it (and them) as Well.

Physical separation- Place workers together so that casual interaction

may occur.

Fragmentation of time Limit-the number of projects, and, therefore,

teams, that a person is assigned to.

Quality reduction of the product -A developer's self-esteem suffers when

he is required to build a product of lower quality than what he is capable Of.

Phony deadlines-Tight deadlines are sometimes a necessity and can even

present an enjoyable challenge to the team.

Clique control Managers don't usually work in jelled teams. Instead, they

achieve peer acceptance via roles.

6.4 Working Together Requires a Framework

The project leader must read the team's collective personality, select an

appropriate infrastructure suitable for it, and maintain its rhythm throughout

the project. It should become part of the group's norm.

Communication and Team Size

Many of the causes of teamicide are under the control of a project leader.
Team size in relation to the project size
Team Communication

Communication among the team members is fundamental to the

accomplishment of the project's tasks. To prevent teamicide, everyone,

managers and team members alike, must attempt to use the preferred channel

of communication to transmit information so that the receiver can truly hear

the message.

As the team size grows, the number of two-way communications paths

increases rapidly according to the formula,where n is the number of participating

team members
Team Dispersion

The management of a project team is much more difficult when it is

geographically dispersed.

Geography Issues

Communication and dispersion are the limiting realities for any work team spread
over a wide physical area, where the team members will not likely interact face-to-
face.

This is because most of the team interaction models assume that team members
are physically close and can use all their senses to detect the useful individual
personality clues of other team members.
Time Considerations
Time shifts are an important issue as well. All teams require both asynchronous (done
alone without coordination with other team members) and synchronous (done together
in time and place) tasks.

Structure and Ritual

This is the engine of a project. It is the framework to which the team personalities will
react and anchor

Provide a Strong Framework

One of the most important things a leader can do is to set up a project office as a hub of
information about the project. This is where the P-CMM project documents can reside,
along with the working documents of the team. A project office is a concept, not
necessarily a physical place.
A decentralized project office is most common, but not best. It means that
documents and tools are geographically dispersed into different team members'
control.
A centralized project office is a concept of commonality and colocation. It may

involve only one geographic location under one team member's control; be a

physical space such as a project lab, conference room, or office; or be a virtual

space on a remote system.

Practice Rituals
For project teams, this means that a regular schedule of exchanges (the

synchronous part of projects) and "free" time (the unstructured part set aside

for individual task accomplishment) is required. The leader must define this

pattern and communicate it to the team as early in the project as possible.

Peoplework, Not Paperwork

The amount of framework to provide for a given project is a matter of

judgment for the team leader.

6.5 Providing the Total Solution

The total solution requires more than just technology and process today.

Referring again to Fred Brooks' "No Silver Bullet," no single tool or

approach will solve all problems.

Managing Creativity

Creativity thrives in an environment that is safe and bounded. Children at play on a gym
in a field with no boundaries show a reluctance to explore the area, clinging to the gym in
the center because they fear violation of an unidentified boundary.

When to Lead and When to Manage

Management is about following policies and procedures, and doing things right as an
agent of the project and organization. It is about execution and compliance. It is getting
the project team to perform at its best to pursue the project's goal.
Situational leadership model
Chapter 7-Defining the Goal and Scope of the
Software Project
To define the goal and scope of the project so clearly that measuring progress is easy and
there is no ambiguity that the project goals have been achieved.

There are several techniques and tools available to the project manager to

define the goal and scope clearly. Among them are the Is/Is Not technique and

the S.M.A.R.T. goal checklist.

7.1 Project Planning

Project planning is the process that lays the framework for how the project will be run. It
includes the definition of the project's objectives, selection of an appropriate life cycle, and
establishment of the policies, procedures, and processes necessary to achieve the
objectives.
Project processes:

Describe how the project team will define and execute the product development

Processes.

Product:

processes: Describe how the software product will be built.

Project Process Integration Map
why
Every project needs a good reason to exist, and this step ensures that there is

at least one. Using business analysis suitable for the organization, the project

manager should perform an opportunity analysis and prepare a return on

investment (ROI) statement for the project.

What

When a good reason is identified for proceeding with the software project, the

goal and scope of the project can be defined to distinguish it from ongoing

operations
The project charter(a written statement of rights) has two purposes:

1. To formally document the existence of a software development project and to

separate the work of the project from ongoing operations such as maintenance
and support.

2.To obtain management approval for the work to be done and to get

commitment for the resources to do it.

The charter may take the form of a legal contract and statement of work

(SOW) for external work to be executed by a third party outside the project

manager's direct control.

How

The authority granted by charter approval, the software project manager

can employ the many other software engineering and people skills needed to

define the product and manage a team to develop and deliver it. This is the

heart of software project planning. The major work product of this step is the

software project management plan (SPMP).

The SPMP explains (in an appropriate level of detail for the maturity of the performing
organization) how the life cycle steps will be performed.

Do It

When the SPMP is completed and approved (by the customer or by management), the team
can execute the plan, following the life cycle steps chosen for this particular project instance.
Did It

Commensurate with good process management, an evaluation step should be

performed before closing out the software development project. This is the

post-performance analysis (PPA) step, and it results in a PPA report

documenting lessons learned and recommendations for project or product

process improvements for the next similar project that the organization

Attempts.

The Project Management Institute (PMI ) cites five processes necessary for

any project, or phases within a project: initiating, planning, executing,

controlling, and closing,

The initiating processes are where the why step is handled. It includes enough of the what step
to describe the project at a high level. The rest of the what step and the entire how step are
handled in the planning processes. The do it step is composed of the executing and controlling
processes, and the did it step is covered by the closing processes.

7.2 What Is "The Goal"?

Every project needs at least one goal. Most have multiple goals. Sometimes

these are called the project objectives or are collectively referred to as the

mission of the project

The software project manager always has at least one goal: to finish the

project. This comes from the definition of what a software project is: a unique,

temporary endeavor with defined start and end dates to achieve one or more

objectives within the constraints of cost, schedule, and quality performance.

For example, a software development project

to build a Web-based timesheet data entry system may be viewed as:

● An internal tool development effort by the engineering manager;
● A training exercise by the recently hired programmers;
● A requirement before starting a new software development project for an
● external customer by the general manager;
● A marketing tool to demonstrate the capabilities of the development team by the
sales staff.

Setting Clear Objectives

the objectives in the goal statement have certain

characteristics that make it clear. Most objectives tell what. The best ones also

imply why. Good project objectives are:

 ● Focused on deliverables, not just processes
● Measurable and testable
● Action-oriented
● Conversational
● Doable (within your authority)
● Communicated

7.3 What Is the Scope of Work?

Often part of the SPMP, but sometimes a separate document (or several), is

the scope of work, statement of work (SOW), or, sometimes, statement of

requirements (SOR),The SOW contains just enough specific details and

specifications of components packaged so that they can be given to a
subcontractor for execution.
Setting Boundary Conditions
It is usually easier for a project team to identify what the software project

should include than what it should not include. The goal and objectives

statements describe what is to be part of the final project scope.

Use the Is/Is Not technique to help draw crisp boundaries around the project

scope and its objectives individually. This technique is simple. For each goal or

objective,
Is:
● internal;
● a timesheet data-entry system;
● Web-based;
● for the engineering department;
● to be deployed before we begin the next major external project;
● to be successful per existing application deployment criteria;
● to serve as a training project to familiarize the team with the new project
● management process.
Is not:
● intended for use by other departments or external customers;
● a full-blown labor accounting system;
● intended to be accessed by PDAs or wireless Web cell phones;
● required to interface to existing earned value management programs such as
MS Project;
● to be in beta test mode when the next external project begins;
● to use outside contractors for development.
7.4 Project Charter

A charter includes the business need, the product description, and major

Assumptions.

Project Charter Contents

The charter may sometimes be called by other names, such as the project

initiation document (PID), scope baseline, or just contract (usually for external

work).

The charter contains the why and what of the project processes discussed at

the beginning of this chapter

 ● Objectives: What the desired outcomes are
● Functions: Major features and/or processes
● Performance: Generalized specifications
● Constraints: Limitations of the environment
● Scope: Boundaries of the project
● Costs/benefits: Rough order of magnitude estimates

7.5 The Software Project Management Plan

This is the most important document of a project. It defines how the project is

supposed to be executed and what it is going to produce.

The SPMP should contain definitive project information that

includes:

Charter: Elements from the project charter that define the project,

including deliverables

Organization: How the project will be organized and executed to produce

the deliverables

Process: Details of the managerial and technical processes that will be

used during the project

Work breakdown: Work breakdown and work package details

Schedule: Schedule, dependencies, and resources

Budget: Budgetary and definitive estimates

Major Elements of SPMP
The project charter information is integrated into appropriate sections of the

SPMP. The rest of the document contains sections that include these:
● Project overview and deliverables
● Project organization
● Managerial processes
● Technical processes
● Work packages, schedule, and budget
How These Project Planning Documents Relate

Relationship of Planning Documents

the flow of information starts with defining the goal, objectives, and high-level
scope of the proposed software project. These items are usually presented in a
project charter document.
Chapter 8- Creating the Work Breakdown Structure
8.1 WBS is a hierarchical list of the work activities required to

complete a project. It will include managerial, administrative, integral, or

developmental activities for:

● Doing the software development;
● Managing the project;
● Providing support for all of the project's activities;
● Any other activities required to meet the objectives of the project and the

customer requirements, such as the creation of documents, training

programs, tools for development, acquisitions, travel, and so on.

The WBS is a description of the work to be performed, broken down into its

key components, to the lowest level. By partitioning the project into

manageable pieces this way, each component can be sized

and its effort can be estimated.

A product-oriented WBS contains process steps to build the product, organized

around the product components. It drives the planning for the what and how

steps, and provides the foundation for tracking of work activities, cost, and

schedule in the do it step by giving the engineer or manager a global view. It

The WBS for the following three project activities:
Cost estimating
To make sure that all activities get estimated;
To make sure that each element of the estimate corresponds to a necessary activity;
To "roll up" costs of individual elements into total costs for sub elements and for the
system as a whole.
Cost accounting
To assign work and "charge it" to appropriate cost centers based on specific WBS
elements;
To determine the actual cost of each element.
Schedule performance
To monitor which activities are complete;
WBS Relationship to Cost Control
Sample Work Breakdown Structure Shown as a Tree
Sample Work Breakdown Structure Shown as an
Indented List
A WBS may be created for the two most common views of the project:

A product view depicting hierarchical relationships among product

elements (routines, modules, subsystems, etc.). But don't confuse this with

a bill of materials.

A project view depicting hierarchical relationships among work activities

(process elements). This is often divided along organizational lines.

Both sets of elements and activities need to be considered in sizing and

estimating the software to be built

8.2 Approaches to Building a WBS
A WBS can be organized in many ways, but it is usually best to arrange the

activities around major work products and customer deliverables that will

satisfy the customer's requirements.

the hierarchical "tree" of information is:

● the compiler.
● the basic parts of the compiler.
● the steps of the development process to build the basic parts of the compiler.
Several Possible Arrangements for a Work
Breakdown Structure, Shown as an Indented List
Courtesy
The WBS can be created from the top down or from the bottom up, as

illustrated.The top-down approach involves successive

decomposition. The bottom-up approach uses brainstorming and affinity

diagramming.
8.3 Defining Project Milestones
A milestone is a significant event in a project, usually associated with a major work product
or deliverable. They mark passage points in the journey toward completion, and every
project should have enough of them, spread evenly throughout the schedule so that it is
easy to measure achievement toward the final goal.

8.4 Creating Work Packages

The lowest level of the WBS is where the work gets done. These are the

"leaves" on the tree representation, or the farthest indented activities in the

indented list. These are called work packages and usually result in a work

product being delivered.

The contents of a work package may include:

Description of the work product expected software element to be produced;

The staffing requirements who or how many people will do this activity;

Names of responsible individual(s) who is responsible for seeing that it is

completed;

The scheduled start and end dates when the activity is expected to start

and to end;

The budget assigned (dollars, hours, or other unit) the effort estimate for

the activity;

The acceptance criteria for the work defect level or other quality measure.
8.5 Building a WBS for Software
The WBS is the key work product needed to do software project estimating.

Here are five steps to constructing a WBS for a software project:

1. Identify the work concerning the software product (separate from hardware and
work processes).

Find any higher system WBS (separate the software from other systems and
components).

Determine the software WBS architecture (how to organize this software product
and project).

Populate the software WBS architecture (identify all the parts and activities to
produce them).

Determine cost categories for software (prepare for estimation activities).

Identify the Work Concerning Software
Many possible source documents might be available:

SOW (usually the best item to start with);

Specifications, concept of operation;

Requirements documents of many kinds;

Design documents;

Standards (internal and external);

Customer conversations;

Test criteria or expectations.

Find Any Higher System WBS
Determine whether there is a WBS for any higher system (higher project or

program) and how the software fits in.

Example Higher Level WBS Showing Where

Software Might Be Placed
Determine the Software WBS Architecture
Example WBS Architectures for Software from
Populate the Software WBS

Populate the chosen WBS structure with activities that address the work

identified in the available documentation (SOW, etc., )

Example Cross-Reference Matrix for Software from

Determine Cost Categories for Software
Determine the cost-estimating category for each element in the WBS. This

final step is not always necessary for every project, but it will be important for

those that track unit-level costs in a WBS