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