Project Planning Objectives, Primary Planning Steps

<< Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks

Tools and Techniques for SDP, Outputs from SDP, SDP Execution >>

Software Project Management (CS615)

LECTURE # 23

4. PLANNING

Planning is one of the most important management activities and is an ongoing effort

throughout the life of the project. Software project management begins with a set of

activities that are collectively called Project Planning.

Preliminary planning starts on day one even in the pre-project phase

It should not be conducted "in secret"

It needs buy-in and approval

4.1

Project Planning Objectives

The objective of software project planning is to provide a framework that enables the

manager to make reasonable estimates of:

Resources

Cost, and

Schedule

These estimates are made within a limited time frame at the beginning of a software

project and should be updated regularly as the project progresses.

In addition, estimates should attempt to define best case and worst-case scenarios so

that project outcomes can be bounded.

Planning is one of the most important management activities and is an ongoing effort

throughout the life of the project.

Software project management begins with a set of activities that are collectively

called Project Planning.

The software project planner must estimate following things before a project begins:

How much will it cost?

How long will it take?

How many people will it take?

What might go wrong?

4.2

Project Planning - Definition

142

Software Project Management (CS615)

What is it? Software project planning involves estimation - your attempt to

determine how much money, how much effort, how many resources, and how

much time it will take to build a specific software-based system or product.

Who does it? Software Project Managers- Using information solicited from

customers and software engineers and software metrics data collected from past

projects. It is advisable to generate your estimates using at least two different

methods (as a cross check). Problem complexity and risk are considered before a

final estimate is made.

What is the work product? A Simple table delineating the tasks to be

performed, the functions to be implemented and the cost, effort and time involved

for each is generated. A list of required project resources is also produced.

How do I ensure that I've done it right? That's hard, because you won't really

know until the project has been completed. However, if you have experience and

follow a systematic approach, generate estimates using solid historical data, create

estimation, data points using at least two different methods, and factors in

complexity and risk. You can feel confident that you've done a right job to

achieve the targets.

4.3

Project Planning: Key Tasks

1. Set goal and scope

2. Select lifecycle

3. Set organization team form

4. Start team selection

5. Determine risks

6. Create WBS

7. Identify tasks

8. Estimate size

9. Estimate effort

10. Identify task dependencies

11. Assign resources

12. Schedule work

4.4

Project Management Process

The software development management section, which describes the organization and

resources that will be used to develop the product, should always be included. The

management section discusses how the facilities will be organized to support the

development effort. This is one of the sections that provide much of the detail needed

to prepare the heart of the development plan, namely the development schedule. The

schedule provides answers to two basic planning questions: what and when, while

much of the remaining sections discuss how.

143

Software Project Management (CS615)

The discussion in the how sections provides information on how the project will be

organized, how risks will be handled, how reviews will be conducted, how standards

will be applied, what development methodologies will be used, and how the product

will be tested.

It is usually best to leave the completion of the schedule section for last. The

schedule, being dependent on most of the other sections, is the most sensitive part of

the development plan. After a first draft of the development plan is ready, an initial

development schedule can then be prepared. As we shall see, the schedule will then

be further refined as the development plan goes through progressive iteration.

Why is the system being developed? The answer to this question enables all parties

to assess the validity of business reasons for the software work. Stated in another

way, does the business purpose justify the expenditure of people, time and money?

What will be done, by when? The answers to these questions help the team to

establish a project schedule by identifying key project tasks and the milestones that

are required by the customer.

Who is responsible for a function? Earlier in this chapter, we noted that the role and

responsibility of each member of the software team must be defined. The answer to

this question helps accomplish this.

Where they are organizationally located? Not all roles and responsibilities reside

within the software team itself. The customer, users, and other stake" holders also

have responsibilities.

How will the job be done technically and managerially? Once product scope is

established, a management and technical strategy for the project-must be defined.

How much of each resource is needed? The answer to this question is derived by

developing estimates based on answers to earlier questions.

The definition phase focuses on what. That is, during definition, the software

engineer attempts to identify what information is to be processed, what function and

performance are desired, what system behavior can be expected, what interfaces are

to be established, what design constraints exist, and what validation criteria are

required to define a successful system. The key requirements of the system and the

software are identified. Although the methods applied during the definition phase will

vary depending on the software engineering paradigm (or combination of paradigms)

that is applied, three major tasks will occur in some form: system or information

engineering, software project planning and requirements analysis.

The development phase focuses on how. That is, during development a software

engineer attempts to define how data are to be structured, how function is to be

implemented within a software architecture, how procedural details are to be

144

Software Project Management (CS615)

implemented, how interfaces are to be characterized, how the design will be

translated into a programming language (or nonprocedural language), and how testing

will be performed. The methods applied during the development phase will vary, but

three specific technical tasks should always occur: software design, code generation,

and software testing.

The support Phase focuses on Change associated with error correction, adaptations

required as the software's environment evolves, and changes due to enhancements

brought about by changing customer requirements. The support phase reapplies the

steps of the definition and development phases but does so in the context of existing

software. Four types of change are encountered during the support phase:

1. Correction

Even with the best quality assurance activities, it is likely that the customer will

uncover defects in the software. Corrective maintenance changes the software to

correct defects.

2. Adaptation

Over time, the original environment (e.g., CPU, operating system, business rules,

external product characteristics) for which the software was developed is likely to

change. Adaptive maintenance results in modification I the software to

accommodate changes to its external environment.

3. Enhancement

As software is used, the customer/user will recognize additional functions that

will provide benefit. Perfective maintenance extends the software beyond its

original functional requirements.

4. Prevention

Computer software deteriorates due to change, and because ( this, preventive

maintenance, often called software reengineering, must be conducted to enable

the software to serve the needs of its end users, in essence, preventive

maintenance makes changes to computer programs so that they ca be more easily

corrected, adapted, and enhanced.

In addition to these support activities, the users of software require continuing

support. In-house technical assistants, telephone-help desks, and application-

specific Web sites are often implemented as part of the support phase.

4.5

Planning Puzzle

Planning is one of the most important management activities and includes the

preparation of good estimates, the maintenance of the development schedules and the

efficient assignment of personnel.

i. Scope Planning

145

Software Project Management (CS615)

Scope planning is the process of progressively elaborating and documenting the

project work (project scope) that produces the product of the project.

ii. Risk Planning

Risk management planning is the process of deciding how to approach and plan

the risk management activities for a project. It is important to plan for the risk

management processes that follow to ensure that the level, type, and visibility of

risk management are commensurate with both the risk and importance of the

project to the Organization.

iii. Schedule Development

Analyzing activity sequences, activity durations, and resource requirements to

create the project schedule.

iv. Cost Estimating

Developing an approximation (estimate) of the costs of the resources required to

complete project activities

v. Project Control

Project Control may be considered to be one of the continuous objectives for the

project manager. As such he is responsible for taking remedial actions, within

the defined terms of reference, to correct potential problems or taking risk

avoidance measures. The prime objective is to protect the integrity of the project

at all times.

4.6

Primary Planning Steps

Once the scope of the project has been defined in the Terms of Reference, the project

enters the detailed planning phase. This involves the creation of a:

Project Plan (outlining the activities, tasks, dependencies and timeframes)

Resource Plan (listing the labor, equipment and materials required)

Financial Plan (identifying the labor, equipment and materials costs)

Quality Plan (providing quality targets, assurance and control measures)

Risk Plan (highlighting potential risks and actions taken to mitigate them)

Acceptance Plan (listing the criteria to be met to gain customer acceptance)

Communications Plan (listing the information needed to inform stakeholders)

Procurement Plan (identifying products to be sourced from external suppliers).

At this point the project has been planned in detail and is ready to be executed

By this stage, the benefits and costs of the project have been clearly documented, the

objectives and scope have been defined, the project team has been appointed and a

formal project office environment established. It is now time to undertake detailed

planning to ensure that the activities performed in the execution phase of the project

are properly sequenced, resourced, executed and controlled.

146

Software Project Management (CS615)

1. Develop Project Plan

The first step is to document the Project Plan. A 'Work Breakdown Structure'

(WBS) is identified, which includes a hierarchical set of phases, activities and

tasks to be undertaken on the project. After the WBS has been agreed, an

assessment of the effort required to undertake the activities and tasks is made. The

activities and tasks are sequenced, resources are allocated and a detailed project

schedule is formed. This project schedule will become the primary tool for the

Project Manager to assess the progress of the project.

2. Develop Resource Plan

Immediately after the Project Plan is formed, it is necessary to allocate the

resources required to undertake each of the activities and tasks within the Project

Plan. Although general groups of resources may have already been allocated to

the Project Plan, a detailed resource assessment is required to identify the:

Types of resources (labor, equipment and materials)

Total quantities of each resource type

Roles, responsibilities and skill-sets of all human resources

Items, purposes and specifications of all equipment resource

Items and quantities of material resource

A schedule is assembled for each type of resource so that the Project Manager can

assess the resource allocation at each stage in the project.

3. Develop Financial Plan

Similar to the Resource Plan, a Financial Plan is prepared to identify the quantity

of money required for each stage in the project. The total cost of labor, equipment

and materials is quantified and an expense schedule is defined which provides the

Project Manager with an understanding of the forecast spending vs. the actual

spending throughout the project. Preparing a detailed Financial Plan is extremely

important as the project's success will depend on whether or not it is delivered

within the 'time, cost and quality' estimates for this project.

4. Develop Quality Plan

Meeting the quality expectations of the customer is critical to the success of the

project. To ensure that the quality expectations are clearly defined and can

reasonably be achieved, a Quality Plan is documented. The Quality Plan:

Defines what quality means in terms of this project

147

Software Project Management (CS615)

Lists clear and unambiguous quality targets for each deliverable. Each quality

target provides a set of criteria and standards which must be achieved to meet

the expectations of the customer

Outlines a plan of activities which will assure the customer that the quality

targets will be met (i.e. a Quality Assurance Plan)

Identifies the techniques used to control the actual level of quality of each

deliverable as it is built (i.e. a Quality Control Plan).

Finally, it is important to review the quality not only of the deliverables produced

by the project but also of the management processes which produce them. A

summary of each of the management processes undertaken during the execution

phase is identified, including Time, Cost, Quality, Change, Risk, Issue,

Procurement, Acceptance and Communications Management.

5. Develop Risk Plan

The foreseeable project risks are then documented within a Risk Plan and a set of

actions to be taken formulated to both prevent each risk from occurring and

reduce the impact of the risk should it eventuate. Developing a clear Risk Plan is

an important activity within the planning phase as it is necessary to mitigate all

critical project risks prior to entering the Execution phase of the project.

6. Develop Acceptance Plan

The key to a successful project is gaining acceptance from the customer that each

deliverable produced meets (or exceeds) his/her requirements. To clarify the

criteria used to judge each deliverable for customer acceptance, an Acceptance

Plan is produced. The Acceptance Plan provides the criteria for obtaining

customer acceptance, a schedule of acceptance reviews within which customer

acceptance will be sought and a summary of the process used to gain acceptance

of each deliverable from the customer.

7. Develop Communications Plan

Prior to the Execution phase, it is also necessary to identify how each of the

stakeholders will be kept informed of the progress of the project. The

Communications Plan identifies the types of information to be distributed, the

methods of distributing information to stakeholders, the frequency of distribution

and responsibilities of each person in the project team for distributing information

regularly to stakeholders.

8. Develop Procurement Plan

The last planning activity within the Planning phase is to identify the elements of

the Project which will be acquired from external suppliers to the project. The

Procurement Plan provides a detailed description of the Products (i.e. goods and

services) to be procured from suppliers, the justification for procuring each

148

Software Project Management (CS615)

product externally, as opposed to from within the business, and the schedule for

procurement. It also references the process for the selection of a preferred supplier

("Tender Process") and the process for the actual order and delivery of the

procured products ("Procurement Process").

4.7

The Software Development Plan (SDP)

The project development plan is one of the first formal documents produced by the

project. Within this document, the project manager describes in detail:

How the project will be developed?

What resources will be required?

How these resources will be used?

The project development plan assures that the development of the project is well

charted before the main development activities begin. In -addition to the basic

development schedule, the plan addresses such issues as:

The timely provision of equipment and tools so that they are available to

developers when needed.

The availability of staff to perform the development tasks in accordance with

the schedule.

Provision of contingency plans in the event that project risks materialize

The designation .of duties within the development team, and the assignment

of these duties to the team members.

Preparing the project plan for a software project helps you ensure that the specified

requirements and objectives are met successfully. It is a collation of all planning

activities that have happened for a software project. This includes activities such as

design and analysis, activity definition, risk planning, and cost estimation. To create

the plan, you assess all planning activities, organizational policies regarding the

creation of the project plan and assumption and constraints for the project. To

implement the software project plan, you require management skills, such as

leadership, communication, and problem solving, along with the basic knowledge

about the software. You also need to ensure that the senior management bf the

company has authorized work on the software project. Knowledge management

techniques help you to make informed decision regarding the project plan.

After the project plan is executed, you manage the changes to it in such a way that the

performance measurement baselines are not impacted, To manage the project plan

effectively you monitor the project plan, periodic performance status reports, and

requests for change. The primary tool that you can use to control the changes in the

project plan is the change control mechanism: This is a set of formal procedures for

changing the project plan.

4.7.1

Software Development Plan (SDP) Information needs

149

Software Project Management (CS615)

The Project Plan is a vital part of the project initiation stage. The plan

should normally contain the following information:

1. Introduction and status of the plan

2. The authorisation procedures

3. Statement of project objectives

4. Statement of requirement

5. Deliverables in the project

6. A Work Breakdown Structure

7. The project milestones

8. The resource requirements

9. Interdependencies of work

10. The timetable of events

11. Staffing, organisation and responsibilities

12. Development methods and toolsets to be used

13. Source documentation

14. Resource and financial summary

This information creates the generation of a Project Book (log). The log

should be in a loose-leaf binder with clearly identified sections and version

control exercised over the documentation sets. These logs are now often

retained as computer file, which enables a greater level of security to be

maintained over them and version control to be established as an automatic

feature.

4.7.2

Software Development Plan (SDP) Steps/items required

The contents of the project development plan may be adapted to the size of

the project; it may be a large document or just a few pages. Table 1 presents

an outline of some of the subjects covered in the project development plan.

Not all subjects in Table 1 are applicable to all projects. For example, many

projects do not administer their own budget. Some organizations have a

financial officer responsible for the administration of project budgets. The

interface with external sources is another area riot applicable to all projects.

The term, external sources covers such activities as interfacing with

subcontractors, vendors and representatives of the customer.

Many standards have been produced for the project development plan. The

formal structure or the project development plan document differs,

depending on the actual documentation standard used. For example, the US

DOD standard 2167 provides the option of describing the testing,

configuration management and quality assurance plans in three separate

documents. For large projects, this option can become a requirement.

150

Software Project Management (CS615)

The IEEE standard 1058.1 describes what is referred to as the software

project management plan, which is essentially the same as the project

development plan. This standard is largely compatible with the 2167 project

development plan, although it is significantly less detailed.

This standard, too, provides the option of including configuration

management and quality assurance plans, or of describing them in separate

documents. The project development plan should be prepared as a

standalone document, in the sense that it should be read and understood

without the need to refer to other documents.

A general overview of the project is therefore usually included in the first

section of the document. References for additional detail, of course, should

always be provided, including pointers to such documents as the project

contract, the concept document or the market research analysis.

151

Software Project Management (CS615)

Table 1: Software project development plan items

1. System overview

2. Software development management

Project organization and resources

Development facilities

Project organizational structure

Personnel

3. Schedule and milestones

Scheduled activities

Milestones and baselines

Activity network diagrams

System component source

Budget administration

Milestone payments

Major budgetary expenditures

Expenditure authorization procedure

4. Risk analysis

5. Security

6. Interface with external sources

7. Procedure for formal reviews

8. Corrective action process

9. Problem change report

10. Software engineering

Standards and procedures

Development methodology

Development resources

Personnel - qualifications and function

11. Testing procedure

12. Software configuration management

13 Software quality assurance

4.7.3

Inputs to SDP

Project plan development uses the outputs of the other planning processes,

including strategic planning, to create a consistent, coherent document that

can be used to guide both project execution and project control. This process

is almost always iterated several times. For example, the initial draft may

include generic resource requirements and an undated sequence of activities

while the subsequent versions of the plan will include specific resources and

explicit dates.

1. Other planning outputs. All of the outputs of the planning processes in

the other knowledge areas are inputs to developing the project plan. Other

planning outputs include both base documents, such as the WBS, and the

152

Software Project Management (CS615)

supporting detail. Many projects will also require application area-specific

inputs (e.g., most major projects will require a cash-flow forecast).

2. Historical information. The available historical information (e.g.,

estimating data-bases, records of past project performance) should have

been consulted during the other project planning processes. This

information should also be available during project plan development to

assist with verifying assumptions and assessing alternatives that are

identified as part of this process.

3. Organizational policies. Any and all of the organizations involved in the

project may have formal and informal policies whose effects must be

considered. Organizational policies that typically must be considered

include, but are not limited to:

Quality management--process audits, continuous improvement

targets

Personnel administration--hiring and firing guidelines, employee

performance reviews

Financial controls--time reporting, required expenditure and

disbursement reviews, accounting codes, and standard contract

provisions.

4. Constraints. A constraint is an applicable restriction that will affect the

performance of the project. For example, a predefined budget is a

constraint that is highly likely to limit the team's options regarding scope,

staffing, and schedule. When a project is performed under contract,

contractual provisions will generally be constraints.

5. Assumptions. Assumptions are factors that, for planning purposes, are

considered to be true, real, or certain. Assumptions affect all aspects of

project planning, and are part of the progressive elaboration of the project.

Project teams frequently identify, document, and validate assumptions as

part of their planning process. For example, if the date that a key person

will become available is uncertain, the team may assume a specific start

date. Assumptions generally involve a degree of risk.

153

Table of Contents: