copyright © 1995-2004, dennis j. frailey, all rights reserved day 4, part 1, page 1 1/11/2004 day...

Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, 1/11/2004

Day 4, Part 1

Software Development Plans


Outline (slide 1 of 2)

• The Contents of a SW Development Plan• The Role of a Software Development Plan

• The Role of the SW Project Manager

• Reviewing Assumptions, Estimates & Commitments

• Setting Expectations

• Using the SEI CMM to set the stage for a Successful Software Project


Outline (slide 2 of 2)

• Planning Reviews and Audits

• Planning Subcontractor Management

• Facilities and Staffing Plans• Maintaining an Effective Plan• Summary


The Overall Planning Cycle

AnalyzeJob

Manage Risks

Execute

GenerateDetailed Plans

GenerateInitial Plans

Measure, Manage Productivity and Quality


Detailed Planning - Processes

EstimateSize

EstimateEffort and

Cost

EstimateSchedule

Evaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK


The Contents of a Software Development Plan


Warning from Dilbert

“There are two major steps to building a business plan:

1. Gather information

2. Ignore it”

Adams, The Dilbert Principle



2. Ignore it”



Your plan consists of virtually everything you produce as a result of

planning


“software development plan”definition

“The accumulation of all plans and related artifacts generated during the planning

process”Prototype

Final DesignBuild

Design

PrototypeFinal Design

Build

Design


Build

Design


Build

Design


Build

Design


Build

Design


Build

Design

CodeDesign Test

Build

DeliveryContract


Build

Design


Build

Design

technical interchanges

contract issues

legal issues

Copyright © 1995-2004, Dennis J. Frailey, All Rights ReservedDay 4, Part 1, 1/11/2004

Your Plan is a document containing a selected group

of the principal planning artifacts


“Software Development Plan”definition

“A document describing the principal plans for developing software”


The Plan within a plan

SoftwareDevelopment

Plan(formal

document)

software development plan

SoftwareStandards

andProcedures

WBS

PoliciesFacilities

Estimates

StaffingplanSchedule


Why Create a FormalSoftware Development Plan?

• To help you manage the project

AND

• To show others that you can manage the project


To Show that You CanManage the Project ...

• The Plan demonstrates that sufficient planning has been done

• The Plan shows that you understand the project, the problem, the risks, the criteria for completion, the methods for developing software, and the customer expectations


To Help YouManage the Project ...

•The Plan forces you to answer questions that might otherwise be left unanswered

How will we set up our software library?

How will we track progress on the

data base development?


To Help You Manage ...

• The Plan communicates your plans to concerned parties - your staff, other organizations, subcontractors

• It provides a common framework from which all participants can make their individual plans


To Help You Manage ...

• The Plan documents assumptions, contractual understandings, mutual agreements, etc.

• It helps you to remember what you planned

• It helps you manage risks by recording your rationale, backup plans, expectations, etc.


Don’t Overdo the Formal Plan

• The Formal Plan should contain …… a guide to the software development

approach

… a guide to your management approach

... information that is not likely to change frequently during the project

… information that is necessary to evaluate and understand your plan


The exact content of the formal plan will depend on specifics of your contract, organization,

project size, customer, management style, etc.

The exact content of the formal plan will depend on specifics of your contract, organization,

project size, customer, management style, etc.

The Formal PlanShould Not Contain ...

… detailed information about the product’s technical characteristics, architecture, or design approach

… detailed schedules, cost estimates, etc.… excessive detail about the process and

methods you will use, especially if it is likely to change often


The Formal Plan is like the Textbook for your Project

• You learn from it• You use it to teach new employees

all about the project• You refer to it from time to time• But most people do not use it on a

daily basis


The Formal Plan Should Cover ...

… a little about the product– A summary that shows its characteristics,

components, and performance goals

… more about the project– Focusing on organization, structure, and

management

… a lot about the process– In detail, including all aspects of how

software will be developed and managed


A Checklist for an SDP

Product Project Process

Description Summary Basic Details

Metrics &Risk Mgt

Basic Details Details

Other PlanI nformation

A smallamount

A modestamount

A largeamount


Where Does This Information Come From?

• Job Analysis• Initial Planning• Estimating• …• In other words, all of

the planning activities


A Closer Look at the Contents of a

Software Development Plan


Product Information - The Application and the

System• A summary description of the

application and the system, such as:– Scenarios describing system use– An overview of the architecture,

including the major components– Processors and their functions– Brief discussions of the technologies

involved or any unusual aspects– Summary of any key performance

objectives and system constraints


Product Information - The Software

• For each software product– Its type and characteristics– Its function, in relation to the other

software and the rest of the system– Its architecture, including the major

software components and interfaces– Processor(s) and other system

elements the software will use– Programming language(s)– Rough size estimate


Metrics and threshold values are discussed in another course.

Metrics and threshold values are discussed in another course.

Product Information - Risk Management and Metrics

• Key risks or performance goals• For each risk or performance goal

(such as speed, memory size, etc), identify– Objectives, constraints and concerns– Metrics you will use to monitor – Threshold values requiring management

action


Anything that tells you whether the product is likely to meet its performance

requirements or encounter significant risks

Anything that tells you whether the product is likely to meet its performance

requirements or encounter significant risks

Sample Product Metrics

• How fast the software is expected to run

• Unused processing capacity• Memory size• I/O channel or network utilization


Project Information - General

• The nature of the project– Type of contract, if any– Source of funding– Reporting structure– Interfaces with customer

• Logistics– Location(s) of organizations– Facilities you will use– Security considerations, if any


Project Information -Schedule

• Lifecycle model, if any• Integrated master plan (at a

summary level - major tasks to be performed)

• Integrated master schedule– Major milestones and goals– Top level schedules for major tasks– Key reviews and milestones or gate

points


Project Information - Organization

• Organizational Breakdown Structure– Key roles and responsibilities– Reporting structures within the project– Key relationships and communication

paths– Skills required for key roles

• Work Breakdown Structure• Subcontract and Co-Contract

relationships (if applicable)


Project Information - Risk Management and Metrics• Key risks and project goals should

be identified• For each risk or goal, indicate:

– Objectives, constraints and concerns– Metrics you will use to monitor – Threshold values requiring

management action


Anything that tells you whether the project is likely to meet its cost,

schedule, or other goals

Anything that tells you whether the project is likely to meet its cost,

schedule, or other goals

Sample Project Metrics• What work tasks are complete (such

as requirements defined, modules designed, units coded or tested)– Compare with plans

• Expenditures of effort or funds– Compare with budgets

• Unplanned turnover rates


Process Information

This forms the bulk of the content of a formal software development plan. Typical information includes:– Methods and processes for software

development, evaluation and testing– Milestones and reviews– Subcontractor management methods– Tools to be used


Additional Process Information

• Reuse plans and approaches • Process improvement techniques• Risk analysis and management

techniques• Structure and procedures of

software development libraries• Processes for support activities such

as quality assurance and configuration management


Process Information is Identified Throughout the

Project • Much of it can be established during

planning, at least at a high level• But many of the details are typically

not fully worked out until the project is underway

• And such details are not necessary to understand your plan


Process Information - Risk Management and Metrics• Key risks and process goals should

be identified• For each risk or goal, indicate:

– Objectives, constraints and concerns– Metrics you will use to monitor – Threshold values requiring

management action• Some process metrics are used to

identify the causes of project and product problems


Typical Plan Supplements• Project-specific standards, detailed

procedures and methods– Often found in an SSPM (software

standards and procedures manual)• Detailed schedules • Shoploads • Specific assignments of people and

resources to tasks• Details of SW Engineering

Environment (SEE)


Anything that tells you whether the process is being followed correctly or is

achieving its objectives

Anything that tells you whether the process is being followed correctly or is

achieving its objectives

Sample Process Metrics

• How well we are finding problems during inspections and reviews

• Defect levels and defect correction levels

• Amount of rework due to errors


The Role of the Software Project Manager


You Have Four Customers1) The Project Manager

– Wants you to deliver a product on budget and on schedule

2) The Company– Wants you to meet corporate goals and

follow company standards

3) The End User– Wants a quality product, on time, at low

cost

4) The Software Development Staff– Wants a rewarding job and career


Do what is best for

theproject

Do what is best for

the employee

Do what is best for the end

user

Do what is best for

the company

You May Have Conflicts


To Succeed, You Must ...

• Understand what each of them expects– What they think you should do for them

• Understand the perspective of each– Why they want what they want

• Establish communication with each of them and develop mutual understanding and respect


The Project Manager Wants ...• Effective management of the

software project– Accurate estimates & realistic plans– Participation in project level planning– Timely reports on project status– Early warnings of problems– Effective coordination with the rest of

the project• Satisfied customers

– Maintaining schedule and budget


Building a Good Relationship with the Project Manager

• Ask what will help them the most– Information and interaction needed from you -

when and in what format

• Learn about priorities - ask them to define success for the sw project

• Document commitments & agreements• Support the project manager

– Don’t deceive or cover up the truth– No surprises! -- Identify risks early

• Admit mistakes and ask for help


The Company Wants ...• Accurate estimates and plans• Periodic reviews of project status• Maintaining schedule and budget• Following company standards,

processes, and procedures• Timely notice of staffing and other resource needs• Prudent use of resources• Happy customers

I’m hereto help.

CorporateMandate

…..


Building a Good Relationship with the Company

• Follow company standards– or tailor to your needs

• Understand and support company goals and values

• Understand how the company handles finances and measures performance

• Use resources wisely and prudently• Cooperate with company-imposed

mandates


Remember - the customer pays the bill

Remember - the customer pays the bill

The End User Wants ...

• High quality products• Ease of use• On-time delivery• Low costs• Low maintenance costs• Keeping commitments


Building a Good Relationship with the End User

• Don’t miss milestones– Especially the early ones

• Don’t give excuses or act defensively if things have gone wrong – Accept responsibility

• Accept their suggestions and invite their participation

• Meet commitments and promises• Explain what you can do, not what you

can’t


• Good organization, effective project structure, and good management– Guidance without micro-management

• Good working conditions– Minimal interruptions and disruptions– Removal of barriers– Interesting work– Good facilities

• Career growth– Learning & Recognition

The Staff Wants ...


Building a Good Relationship with the Staff

• Learn and apply team building skills• Use consensus techniques• Let the staff define processes and

measurements where possible, or tailor standards in these areas

• Acknowledge small successes• Walk the talk - be out there with them• Treat each person as an individual


When conflicts arise, you should focus on the common goals in order to achieve effective compromises

When conflicts arise, you should focus on the common goals in order to achieve effective compromises

Many Goals Overlap

• Good organization and management• Avoidance of risks• Profits• Effective progress reports• Satisfied customers


• You will make mistakes– Learn from them– Recover from them (knowledge helps)

• Not everyone will like you all the time– Maintain professional behavior– Deliver!

• But success will be rewarding– Sense of accomplishment & personal

growth– Career advancement

The Job is Challenging


Learn to Balance

Performance

Cost Schedule


Learn to Prioritize

Urgent,I mportant

Not Urgent,I mportant

Urgent, NotI mportant

Not Urgent,Not I mportant

Covey’s Matrix for Prioritizing Your Time

Covey’s Matrix for Prioritizing Your Time


Reviewing Assumptions, Estimates and Commitments


Initial Planning

etc.initialplan

Periodic Review and Update


revisedplan

Update your Estimates and Plans

• The Start of Execution is an Excellent Time to Review the plans and estimates

– Especially if there was a long gap between planning and execution.


Review Commitments & Assumptions

• Commitments are often changed during contract negotiations– Make sure you know what they are

• The start of a project is often a stressful environment– It is common to overlook changes that

affect your plans– Especially changes in parts of the

project that are not your responsibility


Projects that start out in trouble tend to end up in trouble.

Projects that start out in trouble tend to end up in trouble.

You Have the Most Leverage at the Start of the Project

• The most expensive problems result from mistakes made very early

• Beware of inconsistent system concepts that lead to incompatible interfaces– These problems might not even surface

until you are near the end of the project


Set Expectations


Let People Know the Plan

• Define what will happen• Document the processes• Teach people• Deal with their concerns• Let them know how you will

evaluate them and what you expect from them– And then follow through– Say what you do and do what you say


Buy-in and Respect are Earned

• Show by actions that you are serious• Avoid preaching• Let the people who will do the work

own the processes, the metrics, and the change mechanisms


When there is Trouble, Don’t Focus on the Practitioners

David, I’ll bewatching you as you debug

to see how well you are doing

and help you improve.

David is likely to: -- be more careful than usual (and thereforeNOT behave as usual) -- be nervous & error prone

David is likely to: -- be more careful than usual (and thereforeNOT behave as usual) -- be nervous & error prone

NowI’m

ReallyNervous!


Don’t Punish or Blame the Practitioners

David, this disasteris all your fault!

I’ll show you!

David is likely to be: -- defensive -- uncooperative

David is likely to be: -- defensive -- uncooperative


Focus on the ProcessDavid, our

coding conventionsare flawed and weneed your help to

improve.

I had a lot oftrouble with some parts, and I think I know some better

rules.

David will helpto improve andwill become abetter coder

as well.

David will helpto improve andwill become abetter coder

as well.


Frailey’s Maxim forLife in the Real World

You must succeed with normal, average people. Unlike the

university, you cannot reward the top 50% and flunk out the rest.


The Normal Distribution Curve

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

Mean

+ 1 s- 1 s

+ 2 s

Capability

Number of People with This

Capability


Using the SEI CMM to set the stage for a

Successful Software Project


Quality Management

Goal: Manage the software engineering function to achieve high quality at low cost and cycle time

Quality

LowCost

ShortCycle Time

CustomerValue


Organizational Process Maturity

• This is the way to achieve quality management

• The concept of organizational maturity began with Philip Crosby– who introduced a five level maturity

level for project management

• Crosby found that organizational effectiveness was directly related to process maturity


Crosby’s Model was a Model of Management

• Crosby believed that this could be measured by how effectively you use processes

• This was based on the work of Edwards Deming

How Mature and Effective is Your Organization?


Philip Crosby’s Five Patterns of Management Attitude

1) Uncertainty – Do not understand the task

2) Awakening – Understand the problems, not the solutions

3) Enlightenment – Understand HOW to solve known problems

4) Wisdom – Understand WHY the solutions work

5) Certainty – Can solve unexpected problems


Watts Humphrey’s Model for Software Organizational

Maturity• Humphrey used Crosby’s concept of

a five level Model to form a model of Software Process Management Maturity

• This eventually became the SEI CMM model, which is widely used today

• Regardless of whether you use the CMM model, the ideas here are worthwhile


Humphrey’s Five Levels1) Initial - Ad-hoc and unmanaged

– Not under control– Success depends on heroes and

heroic actions– Results cannot be reliably predicted

2) Repeatable - Stable– Relies on firm management and

control– Results can be predicted provided you

use the same people and the have the same kind of problem


Humphrey’s Five Levels (Continued)

3) Defined – Stable due to knowledge and definition

of processes.– Predictable even if entirely new people

are used– Automation begins to pay off

4) Managed – Comprehensive measurement and

analysis– Management by fact


5) Optimizing– Significant improvements on a regular

basis in a controlled fashion– Adapts well to new conditions and

environments

Humphrey’s Five Levels (Continued)


Humphrey’s ModelFocus Key Process Areas ResultLevel

Productivityand Quality

RISK

4

Managed

3

Defined

2

Repeatable

1

Initial

5Optimizing

ProjectManagement

EngineeringProcess

Product andProcess Quality

ContinuousProcessImprovement

Heroes

Process Meas/AnalQuality Management

Process Focus&Def’n;Integrated SW Mgmt;

Peer Reviews; Training;Intergroup Coord; SWProduct Engineering

Project Mgmt; Planning;Rqmts Mgmt; SQA;SCM; Subcont. Mgmt

Defect PreventionTechnology InnovationProcess Change Mgmt


Each Level Contains Key Process Areas (KPA)

• These are the things you must master to attain a given level

• For example, at level 2 the KPAs are:– Project Management– Planning– Requirements Management– Software Configuration Management– Software Quality Assurance– Subcontractor management


What You Know at Each LevelI nitial You make guesses and rely on heroes

Repeatable You know what to do

Defined You know why it should be done (based on theory)

Managed You know exactly why and what (based on f actual data to supplement theory)

Optimizing You keep up to date and know what changes are coming and how to cope with them


Rationale for the Five Levels

• Historical experience (Crosby, et. al.) with other processes

• A reasonable sequence of measurable and attainable improvement goals– You know what to do first

• Interim improvement plateaus– You don’t take on too much at a time

• They assist in setting priorities• Each level is the foundation for the next


CAVEAT: Do one level at a time.

Skipping levels results in ultimate failure

Level 5Maturity

Level 4 Maturity

Level 3 Maturity

Level 2 Maturity

Level 1 Maturity


Characteristics of an Immature Software Organization

• In an immature organization, there is no objective basis for judging product quality or for solving product or process problems

• Therefore, product quality is difficult to predict


How to Spot an Immature Organization

• Activities intended to enhance quality, are often curtailed or eliminated when projects fall behind schedule

For more information, see Paulk (references).

For more information, see Paulk (references).


Characteristics of a Mature Software Organization

• Possesses an organization-wide ability for managing software development and maintenance processes

• The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process.


Mature Organization (continued)

• The processes mandated are fit for use and consistent with the way the work actually gets done

• These defined processes are updated when necessary, and improvements are developed through controlled pilot-tests and/or cost benefit analyses


For more information, see Crosby, Humphrey, and Paulk

(references).

For more information, see Crosby, Humphrey, and Paulk

(references).

Mature Organization (continued)

• Roles and responsibilities within the defined process are clear throughout the project and across the organization.


Attributes that Characterize a Mature Process Area

• These attributes, derived from the SEI CMM, indicate whether a process area is implemented & institutionalized effectively, repeatably, and in a lasting manner.

• These attributes are a good checklist of things to look for when preparing your program and your organization


• Commitment to Perform

• Ability to Perform• Activities Performed• Measurement and Analysis• Verifying Implementation

We WILL do

this!

The Five Attributes


Commitment to Perform

• Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure– Example: establishing a policy that

mandates a particular activity • Commitment to Perform typically

involves establishing organizational policies and demonstrating senior management sponsorship


Boss

SEPGSW

Manager

Ability to Perform

• Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently

• Ability to Perform typically involves resources, organizational structures, and training


Activities Performed

• Activities Performed describes the roles and procedures necessary to implement a key process area

• Activities Performed typically involve:– Establishing plans and procedures– Performing the work– Tracking it and – Taking corrective actions as necessary


Measurement and Analysis

• Measurement and Analysis describes the need to measure the process and analyze the measurements

• Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed.


Verifying Implementation

• Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established

• Verification typically encompasses reviews and audits by management and software quality assurance.


Key Practices

• The SEI CMM describes several key practices that suggest what should be done to master a given process area– Example: a key practice for risk

management might be periodic evaluation of risks and the status of known risk mitigation activities

• The CMM is a good source of ideas and recommended practices– But they are NOT mandates


Alternative Practices

• Alternative practices may accomplish the goals of the key process area

• Key practices should be evaluated to judge whether the objectives can be achieved effectively, although perhaps differently.

Key Practice per CMM Example

Key Practice for Our Situation


Using a Maturity Model Effectively

• Know your maturity• Focus on the key process areas

needed to move up to the next level• Maintain the good practices of your

current level• Use the model to improve your

effectiveness, not to “keep score”– Focusing on “levels” can lead to

“cosmetic” improvements rather than real ones


Planning Reviews and Audits


ReviewsPurpose:

– To learn the status of the project

Performed by:– Managers or Peers

Method:– Practitioners report on the status and

plans of their projects, following specified formats and reporting on specific metrics


Reviews (continued)

Typical Duration:– A few hours to several days

Achieves:– Uncovers problems (or, at least,

symptoms)

Drawbacks:– Does not always identify solutions– May motivate hiding of problems

• Avoid punishing the messenger if you want to get an accurate message


Advantages of Reviews

• Reviews are relatively inexpensive– Standardize how they are done so

people know exactly what to prepare– Make it easy to prepare for a review by

making normal work products a natural part of the review

• Reviews tend to get everyone back on the same track


Three Categories of Reviews1) Phase or Milestone Reviews (Gates)

– Held at major milestones– Ensures that the project is ready to move

to the next phase

2) Status Reviews– Held periodically, frequency driven by risk

• Typically 1-week to 4-month intervals

– Ensures that everyone knows current status

3) Peer Reviews and Inspections– Designed to evaluate a specific

development artifact


Phase or Milestone Reviews (Gates)

• Provide a forum to understand– the state of the project and product– at a point where the direction can be

altered or refined

• A quality control checkpoint for the project team and organization

• Typically attended by senior management and external organizations and maybe the customer


Topics Covered in a Phase Review

• Major accomplishments and plans• Actions needed for phase

completion• Variances from estimates and plans• Problems that are impacting quality,

cost and the schedule • High-risk areas that need attention• Problems or lessons learned that

could impact later phases


Status Reviews

• A team progress review• Provide a forum to identify and raise

issues and problems (technical and schedule) as early as possible

• Focused on near-term issues and actions (often sensitive ones)

• Typically attended mostly by the people working directly on the software project


Topics Covered in aStatus Review

• Accomplishments since previous review

• The original plan vs actual performance

• The critical path of the project

• High-risk areas that need attention

• Problems that are impacting quality, cost and the schedule

• Status of action items (open & closed)


Topics Covered in a Status Review - For the Next Period

• The plan– Possibly revised during the review

• New action items– Assignments– Dates Due– Who will track to closure


Peer Reviews and Inspections

• Provide a way to evaluate specific artifacts– designs, code, test code, etc.

• Typically attended only by peers of the person whose work is being evaluated


Why Only Peers?

• This approach is designed to foster free and open discussion– The supervisor’s presence tends to

inhibit open discussion, often in ways that are not evident to participants

• Often a facilitator or quality assurance representative will participate– To keep everyone focused and to

record findings and action items


Issues Regarding Peer Reviews & Inspections

• You must foster a culture where people actively participate in the reviews and inspections of others– Include this in how you evaluate them– Include time in the schedule– Don’t count their work done until they

have participated in others’ peer reviews

• There are many methods available– Select methods that fit your team


Audits


AuditsPurpose:

– To study a project in detail and find problems that may not be evident

Performed by:– Independent technical experts, often

outsiders

Method:– Experts question practitioners and

examine artifacts of their process to determine what is happening


Audits (continued)

Typical Duration:– Several days to several weeks

Achieves:– Uncovers problems not seen by insiders– Informs staff that management cares about

the results

Advantages:– Tends to uncover real problems– Tends to confirm or disprove suspected

problems


You don’ttrust us!

Drawbacks of Audits

• More expensive than reviews• Do not usually identify solutions• May motivate hiding of problems• Can generate hostility and lack of

cooperation or demotivation• Outsiders often do not

understand– even if they do, they are not

always believed


When and How to Plan for Audits

• Use audits at points when verification and validation are important– Such as before shipping a product or

after making substantial progress• Use audits sparingly, but regularly

– An audit should not be viewed as a sign that you suspect trouble

– It should be treated as a normal part of doing a high quality job• Like a regular medical checkup


Get the Practitioners Involved

• Have the practitioners identify the right times for audits– Use them as a way to validate their work– Remind them that athletes and artists

rely on coaches and critics

• Have practitioners participate in audits of other projects– Let periodic audits become part of the

culture


PlanningSubcontractor/Supplier

Management


Typical Symptoms of Weak Software Subcontract

ManagementThey were supposed

to deliver it today. They just

called and told us they have

a three month delay!

They always

delivered on time in the past!


More Typical SymptomsWe’ve been

hit by a $25,000fine because our

user interface does not meet EPA

standards.

The subcontractor did not know

about the regulations.

The bigcost will be the recall - about

$200,000


Further Typical Symptoms

They delivered the

software module, but no test cases

or documentatio

n

The contract was vague

on this point.

They thought that

was our responsibilit

y.


Software Subcontract Management

Purpose:– To select qualified subcontractors– To manage subcontractors effectively


How to Do Software Subcontract Management

• Select subcontractors based on ability to do the job

• Communicate effectively with subcontractors

• Document commitments• Flow down standards, processes, etc.• Track and review subcontractor

performance and results


Subcontractors May Not Like to be Reviewed and Audited

• Diplomacy, tact, and firm management skills are needed

• A cooperative approach based on mutual goals can lead to more openness and more accurate information

• Standards and regulations can provide leverage in negotiations– “We trust you, but ISO 9000 requires that

we do an audit”


Other Parts of Your Company are Subcontractors to You

• They may not require all the formality, but the principles are still the same:– Statement of work, commitment,

tracking, etc.

• Their goals may not align with yours– Unless you make sure that they do


Facilities and Staffing Plans


You Must Plan Reasonable Staff Acquisition and Use

Patterns

0

20

40

1 2 3 4 5 6

Unrealistic

0

10

20

1 2 3 4 5 6

More Realistic


Your job is to remove obstacles to their effectiveness ...

… not to have them take burdens off of you!

Your job is to remove obstacles to their effectiveness ...

… not to have them take burdens off of you!

People Cost Money --Make Them Productive!

• Adequate training• Adequate facilities• Avoid excessive interruptions


Make Sure the Facilities Fit the Job to be Done

• Enough computers, copiers, etc.

• Enough work space

• Reliable networks and utilities

• People who work closely together should be located closely together


The Software Development Plan ...

… should describe the facilities needed and planned (at a high level)

… and the overall staffing plans– Numbers– Skills required

… and the plans for managing any risks related to these– Backup staffing plans– Alternate facilities options


Maintaining an Effective Plan


Warning from Dilbert



2. Ignore it”




2. Ignore it”



The Plan is Static --Planning is Dynamic

• You rarely follow the plan exactly as written

• As you progress, you learn more• Keeping the plan up to date keeps

everyone synchronized and reduces the chances of miscommunication, etc.

Initial Planning

etc.initialplan



revisedplan


You Learn More Every Day

Plans need to reflect what you know today ...

… not what you didn’t know when you wrote the plan.

Plans need to reflect what you know today ...

… not what you didn’t know when you wrote the plan.


Be Sure to Coordinate and Communicate Plan Changes

• Some software managers change their plans without notifying affected parties

• This can lead to chaos• So it is worth the trouble to coordinate

changes and communicate them effectively

• Don’t change too frequently or people will not take the time to pay attention to changes


Beware of Bureaucrats• It is a good idea to have an approval

process for plan changes• But some customers or managers

have instituted a slow, burdensome bureaucracy for approval of plan changes that impedes effective plan updates

People who must approve changes

to the plan


Dealing with the Realities ofBureaucratic Change

Approvals• Avoid excessive detail in the Plan

– put it in a supplement• Incorporate plans for changing the

Plan• Maintain “Duplicate” plans

– Formal, approved plan (high level)– Working, dynamic plan (more specific)

• Establish trust with customers by keeping commitments


SummarySoftware Development Plans

• The Software Development Plan serves many roles– Communicates your plans– Helps you plan– Shows you know how to manage the

project

• The formal Plan is supplemented by many other plan elements


• Planning forces you to think• Documenting your plan helps you

avoid glossing over issues that need to be pinned down

• Plans must be maintained and used• Plans changes must be communicated• A standard plan is like a checklist to

make sure you have included everything in your plan

SummarySoftware Development Plans


Summary• Understand your role• Establish good relationships with all

of your “customers”• Review and update assumptions,

estimates and plans• Set the right expectations• Establish an environment for success• Plan reviews, audits• Plan subcontractor management


References• Covey, Stephen R. The Seven Habits of Highly

Effective People. New York: Simon & Schuster, 1986. Copyright © 1989 by Stephen R. Covey.

• Crosby, Philip B. Quality is Free, New York, McGraw-Hill, 1979.

• Deming, W. Edwards, Out of the Crisis, MIT Press, 1986, ISBN: 0911379010

• Deming, W. Edwards, Quality, Productivity, and Competitive Position, MIT Press, Cambridge, 1982. (out of print)

• Humphrey, Watts S. Managing the Software Process, Reading, Mass., Addison-Wesley, 1989.

• Paulk, M. C., Curtis B., Chrissis, M. B. and Weber C. V. 1993. “Capability maturity model version 1.1”, IEEE Software 10(July): 18-27.


• Donaldson, Scott E. and Stanley G. Siegel, Cultivating Successful Software Development, Prentice-Hall, 1997, Chapter 2.

• Department of Defense, Defense System Software Development, Dod-STD 2167A, 29 Feb. 1988, Department of Defense, Washington D.C., 20201.

• Reifer, Donald, Tutorial: Software Management, IEEE Computer Society

ReferencesSoftware Development Plans

copyright © 1995-2004, dennis j. frailey, all rights reserved day 4, part 1, page 1 1/11/2004 day...

Documents