The document discusses various techniques for estimating costs and timelines for software projects, including: - Cost estimation should be done throughout the software development life cycle to continually refine estimates. - Common metrics for estimating include person-days, person-months, and person-years. - Methods like expert judgement, top-down estimating, bottom-up estimating, and parametric formulae can be used. - PERT (Program Evaluation and Review Technique) uses optimistic, most likely, and pessimistic estimates to calculate expected time. - Gantt charts can be used for project scheduling and identifying critical paths. - Budgeting rather than estimating is recommended for strategic decisions to reduce risks of cost overruns

1. Software Engineering
WEEK 4
Project Management I: Cost estimation
Sibel Kuzgun Akın

2. How long will this take?
● When the project will finish?
● Every project manager should answer this
question.

3. Cost estimation
● Cost estimation can be defined as the
approximate judgement of the costs for a
project.
● Cost estimation will never be an exact
science because there are too many
variables involved in the calculation for a
cost estimate, such as human, technical,
environmental, and political.
● http://www.computing.dcu.ie/~renaat/ca421/report.html

4. Common metrics
● Person days
● Person months
● Person years ?!
● Cost estimation is an important tool that
can affect the planning and budgeting of a
project.

5. Cost estimation during the
software life cycle
● Cost estimation should be done throughout
the entire life cycle.
● First: At the beginning of the project after
the requirements analysis.
● Doing cost estimation during the entire life
cycle allows for the refinement of the
estimate because there is more data
available.

6. Cost estimation during the
software life cycle
● Effective monitoring and control of the
software costs is required for the
verification and improvement of the
accuracy of the estimates.
● The success of a cost estimate method is
not necessarily the accuracy of the initial
estimates, but rather the rate at which the
estimates converge to the actual cost.

7. Time estimation methods
● Expert judgement: Should be used when
guided by historical information.
● Top down estimating:
– Detailed information is limited
– Previous activities are similar
– The individuals making estimates are
experienced.
● Bottom up estimating
● Parametric formulae

8. PERT
● Project Evaluation and Review Technique
● Expected time = (optimistic + 4 * most likely + pessimistic) / 6
● First developed by the United States Navy
in the 1950s, it is commonly used in
conjunction with the critical path method
(CPM).
● https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

9. PERT and CPM
PERT network chart
for a seven-month
project with five
milestones (10
through 50) and six
activities (A through
F).

10. PERT Example
7 tasks, labeled A through G. Some tasks can be done concurrently (A
and B) while others cannot be done until their predecessor task is
complete (C cannot begin until A is complete). Additionally, each task has
three time estimates: the optimistic time estimate (o), the most likely or
normal time estimate (m), and the pessimistic time estimate (p). The
expected time (te) is computed using the formula (o + 4m + p) ÷ 6.

11. Gantt Chart

12. Project Scheduling
Finding the critical path
● https://youtu.be/-TDh-5n90vk
PERT/CPM – Calculating variance and
probabilities
● https://youtu.be/2124ZV4wbQ8

13. Cost estimation

14. Estimation
Estimation is based on −
● Past Data / Past
Experience
● Available Documents /
Knowledge
● Assumptions
● Identified Risks
The four basic steps in Software
Project Estimation are estimating:
● The size of the development
product.
● The effort in person-months or
person-hours.
● The schedule in calendar months.
● The project cost in money.
Estimation determines how much money, effort,
resources, and time it will take to build a specific
system or product.

15. Observations
● Estimation need not be a one-time task
in a project. It can take place during −
– Acquiring a Project.
– Planning the Project.
– Execution of the Project as the
need arises.
● Project scope must be understood
before the estimation process begins. It
will be helpful to have historical Project
Data.

16. Observations
● Project metrics can provide a historical
perspective and valuable input for
generation of quantitative estimates.
● Planning requires technical managers and
the software team to make an initial
commitment as it leads to responsibility
and accountability.

17. Observations
● Past experience can aid greatly.
● Use at least two estimation techniques to
arrive at the estimates and reconcile the
resulting values. Refer Decomposition
Techniques in the next section to learn
about reconciling estimates.
● Plans should be iterative and allow
adjustments as time passes and more
details are known.

18. Your agile project needs a
budget, not an estimate
First question: How much is this going to cost?
Second question: How long will this take?
Two possible answers:
1.We don’t know;
2.Let us estimate and get back to you.
It’s the responsibility of the technical team to answer
the question “How much is this going to cost?”
https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

19. Estimations versus budgets
A recent Harvard Business Review article revealed
that one in six IT projects has a cost overrun of
200%. That’s a pretty high rate of failure for
estimation.
To minimize the risk of having your next technical
project go awry, stop estimating and start budgeting.
For most strategic decisions, estimating is too
precise. Estimating breaks down a software project
into granular, 1-to-3 day chunks. For a $100,000
project, that’s a lot of work. For a $1 million project
or bigger, that’s inordinate.

20. A four-step, tactical approach to budgeting
which takes 20% less time than estimating
1. Identify decisions
– Will we do this project?
– Should we hire more people?
2. Match precision to decision
– Detailed decisions -> Estimation
– Strategic decisions -> Budgeting

21. Four step approach
3. Budget
– When the decision you are making is strategic,
budget using a top-down approach, and get only
as granular as you need to in order to have
enough information to make your decision.
Let’s say we are building an online bookstore.
– Shopping Cart
– Browse Books
– Search Books
– Manage Inventory
– Preview Inside of Book

22. Four step approach
● The decision we aim to make is: Should we build this
Online Book Store?
● We expect the project to cost 775k – 4.3M

23. Four step approach
We can use this table to make a decision:
● If we have $500,000, we should cancel it.
● If we have $5 millions, we can do it.
● But what if we have $2.5 millions???

24. Four step approach
4. Ranges and confidence levels
– 1.Prioritize the topics
– 2.Identify which topics are “Required” vs
“Nice to Haves”
●

25. Four step approach: Application
to Minimum Viable Product
If you are using a Lean Startup approach to
building your software and are building an
MVP, you have two options:
– 1. You can create one budget for the entire
project and list the topics to include in the
MVP as “Required” and everything else
as not required.
– 2. You can create a budget solely for the
MVP and leave the rest of the product
intentionally vague.

26. Four step approach:
Calculate confidence levels
If we have a $2.5M budget, we’ll finish our top 2 priorities within the budget.
● 86.5% likelihood of finishing “Manage Inventory”
● 59% likelihood of finishing “Search Books”
● And 23% likelihood of finishing “Preview Inside Books”

27. Four step approach:
Analysis of results
The same analysis may be used to estimate time.
HINT: Use a software: http://www.stridenyc.com/ballpark

28. It will continue...
● Function points
● Extreme programming practices
● Delphi
● WBS: Work breakdown structure