-
1SOFTWARE PROJECT MANAGEMENT
NUTS & BOLTS
Robert J. [email protected]
September 22, 2014 Robert J. Schaaf
SCOPE: ALL TYPES OF SOFTWARE
All types of applicationsBusiness science and engineering sense
& control tools middlewareBusiness, science and engineering,
sense & control, tools, middleware
All types of configurationsHost-based, client-server, web-based,
embedded,
All types of offeringsCustom, generic / off-the-shelf,
component, service,
2
g p
All flavors of software engineeringNew or evolutionary
development, operations, acquisition,
Scope: Large, complex settings
-
2SCOPE: LARGE, COMPLEX SETTINGS
Projects with more than 5 10 people Projects with more than 5-10
people
Projects longer than ~6 months
Long-life software, an asset
3State of Affairs, from 30,000 feet
STATE OF AFFAIRS, FROM 30,000 FEET
Enormous progress over the past 40 years, particularly in
size
Shift from hardware-defined to software-defined systemsS 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
4
Still missing: Generally-accepted software management
framework
Real: DOS & DONTS for given projects Nuts & Bolts
We Will Touch On
-
3WE WILL TOUCH ON.
Requirements
Project Management
Process Assessment
5
Applies equally to development, acquisition and operations
Requirements
REQUIREMENTS
+ Stakeholders Stakeholder needs Quality
6Requirements Practice
-
4REQUIREMENTS 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 of the project and Yes, requirements change
7
p p j q 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
A stakeholder is a person with an interest in anything related
to the software:
Cast the net much wider than customer and user
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 say the designer of the applications business
processes
8
But also, say the designer of the 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.
Stakeholder NeedsTrade-off
-
5STAKEHOLDER NEEDS
Stakeholder need: A condition that must or should be
Distinguish between stakeholder needs and software
requirements
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 ft it lf
9
The software 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 NEEDSEnvironmental factorsUsability,
human factorsOperabilityInstallabilitySecurity
FunctionalityScheduleTimelinessCost, priceQuality
CompletenessMaintainabilityConfigurabilityFlexibilityScalability
y
Modes of operationPrivacyIntegrityProperty
rightsMerchantabilityGovernabilityRegulatory complianceStandards
compliance
AccuracyPerformanceCapacityResponsivenessEfficiencyEffectivenessSafetyReliability
yPrivacyAdaptabilityPortabilityInteroperabilityExtendibilityCompatibilitySimplicityModularity
10
Standards complianceInternational factorsAuditabilityAND SO
ON
ReliabilityAvailabilityServiceabilityRobustness
ModularityReusabilityTestabilityTrainability
FUNCTION OF PROBLEM DOMAIN AND STAKEHOLDER VALUESThe Subject
Software in its Environment
-
6THE SUBJECT SOFTWARE IN ITS ENVIRONMENT
ENVIRONMENT
SOFTWARE
11Stakeholder Needs
STAKEHOLDER NEEDS
ENVIRONMENT
12
Needs should be irrespective of the subject softwares
boundaryNeeds should be problem and goal oriented Software
Requirements
-
7SOFTWARE REQUIREMENTS
SOFTWARE
13
Software requirements delineate the subject software
Software Requirement
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 should be stated in the positive
14
q pnegatives are hard to prove
There should beno security holes Requirements, like needs, may
change
Requirement Types
-
8REQUIREMENT 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 requirements addressing: function; performance;
15
For example, requirements addressing: function; performance;
reliability; availability; safety, security; installability;
compatibility; scalability; software processes; schedule;
etc.
Who, What, How and When
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 casesDomain
scenarios
Mostly reactive: Feedback
Test cases
Mostly pro-active
Throughout the project Throughout the project
16Consensus and Quality
-
9CONSENSUS 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
17
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?
WHAT IF DISAGREEMENT ON REQUIREMENTS?
Project manager negotiates, in terms of software requirements,
not stakeholder needsrequirements, 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
18What if Requirements are Defective?
-
10
WHAT IF AGREED REQUIREMENTS ARE DEFECTIVE?
Worse, requirements may be unknowable, at least initiallySeveral
root causes of unknowabilityy
The more software, the more unknowability
Incremental evolution of needs > requirements >
software
ANSWER
Each increment based on best-available needs &
requirementsEach increment is a complete engineering cycle, but
short!Each increment released and used > improved
requirementsDEFINE QUALITY AS SATISFYING THE STAKEHOLDERS
19Feedback Loop
FEEDBACK LOOP
ENGINEERING OF NEXT INCREMENT
LIVE USE OF INCREMENT
STAKEHOLDER NEEDS
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 20Software Project Management
-
11
SOFTWARE PROJECT MANAGEMENTSOFTWARE PROJECT MANAGEMENT
21Case: System X
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..
22Typical Sources of Failure
-
12
TYPICAL SOURCES OF FAILURE
#1 Project coordination instead of project management
#2 Little or no planning, or not adaptive#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
23
#6 Unreasonable expectations go unchecked
Wild card: Personnel
A project is.
A project is.
A way of organizing work 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
24Project and Organization
-
13
PROJECT AND ORGANIZATION
Functional organization
Project organization
Matrix organization
25Functional Organization
FUNCTIONAL ORGANIZATION WORK TO THE PEOPLE
ProjectCoordinators
26
- 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 operationsProject
Organization
-
14
PROJECT ORGANIZATION PEOPLE TO THE WORK
SponsorProject A
27
- 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
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
& outputWith 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. 28Project Management Responsibilities
-
15
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 acceptedAchieve 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
29Project Management Responsibilities
PROJECT MANAGEMENT RESPONSIBILITIES Contd
7. Communication- Determine information needs > plan the
flows > track & correct
- Motivate project personnel recognize, explainMotivate 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
30Case: System X
-
16
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
31My Own Typical Priorities
MY PRIORITIES AS PROJECT MANAGER
PLANNINGPLANNING
EXECUTION
RISK
PERSONNEL
32How Do We Get a Plausible Plan?
-
17
HOW DO WE GET A PLAUSIBLE PLAN?
There are many planning methodologies
UNREALISTIC PLANNING LEADS TO REAL WASTE OF TIME AND EFFORT
e e a e a y p a g et odo og es
Our method:
1. Plan incrementally, as time progresses
2 Pl l i ti iti i d t il h tli > 6 th
33
2. Plan close-in activities in detail rough outline > 6
months
3. Do size-based planning around the Golden Triangle
Golden Triangle of Project Planning
GOLDEN TRIANGLE OF PROJECT PLANNING
WHAT=SCOPE
34
WHEN=TIMEHOW =ACTION
Size-Based Planning
-
18
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
SCOPESIZE
35
ACTION
EFFORT SCHEDULETIME
ITERATIVE PROCESS!What Gets Estimated for Size?
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
36
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
-
19
ITERATIVE PLANNING FOR EACH INCREMENT
SCOPESIZE
COSTEFFORT SCHEDULE
TIME
INCREMENTAL ENGINEERING
DO
CHECK
PLAN
ACT
DELIVERY
NEEDS FOR NEXT INCREMENT
USE & FEEDBACK
DEVELOPMENT / ACQUISITION
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
38
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 statusManaging the Execution of the Project Plan
-
20
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 plansWeekly
accounting of shortfalls recovery plans
- Weekly accounting of changes in plan and forecast
Every manager manages to every item in his/her plan
39Manage to Every Plan Item
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.
40Deviations May Come in Many Forms
-
21
DEVIATIONS COME IN MANY FORMSExamples
Outcomes not available in time Milestones not passed in time
Activities not finished in time Dependencies not satisfied in
time
Sizes larger than planned Staffing shortfalls Complexity higher
than planned
BUT MANY OTHER MEASURABLE/OBSERVABLE DEVIATIONS COME EARLIER IN
TIME:
41
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
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
42
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
-
22
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 j t t i ll ith i th i t l Major gates, typically with
six-months intervals- 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
43Management of Risk
MANAGEMENT OF RISKIN PROJECT PLANNING AND EXECUTION
Risk: The combination of the probability of an event
and its adverse consequencesand 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
44Manage Expectations
-
23
C i t U d id
MANAGE EXPECTATIONS
Communicate Up, down, side-ways
Plain-speaking, even bluntness, is good
The earlier the better
Generally audiences have a great sense of reality
45
Generally, audiences have a great sense of reality
Staffing Plan
STAFFING PLAN
Numbers dont make up for too few good people
A id b bbl t i t ffi l l Avoid bubbles or steps in staffing
level
Level headcount desirable all-rounders help
Implement staffing plan with sense of urgency
Making-up later for shortfalls near-impossible
E tend sched le or Extend schedule, or
Cut back on scope
46Pick the Right People to Work With
-
24
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
47
What to do with poor people? Identify them, then... Grow them Or
move them out
First Line Managers
FIRST LINE MANAGERS
PROJECT MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
48How Did the System X Story End
1ST LINE MANAGER
1ST LINE MANAGER
1ST LINE MANAGER
-
25
FIRST LINE MANAGERS
First line managers should be experienced, technically
excellent
Able to take over from any person in group, can break in new
people
TECHNICAL AND PERSONNEL LEADERS
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
49
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 requiredHow
Did the System X Story End
HOW DID THE SYSTEM X STORY END..
Release 2 Country B: Good design, chaotic process
Release 3 Country G: Lesser design good processRelease 3 Country
G: Lesser design, good process
Release 4 Target for convergence, not finished
Release 5 Unified design, coordinated process
AFTER ALLAFTER ALL
System X became a great commercial success
Served by a single software system
Series of Release 5 increments, never a Release 6 50Growing
Risks for Project Managers
-
26
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
51Software Process Assessment
SOFTWARE PROCESS ASSESSMENT
52What If
-
27
WHAT IF
Project manager does the wrong thing
or
Project manager unaware a process is defective
53Software Engineering Processes
SOFTWARE ENGINEERING PROCESSESAcquisitionSupply
Life cycle model
Stakeholder needsRequirements DesignConstructione cyc e ode
InfrastructureProject portfolioHuman resourcesQuality
strategyRe-use strategy
Project planning
ConstructionIntegrationDocumentationReview &
auditTestProblem resolutionQuality assuranceAssets for re-use
Project planningProject controlDecision makingRisk
managementConfiguration mgtInformation mgtMeasurement
Assets for re useQualificationInstallationAcceptance
OperationMaintenanceDisposal D
-
28
DEFECT FAILUREProcess defect >
Process failure >Software defect >
Software failure >
100-1,000 undiscovered software defects per million lines of
code
Even with defects, software works most of the time
Software failure >Stakeholder dissatisfaction
99.999% reliability with 5 MLOC and 5000+ defects
But: Increasing pressure on processes that have no process
defects
55Process Defect
PROCESS DEFECT
Process defect >Process failure >Process failure >
Software defect >Software failure >
Stakeholder dissatisfaction
A process may be defective in its:- Use
56
- Planning- Design- Control
What A Project Manager Can Do
-
29
WHAT A PROJECT MANAGER CAN DOTO IMPROVE THE PROJECTS
PROCESSES
+TO ASSURE ALL ABOUT THE PROJECTS PROCESSES
Root Cause Analysis
Of selected software failures & defects
57
What went wrong process-wise?
What Project Managers Cant Be
WHAT PROJECT MANAGERS CANT BE:INDEPENDENT
Software Process Assessment
An activity outside the control of the project managerThat
analyzes how work is done or not done
Our way:Analysis by hunting for process defects
That could lead to stakeholder dissatisfaction
58SPA: Who. What, When?
-
30
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!
59How We Hunt for Process Defects
HOW WE HUNT FOR PROCESS DEFECTS
Interview selected project members + stakeholders 30-40
interviews/assessor, 4+ weeks
A k l di ti f h f i t t Ask leading questions, for each process
of interest
- Is the process used? What is done? Who? How? When? Show!- Is
the use planned & controlled? Who, etc.- Is the process
designed? Who, etc.- What standards of performance?
Drill down where there appears to be a problem Sample code &
work products No extra testing
60
- What drives process improvement? Who, etc.
Outcome of an Assessment Effort
-
31
OUTCOME OF AN ASSESSMENT EFFORT
Hunt ends with report and presentation to sponsor+
- Findings of process defects, unshakeable facts
Recommendations for certain impro ements- Recommendations for
certain improvements
- Action plans on staff to implement recommendations
No happy talk, project manager pain, appreciation later
TBD: Sponsor charges project manager w/ implementation
61The Take-Away Message.
Assurance for sponsor and project managerthat the right
processes are done right.
THE TAKE-AWAY MESSAGE.
62
-
32
Quality is the common theme in my project management work
Stakeholder satisfaction + Less rework, less slack
A l j t th t t i i As long as a project goes on, the cost meter
is running
The shorter a project, the less project cost
Monetary benefit of the shorter schedule is higher than any
cost of quality
63
BOTTOM LINE: QUALITY IS FREE
