Category Archives: Project Management

Project and Portfolio Management Hero

Do you think you are a good project manager? It’s time to prove it.
Developed by the Computer Associates, PPM Hero Challenge it’s a game that challenges your knowledge in the area.
Give it a try.

The “Balanced Blend”

Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

“Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

 

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

 

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.”

By Mike Griffiths

Software estimation tips

Tip #1   Distinguish between estimates, targets, and commitments.
Tip #2   When you’re asked to provide an estimate, determine whether you’re supposed to be estimating
or figuring out how to hit a target.
Tip #3   When you see a single-point “estimate,” ask whether the number is an estimate or whether it’s
really a target.
Tip #4   When you see a single-point estimate, that number’s probability is not 100%. Ask what the
probability of that number is.
Chapter    2
Tip #5   Don’t provide “percentage confident” estimates (especially “90% confident”) unless you have a
quantitatively derived basis for doing so.
Tip #6   Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t
misrepresent your confidence in your estimates.
Tip #7   If you are feeling pressure to make your ranges narrower, verify that the pressure actually is
coming from an external source and not from yourself.
Chapter    3
Tip #8   Don’t intentionally underestimate. The penalty for underestimation is more severe than the
penalty for overestimation. Address concerns about overestimation through planning and control,
not by biasing your estimates.
Tip #9   Recognize a mismatch between a project’s business target and a project’s estimate for what it is:
valuable risk information that the project might not be successful. Take corrective action early,
when it can do some good.
Tip #10   Many businesses value predictability more than development time, cost, or flexibility. Be sure
you understand what your business values the most.
Chapter    4
Tip #11   Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate
cannot have more accuracy than is possible at your project’s current position within the Cone.
Tip #12   Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow
by removing sources of variability from your project.
Tip #13   Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.
Tip #14   Account for the Cone of Uncertainty by having one person create the “how much” part of the
estimate and a different person create the “how uncertain” part of the estimate.
Tip #15   Don’t expect better estimation practices alone to provide more accurate estimates for chaotic
projects. You can’t accurately estimate an out-of-control process.
Tip #16   To deal with unstable requirements, consider project control strategies instead of or in addition
to estimation strategies.
Tip #17   Include time in your estimates for stated requirements, implied requirements, and nonfunctional
requirements—that is, all requirements. Nothing can be built for free, and your estimates
shouldn’t imply that it can.
Tip #18   Include all necessary software-development activities in your estimates, not just coding and
testing.
Tip #19   On projects that last longer than a few weeks, include allowances for overhead activities such
as vacations, sick days, training days, and company meetings.
Tip #20   Don’t reduce developer estimates—they’re probably too optimistic already.
Tip #21   Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of
better accuracy, they usually introduce subjectivity and degrade actual accuracy.
Tip #22   Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.
Tip #23   Match the number of significant digits in your estimate (its precision) to your estimate’s
accuracy.
Chapter    5
Tip #24   Invest an appropriate amount of effort assessing the size of the software that will be built. The
size of the software is the single most significant contributor to project effort and schedule.
Tip #25   Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.
Tip #26   Use software estimation tools to compute the impact of diseconomies of scale.
Tip #27   If you’ve completed previous projects that are about the same size as the project you’re
estimating—defined as being within a factor of 3 from largest to smallest—you can safely use a
ratio-based estimating approach, such as lines of code per staff month, to estimate your new
project.
Tip #28   Factor the kind of software you develop into your estimate. The kind of software you’re
developing is the second-most significant contributor to project effort and schedule.
Chapter    6
Tip #29   When choosing estimation techniques, consider what you want to estimate, the size of the
project, the development stage, the project’s development style, and what accuracy you need.
Chapter    7
Tip #30   Count if at all possible. Compute when you can’t count. Use judgment alone only as a last
resort.
Tip #31   Look for something you can count that is a meaningful measure of the scope of work in your
environment.
Tip #32   Collect historical data that allows you to compute an estimate from a count.
Tip #33   Don’t discount the power of simple, coarse estimation models such as average effort per defect,
average effort per Web page, average effort per story, and average effort per use case.
Tip #34   Avoid using expert judgment to tweak an estimate that has been derived through computation.
Such “expert judgment” usually degrades the estimate’s accuracy.
Chapter    8
Tip #35   Use historical data as the basis for your productivity assumptions. Unlike mutual fund
disclosures, your organization’s past performance really is your best indicator of future
performance.
Tip #36   Use historical data to help avoid politically charged estimation discussions arising from
assumptions like “My team is below average.”
Tip #37   In collecting historical data to use for estimation, start small, be sure you understand what you’re
collecting, and collect the data consistently.
Tip #38   Collect a project’s historical data as soon as possible after the end of the project.
Tip #39   As a project is underway, collect historical data on a periodic basis so that you can build a data-
based profile of how your projects run.
Tip #40   Use data from your current project (project data) to create highly accurate estimates for the
remainder of the project.
Tip #41   Use project data or historical data rather than industry-average data to calibrate your estimates
whenever possible. In addition to making your estimates more accurate, historical data will
reduce variability in your estimate arising from uncertainty in the productivity assumptions.
Tip #42   If you don’t currently have historical data, begin collecting it as soon as possible.
Chapter    9
Tip #43   To create the task-level estimates, have the people who will actually do the work create the
estimates.
Tip #44   Create both Best Case and Worst Case estimates to stimulate thinking about the full range of
possible outcomes.
Tip #45   Use an estimation checklist to improve your individual estimates. Develop and maintain your
own personal checklist to improve your estimation accuracy.
Tip #46   Compare actual performance to estimated performance so that you can improve your individual
estimates over time.
Chapter    10
Tip #47   Decompose large estimates into small pieces so that you can take advantage of the Law of
Large Numbers: the errors on the high side and the errors on the low side cancel each other out
to some degree.
Tip #48   Use a generic software-project work breakdown structure (WBS) to avoid omitting common
activities.
Tip #49   Use the simple standard deviation formula to compute meaningful aggregate Best Case and
Worst Case estimates for estimates containing 10 tasks or fewer.
Tip #50   Use the complex standard deviation formula to compute meaningful aggregate Best Case and
Worst Case estimates when you have about 10 tasks or more.
Tip #51   Don’t divide the range from best case to worst case by 6 to obtain standard deviations for
individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.
Tip #52   Focus on making your Expected Case estimates accurate. If the individual estimates are
accurate, aggregation will not create problems. If the individual estimates are not accurate,
aggregation will be problematic until you find a way to make them accurate.
Chapter    11
Tip #53   Estimate new projects by comparing them to similar past projects, preferably decomposing the
estimate into at least five pieces.
Tip #54   Do not address estimation uncertainty by biasing the estimate. Address uncertainty by
expressing the estimate in uncertain terms.
Chapter    12
Tip #55   Use fuzzy logic to estimate program size in lines of code.
Tip #56   Consider using standard components as a low-effort technique to estimate size in a project’s
early stages.
Tip #57   Use story points to obtain an early estimate of an iterative project’s effort and schedule that is
based on data from the same project.
Tip #58   Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the
numeric categories in the scale actually work like numbers, not like verbal categories such as
small, medium, and large.
Tip #59   Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in
the wide part of the Cone of Uncertainty.
Tip #60   Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and
other quantities that are difficult to estimate directly.
Tip #61   Count whatever is easiest to count and provides the most accuracy in your environment, collect
calibration data on that, and then use that data to create estimates that are well-suited to your
environment.
Chapter    13
Tip #62   Use group reviews to improve estimation accuracy.
Tip #63   Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when
several diverse disciplines will be involved in the project itself.
Chapter    14
Tip #64   Use an estimation software tool to sanity-check estimates created by manual methods. Larger
projects should rely more heavily on commercial estimation software.
Tip #65   Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation
tool outputs just as you would other estimates.
Chapter    15
Tip #66   Use multiple estimation techniques, and look for convergence or spread among the results.
Tip #67   If different estimation techniques produce different results, try to find the factors that are making
the results different. Continue reestimating until the different techniques produce results that
converge to within about 5%.
Tip #68   If multiple estimates agree and the business target disagrees, trust the estimates.
Chapter    16
Tip #69   Don’t debate the output of an estimate. Take the output as a given. Change the output only by
changing the inputs and recomputing.
Tip #70   Focus on estimating size first. Then compute effort, schedule, cost, and features from the size
estimate.
Tip #71   Reestimate.
Tip #72   Change from less accurate to more accurate estimation approaches as you work your way
through a project.
Tip #73   When you are ready to hand out specific development task assignments, switch to bottom-up
estimation.
Tip #74   When you reestimate in response to a missed deadline, base the new estimate on the project’s
actual progress, not on the project’s planned progress.
Tip #75   Present your estimates in a way that allows you to tighten up your estimates as you move
further into the project.
Tip #76   Communicate your plan to reestimate to other project stakeholders in advance.
Chapter    17
Tip #77   Develop a Standardized Estimation Procedure at the organizational level; use it at the project
level.
Tip #78   Coordinate your Standardized Estimation Procedure with your SDLC.
Tip #79   Review your projects’ estimates and estimation process so that you can improve the accuracy of
your estimates and minimize the effort required to create them.
Chapter    18
Tip #80   Use lines of code to estimate size, but remember both the general limitations of simple
measures and the specific hazards of the LOC  measure in.
Tip #81   Count function points to obtain an accurate early-in-the-project size estimate.
Tip #82   Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in
the project.
Tip #83   Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of
Uncertainty.
Tip #84   With better estimation methods, the size estimate becomes the foundation of all other
estimates. The size of the system you’re building is the single largest cost driver. Use multiple
size-estimation techniques to make your size estimate accurate.
Chapter    19
Tip #85   Use software tools based on the science of estimation to most accurately compute effort
estimates from your size estimates.
Tip #86   Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone
of Uncertainty. For larger projects, remember that more powerful estimation techniques are
easily cost-justified.
Tip #87   Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and
look for convergence or spread among the different estimates.
Tip #88   Not all estimation methods are equal. When  looking for convergence or spread among
estimates, give more weight to the techniques that tend to produce the most accurate results.
Chapter    20
Tip #89   Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.
Tip #90   Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-
large project.
Tip #91   Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort)
schedule estimate early in a project.
Tip #92   Do not shorten a schedule estimate without increasing the effort estimate.
Tip #93   Do not shorten a nominal schedule more than 25%. In other words, keep your estimates out of
the Impossible Zone.
Tip #94   Reduce costs by lengthening the schedule and conducting the project with a smaller team.
Tip #95   For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing
the team size beyond 7 people.
Tip #96   Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce
the final schedule.
Tip #97   Remove the results of overly generic estimation techniques from your data set before you look
for convergence or spread among your estimates.
Chapter    21
Tip #98   When allocating project effort across different activities, consider project size, project type, and
the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.
Tip #99   Consider your project’s size, type, and development approach in allocating schedule to different
activities.
Tip #100   Use industry-average data or your historical data to estimate the number of defects your
project will produce.
Tip #101   Use defect-removal-rate data to estimate the number of defects that your quality assurance
practices will remove from your software before it is released.
Tip #102   Use your project’s total Risk Exposure (RE) as the starting point for buffer planning. Review
the details of your project’s specific risks to understand whether you should ultimately plan for
a buffer that’s larger or smaller than the total RE.
Tip #103   Planning and estimation are related, and planning is a much bigger topic than can be
addressed in one chapter in a book that focuses on software estimation. Read the literature on
planning.
Chapter    22
Tip #104   Document and communicate the assumptions embedded in your estimate.
Tip #105   Be sure you understand whether you’re presenting uncertainty in an estimate or uncertainty
that affects your ability to meet a commitment.
Tip #106   Don’t present project outcomes to other project stakeholders that are only remotely possible.
Tip #107   Consider graphic presentation of your estimate as an alternative to text presentation.
Tip #108   Use an estimate presentation style that reinforces the message you want to communicate
about your estimate’s accuracy.
Tip #109   Don’t try to express a commitment as a range. A commitment needs to be specific.
Chapter    23
Tip #110   Understand that executives are assertive by nature and by job description, and plan your
estimation discussions accordingly.
Tip #111   Be aware of external influences on the target. Communicate that you understand the business
requirements and their importance.
Tip #112   You can negotiate the commitment, but don’t negotiate the estimate.
Tip #113   Educate nontechnical stakeholders about effective software estimation practices.
Tip #114   Treat estimation discussions as problem solving, not negotiation. Recognize that all project
stakeholders are on the same side of the table. Everyone wins, or everyone loses.
Tip #115   Attack the problem, not the people.
Tip #116   Generate as many planning options as you can to support your organization’s goals.
Tip #117   As you foster an atmosphere of collaborative problem solving, don’t make any commitments
based on off-the-cuff estimates.
Tip #118   Resolve discussion deadlocks by returning to the question of, “What will be best for our
organization?”

Tip #1   Distinguish between estimates, targets, and commitments.

Tip #2   When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.

Tip #3   When you see a single-point “estimate,” ask whether the number is an estimate or whether it’s  really a target.

Tip #4   When you see a single-point estimate, that number’s probability is not 100%. Ask what the  probability of that number is.

Tip #5   Don’t provide “percentage confident” estimates (especially “90% confident”) unless you have a quantitatively derived basis for doing so.

Tip #6   Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t  misrepresent your confidence in your estimates.

Tip #7   If you are feeling pressure to make your ranges narrower, verify that the pressure actually is coming from an external source and not from yourself.

Tip #8   Don’t intentionally underestimate. The penalty for underestimation is more severe than the  penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

Tip #9   Recognize a mismatch between a project’s business target and a project’s estimate for what it is:  valuable risk information that the project might not be successful. Take corrective action early,  when it can do some good.

Tip #10   Many businesses value predictability more than development time, cost, or flexibility. Be sure  you understand what your business values the most.

Tip #11   Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.

Tip #12   Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

Tip #13   Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

Tip #14   Account for the Cone of Uncertainty by having one person create the “how much” part of the estimate and a different person create the “how uncertain” part of the estimate.

Tip #15   Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of-control process.

Tip #16   To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

Tip #17   Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements – that is, all requirements. Nothing can be built for free, and your estimates shouldn’t imply that it can.

Tip #18   Include all necessary software-development activities in your estimates, not just coding and testing.

Tip #19   On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

Tip #20   Don’t reduce developer estimates – they’re probably too optimistic already.

Tip #21   Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of  better accuracy, they usually introduce subjectivity and degrade actual accuracy.

Tip #22   Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.

Tip #23   Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy.

Tip #24   Invest an appropriate amount of effort assessing the size of the software that will be built. The  size of the software is the single most significant contributor to project effort and schedule.

Tip #25   Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.

Tip #26   Use software estimation tools to compute the impact of diseconomies of scale.

Tip #27   If you’ve completed previous projects that are about the same size as the project you’re  estimating – defined as being within a factor of 3 from largest to smallest – you can safely use a ratio-based estimating approach, such as lines of code per staff month, to estimate your new project.

Tip #28   Factor the kind of software you develop into your estimate. The kind of software you’re developing is the second-most significant contributor to project effort and schedule.

Tip #29   When choosing estimation techniques, consider what you want to estimate, the size of the project, the development stage, the project’s development style, and what accuracy you need.

Tip #30   Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.

Tip #31   Look for something you can count that is a meaningful measure of the scope of work in your environment.

Tip #32   Collect historical data that allows you to compute an estimate from a count.

Tip #33   Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per Web page, average effort per story, and average effort per use case.

Tip #34   Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy.

Tip #35   Use historical data as the basis for your productivity assumptions. Unlike mutual fund disclosures, your organization’s past performance really is your best indicator of future performance.

Tip #36   Use historical data to help avoid politically charged estimation discussions arising from assumptions like “My team is below average.”

Tip #37   In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently.

Tip #38   Collect a project’s historical data as soon as possible after the end of the project.

Tip #39   As a project is underway, collect historical data on a periodic basis so that you can build a data-based profile of how your projects run.

Tip #40   Use data from your current project (project data) to create highly accurate estimates for the remainder of the project.

Tip #41   Use project data or historical data rather than industry-average data to calibrate your estimates whenever possible. In addition to making your estimates more accurate, historical data will reduce variability in your estimate arising from uncertainty in the productivity assumptions.

Tip #42   If you don’t currently have historical data, begin collecting it as soon as possible.

Tip #43   To create the task-level estimates, have the people who will actually do the work create the  estimates.

Tip #44   Create both Best Case and Worst Case estimates to stimulate thinking about the full range of  possible outcomes.

Tip #45   Use an estimation checklist to improve your individual estimates. Develop and maintain your own personal checklist to improve your estimation accuracy.

Tip #46   Compare actual performance to estimated performance so that you can improve your individual estimates over time.

Tip #47   Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.

Tip #48   Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

Tip #49   Use the simple standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates for estimates containing 10 tasks or fewer.

Tip #50   Use the complex standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates when you have about 10 tasks or more.

Tip #51   Don’t divide the range from best case to worst case by 6 to obtain standard deviations for individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.

Tip #52   Focus on making your Expected Case estimates accurate. If the individual estimates are accurate, aggregation will not create problems. If the individual estimates are not accurate, aggregation will be problematic until you find a way to make them accurate.

Tip #53   Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.

Tip #54   Do not address estimation uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms.

Tip #55   Use fuzzy logic to estimate program size in lines of code.

Tip #56   Consider using standard components as a low-effort technique to estimate size in a project’s early stages.

Tip #57   Use story points to obtain an early estimate of an iterative project’s effort and schedule that is based on data from the same project.

Tip #58   Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the numeric categories in the scale actually work like numbers, not like verbal categories such as  small, medium, and large.

Tip #59   Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in the wide part of the Cone of Uncertainty.

Tip #60   Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and other quantities that are difficult to estimate directly.

Tip #61   Count whatever is easiest to count and provides the most accuracy in your environment, collect  calibration data on that, and then use that data to create estimates that are well-suited to your environment.

Tip #62   Use group reviews to improve estimation accuracy.

Tip #63   Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when several diverse disciplines will be involved in the project itself.

Tip #64   Use an estimation software tool to sanity-check estimates created by manual methods. Larger projects should rely more heavily on commercial estimation software.

Tip #65   Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation tool outputs just as you would other estimates.

Tip #66   Use multiple estimation techniques, and look for convergence or spread among the results.

Tip #67   If different estimation techniques produce different results, try to find the factors that are making the results different. Continue reestimating until the different techniques produce results that converge to within about 5%.

Tip #68   If multiple estimates agree and the business target disagrees, trust the estimates.

Tip #69   Don’t debate the output of an estimate. Take the output as a given. Change the output only by changing the inputs and recomputing.

Tip #70   Focus on estimating size first. Then compute effort, schedule, cost, and features from the size estimate.

Tip #71   Reestimate.

Tip #72   Change from less accurate to more accurate estimation approaches as you work your way through a project.

Tip #73   When you are ready to hand out specific development task assignments, switch to bottom-up estimation.

Tip #74   When you reestimate in response to a missed deadline, base the new estimate on the project’s actual progress, not on the project’s planned progress.

Tip #75   Present your estimates in a way that allows you to tighten up your estimates as you move further into the project.

Tip #76   Communicate your plan to reestimate to other project stakeholders in advance.

Tip #77   Develop a Standardized Estimation Procedure at the organizational level; use it at the project level.

Tip #78   Coordinate your Standardized Estimation Procedure with your SDLC.

Tip #79   Review your projects’ estimates and estimation process so that you can improve the accuracy of  your estimates and minimize the effort required to create them.

Tip #80   Use lines of code to estimate size, but remember both the general limitations of simple measures and the specific hazards of the LOC  measure in.

Tip #81   Count function points to obtain an accurate early-in-the-project size estimate.

Tip #82   Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project.

Tip #83   Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of Uncertainty.

Tip #84   With better estimation methods, the size estimate becomes the foundation of all other estimates. The size of the system you’re building is the single largest cost driver. Use multiple size-estimation techniques to make your size estimate accurate.

Tip #85   Use software tools based on the science of estimation to most accurately compute effort estimates from your size estimates.

Tip #86   Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone of Uncertainty. For larger projects, remember that more powerful estimation techniques are easily cost-justified.

Tip #87   Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and look for convergence or spread among the different estimates.

Tip #88   Not all estimation methods are equal. When  looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results.

Tip #89   Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.

Tip #90   Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-large project.

Tip #91   Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort) schedule estimate early in a project.

Tip #92   Do not shorten a schedule estimate without increasing the effort estimate.

Tip #93   Do not shorten a nominal schedule more than 25%. In other words, keep your estimates out of the Impossible Zone.

Tip #94   Reduce costs by lengthening the schedule and conducting the project with a smaller team.

Tip #95   For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing the team size beyond 7 people.

Tip #96   Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce the final schedule.

Tip #97   Remove the results of overly generic estimation techniques from your data set before you look  for convergence or spread among your estimates.

Tip #98   When allocating project effort across different activities, consider project size, project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.

Tip #99   Consider your project’s size, type, and development approach in allocating schedule to different  activities.

Tip #100   Use industry-average data or your historical data to estimate the number of defects your project will produce.

Tip #101   Use defect-removal-rate data to estimate the number of defects that your quality assurance practices will remove from your software before it is released.

Tip #102   Use your project’s total Risk Exposure (RE) as the starting point for buffer planning. Review the details of your project’s specific risks to understand whether you should ultimately plan for a buffer that’s larger or smaller than the total RE.

Tip #103   Planning and estimation are related, and planning is a much bigger topic than can be addressed in one chapter in a book that focuses on software estimation. Read the literature on  planning.

Tip #104   Document and communicate the assumptions embedded in your estimate.

Tip #105   Be sure you understand whether you’re presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment.

Tip #106   Don’t present project outcomes to other project stakeholders that are only remotely possible.

Tip #107   Consider graphic presentation of your estimate as an alternative to text presentation.

Tip #108   Use an estimate presentation style that reinforces the message you want to communicate about your estimate’s accuracy.

Tip #109   Don’t try to express a commitment as a range. A commitment needs to be specific.

Tip #110   Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly.

Tip #111   Be aware of external influences on the target. Communicate that you understand the business  requirements and their importance.

Tip #112   You can negotiate the commitment, but don’t negotiate the estimate.

Tip #113   Educate nontechnical stakeholders about effective software estimation practices.

Tip #114   Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses.

Tip #115   Attack the problem, not the people.

Tip #116   Generate as many planning options as you can to support your organization’s goals.

Tip #117   As you foster an atmosphere of collaborative problem solving, don’t make any commitments based on off-the-cuff estimates.

Tip #118   Resolve discussion deadlocks by returning to the question of, “What will be best for our organization?”

From Software Estimation by Steve McConnell (Microsoft Press, 2006)

Estimate Sanity Check

The following sanity check indicates how useful your current project estimate is likely to be in managing your
project. For each Yes answer, give the estimate one point.

The following sanity check indicates how useful your current project estimate is likely to be in managing your project. For each Yes answer, give the estimate one point.

1. Was a standardized procedure used to create the estimate?

2. Was the estimation process free from pressure that would bias the results?

3. If the estimate was negotiated, were only the inputs to the estimate negotiated, not the outputs or  the estimation process itself?

4. Is the estimate expressed with precision that matches its accuracy? (For example, is the estimate expressed as a range or coarse number if it’s early in the project?)

5. Was the estimate created using multiple techniques that converged to similar results?

6. Is the productivity assumption underlying the estimate comparable to productivity actually  experienced on past projects of similar sizes?

7. Is the estimated schedule at least 2.0 x StaffMonths1/3? (That is, is the estimate outside of the  Impossible Zone?)

8. Were the people who are going to do the work involved in creating the estimate?

9. Has the estimate been reviewed by an expert estimator?

10. Does the estimate include a nonzero allowance for the impact that project risks will have on effort and schedule?

11. Is the estimate part of a series of estimates that will become more accurate as the project moves into the narrow part of the cone of uncertainty?

12. Are all elements of the project included in the estimate, including creation of setup program,  creation of data conversion utilities, cutover from old system to new system, etc.?

This Estimate Sanity Check is from Software Estimation by Steve McConnell (Microsoft Press, 2006)

Scores of 10-12 indicate estimates that should be highly accurate.

Scores of 7-9 indicate estimates that are good enough to provide project guidance but that are probably optimistic.

Scores of 6 or below indicate estimates that are subject to significant bias, optimism, or both, and are not accurate enough to provide meaningful guidance to managing a project.

What to do if your estimate doesn’t get accepted?

Developers and managers sometimes worry that presenting an estimate that’s too high will cause the project to
be rejected. That’s OK. Executive management has both the responsibility and the right to decide that a project
is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important
information they need to make effective decisions, effectively undermining the executive’s decision-making
authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t
cost-justified. Good projects aren’t supported adequately, and bad projects are supported excessively. The
whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved
in the projects that should not have been approved in the first place.

Developers and managers sometimes worry that presenting an estimate that’s too high will cause the project to  be rejected. That’s OK. Executive management has both the responsibility and the right to decide that a project is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important information they need to make effective decisions, effectively undermining the executive’s decision-making authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t cost-justified. Good projects aren’t supported adequately, and bad projects are supported excessively. The whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved in the projects that should not have been approved in the first place.

Communicating Estimate Assumptions

An essential practice in presenting an estimate is to document the assumptions embodied in the estimate.
Assumptions fall into several familiar categories:
Which features are required
Which features are not required
How elaborate certain features need to be
Availability of key resources
Dependencies on third-party performance
Major unknowns
Major influences and sensitivities of the estimate
How good the estimate is
What the estimate can be used for

An essential practice in presenting an estimate is to document the assumptions embodied in the estimate.

Assumptions fall into several familiar categories:

  • Which features are required
  • Which features are not required
  • How elaborate certain features need to be
  • Availability of key resources
  • Dependencies on third-party performance
  • Major unknowns
  • Major influences and sensitivities of the estimate
  • How good the estimate is
  • What the estimate can be used for

How to Kill a Software Project

• Show the same demo twice to the same audience.

• Focus on the technologies, not the problems and scenarios.

• Fail to maximize return on investments; for example, developing proof−of−concept

prototypes is more effective than adding additional content to an existing prototype.

• Change project focus from the larger scale to the smaller scale.

• Don’t maintain consistency between releases.

• Isolate team efforts from other groups within an organization.

• Rewrite existing clients, servers, and applications.

• Change the purpose of the system, so that the models describe the wrong focus and

objects.

Is it better to overestimate or underestimate?

Intuitively, a perfectly accurate estimate forms the ideal planning foundation for a project. If the estimates are  accurate, work among different developers can be coordinated efficiently. Deliveries from one development  group to another can be planned to the day, hour, or minute. We know that accurate estimates are rare, so if we’re going to err, is it better to err on the side of overestimation or underestimation?

Arguments Against Overestimation

Managers and other project stakeholders sometimes fear that, if a project is overestimated, Parkinson’s Law  will kick in – the idea that work will expand to fill available time. If you give a developer 5 days to deliver a task  that could be completed in 4 days, the developer will find something to do with the extra day. If you give a project team 6 months to complete a project that could be completed in 4 months, the project team will find a  way to use up the extra 2 months. As a result, some managers consciously squeeze the estimates to try to  avoid Parkinson’s Law.

Another concern is Goldratt’s “Student Syndrome”. If developers are given too much time, they’ll procrastinate until late in the project, at which point they’ll rush to complete their work, and they probably won’t finish the project on time.

A related motivation for underestimation is the desire to instill a sense of urgency in the development team. The line of reason goes like this:

The developers say that this project will take 6 months. I think there’s some padding in their estimates and some fat that can be squeezed out of them. In addition, I’d like to have some schedule urgency on this project to force prioritizations among features. So I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will  deliver in the 6 months they originally estimated.

Are these arguments compelling? To determine that, we need to examine the arguments in favor of erring on the side of overestimation.

Arguments Against Underestimation

Underestimation creates numerous problems – some  obvious, some not so obvious.

Reduced effectiveness of project plans. Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work.

If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems. But numerous studies have found that software estimates are often inaccurate by 100% or more. When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.

Statistically reduced chance of on-time completion Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.

Poor technical foundation leads to worse-than-nominal results A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take longer than it would have taken with an accurate estimate.

Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project. Here are some examples:

  • More status meetings with upper management to discuss how to get the project back on track.
  • Frequent reestimation, late in the project, to determine just when the project will be completed.
  • Apologizing to key customers for missing delivery dates (including attending eetings with those customers).
  • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready     on time, the software itself could be used, and no interim release would be necessary.
  • More discussions about which requirements absolutely must be added because the project has been  underway so long.
  • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the     schedule pressure.

The important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals. These extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately.

Weighing   the  Arguments

Goldratt’s Student Syndrome can be a factor on software projects, but I’ve found that the most effective way to address Student Syndrome is through active task tracking and buffer management (that is, project control), similar to what Goldratt suggests, not through biasing the estimates.

I believe that Parkinson’s Law does apply to software projects. Work does expand to fill available time. But deliberately underestimating a project because of Parkinson’s Law makes sense only if the penalty for overestimation is worse than the penalty for underestimation. In software, the penalty for overestimation is linear and bounded -work will expand to fill available time, but it will not expand any further. But the penalty for underestimation is nonlinear and unbounded – planning errors, short changing upstream activities, and the creation of more defects cause more damage than overestimation does, and with little ability to predict the extent of the damage ahead of time.

Tip: Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

A Working Definition of a “Good Estimate”

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets

Communicating about Estimates, Targets, and Commitments

One implication of the close and sometimes confusing relationship between estimation and planning is that project stakeholders sometimes miscommunicate about these activities. Here’s an example of a typical miscommunication:

EXECUTIVE: How long do you think this project will take? We  need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT LEAD: OK, let me crunch some numbers, and get back to you.

Later…

PROJECT LEAD: We’ve estimated the project will take 5 months.
EXECUTIVE: Five months!? Didn’t you hear me? I said we needed to have this software ready in 3 months for a trade show!

In this interaction, the project lead will probably walk away thinking that the executive is irrational, because he is asking for the team to deliver 5 months’ worth of functionality in 3 months. The executive will walk away thinking that the project lead doesn’t “get” the business reality, because he doesn’t understand how important it is to be ready for the trade show in 3 months.
Note in this example that the executive was not really asking for an estimate; he was asking the project lead to come up with a plan to hit a target. Most executives don’t have the technical background that would allow them to make fine distinctions between estimates, targets, commitments, and plans. So it becomes the technical leader’s responsibility to translate the executive’s request into more specific technical terms.

Here’s a more productive way that the interaction could go:

EXECUTIVE: How long do you think this project will take? We  need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT  LEAD: Let me make sure I understand what you’re asking for. Is it more important for us to deliver 100% of these features, or is it more important to have something ready for the trade show?

EXECUTIVE: We have to have something ready for the trade show. We’d like to have 100%  of those features if possible.
PROJECT LEAD: I want to be sure I follow through on your priorities as best I can. If it turns out that we can’t deliver 100% of the features by the trade show, should we be ready to ship what we’ve got at trade show time, or should we plan to slip the ship date beyond the trade show?

EXECUTIVE: We have to have something for the trade show, so if push comes to shove, we have to ship something, even if it isn’t 100% of what we want.
PROJECT  LEAD: OK, I’ll come up with a plan for delivering as many features as we can in the next 3 months.

Tip: When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.