Roadmap to a Project Plan

1
Roadmap to a Project Plan

• George Girod
• Great Lakes Software Process Improvement Network
• October 11, 2007

Infowidget LLC
2
Who is the intended audience?

• Newly anointed Project Managers
• Their boss came in with a magic wand and now they
  are project managers
• Training will be provided sometime soon when just
  this (or these) project(s) are done.
• Here is a sample schedule for a project just like
  yours.
• Here is the schedule, go forth and prosper.

Infowidget LLC
3
Who is the intended audience?

• Technical Leads, Testing Leads, Analysts
• Executing a project plan
• Called on to estimate or sign off on a plan
• Working feverishly trying to get a project back
  on schedule (notice I did not say under control)
• Leading a team without a project manager

Infowidget LLC
4
Who is the intended audience?

• Experienced Project Managers
• Just want to learn more / different perspective
• Fun to discuss different approaches that is the
  point of GL-SPIN
• Wondering why projects seem to run over so
  consistently
• Want ideas to improve project success and
  establish new processes
• Level 3 really requires attention to PM Issues.

Infowidget LLC
5
Who is the intended audience?

• Auditors, Security Experts, IT Infrastructure,
  Business Owners
• If it doesnt get planned it doesnt get done
• Building Security In
• Audit Requirements / Governance
• What should the constituents or stakeholders
  expect from a project plan? How can they express
  their expectations?

Infowidget LLC
6
Who is the intended audience

• Members on outsourced projects
• Maybe a portion of project is outsourced
• Will I meet integration deadlines?
• Infrastructure
• Data Cleanup / Import
• Responsible for customer deliverables
• How do I communicate my status / issues /
  problems to the team?

Infowidget LLC
7
Project Management Challenges

• Complexity of applications grows to just keep
  ahead of the power of the tools used to create
  them.
• Integration, Security, Audit, Safety, Legal
  issues surround software projects
• Projects are becoming more integrated,
  dependencies, costs, and risks are greater
• Globalization means projects are spread all
  around the globe and coordination /
  communications are critical.

Infowidget LLC
8
What is a Plan?

• A basis for agreeing on the cost and schedule for
  a job
• An organizing structure for doing the work
• A framework for obtaining the required resources
• A record of what was initially committed.
• (from Watts Humphrey, A Discipline for Software
  Engineering)

Infowidget LLC
9
Quality Characteristics for a plan

• Is it complete?
• Is it accessible?
• Is it clear?
• Is it specific?
• Is it precise?
• Is it accurate?
• (also from Watts Humphries)

Infowidget LLC
10
Is it complete?

• Do you have documented requirements?
• Do you have a conceptual design do you
  understand how it can be implemented?
• Do you trust your estimates and those of your
  team? Why do you trust them?
• Do you have commitments for resources?
• Does the plan produce information for frequent
  reporting?

Infowidget LLC
11
Is it accessible?

• Where is it kept?
• Can those who need it get it?
• Where are the original and revisions?
• Does it have supporting information for scope,
  estimates, signoffs, status reports, change
  control.
• In short, a well-organized project notebook is
  critical

Infowidget LLC
12
Is it clear?

• Ambiguities cause problems
• Remember the project plan is shared
• Marginal notes, scratch-outs, etc. should be
  avoided.
• Be sure people understand how changes are
  incorporated in all documents.

Infowidget LLC
13
Is it specific?

• Who will do it? What will they do?
• What will be done?
• Where will it be done?
• When will it be done?
• Why are we doing these things?
• And finally, How much will it cost?

Infowidget LLC
14
Is it precise?

• Precision is relative to the scope of the
  project.
• Beware of excessive precision.
• It can deceive everybody including the manager.
  Implies more than is known
• Large projects need bigger units than small
  projects.
• Beware of inadequate precision.
• Small projects need small measurements

Infowidget LLC
15
Is it accurate?

• Plans need to be unbiased neither over nor
  under estimated
• Actual times for tasks should be above or below
  but average out at zero variability
• Is it up to date? Do you know where your project
  is?

Infowidget LLC
16
Estimating

• Top-down estimating
• Experience-based estimates
• COCOMO II model
• Rules of thumb
• Expert-based estimates
• Sizing methods
• Function Points
• Bottom-up estimating

Infowidget LLC
17
Top-down estimates

• Estimate based on experience with similar
  projects. Intended to be early and reasonable
  but it seldom turns out that way.
• When offered up front, it is generally the last
  estimate the client ever hears.
• If the detailed estimate comes in larger then
  they immediately ask what they would get for the
  smaller estimate.
• Clients take the estimate and immediately lay out
  detailed plans and commitments to make sure it is
  the final estimate because so many things depend
  on it. They get EXACTLY the amount of money the
  estimate requires.
• Produces projects in which only the delivery date
  is known.

Infowidget LLC
18
Top-down estimating (cont)

• Very useful to manage phases.
• Break project down by phases
• For example requirements typically take 15 of
  schedule and 5-8 of resources
• If requirements take a month, then it is probably
  about six months to do the project.
• A thorough top-down view highlights integrations,
  testing, deployment, training, etc. that can be
  forgotten in bottom-up estimates.

Infowidget LLC
19
Model-Based Estimating

• Estimates are based on using a model for software
  development.
• Models are Experience-Based
• Requires discipline to develop software following
  a consistent process
• Requires measurement of critical parameters to
  provide predictions
• Are used fully only in large organizations and
  large project / contract situations

Infowidget LLC
20
Model-Based Estimating

• Applying models without considering their
  underlying assumptions is FOLLY
• To be accurate, a model must be calibrated
• Corporate and group culture are important
• Requires process maturity to actually deliver
  accurate results.
• MODELS ARE VERY USEFUL IN UNDERSTANDING THE
  DEVELOPMENT PROCESS.

Infowidget LLC
21
Model-Based Estimates

• COCOMO II (Barry Boehm) is probably the most
  complete model.
• Resulted from studying many projects and looking
  at effort required (1960s to the present)
• Models the effort to produce a given size of
  project (Source Lines of Code - SLOC)
• Identifies many drivers of schedule and effort
• Useful in stable development environments.

Infowidget LLC
22
COCOMO II Model

• COCOMO is COnstructive COst MOdel
• Barry Boehm created it based on experience in
  Mainframe applications for well documented
  projects. Published 1981
• COCOMO II came out in 1990, updated for
  technologies and techniques.

Infowidget LLC
23
COCOMO II

• Scale Drivers
• Precedentedness 
• Development Flexibility 
• Architecture/Risk Resolution
• Team Cohesion
• Process Maturity 

Infowidget LLC
24
COCOMO II

• Drivers are rated
• Very Low
• Low
• Nominal
• High
• Very High
• Extra High

Infowidget LLC
25
COCOMO II

• Precedentedness Ranges from
• Give me another one, just like the other one
• This product is UNPRECEDENTED!!!!
• Well, Not Exactly
• Each driver has contributors to its value
• The drivers and contributors are very useful in
  understanding the development process and
  encouraging thinking.

Infowidget LLC
26
COCOMO II

• Precedentedness
• Organizational understanding of product
  objectives
• Experience working with related software systems
• Concurrent development of new hardware and
  operational procedures
• Need for innovative data processing architectures
  and algorithms

Infowidget LLC
27
COCOMO II

• Development Flexibility
• Need for software conformance with
  pre-established requirements
• Need for software conformance with external
  interface specs
• Premium on early completion
• Homework read the page on cost drivers
  http//sunset.usc.edu/research/COCOMOII/expert_coc
  omo/drivers.htmlPREC

Infowidget LLC
28
COCOMO II

• Product Attributes
• Required Reliability
• Database Size
• Product Complexity
• Required Reuse
• Documentation

Infowidget LLC
29
COCOMO II

• Platform Attributes
• Execution Time Constraint
• Main Storage Constraint
• Platform Volatility

Infowidget LLC
30
COCOMO II

• Personnel Attributes
• Analyst Capability
• Programmer Capability
• Personnel Continuity
• Applications Experience
• Platform Experience
• Language and Toolset Experience

Infowidget LLC
31
COCOMO II

• Project Attributes
• Use of Software Tools
• Multisite Development
• Required Development Schedule

Infowidget LLC
32
Function Points

• Published by A.J. Albrecht, IBM, 1979
• Quite commonly used sizing / estimating technique
• Requires detailed knowledge of the system being
  developed. Cannot be performed without
  requirements / application design what a
  concept!
• Requires certification of points counters who
  review the spec and size the application.

Infowidget LLC
33
Function Points

• Very useful technique for measuring productivity
  how many points per day.
• Good predictive validity
• Can be used to predict time for testing,
  integration, etc. as a function of size in
  points.
• Well calibrated and customizable for
  organizations.

Infowidget LLC
34
Function Points

• Produces estimated effort to produce the code and
  Source Lines of Code (SLOC)
• SLOC Can be combined with COCOMO II to provide
  more insights and schedule prediction
• Good resources are Software Performance Research
  (SPR) and International Function Point User Group
  (IFPUG), both on the web.

Infowidget LLC
35
Bottom-Up Estimating

• This method is an excellent shortcut to a Work
  Breakdown Structure. In fact, thats what it IS.
• Use Functional Decomposition to break down the
  development to units (screens, reports, database
  tables, imports, etc)
• Use your experience with toolset, application,
  environment to estimate how long each piece will
  take.
• If you dont understand what needs to be done,
  then requirements need more work! Dont
  estimate what you dont understand!

Infowidget LLC
36
Bottom-Up Estimating, Cont

• Makes the plan easy to understand and tightly
  tied to deliverables.
• Plan is easy to explain to the client because
  they see the deliverables and the time.
• - Frequently people forget (pick one or more)
  Integration, Infrastructure,Testing,
  Requirements, Design, Audit, Training/Documentatio
  n

Infowidget LLC
37
Bottom-Up Estimating

• - If the are pieces are too large the estimate
  becomes useless
• Keep most items between 4 and 20 hours
• Keep ALL items less than 80 hours
• In other words, Inch Pebbles
• - If pieces are too small, the total estimate
  tends to be overly large.
• Recommended size somewhat overcomes the
  programmers tendency to underestimate by about
  30

Infowidget LLC
38
Inch Pebble Deliverables

• Inch-Pebble deliverables
• Accurate status is frequent and fact-based
• If all items in WBS comply with rules, you will
  have measured progress at least every two weeks.
• You can do Earned Value reporting with great
  accuracy (more on this if there is time)
• Customer gets to see concrete progress with
  almost every report

Infowidget LLC
39
Why Inch Pebble Deliverables?

• If you have a one-month deliverable you can count
  on the following sequence of events
• Week 1 doing great!
• Week 2 running into some small problems but no
  worry. We still have plenty of time to recover
• Week 3 still have risks, not sure when it will
  finish
• Week 4 Looks like we are about 80 done

Infowidget LLC
40
Why Inch Pebble Deliverables?

• Week 5 Manager realizes there is a problem when
  deliverable is not done, reports to customer
• Week 6 Customer has padded his secret real
  schedule so is not too worried but faith is
  jeopardized.
• Remember, the customer made lots of plans based
  on your plans so padded it a bit to cover
  himself.
• Week 7 - Obviously 80 done was wrong still
  not sure how much more is needed, revisit scope
  definition
• Week 8 If luck is on your side, it gets done.
  Customer starts to worry.

Infowidget LLC
41
Why Inch Pebble deliverables?

• With 4-80 hour deliverables in the worst case
  time to discover a problem is 2 weeks and often
  sooner
• The root cause is apparent sooner so can be
  identified and managed.
• Go back and substitute Two Month deliverable for
  one month and consider the consequences if you
  dare.

Infowidget LLC
42
Why do people hate me when I call for Inch Pebble
deliverables?

• More up front work planning and specifying so
  detailed WBS can be produced. Why arent we
  doing code yet?
• Highlights need for requirements and delays
  coding longer.
• Everybody wants team to commit before
  requirements are complete, and this delays that.
  We know what the system should do, GET CODING!
• Programmers feel exposed because they have
  concrete status every week or at most two.
  Feeling of pressure

Infowidget LLC
43
Why do people hate me when I call for Inch Pebble
deliverables?

• Can be a nightmare if somebody micromanages.
• Requires lots of technical input to create the
  plan
• Leaves scope uncertain until the plan is done.
  Leads to early scope discussions if plan and
  preliminary estimates are inconsistent. Usually
  scope discussions are Too Late, Under Pressure,
  and Constrained and people like their customs.
• Means the technical people need to commit to
  deliver something concrete.
• Reduces need to pad the schedule and removes the
  illusion of safety and comfort padding provides
• Keeps pressure active continuously, instead of in
  the last 20 of schedule.

Infowidget LLC
44
Risks

• Lots of kinds of risks
• Scope
• Changes
• Misunderstandings
• Late Changes
• Resources
• Critical Resources
• Illness
• Vacations
• Schedule
• Fixed critical date
• Aggressive compression (less than 80 of optimum
  schedule)

Infowidget LLC
45
Risks

• Costs
• Missed Requirements
• Or no requirements
• Late Changes
• Integration Failures
• Late integration
• Large Scale Integration
• Testing Failures
• Project is done with huge bug list
• Last month is all testing and bug fixing
• Catching more bugs than fixing

Infowidget LLC
46
Risks

• Go back to our old friend COCOMO II
• Every Cost Driver is a potential risk if it is
  not optimum.
• Personnel Risks
• Turnover affects Personnel Continuity from the
  model
• The New person does not have the same
  Application, Platform, and Application Experience
• Predicted effort could DOUBLE for the work that
  person does.

Infowidget LLC
47
Traditional Methods for Risk

• Take each risk and put it into the contractual
  terms and conditions as assumptions.
• Customer will provide hardware or people at the
  stated date
• Delay will be charged day by day at x. per day
• Consequential charges may also apply

Infowidget LLC
48
Traditional Methods for Risk

• Advantages of Contractual terms
• Protects both parties from costly arguments
• Applies monetary costs to dependencies
• Almost always a necessary precaution.
• Disadvantages
• Not very friendly
• Misused by both sides
• Does not improve the situation, only penalizes

Infowidget LLC
49
Managing Risks

• A Risk is quantified by
• Probability of occurence
• Impact if it does happen
• How do we know it is happening?
• How do we know the risk is past?

Infowidget LLC
50
Managing Risks

• A Risk is managed by
• Reducing the probability of occurrence
• Prevention is almost always the best method
• Preventable risks should be prevented.
• Mitigating the impact if it occurs
• Contingency Plans are good mitigation
• When do you trigger the plan?
• How much does the plan cost / delay / effect
  product?
• Planning around a risk works too
• Assume Risk will happen and make plan robust
• What is the cost of the plan changes?

Infowidget LLC
51
Managing Risks

• Accepting the Risk
• Person in authority accepts that risk may happen
  and will accept the consequences
• Good technique for low probability/impact risks
• Good reason for contract terms
• Can be accepted too casually in lieu of
  understanding or questioning what is really going
  on.

Infowidget LLC
52
Where do I find Risks?

• Look at the project plan
• Schedule
• Is it aggressive? Schedule Compression?
• Resources
• Are shared resources required?
• Are commitments in place for all resources?
• What happens if schedule shifts? Do we lose
  people?

Infowidget LLC
53
Where do I find risks?

• Dependencies?
• When do we find out a dependency wont be met?
• Who owns prevention / mitigation / acceptance?
• Under Rocks
• Risks are everywhere
• Dont be afraid to turn over rocks now and again

Infowidget LLC
54
Managing Risks

• Itemize the Risks
• List all the risks in a table
• Answer the big questions
• Assess the Risks
• Probability of occurrence
• Impact if risk occurs

Infowidget LLC
55
Risk Management

• Categorize and Characterize the Risks
• Accept, Mitigate, Prevent, Eliminate?
• Describe the risk more fully
• How do we know it is happening
• How do we know it is past?
• What is the impact at various stages in the
  project?
• What is the plan to deal with it?

56
Risk Management

• Budget for the Risks
• Identify the potential cost for each risk and its
  associated action
• Expend risk budget only on the occurrence of the
  risk or triggering mitigation plan
• Expend the budget through change management
  process
• Keep risk budget separate from change budget.
• Stay aware of risks

57
Risk Management

• Create a risk management plan and report it
  regularly to project owner.
• Agenda is upcoming risks and discussions of past
  risks, mitigations, etc.
• Plan keeps everyone alert sensitizes the whole
  team to upcoming risks
• Encourages people that risks dont all have to be
  accepted
• Involves the project owner in Prevention and
  critical decision making

Infowidget LLC
58
PAD IS BAD

• Padding is the usual method of managing risks
• Developer pads his estimate
• Project manager is skeptical and pads the plan
• Project owner suspects padding so contingently
  seeks lots of changes to use up the pad
• Project overruns mount and everybody suffers

59
PAD IS BAD

• Pad is really comfy
• Avoids accountability
• Covers for mistakes
• Manages risks, especially the surprises
• Manages those pesky changes
• Covers all those underestimates
• Because it is not measured and managed, it is
  really not there at all!

Infowidget LLC
60
PAD IS BAD

• So, how do we get rid of BAD PAD
• Establish a realistic Change Budget and expend it
  through Change Control.
• Requirements really do change now and again
• Scope really does change
• People really do make mistakes / misunderstand
• Zero cost change requests increase faith in
  system
• Establish a risk budget and expend it through the
  Change Control Process.
• Risks do happen
• Visibility breeds prevention and cooperation

Infowidget LLC
61
PAD IS BAD

• Drive out Padding from the culture
• Compare actuals to estimates
• Programmers analyze their own work
• Report performance in mentoring sessions
• NO CONNECTION TO EMPLOYEE REVIEWS
• Find/Eliminate root causes for bugs
• Programmers analyze their own bugs
• Plan and Report improvements in mentoring
  sessions
• Reward credible estimates / improvements

Infowidget LLC
62
PAD IS BAD

• Walk the Talk
• No sneaking around change control
• No transfer of risks from owners / PMs to
  programmers
• Do Lessons Learned for SUCCESSES Why did we
  succeed? What did we learn? What problems arose
  that we solved? What near misses happened that
  we need to watch for? Where were our estimates
  off? Why?

Infowidget LLC
63
PAD IS BAD

• Your personal war on pad
• Beware this is culturally sensitive
• Understand the project scope before you estimate
  and clarify issues Inch Pebble plans are easily
  reported and reliable
• Identify/Quantify the risks in your piece of the
  project
• Quietly create a risk management plan
• Report upcoming risks and unplanned scope changes
  in your status reporting as a means of escalation
• Pad your plan to cover the risks and some
  anticipated changes.
• Expend pad only when necessary
• Warn your boss when pad is running out. (or 50
  used, or whatever)

Infowidget LLC
64
Why doesnt everybody do this?

• Business and Corporate Culture
• The first awkward step is accountability
• Inch-Pebble plans are highly accountable
• Requires trust between the manager and team
• Needs to be a blame-free environment for real
  success. Focus blame on process, not people.
• Customer realizes they are accountable for their
  part of the project and are being tracked
• Absence of PAD is like a little kid without his
  blanket

Infowidget LLC
65
Why doesnt everybody do this?

• Business and Corporate Culture
• Seat of the Pants Management is comfortable
• We have always done things the old way
• Changing reporting content to your customer or
  boss is a touchy issue
• Risks eventually change to crises, and require
  heroism to resolve as a Manager, why else am I
  here?
• Process starts to replace management /
  micromanagement and threatens peoples security
• People like to avoid visibility into what they do

Infowidget LLC
66
Why doesnt everybody do this?

• Business and Corporate Culture
• The existing business model
• Frequently projects are PRICED TO WIN
• If scope is too specific, there are no changes in
  scope to collect added money / time
• If risks are too well managed there are no
  consequential charges to assess / schedule relief
• There is a very real risk that if we do our job
  well, the plan will go as written and potential
  revenue will be lost / we will have to deliver on
  time
• Remember, YOU have priced to win even if you are
  internal staff and believe any of those things
  about your project.

Infowidget LLC
67
Why doesnt everybody do this?

• Business and Corporate Culture
• The Existing Business Model
• Projects and groups are often sized from the
  executive level on headcount
• Less headcount, less revenue for contract
  companies
• Improvements can reduce size of the group
• This is an impediment to many improvement
  initiatives, not just improved project management

Infowidget LLC
68
Why doesnt everybody do this?

• Business and Corporate Culture
• Customer Expectations
• Fixed Price feels safe to the customer
• Risk budgets are unfamiliar

Infowidget LLC
69
Summary

• PAD IS BAD
• Estimating is a science and you can master it
• Inch-Pebble project planning is your friend
• Change Management is your friend.
• Risks are quantifiable and mostly manageable
• If it isnt in the plan, it doesnt get done.

Infowidget LLC
70
Good Resources

• A Discipline for Software Engineering, Watts
  Humphrey
• Software Engineering Economics, Barry Boehm
• The Team Software Process, Watts Humphrey
• The Software Engineering Body of Knowledge, IEEE,
  swebok.org

Infowidget LLC
71
Questions and Discussion

• There is no such thing as a stupid question, only
  stupid people who fail to ask.

Infowidget LLC