Software Project Management

1

© 2001 Shawn A. Bohner

Software Project ManagementCS6704: Class 2

Software Project Software Project ManagementManagementCS6704: Class 2CS6704: Class 2

Instructor: Shawn A. BohnerVoice: (703) 538-8374

Email: [email protected]

Teaching Assistant: Yunxian ZhouEmail: [email protected]

Voice: (703) 538-8381

2

Agenda

u Review Last Week’s Materiall Turn in Homeworkl Reading Discussionl Project Plans Discussionl Review last weeks class

u Chapter 1: What Makes a Good Software Manager?

u Chapter 2: Four Basics that Workl Break

u Software Process Managementu Homework Assignment

2

3

AugAug SeptSept OctOct NovNov DECDEC

Class BeginsClass BeginsPM BasicsPM Basics

Software Software Project Project

PlanningPlanning

Managing with Managing with MetricsMetrics

ProgramProgramManagementManagement

Emerging PM Emerging PM ParadigmsParadigms

Final ExamFinal Exam

Software Software Process and Process and

Life CycleLife Cycle

Software Software EstimationEstimation

Risk Risk ManagementManagement

Human SideHuman Sideof PMof PM

Project Project Portfolio Portfolio

ManagementManagement

Fall Semester Timeline

16 weeks, 13 sessions… So much to do & so little time … manage your time effectively!

16 weeks, 13 sessions… So much to do & so little time … manage your time effectively!

MidMid--Term Term ExamExam

4

Discussions…

u Reading Discussionl What was the main idea of the paper?l Does software projects differ from other

projects? If so, how?l Do you do these things in your projects?l What parts of these can be automated?

u Software Project Plans Discussionl Where did you find software plan examples?l What did the software plans contain?l Was it what you expected? What was different or

missing? l What there enough information in the plans to

support the management decisions for projects you have seen?

3

5

So, why is e-Engineering a project management problem?

u Large, complex, distributed systemsl CPU speed, memory, bandwidthl Things we’re taught to ignore

u Heterogeneous platform architecturesl Mainframe, desktop, laptop, palmtop … l CORBA, VXML, EJB, … languages

u Mobility (Several 2000/1 IEEE Computer Issues)

l One application runs on many devices across varied communications

l Each device has varied resource profiles

u Modeling, analysis, simulation…l Collaborative design on partial information

u Development teams across the globel Around the clock developmentl Decentralized ownership and control

6

Why Are Projects Late?u Unrealistic deadline established by someone outside the software

development groupu Changing customer requirements that are not reflected in schedule

changesu Honest underestimate of the amount of

effort and/or the number of resources that will be required to do the job

u Predictable and/or unpredictable risks that were not considered when the project started

u Technical difficulties that could not have been foreseen in advance

u Human difficulties that could not have been foreseen in advance

u Miscommunication among project staff that results in delaysu Failure by project management to recognize that the project is

falling behind schedule and a lack of action to correct the problem

Which of these are unique to Software Projects?Which of these are unique to Software Projects?

4

7

So, what did Capers Jones tell us here?

Early On-Time Delayed Canceled Sum

1 FP 14.68% 83.16% 1.92% 0.25% 100.00%

10FP 11.08% 81.25% 5.67% 2.00% 100.00%

100FP 6.06% 74.77% 11.83% 7.33% 100.00%

1000FP 1.24% 60.76% 17.67% 20.33% 100.00%

10,000FP 0.14% 28.03% 23.83% 48.00% 100.00%

100,000FP 0.00% 13.67% 21.33% 65.00% 100.00%

Average 5.53% 56.94% 13.71% 23.82% 100.00%

From Capers Jones, Patterns of Software Systems Failure and Success(International Thomson Computer Press, 1996)

8

Semi-Formal Definition

u Management – The activities undertaken by ??? to plan and control activities of others to ???.

u Project Management – “… a ??? of procedures, practices, technologies, and know-how that provide the ?, ??, ???, ????, and ????? necessary to successfully manage an engineering project.” [Thayer 1987]

5

9

Classic Management Activities

SoftwareProject

SoftwareSoftwareProjectProject

Planning

Planning

PlanningDi

recti

ng

Dire

cting

Dire

cting

StaffingStaffingStaffing Organizing

OrganizingOrganizing

ControllingControllingControlling

?

?

?

?

?

10

Prog. Mngt. Capability Maturity Model

Result

Value

Risk

MaturityLevel

Key Process AreaConcentrations

StrategicInflection

Point

EffectiveSpan

5Incorporated

Value Management,Business Continuity Planning,Procurement Management,Outsourcing and Contract Manage-ment, PM Center of Excellence

Integrationwith Business

Enterprise/Industry

4Managed

Program Process Management,Project Integration Management,Project Performance Management,Vendor Management, PM Career Path,Staff Performance Management,Customer Relationship Management,Contingency Management,Communications Management

DynamicMicro-LevelChange

MultipleBusinessUnits

3Defined

PM Methodology, Skill Management,PM Training, Risk Management,Change Management,Staff Resource Management,Environment Resource Management,Conflict/Issue Management

Static Macro-Level Change

MultipleProject

2Stable

Planning, Estimation,Tracking, Risk Identification,Schedule Management,Budget/Cost Management,Scope Mgmt., Progress Reporting

StabilizePerformance

SingleProject

1 - Initial Acquiring New PMs

6

11

What do PMs Manage? Software!

u Software is part of a computer system that is ???

u Business changes and its computer systems must respond

u Software is ???, not manufactured

u Software is intangibleu Software is complex

Software is suppose to change… otherwise it would in the hardware!Software is suppose to change… Software is suppose to change… otherwise it would in the hardware!otherwise it would in the hardware!

12

Software Project Management must Manage to a Future (moving) Target

u ??? Changesl Market shifts and investment fluctuationsl Portfolio changesl Mergers and Acquisitions …

u ??? Changesl Hardware, software, networks, mobile …l Fast, better, cheaper …

u ??? Changesl Agility vs. qualityl Business and technology …

u ??? Changesl Shortages and gluts …

7

13

Project Management Truths

u You can get someone to commit to an unreasonable deadline, but you can’t l …bully him into meeting it

u Experienced PM’s Motto: Projects fail l …one day at a time

u Projects progress to 90% completion very rapidly…l They remain there while great sums of money and time are

spent to keep them there

u You can freeze specifications, l …but you can’t freeze expectations

u When quoting “off the shelf,” remember l …there is no shelf

u If project content is allowed to change freely, l the rate of change will soon exceed the rate of progress

14

Chapter 1: What makes a good Software Manager?

u The purpose of this chapter is to examine characteristics of a good software project managerl What are the key attributes associated with

successful project managers? l Which software projects management skills are

essential?u Objectives

l Outline key characteristics of a good software manager

l Examine people, business, and process perspectives

8

15

People Perspective

u Rob Thomasett – “most projects fail because of people and PM concern rather than technical issues.”

u ~80% of software project managers come from technical ranksl Some with natural abilities, others must learnl Often with predispositions about managers

and how projects should be runl Most are surprised by their first project

– Budgets, resources, customers, estimates, teams, meetings, decisions, and risks

u Beware of the little hairy boss syndrome…

16

Some Sage Advice…

u Be flexible. l Let your people perform according to their capabilities.

Stretch goals are good but they have to have enough room to stretch.

u Have compassion. l Deal compassionately with difficult people (often they do

not know they are difficult and may be difficult because the do not understand)

u Know when to lead and when to manage.l Lead people… manage process and product

(by example) (systematically)

u Accept the role of meetings.l Communication, not bureaucracyl Prepare and manage them

9

17

Coach Your Team to Success [Hawkins 1994]

u Yes, project management is a team sportu Success is spelled “T E A M”u Increase chances of success by

l Hiring the best and brightestl Keep the teams smalll Minimize distractionsl Train staff for best performancel Meet as a team often but not for long periodsl Know your team membersl Set the example

18

Software Teams

u Difficulty of the problem to be solvedu Size of the resultant program(s) in lines of code

or function pointsu Time that the team will stay togetheru Degree to which the problem can be modularizedu Required quality and reliability of the system to

be builtu Rigidity of the delivery dateu Degree of sociability (communication) required

for the project – Relationship management

Consider the following factors when selecting asoftware project team structure ...

10

19

Business Perspective

u Again, most software project managers did not come from the business…

u Chaos Studyu Creating software products to benefit the

business and its customersl Who wants the software and who doesn’t?l Who are the users? What will the software do

for them and the business?l When do users need (not want) the software?l Why does the business need the software?l Why is your team developing the software?

u Business investment portfolio view

20

Basis for IT Portfolio Investment

u Value maintenance —managing ongoing, non-discretionary investments in IT assets

u Value enhancement —discretionary investments in improving or growing IT asset base

u Value exploration —venture into high-risk/high-payoff IT investments •

• •

• • •

• •

•

• • •

• •

•

• •

•

IT PortfolioIT Portfolio

Projects/Initiatives

Projects/InitiativesERPERPEE--BizBiz

CRMCRMSecuritySecurityNetwork

Network UpgradeUpgradeConsolidation

Consolidation

ApplicationsApplications

DataData

ServicesServices

Infrastructure

Infrastructure

Human Capital

Human Capital

Existing

AssetsExisting

Assets

11

21

Maintain Existing IT Asset Value

u IT liability avoidance and value retention

u Fund baseline costs for critical business operations, maintenance, and support

u Skeleton funding based on minimum headcount and costs to keep system running

u Incentives to reduce baseline costs

Prevent Business Discontinuity

ValueValueMaintenanceMaintenance

IT Investment BudgetIT Investment Budget

22

Enhancing Existing IT Asset Value

u Strategic prioritiesl Investments criteria l Investment process

u Phased funding on projects with interim deliverablesl Jump-startl Initial capability l Advanced function

u Continued allocations through project value and delivery commitments being met and communicated

Invest in Existing Assets According to Business Strategy

ValueValueEnhancementEnhancement

ValueValueMaintenanceMaintenance

IT Investment BudgetIT Investment Budget

12

23

Exploring Future IT Asset Value

u Requires dynamic mindset for quick response to value and market changesl Digital Planning for agility

u Value Enhancement investment criteria plus:l Business/Market advantagel 2-3 year ROI/IRR projectionl Clear exit strategy

u Manage using a venture funding model – close and regular interactions

Engage in high risk, high yield opportunities

ValueValueEnhancementEnhancement

ValueValueMaintenanceMaintenance

ValueValueExplorationExploration

24

Investment Model IT Portfolio

Cost toConform

Cost toExcel

Lost ValueLeveraged Value

Followers Leaders

Minimum Investment

Excess Investment

ValueValueMaintenanceMaintenance

ValueValueExplorationExploration

ValueValueEnhancementEnhancement

13

25

Process Perspective

u Software process has matured into a vital part of software projectsl Software Engineering Institute’s Capability

Maturity Modelsl Best practicesl ISO 9000, Malcolm-Baldridge, TQM…

u At the heart of every project plan is an activity/task set derived largely from the process

26

Management Secrets

u Avoid having team members work in isolation

u Stay with your project team – they are the ones delivering the products of the project

u Concentrate on Tasks – not toolsu Do your homework (no this is not a

subliminal message for CS6704)l Stay current on latest advancements in

management and technical techniques for projects that you manage

u Sounds like common sense… but it is not so common!

14

27

Chapter 2: Four Basics that Work

u The purpose of this chapter is to examine four basic software project management principles that workl What are the basic areas for successful project

managers to manage?

u Objectivesl 1. Balance people, process, and productl 2. Promote visibilityl 3. Organize using configuration managementl 4. Apply standards judiciously

28

The 3 P’s

u Peoplel Critical to all projects but the most variable in

the management equationl Creative, complex, capable, costly

u Processl Most focused on in recent yearsl Manage the process through measures (next

section)l Universe, world, and atomic views

u Productl Software is to be change tolerantl Quality measuredl Ultimate delivery

15

29

Balancing the 3 P’s

u Difficult of the product dependent on people and process capabilitiesl Must triangulate on Pfactors…

u People Knowledgel Domainl Systeml Programming

u Process Maturityl Levels 1-5 on the SEI-CMM scale

u Product Maturityl From research prototype to packaged

component

30

Visibility

u Software is invisible to naked eye… l Intangible – must be measured with a computer

u Software projects are largely invisible (until they complete) – managed as a cost

u Project managers must bring visibility to software product and project

u Two “dreaded” visibility vehiclesl Documentationl Metrics

u Project team vision, commitment, and group memory

16

31

Visibility Through Modeling

u Models answer questionsu What questions need clarity (better

visibility) – model themu Modeling tools

l SADT/IDEF0, Warnier-Orr diagrams, STDs, Structure charts

l CRC cards, object interaction diagramsl Mind maps, story boards,

32

How are Metrics Used for Visibility?

02468

10Predevelop

Develop

Post-develop

Integral (CM, V&V)

Life Cycle

Project Mgmt

GoalQuestion

Metric

Decision?

tGetting attention —What situations need to be addressed?

Dashboard of indicators

tKeeping score —How well is it (or IT) doing?

Scorecard on goals

tSolving problems —Which choice or improvement should be made?

Benchmarking for performance improvement

17

33

Meaningful Management Visibility

Operational View• Process/activities• Products/specs• Policy/procedures• Constraints/guides . . . OLTG

TL A p p l i c a t i o n s ,

I n f o r m a t i o n Reques t s ,

Updates

Appl ica t ion Acceptance

I n f o r m a t i o n

Obtain Technical

Loan Applications

A13 3 . 0 D

Conduct Applicant

Credit CheckA25 3 . 0 D

Conduct Technical

ReviewA31 3 2 . 0 D

Accept/Reject Loan

GuaranteeA41 3 1 . 0 D

Appl ica t ion Correspondence

Comple ted Loan

Appl ica t ions

Cred i t

Approval

Technical Approval

S c i e n t i f i c / E n g i n e e r i n g Review Team,

DoD Review Team

Management ViewiCosts/budgetiSchedule/effort/delayiUtilization and loadingiResource availability . . .

del

Sdel

svcSsvc

0.136.7615500.412

Audit A

arcvTm

*

16.8751121

Workload

wkld

svtm

# d u C s t Dr

146 0.68 24.5Base Acty

a b mo

avgmax

m i nx0

SD

30.006726.135916.8753.11928

BaseThrupu

xx

3.51362

145.6003000

Delay>Svtm

a b mo

avg

max

m i nsSD

1680.46

980.271280.077392.198

SvcTmBase

Exp*

Base

delSdel

svcSsvc

334.0530980.271

Audit

Alt

a b mo

avg

max

m i ns

SD

974.839500.41225.9854

293.569SvcTmAlt

wkld

svtm

# d u C s t Dr

0.78 0.35 16.9Alt.Acty

x

0.350250.782503000

Delay>Svtm

Exp*A

a b mo

avg

max

m i n

x0

SD

49.5746

36.130116.87512.4660

AltThruput

1st Qtr 2nd Qtr 3rd Qtr 4th Qtr0

20

40

60

80

100

42

4344

45

46

47

48Production

DelayOverhead

Executive Decision ViewiROI, ROM, EVA, …iBusiness ImpactiPrice/performanceiRisk/opportunity . . . Value

34

Key Visibility Principles for Metricsu Clearly defined metrics,

consistently appliedu Metrics are only indicators, use

them accordinglyu Focus on leading indicators over

lagging onesu Recognize indicators of

problemsl Lack of changel Frequent changel Slow, steady deviation from plans

Navigation

Software metrics are navigational instruments giving position, direction, and rate of change

Software metrics are navigational instruments giving position, direction, and rate of change

18

35

Configuration Management

No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.

Ed Bersoff, et al, 1980

u Product dependencies can be complexl Time, use, version, …

36

Flow of SCM: Definition, Use, Archive

Production Library

Acceptance Test Library

Integration Testing Library

System Testing Library

Unit Development Library

Emergency Fix Library

Production Library

Acceptance Test Library

Integration Testing Library

System Testing Library

Unit Development Library

Emergency Fix Library

Archives of SystemSoftware

SCM Staff

0 Defines SCM Structures, Standards and Procedures

Key Software BaselineVersions

Software Project Staff

0 Uses SCM Library Structures, Standards and Procedures

SCM Staff

0 Archives/ControlsBaselined Software

19

37

Standards

u The wonderful thing about standards is that there are so many to choose from…l But when leveraged correctly, they simplify the

process and management of a software project

u Standards save time and moneyu Examples:

l IEEE 1042 – SCM Standardl MIL-STD-498/IEEE 1498 – Software

Development Life Cycle

38

Software Process

u The purpose of this module is to introduce several software process models used to manage large-scale software projectsl While no software process works well for every

project, every project needs to conform to some systematic process

u Objectivesl Outline software as a processl Outline key aspects of software processl Examine how to assess software process

maturity

20

39

The Linear Model

analysis design code test

System/informationengineering

40

Iterative Models

listento

customerbuild/revisemock-up

customertest-drivesmock-up

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

team #1

team #2team #3

60 - 90 days

Prototyping

RAD

21

41

The Incremental Model

analysis design code test

System/informationengineering

analysis design code test

analysis design code test

analysis design code test

increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time

42

An Evolutionary (Spiral) Model

CustomerCommunication

Planning

Construction & ReleaseCustomerEvaluation

Engineering

Risk Analysis

22

43

Still Other Process Modelsu Component assembly model—the process

to apply when reuse is a development objective

u Concurrent process model—recognizes that different part of the project will be at different places in the process

u Formal methods—the process to apply when a mathematical specification is to be developed

u Cleanroom software engineering—emphasizes error detection before testing

44

SEI Process Program Background

u CBA IPIs and SPAs conducted since 1987 through December 1999 and returned to the SEI by January 2000l 1512 assessments

– 1024 CBA IPIs– 488 SPAs

l 1166 organizationsl 309 participating companiesl 283 reassessed organizationsl 6168 projects

*Source: Software Engineering Institute

23

45

SEI’s Software Process Capability Maturity Model

Level Focus Key Process Areas Result

1Initial

Heroes

5Optimizing

ContinuousProcess

Improvement

Defect preventionTechnology innovationProcess change management

4Managed

Product andProcess Quality

Process measurement andanalysisQuality management

3Defined

EngineeringProcess

Organization process focusOrganization process definitionPeer reviewsTraining programIntergroup coordinationSoftware product engineeringIntegrated software management

Productivity& Quality

Risk

2Repeatable

ProjectManagement

Software project planningSoftware project trackingSoftware subcontract mgt.Software quality assuranceSoftware configuration mgt.Requirements management

*Source: Software Engineering Institute

46

Summary of the SEI/CMM Levels

1) Initial: The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.

2) Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

3) Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standardsoftware process for developing and maintaining software.

4) Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

5) Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

24

47

Software Process Maturity Advances

0.87

79.8

12.40.58.7

75.3

15.49.7

0.50.7

16.9

72.2

1.40.5

12

64.4

21.7

0.62.3

15.1

58.1

23.9

1.53.815.6

30.6

48.6

0

10

20

30

40

50

60

70

80

90

Level 1 Level 2 Level 3 Level 4 Level 5

1987-91 1992 1994 1996 1998 1999

*Source: Software Engineering Institute

48

Summary Maturity Findings: Organizational Trends

u Software Quality Assurance is the least frequently satisfied level 2 KPAs among organizations assessed at level 1

u Integrated Software Management, Training Program and Organization Process Definition are the least frequently satisfied level 3 KPAs among organizations assessed at level 2

u Higher maturity has been reached among those organizations reporting reassessments

*Source: Software Engineering Institute

25

49

Process Improvement Maturity Levels

Process

Ad hocs High variability/Low

predictabilitys Heroes => Successs High Risk

Process

Repeatables Project metrics focuss Low variability/Medium

predictabilitys PM => Successs Medium-High Risk

Defineds Process metrics focuss High predictabilitys Process => Successs Medium Risk

50

More Traction at Upper levels...

Manageds Product and

Process metricss High predictabilitys Managed Process

=> Successs Low-Medium Risk

Optimized (Incorporated)

s Value metricss High predictabilitys Agility => Successs Low Risk

26

51

Homework Assignment for 9/10/01

u Read Paper entitled, “Anchoring the Software Process” by Barry Boehml Summarize key points of assigned reading into a short 1

page paper (~300-500 words)

u Read SPMH Text Chapters 1, 2, and 3l Homework Questions/Deliverables:1. What are the key characteristics of an effective project

manager? Please include references.2. Outline how to balance people, process, and product for

effective project management3. What visibility techniques work best for showing project

progress? Why?4. Search web for Configuration Management Plan

Template and send it to me via email.

u Have a great week!