Software Project Management CS6704: Class 3

© 2001 Shawn A. Bohner

Software Project

Management

CS6704: Class 3

Software Project

Software Project

Management

Management

CS6704: Class 3

CS6704: Class 3

Voice: (703) 538-8374 Email: sbohner @vt.edu

Teaching Assistant:Yunxian Zhou

Email: [email protected] Voice: (703) 538-8381

Agenda

u

Review Last Week’s Material

l Turn in Homework l Reading Discussion l CM Plans Discussion l Review last weeks class

u

Chapter 4: Managing a Project Day By Day

l Break

u

Theory-W Introduction

3

Aug

Aug

Sept

Sept

Oct

Oct

Nov

Nov

DEC

DEC

Class Begins Class Begins PM Basics PM Basics Software Software Project Project Planning Planning Managing with Managing with Metrics Metrics Program Program Management Management Emerging PM Emerging PM Paradigms Paradigms Final Exam Final Exam Software Software Process and Process and Life Cycle Life Cycle Software Software Estimation Estimation Risk Risk Management Management Human Side Human Side of PM of PM Project Project Portfolio Portfolio Management Management

Fall Semester Timeline

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

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

Mid

Mid--Term Term

Exam

Exam

Discussions…

u

Reading Discussion

l What was the main idea of the paper? l Do you agree with Barry Boehm on new

Milestones (LCO, LCA, IOC)?

l Explain what is meant by Win-Win Spiral Model?

u

Software CM Plans Discussion

l Where did you find CM plan examples? l What did your CM plans contain? l Was it what you expected?

l Why is Managing Change so Important to Software Project Management?

5

Chapter 1: What makes a good

Software Manager?

u

The purpose of this chapter is to examine

characteristics of a good software project

manager

l 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

Chapter 1: What makes a good

Software Manager?

People Perspective

u Rob Thomasett – “most projects fail because of

??? concerns rather than technical issues.” u ~80% of software project managers come from

technical ranks

l Some with natural abilities, others must learn

l Often with predispositions about managers and how projects should be run

l Most are surprised by their first project

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

7

Some Sage Advice…

u Be ???.

l Let your people perform according to their capabilities. Stretch goals are good but they have to have enough room to stretch.

u Have ???.

l Deal ???with difficult people (often they do not know they are difficult and may be difficult because the do not

understand)

u Know when to leadand when to manage. l Lead ???… manage ???

(by example) (systematically) u Accept the role of meetings.

l Communication, not bureaucracy l Prepare and manage them

Coach Your Team to Success

u

Yes, project management is a team sport

u

Success is spelled “

???

”

u

Increase chances of success by

l Hiring the ??? l Keep the teams ??? l Minimize ???

l Train staff for best performance

l Meet as a team often but not for long periods

l Know your team members

9

Business Perspective:

Basis for IT Portfolio Investment

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

investments in improving or growing IT asset base u Value ??? — venture into

high-risk/high-payoff IT investments _• • • • • • • • • • • • • • • • • •

IT Portfolio

IT Portfolio

Investment Model IT Portfolio

Cost to Conform Cost to Excel Lost Value Leveraged Value Followers Leaders Minimum Investment Excess Investment Value Value Maintenance Maintenance Value Value Exploration Exploration Value Value Enhancement Enhancement

11

Process Perspective

u

Software process has matured into a vital

part of software projects

l Software Engineering Institute’s Capability Maturity Models

l Best practices

l ISO 9000, Malcolm-Baldridge, TQM…

u

At the heart of every project plan is an

???

derived largely from the process

Chapter 2: Four Basics that Work

u

The purpose of this chapter is to examine

four basic software project management

principles that work

l What are the basic areas for successful project managers to manage?

u

Objectives

l 1. Balance people, process, and product l 2. Promote visibility

l 3. Organize using configuration management l 4. Apply standards judiciously

13

The 3 P’s

u

People

l Critical to all projects but the most variable in the management equation

l Creative, complex, capable, costly

u

Process

l Most focused on in recent years

l Manage the process through measures (next section)

l Universe, world, and atomic views

u

Product

l Software is to be change tolerant l Quality measured

l Ultimate delivery

Four Basics: #1. Balancing the 3 P’s

u

Difficult of the product dependent on

people and process capabilities

u

People Knowledge

l ??? l ??? l ???

u

Process Maturity

l Levels 1-5 on the SEI-CMM scale

u

Product Maturity

l From research prototype to packaged component

15

#2. Visibility

u

Software is invisible to naked eye…

l Intangible – must be measured with a computer

u

Software projects are largely

???

(until

they complete) – managed as a

???

u

Project managers must bring visibility to

software product and project

u

Two “dreaded” visibility vehicles

l ??? l ???

u

Project team vision, commitment, and

group memory

Visibility Through Modeling

u

Models answer

???

u

Modeling tools

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

l CRC cards, object interaction diagrams l Mind maps, story boards, …

17

Meaningful Management Visibility

???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 R e q u e s t s , Updates A p p l i c a t i o n Acceptance I n f o r m a t i o n Obtain Technical Loan Applications A1 3 3 . 0 D Conduct Applicant Credit Check A2 5 3 . 0 D Conduct Technical Review A3 1 3 2 . 0 D Accept/Reject Loan Guarantee A4 1 3 1 . 0 D A p p l i c a t i o n Correspondence C o m p l e t e d Loan A p p l i c a t i o n s C r e d i t Approval T e c h n i c a l 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

???View

iCosts/budget

iSchedule/effort/delay

iUtilization and loading

iResource availability . . . del Sdel svc Ssvc 0.13 6.76 15 500.412 Audit A ar cv Tm * 16.875 1 12 1 Workload wkld svtm #duC s tDr 1460.682 4 . 5 Base Acty a b mo avg max m i n x0 SD 30.0067 26.1359 16.875 3.11928 BaseThrupu x x 3.51362 145.600 300 0 Delay>Svtm abmo avg max m i n s SD 1680.46 980.271 280.077 392.198 SvcTmBase Exp* Base del Sdel svc Ssvc 3 34.05 30 980.271 Audit Alt abmo avg max m i n s SD 974.839 500.412 25.9854 293.569 SvcTmAlt wkld svtm #duC s tDr 0.780.351 6 . 9 Alt.Acty x 0.35025 0.78250 300 0 Delay>Svtm Exp*A abmo avg max m i n x0 SD 49.5746 36.1301 16.875 12.4660 AltThruput 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr 0 20 40 60 80 100 42 43 44 45 46 47 48 Production Delay Overhead ???Decision View

iROI, ROM, EVA, …

iBusiness Impact

iPrice/performance

iRisk/opportunity . . . Value

#3: Configuration Management

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 System Software

SCM Staff

0 DefinesSCM Structures, Standards and Procedures

Key Software Baseline Versions Software Project Staff

0 UsesSCM Library Structures, Standards and Procedures

SCM Staff

0 Archives/Controls

19

Standards

u

The wonderful thing about standards is

that there are so many to choose from…

process and management of a software project

u

Standards save time and money

u

Examples:

l IEEE 1042 – SCM Standard

l MIL-STD-498/IEEE 1498 – Software Development Life Cycle

l What did we Read About?

J-STD-016/ISO-IEC-12207

SEI’s Software Process

Capability Maturity Model

Level Focus Key Process Areas Result

1 Initial Heroes 5 Optimizing Continuous Process Improvement Defect prevention Technology innovation Process change management

4 Managed

Product and Process Quality

Process measurement and analysis Quality management 3 Defined Engineering Process

Organization process focus Organization process definition Peer reviews

Training program Intergroup coordination Software product engineering Integrated software management

Productivity & Quality Risk 2 Repeatable Project Management

Software project planning Software project tracking Software subcontract mgt. Software quality assurance Software configuration mgt. Requirements management

21

Process Improvement Maturity Levels

Process Ad hoc s ???variability/ ???predictability s ???=> Success s High Risk Process Repeatable

s Project metrics focus

s ???variability/Medium predictability

s ???=> Success

s Medium-High Risk Defined

s Process metrics focus

s ???predictability

s ???=> Success

s Medium Risk

More Traction at Upper levels...

Managed s Product and Process metrics s High predictability s ???Process => Success Optimized (Incorporated) s Value metrics s High predictability s ???=> Success s Low Risk

23

Chapter 4: Managing a Project Day by Day

u

The purpose of this chapter is to examine

the activities that dominate a project

manager’s attention (or at least should).

l What are the key activities associated with successful projects?

l What are some daily project management principles?

u

Objectives

l Outline key software project activities and understand their underlying principles

l Identify some useful techniques used day to day in software project management

l Explore activities that the class engages in their projects

First, What doesn’t work?

u

Applying a waterfall process to a project

where there is considerable unknowns

and risk

l Or…Applying an evolutionary (learning) process to a project that is well-understood

u

Not having Measurable/Visible results

l Or… Too much measurement overhead

u

Not applying effective configuration

control (losing a grip on baselines)

u

No standards – reinvention and rework

25

Creating a Good Environment

u

Emotional Safety

l Integrity, values, communication…leaving your human condition out of others’ lives

u

Emphasize TEAM

l Empowerment to succeed (and to make mistakes) together

u

Lots of Personal Interaction

l Walk-about techniques

u

Balance Work and Rest

l Crunch mode mixed with stable times

u

Structure for Success (professionalism)

l Collegial, trust, keeping current, visibility, and mistakes

Visibility

u

Control = Plan + Status + Corrections

l Plan => Targets or Goals/Objectives

l Status => Position + Direction + Rate of Change l Correction => Tactics or Adjustments

u

Getting Status Information

l Informal – management by walking around…

–Encouragement

–Localized problem resolution

l Formal – Scheduled…Communication

–Reporting

–Reviews

27

Project Management Visibility Concerns

staffing? cost estimation? project scheduling? project monitoring? other resources? customer communication? risk assessment? product quality? measurement?

Critical Visibility Practices

u

Formal risk analysis

u

Empirical cost and

schedule estimation

u

Metrics-based project

management

u

Earned value tracking

u

Defect tracking against

quality targets

u

People aware project

Visibility Framework for Measures

Project Management Business

Management

Core

Metrics

–Size (change and build) –Cost/Budget

–Effort/Schedule

• Risks (impact & exposure)

–Resource Availability –Technology

–Delivery

Product Management

•Size in KLOCs or FPs

–Maintenance and Development

•Quality/Reliability

–Pre and Post-Delivery Defects –Severity

•Change actions

–Type (fix, enhancement, update) –Impact of change (small -> large) –Priority (emergency -> routine)

• Throughput - rate of changes delivered • Cost of operations • Inventory • # of concurrent changes • Testing Efficiency • Business Value of IT • Business Risks • Financial breakeven point • ROI/ROA/ROE

31

Visibility Cautions

u

Collect what contributes to key decisions

l And it cheap to acquire

l And does not create undue stress (this means you may have to sell it to those measured) l And does not measure people directly

u

Apples to Apples Comparisons

l Granny Smith and Macintosh apples

u

When you stop making decisions on the

measures, take them out

l “We may need this someday” is not a good reason to keep measuring unless the payoff is high

Status Reporting Vehicles

u

Gantt Charts

u

PERT/CPM Charts

u

Software Size Status (Deviation From Plan)

u

Cumulative Cost (DFP)

u

Staffing (DFP)

u

Earned Value

u

Requirement Stability (Volatility)

33

Derive a Timeline Chart (AKA Gantt)

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined I.1.2 Define desired output/control/input (OCI)

Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI

FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined I.1.3 Define the functionality/behavior

Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required

Milestone: OCI defintition complete I.1.4 Isolate software elements

Milestone: Software elements defined I.1.5 Research availability of existing software

Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified I.1.6 Define technical feasibility

Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed I.1.7 Make quick estimate of size I.1.8 Create a Scope Definition

Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4

Work tasks week 5

Timeline of Formal Project Visibility Activities

System Requirements Review System Design Review Software Specification Review Preliminary Design Review Critical Design Review Test Readiness Review

Software Audit Design Assessment/ Error Handling Analysis

Software Management Metrics Exit Criteria Exit Criteria Exit Criteria Exit Criteria Exit Criteria Exit Criteria

35

Data Required: 1999 Projects Planned vs. Actual Delivery Dates from Each Reporting Unit

Frequency: Monthly

Effectiveness: Project Delivery Commitment

Sample: Zoning Project Performance

0.6 0.8 1 1.2 1.4 J F M A M J J A S O N D

Prior Months – Actual Months/Estimated Months

Delivery Index

Unit 1 Actual = Est Unit 2 Unit 3

Goal

Goal

Earned Value

u Quantitative technique for monitoring project

completion to date and assessing progress from a value perspective

u Estimate total project completion time then compute the percentage of the total project time associated with each project task

37

Barry Boehm’s Top Software Risks

1. Personnel Shortfalls

2. Unrealistic Schedules and Budgets 3. Developing the wrong software

functions

4. Developing the wrong user interface 5. Gold-plating. Requirements

scrubbing

6. Continuing stream of requirements changes

7. Shortfalls in externally-performed tasks

8. Shortfalls in externally-furnished components

9. Real-time performance shortfalls. 10.Straining computer science

capabilities

Productivity Management Theories

u

Management Theories:

l X: Fredrick Taylor (1911) professes that more productivity with efficient production

l Y: Evans, Piazza, and Dolkas (1983) profess that stimulating more creativity and individual initiative brings better results

l Z: Gellerman (1978) profess that corporate culture and conflict resolution bring better results

u

They are all right – in their own respect

u

Theory-W moves the productivity equation

39

Theory-W: Win-Win?

u

Theory-W moves the productivity equation

outside of the internal organization

u

What makes a “win” for key stakeholders

u

Basic Steps

l Establish a set of win-win preconditions

–Understand how people want to win

–Establish reasonable expectations

–Match peoples’ tasks to their win conditions

–Provide supportive environment

Theory-W: Win-Win?

u

The Basic Steps (continued)

l Structure a win-win software process

–Establish a realistic process plan

–Use plan to control project

–Identify project’s “win-lose” and “lose-lose” risks

–Keep people involved

l Structure a win-win software product

–Match product to users and maintainers win conditions

41

Homework Assignment for 9/17/01

u Read Paper entitled, “Theory-W Software Project Management: Principles and Examples” by Boehm and Ross

u Read Paper entitled, “Using the WinWin Spiral Model: A Case Study” by Boehm, ...

l Summarize key points of assigned reading into a short 1 page paper (~300-500 words)

u Read SPMH Text Chapter 4

l Identify and collect 4 project management status report examples – hand them in with a short paragraph about each explaining the decisions it supports