The Art of Successful Software Project Management

1
The Art of Successful Software Project Management

• Professor William Poole, Ph. D.
• Computer Science
• Software Engineering

7 July 2003
2
Mini-Résumé

• Seattle University
• Director of Software Engineering
• New chair of Computer Science Software Eng.
  department
• Technical, Software, Internet Businesses
• Boeing
• Pacific Analysis
• Fine.com
• Aris Corporation
• Cobalt Group
• College of William Mary
• U. California, Berkeley and U. Texas, Austin

2
3
Overview The Art of Successful Software Project
Management

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

3
4
Software Projects

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

4
5
Software ProjectsThe Mythical Man-Month

• Frederick Brooks
• IBM System/360
• 1975
• 1995

5
6
Software ProjectsThe Mythical Man-Month

• Lessons learned from failures
• Workers months are not interchangeable
• Architectural integrity is important
• Communication organization are critical
• Weak techniques of estimating
• Effort is not progress
• Poorly monitored schedule
• Adding more people to a late project hurts

6
7
Software ProjectsThe Mythical Man-Month

• Other lessons learned
• Programmers are (too) optimistic
• Cost does vary as the product of people and
  months
• Progress does not
• Testing is usually the most mis-scheduled part of
  programming
• Urgency of the customer may govern the scheduled
  completion, but it cannot govern the actual
  completion

7
8
Software ProjectsRational Unified Process

• Rational Unified Process (RUP)
• http//www.rational.com
• IBM, February, 2003
• The primary standard in the U.S. for large-scale
  software development project management
  methodology

8
9
Software ProjectsRational Unified Process

• Life-Cycle Phases
• Engineering Stage
• Inception (achieve agreement on objectives)
• Elaboration (design a solution architecture
  infrastructure, control and data interfaces that
  permit component cooperation)
• Production Stage
• Construction (all remaining components and
  application features are integrated into the
  system thorough testing)
• Transition (deploy in end-user domain beta
  testing conversion of databases training)

9
10
Software ProjectsRational Unified Process

• Iteration
• Represents a sequence of activities for which
  there is a well-defined milestone
• Each of the four phases consists of
• one or more iterations
• in which some technical capability is produced
• in demonstrable form and
• assessed against a set of criteria

10
11
Software ProjectsLarge-scale System Failures

• Large information systems (Standish Group)
• About 25 were considered failures
• Another 50 overran their budget or schedule,
  thus losing some of the promised payoff
• Of remaining 25, some undetermined number failed
  to meet the cost savings or business
  transformation objectives

11
12
Software ProjectsLarge-scale System Failures

• 7 reasons for failure Dr. A. M. Erisman
  (Boeing)
• Bad ideas (fails to address business need)
• Corporate immune systems (people dont want to
  change)
• Lack of shared ownership (projects run only by IS
  department or only by business unit)
• Poor requirements process

12
13
Software ProjectsLarge-scale System Failures

• Erisman 7 reasons for failure
• Lack of systems thinking (think about interaction
  with others)
• Fundamental complexity (changes in hardware,
  software and business add complexity)
• Program management weakness (this is difficult
  work, conflicting demands)

13
14
Software ProjectsProcess Improvement

• The Capability Maturity Model for Software (CMM
  or SW-CMM)
• Evaluate the maturity of the software processes
  of an organization and
• Identify the key practices that are required to
  increase the maturity of these processes
• SW-CMM has been developed by the software
  community with stewardship by the SEI (Software
  Engineering Institute of Carnegie Mellon
  University in Pittsburgh, USA

14
15
Software ProjectsProcess Improvement

• SW-CMM Purpose
• Help software organizations improve processes
• from ad hoc, chaotic processes
• to mature, disciplined software processes
• 5 maturity levels
• Initial varies, chaotic
• Repeatable PM processes for cost, schedule,
  functions
• Defined management and engineering processes
  are standardized and documented
• Managed measurement of process and quality
• Optimizing quantitative feedback used to improve

15
16
Small Projects

• A large majority of projects do not require the
  detail of RUP - Adoption can be painful
• A majority of labor hours are worked on smaller
  projects
• What are the minimum steps we must take to be
  successful with RUP?

16
17
Small Projects

• Ten Essentials of camping and hiking
• Map
• Compass
• Sun protection
• Extra clothing
• Extra water and food
• Flashlight
• Matches
• Knife
• Cookware
• First-aid kit

17
18
Small Projects

• Ten Essentials of Project Management Leslee
  Probasco, Rational
• Develop a vision have a clear vision that
  addresses the stakeholders real needs
• Manage to the plan Software Development Plan
  contains all information required to manage the
  project
• Identify and track issues identify and attack
  the highest risk items early
• Assign and track issues regular status
  assessments provide the mechanism for addressing,
  communicating and resolving issues
• Examine the business case needed to determine
  whether or not the project is a worthwhile
  investment

18
19
Small Projects

• Ten Essentials of Project Management (continued)
• Design a component architecture organization or
  structure of systems significant components and
  how they interact
• Incrementally build and test code, build, test
  components throughout lifecycle, producing
  executable releases at end of each iteration
  after inception
• Verify and evaluate results assess how an
  iteration met the evaluation criteria
• Manage and control changes to the scope of the
  project as changes occur throughout the lifecycle
• Provide user support deliver product with
  materials to assist the end-user in learning,
  using and maintaining the product

19
20
Small Projects

• Using RUP for Small Projects Expanding upon
  eXtreme Programming Gary Pollice
• Inception (4 essential activities)
• Formulate the scope of the project
• Plan and prepare the business case
• Synthesize a candidate architecture
• Prepare the project environment
• Artifacts (human-made docs, software, diagrams,
  etc.)
• Approved Business Case
• Risk List
• Preliminary Project Plan
• Project Acceptance Plan
• Plan for initial Elaboration Iteration
• Initial Use-Case Model

20
21
Small Projects

• Using RUP for Small Projects
• Elaboration (3 essential activities)
• Define, validate and baseline the architecture
• Refine the Vision
• Create and baseline iteration plans for
  Construction phase
• Artifacts
• Update those from Inception Phase
• Software Architecture Document (SAD)
• Iteration Plans for Construction

21
22
Small Projects

• Using RUP for Small Projects
• Construction (3 essential activities for each
  iteration)
• Manage resources and control process
• Develop and test components
• Assess the iteration
• Artifacts
• Components (source, binary, or executable
  ReadMe)
• Training materials
• Deployment Plan
• Transition Phase Iteration Plan

22
23
Small Projects

• Using RUP for Small Projects
• Transition (4 essential activities)
• Finalize end-user support material
• Test the product deliverable in a customer
  environment
• Fine tune the product based upon customer
  feedback
• Deliver the final product to the end user
• Artifacts
• Deployment plan
• Release notes
• Training materials and documentation

23
24
Internet Projects

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

24
25
Internet Projects

• Organizational Change in the Internet Age Sid
  Fuchs
• Internet Age changes rapidly
• Plan or Product is never finished
• No annual releases
• Monthly, weekly, daily for software
• hourly, instantaneously for information
• CNN, ESPN, FT

25
26
Internet Projects

• Laying the Foundation for Organizational Change
• Leadership support at all levels?
• Vision and Planning flexible, understood
• Reasonable Alternatives options evaluated?
• Culture and Behavior people willing?
• Skills, Resources, and Personnel what is
  needed?
• Technology what is needed?

26
27
Internet Projects

• Top 10 Best Practices for Org. Change
• Identify and agree on key change drivers (time to
  market, efficiency)
• Create demand for change not force
• Consistent leadership and communication
• Continually update and fine tune vision
• Achieve incremental, demonstrable success

27
28
Internet Projects

• Top 10 Best Practices for Org. Change
• Find champions for your solutions
• Acquire and develop new employee skill sets
• Establish a collaborative environment
• Collect and use metrics to monitor progress
• Overhaul incentives before you begin
• Bonus Find the right pace

28
29
Internet Projects

• How Internet Companies Build Software, Alan
  MacCormack
• The Question Does a more evolutionary
  development process result in better performance?
• Interview PMs in industry to understand practices
• Develop metrics to characterize the type of
  process used
• Incorporated in a survey of 29 projects at 17
  companies
• Performance of product panel of 14 experts
• Resource productivity Lines of new code per
  person-day, adjusted for complexity

29
30
Internet Projects How Internet Companies Build
Software

• 4 Practices That Lead To Success
• An early release of the evolving product design
  to customers
• Daily incorporation of new software code and
  rapid feedback on design changes
• A team with broad-based experience of shipping
  multiple projects
• Major investments in the design of the product
  architecture

30
31
Internet Projects How Internet Companies Build
Software

• An Early Release of the Evolving Product Design
  to Customers
• Evolutionary approach start with most important
• Works well with iterative process
• Low functionality at first ? most successful
• Reduces risk

31
32
Internet Projects How Internet Companies Build
Software

• Daily Incorporation of New Software Code and
  Rapid Feedback on Design Changes
• Require process that allows teams to interpret
  new information quickly
• Make appropriate design changes
• High correlation between rapid feedback and
  success

32
33
Internet Projects How Internet Companies Build
Software

• A Team With Broad-Based Experience of Shipping
  Multiple Projects
• Average tenure in years had no association with
  either quality or productivity
• Number of project generations was a powerful
  predictor of productivity

33
34
Internet Projects How Internet Companies Build
Software

• Major Investments in the Design of the Product
  Architecture
• Key to an evolutionary process is to develop an
  architecture that is both modular and scaleable
• Loosely coupled nature buffers the effect of
  changes
• Scaleable system allows initially unanticipated
  functions to be added

34
35
Internet Projects

• The Softer Side of Custom Software Development
  Working with the Other Players
• Software engineers must understand and work with
  professionally diverse people
• Project manager
• Graphic designer
• Interaction designer
• Usability specialist
• Sales
• marketing

35
36
Cost and Time Estimation

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

36
37
Cost Time Estimation

• Mistakes we make
• Construx Softwares 10 Deadly Sins of Software
  Estimation
• What can be done
• Steve Tockeys Software Estimation Chalk-talk
• Look for his new book later this year

37
38
10 Deadly Sins of Software Estimation

• Confusing targets with estimates
• Business managers set targets
• Created without analysis of system
• Are you supposed to estimate cost or figure out
  how to meet a target?
• Iterative process to bring targets and estimates
  into alignment

38
39
10 Deadly Sins of Software Estimation

• Saying yes when you really mean no
• Software developers tend to be introverts and
  relatively young
• Managers, marketing and sales personnel tend to
  be extroverts and organizationally senior
• Understand what is expected of you
• Learn to say no or maybe when it is
  appropriate

39
40
10 Deadly Sins of Software Estimation

• Committing to estimates too early
• Pressure applied to get estimate out early to
  satisfy the customer
• Plan to revise estimates throughout the project

40
41
10 Deadly Sins of Software Estimation

• Assuming underestimation has a neutral impact on
  project results
• Underestimation has a super-linear impact due to
  planning errors, upstream defects, high-risk
  practices
• If you overestimate, you will use up the time

41
42
10 Deadly Sins of Software Estimation

• Estimating in the impossible zone
• Suppose you need to drive 100 km/hour for 20 km.
  Because of traffic you drive the first 10 km at
  only 50 km/hour. How fast do you have to drive
  for the second 10 km to meet your goal?
• Assume a maximum possible schedule compression
  (when you get behind) of about 25.

42
43
10 Deadly Sins of Software Estimation

• Overestimating savings from new tools or methods
• Using only one estimation technique
• Not using estimating software
• Not including risk impacts in estimates
• Providing off-the-cuff estimates

43
44
Good, Better and Best Practices

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

44
45
Good (Better, Best?) Practices

• Principles and Best Practices of Software Project
  Management
• Best Practices (Rational)
• Principles of Software Development (Humphrey)
• Project Management Tips

45
46
Best Practices (Rational)

• Develop Iteratively
• Manage Requirements
• Use Component Architectures
• Model Visually
• Continuously Verify Quality
• Manage Change
• See www.rational.com

46
47
Best Practices 1. Iteration

• Life-cycle consists of several iterations
• Each is time-constrained
• Each ends with a progress milestone
• Address and mitigate risk early and continuously
• Frequent executable releases demonstrate progress

47
48
Best Practices 2. Manage Requirements

• Systematic approach to
• Finding
• Documenting
• Organizing and
• Tracking
• changing requirements

48
49
Best Practices 3. Component Architectures

• Components are non-trivial modules that fulfill a
  clear function
• Architectures based on components tend to reduce
  effective size and complexity
• robustness
• resiliency
• lower costs

49
50
Best Practices 4. Model Visually

• Semi-automatic graphical and textual design
  notations e.g., UML to capture software
  designs
• Hide details and write code using graphical
  building blocks

50
51
Best Practices 5.Continuously Verify Quality

• Poor performance and reliability are common
  results of an inadequate focus on software
  quality
• Quality throughout project, testing in each
  iteration

51
52
Best Practices 6. Manage Change

• Establish repeatable procedures for managing
  change to
• Software
• Artifacts
• Minimize chaos
• Maximize efficient allocation of resources
• Ensures freedom to change

52
53
Principles of Software Development (Watts
Humphrey, SEI, CMU)

• Programming
• Track and Report
• Plan Every Project
• Use a Measured Process
• Design Before You Build
• Quality is the Top Priority
• The Best Projects
• The Best Teams

53
54
Programming

• Your job is to transform poorly understood,
  poorly described and rapidly changing needs into
  precise machine instructions. People really dont
  know what they want its your job to find out.
• When you really know the needs, you can build it.
• When you think you know, you are wrong.
• Then, you must experiment and prototype.
• Get expert feedback on the experiment.
• When experts agree, you build it.

54
55
Track and Report

• Businesses and government agencies run on
  schedules and commitments. You must also. Resolve
  differences in the project and the calendar.
• Your customers and managers must know the status
  of your work.
• To accurately report on status, you must measure
  status.
• To measure status, you must have measurable plans.

55
56
Plan Every Project

• Never make or change a commitment without a plan.
• The people who do the work should make the plan.
• If you cant plan accurately, at least plan
  often.
• Plan what you know and at a level that fits the
  job.
• If the plan doesnt fit the job, revise the plan.
• Base plans on historical data.
• Comparable data requires similar plans.
• Similar plans requires similar processes.

56
57
Use a Measured Process

• To measure your work, you must define its
  measures.
• To define the measure, you must know the job
  steps.
• Tailor the process to fit the work.
• For different kinds of work, use different
  processes.
• When the process doesnt fit the job, change the
  process.
• Use the process to measure, plan, track the
  work.

57
58
Design Before You Build

• Start with the best requirements you can get.
• Recognize that the requirements will change
  throughout the job (thats the way the world is).
• Take small steps (iterations, components).
• Design what you know.
• Explore what you dont know.
• When you know enough, design and build it.

58
59
Quality is the Top Priority

• If it didnt have to work, you could build it
  fast.
• It is always fastest to do the job right the
  first time.
• Rework and repair is wasteful.
• The sooner you fix it, the better.
• Focus on quality from the beginning of the job.
• Quality without numbers is just talk.

59
60
The Best Projects

• The best projects are a careful balance of
  conflicting forces. They must consider
• Customer desires
• Your business needs
• Technical capability
• Product quality will suffer if any is neglected.
• To build the superior products, teams must
  understand the complete context of their projects.

60
61
The Best Teams

• The best teams
• Define their own processes
• Produce their own plans
• Make their own commitments
• Direct their own projects
• Consistently use their selected methods
• Develop the best products
• www.sei.cmu.edu/tsp/watts-bio.html

61
62
Low Hanging Fruit (Steve McConnell Construx)

• The idea Practices that are easy/smart to use
• Numerous Good Practices Have Existed for Decades
• ROI of Good Software Practices is Well
  Established
• Should Have Been Adopted Long Ago
• But Many Good Practices Have Not Been Universally
  Adopted

62
63
Low Hanging Fruit Criteria

• Low cost of adoption
• Good or very good chance of first-time success
• Excellent chance of long term success
• Short time to positive ROI

63
64
Low Hanging Fruit Candidates

• McConnells list was at 58 one month ago
• Few samples
• Coding standards
• Customer orientation
• Daily build and smoke test
• Design for change
• Education
• Hire top talent
• Inspections
• Joint Application Design (JAD)
• Outsourcing
• Planning tools, automated
• Reuse
• Source code control
• Up-front planning, requirements, design

64
65
Not Low Hanging Fruit

• RUP tree, not fruit not low cost
• Developing code for reuse long time to ROI
• Pair Programming no hard evidence of positive
  ROI
• CASE Tools not low cost low chance of
  first-time success
• Use Cases not a high chance of first-time
  success

65
66
Low Hanging Fruit How Do You Start?

• It Depends on Who You Are and Your Sphere of
  Influence
• Developer
• Technical Lead
• Manager
• Executive

66
67
And, Finally, One Last Way to Say It

• Develop a Roadmap
• Build 6-, 9-, 12-, or 24-month plans that fit
  your environment but also stretch you
• Schedule date-based, frequent predictable
  releases
• The plan must acknowledge opportunities for
  change
• Frequently revisit the plan
• Why?
• You wont cram everything into a single release
• Provide concrete comparisons for new scope creep

67
68
One Last Way to Say It

• Early Milestones
• Drive closure on features and priorities
• Propose a straw man scope feature list,
  rather than wait on precision
• Set stick to milestones during early phases
• Works best with experienced PM/Dev leads
• Why?
• End date is far out, who cares if we miss early
  milestone?
• Set a good example for project

68
69
One Last Way to Say It

• Processes
• Dont get hung-up on adhering to all details of
  methodology
• Certain aspects of all projects require process
  but others should be assessed within real-world
  context
• Must-haves
• High-level development process concept, design,
  construct, deploy
• Change management
• Feature prioritization
• Maybe-haves (situation-based)
• Specific process pseudo-waterfall, RUP,
  Iterative, Evolutionary
• Formalized sign-offs
• Feature-based ROI

69
70
One Last Way to Say It

• Planning
• WBS
• Schedule tasks
• Software Primavera, MS Project, Excel, grid
  paper
• Other
• Company culture Boeing or Bobs Garage Software
  Shop
• Strategic nature of product get it right or
  time-to-market
• Project post-mortem review, incorporate
  suggestions into process framework
• For estimating, look at data, compare to similar
  projects, look at team makeup

70
71
References

• Large Projects
• Fred Brooks, The Mythical Man-Month, 1995
• www.rational.com, 2003
• Walker Royce, Software Project Management A
  Unified Framework, 1998
• Al Erisman, Large-scale System Failures, Ethix,
  2003
• www.sei.cmu.edu/cmm
• Small Projects
• www.rei.com
• Leslee Probasco, The Ten Essentials of RUP,
  2001
• Gary Evans, A Simplified Approach to RUP, 2001
• Gary Pollice, Using the Rational Unified Process
  for Small Projects, 2002
• Internet Projects
• Sid Fuchs, Organizational Change in the Internet
  Age, 2001
• Alan MacCormack, How Internet Companies Build
  Software, MIT Sloan Management Review, 2001
• William G. Poole, The Softer Side of Custom
  Software Development Working with the Other
  Players, IEEE Conference on Software Engineering
  Education Training 2003
• Cost and Estimation
• Steve Tockey, 10 Deadly Sins of Software
  Estimation and Software Estimation Chalk-talk,
  2003
• Good, Better and Best Practices
• Watts Humphrey, The Principles of Software
  Development, 2003

71
72
Summary

• Software Project Management
• Software Projects
• Internet Projects
• Cost and Time Estimation
• Good, Better and Best Practices

72