SOFTWARE PROJECT MANAGEMENT

NUTS & BOLTS

Robert J. Schaaf
rjschaaf@ieee.org
September 22, 2014

Robert J. Schaaf

SCOPE: ALL TYPES OF SOFTWARE

All types of applications
Business science and engineering
Business,
engineering, sense & control
control, tools,
tools middleware
middleware

All types of configurations

Host-based, client-server, web-based, embedded,

All types of offerings

Custom, g
generic / off-the-shelf, component,
p
service,

All flavors of software engineering

New or evolutionary development, operations, acquisition,

Scope: Large, complex settings

SCOPE: LARGE, COMPLEX SETTINGS

Projects with more than 5-10
5 10 people
Projects longer than ~6 months
Long-life software, an asset

State of Affairs, from 30,000 feet

STATE OF AFFAIRS, FROM 30,000 FEET

Enormous progress over the past 40 years, particularly in size
S
Shift from hardware-defined to software-defined systems
y
Still, too many failures in development, acquisition, operations
In many cases, big uncertainties in time, cost, quality and risk
Issues are managerial, not technical
Still missing: Generally-accepted software management framework
Real: DOS & DONTS for given projects Nuts & Bolts

We Will Touch On

WE WILL TOUCH ON.

Requirements
Project Management
Process Assessment

Applies equally to development, acquisition and operations

Requirements

REQUIREMENTS
+
Stakeholders
Stakeholder needs
Quality

Requirements Practice

REQUIREMENTS PRACTICE

In the profession, the requirements practice remains controversial

We have no time for requirements, Requirements always change, etc.

Alternatives for example, a project charter dont work well enough

Often, we have to fight for the practice of requirements

- Requirements answer Why this particular project?
- Set the scope
p of the project
p j
and Yes, requirements
q
change
g
- Serve as signposts and yardsticks in the course of the project
- Are critical in judging the readiness for delivery of the software

Stakeholders

STAKEHOLDERS
Cast the net much wider than customer and user
A stakeholder is a person with an interest in anything related to the software:
A. The software itself, incl. any property or attribute of the software
E.g.: the customer(s); the owner(s); the users
But also, say the legal department
B. The environment in which the software will be used
E.g.: the owner of a system interacting with the software
But also,
also say the designer of the applications
application s business processes
C. The processes applied during the life of the software
E.g.: developers; acquirers; trainers; sub-contractors
But also: internal audit, finance, marketers, sales, pricing, etc.

Trade-off

Stakeholder Needs

Distinguish between stakeholder needs and software requirements

STAKEHOLDER NEEDS
Stakeholder need: A condition that must or should be
fulfilled according to one or more stakeholders
Strength of need varies what value to stakeholder?
A need is owned/held by the respective stakeholder(s)
Others may help in the discovery & formulation of needs
Fulfillment of a stakeholder need may depend upon
Th
The software
ft
it lf
itself
The environment interoperating with the software
The processes to engineer the software
More than Function: Endless variety of types of needs

Sample Types of Stakeholder Needs

SAMPLE TYPES OF STAKEHOLDER NEEDS

Functionality
Schedule
Timeliness
Cost, price
Quality
Accuracy
Performance
Capacity
Responsiveness
Efficiency
Effectiveness
Safety
Reliability
Availability
Serviceability
Robustness

Completeness
Maintainability
Configurability
Flexibility
Scalability
y
Privacy
Adaptability
Portability
Interoperability
Extendibility
Compatibility
Simplicity
Modularity
Reusability
Testability
Trainability

Environmental factors
Usability, human factors
Operability
Installability
Security
y
Modes of operation
Privacy
Integrity
Property rights
Merchantability
Governability
Regulatory compliance
Standards compliance
International factors
Auditability
AND SO ON

FUNCTION OF PROBLEM DOMAIN AND STAKEHOLDER VALUES

The Subject Software in its Environment

10

THE SUBJECT SOFTWARE IN ITS ENVIRONMENT

ENVIRONMENT

SOFTWARE

Stakeholder Needs

11

STAKEHOLDER NEEDS
ENVIRONMENT

Needs should be irrespective of the subject softwares boundary

Needs should be problem and goal oriented

Software
Requirements

12

SOFTWARE REQUIREMENTS

SOFTWARE

Software requirements delineate the subject software

Software Requirement

13

SOFTWARE REQUIREMENT
A condition on the software, or on a software process,
to make the software acceptable to the stakeholders
Requirements vary in strength: must, should,
may, etc. all requirements are not equal
Requirements should have permissible cost data
Requirements
q
should be stated in the positive
p

negatives are hard to prove

Requirements, like needs, may change

There should be
no security holes

Requirement Types

14

REQUIREMENT TYPES
Similar to needs addressing everything of interest to the
stakeholders

Requirements must address everything that may

influence the acceptability of the software
For example,
example requirements addressing: function; performance;
reliability; availability; safety, security; installability;
compatibility; scalability; software processes; schedule; etc.

Who, What, How and When

15

WHO, WHAT, HOW AND WHEN

STAKEHOLDER NEEDS

SOFTWARE REQUIREMENTS

Responsibility of stakeholders

Responsibility of project manager

What the problem is

What the solution should+will do

Modeling of the domain, e.g.

- Business processes, workflows
- Domain scenarios

Modeling of the software, e.g.

- Use cases
- Test cases

Mostly reactive: Feedback

Mostly pro-active

Throughout the project

Throughout the project

Consensus and Quality

16

CONSENSUS AND QUALITY

For stakeholder consensus, stay away from needs as they may
conflict - use requirements as basis on which to reach consensus
A-priori consensus about what is to be engineered
A-posteriori consensus that the actual software is acceptable

Transformation from needs to requirements is non-deterministic,

same needs may lead to different requirements opportunity!
A requirement must be formulated in a way that makes it possible
to test for conformance in the course of the project
Working definition of quality: The degree that the software, at the
end of the project, meets software requirements

~~~ Requirements define quality ~~~

What If Disagreement on Requirements?

17

WHAT IF DISAGREEMENT ON REQUIREMENTS?

Project manager negotiates, in terms of software
requirements, not stakeholder needs
Whats wrong with the current iteration of software
requirements? > Rinse & repeat
Focus on bottom-line: Profit, mission, etc.
Persistent disagreement? Case: IBMs Future System

What if Requirements are Defective?

18

WHAT IF AGREED REQUIREMENTS ARE DEFECTIVE?

Worse, requirements may be unknowable, at least initially
y
Several root causes of unknowability
The more software, the more unknowability

ANSWER
Incremental evolution of needs > requirements > software
Each increment based on best-available needs & requirements
Each increment is a complete engineering cycle, but short!
Each increment released and used > improved requirements
DEFINE QUALITY AS SATISFYING THE STAKEHOLDERS
Feedback Loop

19

FEEDBACK LOOP
STAKEHOLDER
NEEDS

ENGINEERING OF
NEXT INCREMENT

LIVE USE OF
INCREMENT

RELEASE OF
FINAL
INCREMENT

NEW/CHANGED/REFINED
STAKEHOLDER NEEDS, SOFTWARE REQUIREMENTS

1-4 week cycle dependency on users able to take delivery

Stakeholder participation: use, feedback
Current practical problems with agile engineering:
(1) Design-in-small-chunks is very hard at best
(2) Low quality of each increment
(3) Total time from start to finish
(4) Does not scale well

Software Project Management

20

10

SOFTWARE PROJECT MANAGEMENT

Case: System X

21

CASE: SYSTEM X

Large, complex communications software system

Embedded in a new, make-or-break product family, X
1000 software engineers, 10 centers, 3 continents
Continuous coordination problems
Enter the first project manager..

Typical Sources of Failure

22

11

TYPICAL SOURCES OF FAILURE

#1

Project coordination instead of project management

#2

Little or no planning, or not adaptive

#3

Project plan implausible vis--vis past performance

#4

Poor execution, tracking & follow-up

#5

Unmanaged risks, small problems left to grow

#6

Unreasonable expectations go unchecked

Wild card: Personnel

A project is.

23

A project is.
A way of organizing work
Work with a beginning and an end
Work that leads to a unique result
As opposed to: Ongoing, repetitive work

Project and Organization

24

12

PROJECT AND ORGANIZATION

Functional organization
Project organization
Matrix organization

Functional Organization

25

FUNCTIONAL ORGANIZATION WORK TO THE PEOPLE

Project
Coordinators

- People understand their own work, but not the total

- Friction in pushing projects through, sub-optimization
- Unfriendly to complexity and uncertainty
- Works for software maintenance and operations

Project Organization

26

13

PROJECT ORGANIZATION PEOPLE TO THE WORK

Project A

Sponsor

- Organize in small teams (10-15) + fully-responsible project manager

- Flexibility, accommodates complexity and uncertainty
- People understand the total less their own contribution
- Nowadays, dominant model for software engineering

Project Management Responsibilities

27

PROJECT MANAGEMENT RESPONSIBILITIES

1. Organization Who
- Project manager is overall manager of the project, where the bug stops
- With total responsibility/accountability/authority for work & output
- Much delegation of responsibilities, authorities and accountabilities

2. Project Scope - What

- Identify stakeholders, elicit stakeholder needs, negotiate requirements
- Break down of work & output
- Maintain link between {needs, requirements} and {work, output}

3. Use of Time - When

- Sequence activities, unearth dependencies and assumptions
- Estimate resources x time for each activity
- Create & maintain project schedule, verify against resource planning etc.

Project Management Responsibilities

28

14

PROJECT MANAGEMENT RESPONSIBILITIES Contd

4. Cost
- For each activity, estimate the costs of the resources needed
- Aggregate the estimated costs in a budget, suitable for control
- Control actuals against budget, control changes in budget

5. Quality
- Establish and maintain a quality management system
- Rule #1: Quality is everybodys responsibility
- Every task, output has an owner + keep owners feet to the fire
- Achieve stakeholder satisfaction, get output accepted

6. Staff
- Develop and execute a staffing plan
- Analyze actual competencies against needs, plan training if necessary
- Track individual and team performance, provide feedback, resolve issues

Project Management Responsibilities

29

PROJECT MANAGEMENT RESPONSIBILITIES Contd

7. Communication
- Determine information needs > plan the flows > track & correct
- Motivate project personnel recognize, explain
- Massage stakeholder expectations

8. Risk
- Establish a risk management system, control its performance
- Track major dependencies and assumptions, analyze plan deviations
- Identify high risks - continuously
- Mitigate high risks: alternative courses of action, fallback plans

9. Procurement
- Set make-or-buy direction, approve make-or-buy decisions
- Control: identification and selection of sellers; contracting + fulfillment

Case: System X

30

15

CASE: SYSTEM X

Large, complex communications software system

1000 software engineers, 10 centers, 3 continents

Enter the first project manager.

Full project management responsibility + accountability

Direct authority over 1/3 of staff
Controlling operating system, tools, plans & controls

My Own Typical Priorities

31

MY PRIORITIES AS PROJECT MANAGER

PLANNING
EXECUTION
RISK
PERSONNEL

How Do We Get a Plausible Plan?

32

16

HOW DO WE GET A PLAUSIBLE PLAN?

UNREALISTIC PLANNING LEADS TO REAL WASTE OF TIME AND EFFORT

There
e ea
are
e many
a yp
planning
a
g methodologies
et odo og es
Our method:
1. Plan incrementally, as time progresses
2 Plan
2.
Pl close-in
l
i activities
ti iti iin d
detail
t il rough
h outline
tli > 6 months
th
3. Do size-based planning around the Golden Triangle

Golden Triangle of Project Planning

33

GOLDEN TRIANGLE OF PROJECT PLANNING

WHAT=SCOPE

HOW =ACTION

WHEN=TIME

Size-Based Planning

34

17

SIZE-BASED PLANNING
- From requirements ( > design specs ), estimate size
- From size, estimate effort for precision, also consider complexity etc.
- Based on size and effort, set (adjust) staffing level and time schedule
- If necessary, change requirements to affect size > effort > schedule
SIZE
SCOPE

ACTION

TIME

EFFORT

SCHEDULE

ITERATIVE PROCESS!

What Gets Estimated for Size?

35

WHAT GETS ESTIMATED FOR SIZE?

MOST OFTEN: Code to be developed, acquired or used

Requirements to be specified (or modeled)

Design to be specified (or modeled)

Architecture to be developed/maintained

Tests to be developed and performed

Parts to be integrated

Documentation and training materials to be developed

Processes to be designed, planned, installed and maintained

Tools to be developed, acquired, installed and maintained

Iterative Planning for Each Increment

36

18

ITERATIVE PLANNING FOR EACH INCREMENT

SIZE
SCOPE

COST

TIME

SCHEDULE

EFFORT

INCREMENTAL ENGINEERING
PLAN

DO
DEVELOPMENT / ACQUISITION
DELIVERY

NEEDS FOR NEXT

INCREMENT

USE & FEEDBACK

ACT CHECK

A Plausible Plan Also Has.

A PLAUSIBLE PLAN ALSO HAS.

Commitment, buy-in explicit, from all actors, and lasting

No commitment equals no plan

Review, comments and silence are no commitments

Brevity - No unnecessary detail, no unnecessary precision

Only specifics that will be checked (measured, counted) and insisted on

Only specifics where deviation would require extra action
No guidelines, no project introduction plan is not for training

Process for the identification and ranking of risks and dependencies

Dependencies on other projects, capital equipment, outside vendors

Identification of responsible parties, other plans
Test whether parties are able, planning and performing to satisfy the dependencies

Currency a project plan is a living thing, planning is continuous

Common sense for example, no plan without contingency resources
A few major milestones (and criteria) for broad visibility of project status

Managing the Execution of the Project Plan

38

19

MANAGING THE EXECUTION OF THE

PROJECT PLAN : TRACKING & FOLLOW-UP
At the individual level: Daily reporting in stand-up mtgs
At managers levels:
- Weekly reporting against plan and forecast
- Weekly forecasting for next week and next 4 weeks
- Weekly accounting of shortfalls > recovery plans
- Weekly accounting of changes in plan and forecast
Every manager manages to every item in his/her plan

Manage to Every Plan Item

39

MANAGE TO EVERY PLAN ITEM

Corollaries: That which is not managed will not happen except by luck +
If its not that important, it should not be in the plan

Impossible to achieve every plan item recognize deviation and recover,

locally or by plan changes: cutbacks, delays, additional resources.

Deviations May Come in Many Forms

40

20

DEVIATIONS COME IN MANY FORMS

Examples

Outcomes not available in time

Activities not finished in time

Milestones not passed in time

Dependencies not satisfied in time

BUT MANY OTHER MEASURABLE/OBSERVABLE

DEVIATIONS COME EARLIER IN TIME:
Sizes larger than planned
Staffing shortfalls
Complexity higher than planned
Hidden assumptions, hidden dependencies
Appearance of important outputs not shown in the plan
Substantial activities underway not shown in the plan
Activities taking more staff than planned
More re-work than planned

Manage to Every Plan Item Contd

41

MANAGE TO EVERY PLAN ITEM

Corollaries: That which is not managed will not happen except by luck + If its not that
important, it should not be in the plan

Impossible to achieve every plan item recognize deviation and recover, locally or by
plan changes: cutbacks, delays, additional resources.

People respond to, and accomplish, things which they perceive are
important to their leaders they perceive important those things on
which their leaders act, not talk

You have to act in a way that makes visible your concern with the item

Early items are as important as later ones

That which is important must be managed

made visible by management action

More Tracking & Follow-up: By the Sponsor

42

21

MORE TRACKING & FOLLOW-UP: BY THE

SPONSOR
Project managers Progress & Issues report, weekly
Regular reviews, typically once per month
- Project manager is lead presenter often the only one
- Basically for the information of sponsor and sponsors staff
- Good questions + No, or minor, course corrections
M
Major
j gates,
t
t i ll with
typically
ith six-months
i
th intervals
i t
l
- Gate tied to a major, visible project milestone
- Project manager is one of the presenters
- With all stakeholders, providing their assessment
- Go/no-go decisions: Incremental commitment

Management of Risk

43

MANAGEMENT OF RISK
IN PROJECT PLANNING AND EXECUTION

Risk: The combination of the probability of an event

and its adverse consequences
Categories of risk sources:
Action, Assumption, Dependency, Estimate, etc.

Prepare alternative courses of action

Have fallback positions ready
Risk assessment + mitigation is continuous
A nasty source of risk: Expectations

Manage Expectations

44

22

MANAGE EXPECTATIONS
C
Communicate
i t Up,
U d
down, side-ways
id
Plain-speaking, even bluntness, is good
The earlier the better
Generally audiences have a great sense of reality
Generally,

Staffing Plan

45

STAFFING PLAN
Numbers dont make up for too few good people
Avoid
A id bubbles
b bbl or steps
t
in
i staffing
t ffi level
l
l
Level headcount desirable all-rounders help
Implement staffing plan with sense of urgency
Making-up later for shortfalls near-impossible
Extend
E tend schedule,
sched le or
Cut back on scope

Pick the Right People to Work With

46

23

PICK THE RIGHT PEOPLE TO WORK WITH

People's performance follows an exponential curve:
Good people 10x better than average people
Average people infinitely better than poor people
Poor people make work for other people
Average people do work
Good people solve problems, minimize the work
What to do with poor people? Identify them, then...
Grow them
Or move them out

First Line Managers

47

FIRST LINE MANAGERS

PROJECT
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

1ST LINE
MANAGER

48

How Did the System X Story End

24

FIRST LINE MANAGERS

TECHNICAL AND PERSONNEL LEADERS
First line managers should be experienced, technically excellent
Able to take over from any person in group, can break in new people
Should be a principal contributor to the design of the software
Responsible for reviewing 100% of the code of his/her group
Responsible for group-level planning and tracking
Responsible for optimal work environment in the broadest sense
Size of group needs to be limited to make the above realistic
Manager gets to learn who the good/average/poor people are
Manager finds out early whether the software will work
Manager can step in in case of staffing emergencies
Managers review better and cheaper than code inspections
Benefits justify the increased number of managers required

49

How Did the System X Story End

HOW DID THE SYSTEM X STORY END..

Release 2 Country B: Good design, chaotic process
design, good process
Release 3 Country G: Lesser design
Release 4 Target for convergence, not finished
Release 5 Unified design, coordinated process

AFTER ALL
System X became a great commercial success
Served by a single software system
Series of Release 5 increments, never a Release 6

Growing Risks for Project Managers

50

25

GROWING RISKS FOR PROJECT MANAGERS

LOSS OF SOME CONTROL BECAUSE OF:
Partial return of functional organizations
More outsourcing and contractors
More acquisition, less development
More attempts to re-use software
More service, cloud-based components
Pull between agile and control
More complexity > loss of intellectual control

Software Process Assessment

51

SOFTWARE PROCESS ASSESSMENT

What If

52

26

WHAT IF

Project manager does the wrong thing

or

Project manager unaware a process is defective

Software Engineering Processes

53

SOFTWARE ENGINEERING PROCESSES

Acquisition
Supply
Life
e cyc
cycle
e model
ode
Infrastructure
Project portfolio
Human resources
Quality strategy
Re-use strategy

Project planning
Project control
Decision making
Risk management
Configuration mgt
Information mgt
Measurement

Stakeholder needs
Requirements
Design
Construction
Integration
Documentation
Review & audit
Test
Problem resolution
Quality assurance
Assets for re-use
re use
Qualification
Installation
Acceptance
Operation
Maintenance
Disposal

27

DEFECT FAILURE
Process defect >
Process failure >
Software defect >
Software failure >
Stakeholder dissatisfaction

100-1,000 undiscovered software defects per million lines of code

Even with defects, software works most of the time
99.999% reliability with 5 MLOC and 5000+ defects
But: Increasing pressure on processes that have no process defects

Process Defect

55

PROCESS DEFECT
Process defect >
Process failure >
Software defect >
Software failure >
Stakeholder dissatisfaction

A process may be defective in its:

- Use
- Planning
- Design
- Control

What A Project Manager Can Do

56

28

WHAT A PROJECT MANAGER CAN DO

TO IMPROVE THE PROJECTS PROCESSES
+
TO ASSURE ALL ABOUT THE PROJECTS PROCESSES

Root Cause Analysis

Of selected software failures & defects

What went wrong process-wise?

What Project Managers Cant Be

57

WHAT PROJECT MANAGERS CANT BE:

INDEPENDENT
Software Process Assessment
An activity outside the control of the project manager
That analyzes how work is done or not done
Our way:
Analysis by hunting for process defects
That could lead to stakeholder dissatisfaction

SPA: Who. What, When?

58

29

SPA: WHO, WHAT, WHEN?

Who:

One or more assessors, we

- Independent from the project manager
- Typical sponsors: CEO, CTO, Div. President

What:

The processes of one or more projects, or the

processes of an organization

When (1): After completion of the process - Sometimes

When (2): In the course the use of the processes Good!
When (3): In the course of process planning Ideal!

How We Hunt for Process Defects

59

HOW WE HUNT FOR PROCESS DEFECTS

Interview selected project members + stakeholders
30-40 interviews/assessor, 4+ weeks
Ask
A k lleading
di questions,
ti
for
f each
h process off interest
i t
t
- Is the process used? What is done?
- Is the use planned & controlled?
- Is the process designed?

Who? How? When? Show!

Who, etc.

Who, etc.

- What standards of performance?

- What drives process improvement?

Who, etc.

Drill down where there appears to be a problem

Sample code & work products No extra testing

Outcome of an Assessment Effort

60

30

OUTCOME OF AN ASSESSMENT EFFORT

Hunt ends with report and presentation to sponsor+
- Findings of process defects, unshakeable facts
- Recommendations for certain improvements
impro ements
- Action plans on staff to implement recommendations
No happy talk, project manager pain, appreciation later
TBD: Sponsor charges project manager w/ implementation

Assurance for sponsor and project manager

that the right processes are done right.

The Take-Away Message.

61

THE TAKE-AWAY MESSAGE.

62

31

 Quality is the common theme in my project management work

Stakeholder satisfaction + Less rework, less slack
As
A llong as a project
j t goes on, the
th costt meter
t is
i running
i
The shorter a project, the less project cost
Monetary benefit of the shorter schedule is higher than any
cost of quality

BOTTOM LINE: QUALITY IS FREE

63

32