eduKate Singapore

Project Estimation | How to Estimate Effort, Duration, Cost and Uncertainty Without False Precision

A stakeholder asks, “How long will it take?” Finance asks, “How much will it cost?” A team lead asks, “How many people do we need?” The sponsor asks, “How confident are you?”

Those four questions are related, but they are not the same.

Project estimation is the disciplined process of predicting effort, duration, cost and resource demand from imperfect information while making assumptions, uncertainty, confidence and the basis of estimate visible enough for real decisions.

An estimate is not a promise extracted from the future. It is a model built from what is currently known.

That distinction matters because projects often damage themselves by turning an early estimate into a fixed commitment before the scope, design, risks, resource conditions or evidence are mature enough to support that certainty.

The strongest estimating systems do not merely produce numbers. They explain what the numbers mean, what they depend on, what could move them, and when the project should estimate again.

The one-sentence answer

Project estimation works by defining what is being estimated, selecting a method appropriate to project maturity and available evidence, using historical or expert information carefully, separating effort from duration and cost, representing uncertainty honestly, documenting assumptions, comparing results against outside evidence and updating the estimate as the project learns.

1. Estimation is not one number

People often ask for “the estimate” as though a project has one natural number waiting to be discovered.

In reality, several estimates may exist:

Each answers a different question.

Ten person-days of effort does not automatically mean ten days of duration. Two people may perform parts of the work in parallel. Or one specialist may be available only twice a week, making five person-days of effort consume several calendar weeks.

Cost also depends on more than effort. Materials, equipment, licences, travel, suppliers, overhead, financing, escalation, contingency and operational transition can all matter.

A useful estimating conversation therefore begins by asking: What exactly are we trying to predict?

2. Estimate, target, budget and commitment are different states

Projects become confused when these four ideas are treated as interchangeable.

TermMeaning
EstimateA model-based prediction of likely effort, duration, cost or resource demand.
TargetAn intended performance objective the organisation wants to achieve.
BudgetAuthorised funding available for defined work.
CommitmentA promise or obligation accepted by the project or organisation.

A target can be more aggressive than the current estimate. That is not automatically wrong if the gap is explicit and accompanied by a credible plan to close it.

The problem appears when a target silently replaces the estimate. The organisation begins reporting aspiration as forecast.

Project Performance Measurement and Project Monitoring and Control become more trustworthy when estimates, targets, baselines and forecasts remain distinguishable.

3. Estimation quality depends on scope, risk and historical evidence

A recurring lesson in Project Management Institute estimating material is that estimation quality depends heavily on understanding the scope, understanding associated risks and having usable historical data.

PMI describes analogous, parametric and bottom-up estimating as fundamental approaches and emphasises that estimation improves as project understanding increases rather than functioning as a one-time event. Source: Project Management Institute, “Estimation is not an event, it’s a process!”

This explains why a sophisticated formula cannot rescue weak inputs.

If the project does not know whether it is building one integration or twelve, a detailed labour rate does not create a reliable cost estimate. If the team ignores a major regulatory approval risk, precision in task durations creates false confidence. If historical records mix projects with different scopes and accounting conventions, a statistical model may be precise and misleading at the same time.

Before selecting an estimation technique, test the information environment.

4. The basis of estimate is as important as the estimate

A number without its basis is difficult to challenge, update or learn from.

A basis of estimate explains how the estimate was produced.

The U.S. Government Accountability Office’s Cost Estimating and Assessment Guide treats technical baseline, work breakdown structure, ground rules and assumptions, data, methodology, sensitivity, risk analysis, documentation and later updating with actual costs as interconnected parts of reliable cost estimating. Source: U.S. GAO, Cost Estimating and Assessment Guide.

The basis is what lets a future reviewer understand whether a change in estimate reflects changed scope, changed evidence, changed rates or merely changed optimism.

5. Top-down estimation

Top-down estimation begins with a high-level view of the project or deliverable and works from aggregate information toward a broad estimate.

It can be useful when:

Its weakness is obvious: detail is limited. The estimate may conceal where difficult work sits.

Top-down estimates should therefore be labelled by maturity. They are often useful for decisions about whether to investigate further, not for pretending detailed delivery certainty exists.

6. Analogous estimation

Analogous estimation uses the actual performance of one or more similar past projects, deliverables or activities as the basis for estimating new work.

The reasoning may be simple:

“The last three branch migrations took between six and eight weeks. This branch has similar transaction volume but a more complex legacy interface. A first estimate should therefore start near that reference range and adjust upward for the interface difference.”

The method is fast and valuable early, but similarity must be real.

Useful comparison dimensions include scope, scale, complexity, geography, technology, supplier model, team capability, regulatory context and delivery environment.

The mistake is not using analogy. The mistake is using a convenient project as an analogue without checking whether the factors controlling performance are actually comparable.

7. Reference-class forecasting is a stronger outside view

Reference-class forecasting broadens analogous reasoning from one convenient example to a class of comparable projects.

Instead of asking, “What happened on the last project?” it asks, “What usually happens to projects of this type?”

This can help counter planning fallacy and exceptionalism.

A team may believe the current project is better staffed, better led or technically easier than history. That may be true. The outside view asks for evidence explaining why the current project should perform differently from the reference class.

Reference classes become particularly valuable for Megaproject Management, where optimism and long horizons can create large estimation error.

8. Parametric estimation

Parametric estimation uses a relationship between a measurable driver and the quantity being estimated.

Examples might include:

A simple form is:

Estimate = quantity × rate

The arithmetic is easy. Choosing the right parameter and rate is not.

If the relationship is unstable or ignores complexity, a parametric model can convert a weak assumption into a very consistent error.

Use historical data that is comparable, understand how the rate was derived, and test whether important drivers are missing.

9. Bottom-up estimation

Bottom-up estimation decomposes the project into smaller work elements, estimates each, and aggregates the results.

It becomes increasingly useful as scope and design mature.

A Work Breakdown Structure can provide the decomposition needed to ensure the estimate covers the full project rather than only the most visible activities.

Bottom-up estimating often creates stronger ownership because the people closest to the work can contribute knowledge about actual tasks, handoffs and constraints.

Its weaknesses include time, hidden integration effort and false completeness.

Thousands of detailed estimates can still be wrong if the project omitted an entire deliverable, assumed unrealistic productivity or failed to include rework, coordination and transition.

10. Expert judgement

Expert judgement uses the knowledge of people with relevant experience.

Expert judgement is not inherently weaker than a mathematical model. In novel work, experienced judgement may be the best available evidence.

But judgement should be made inspectable where possible.

Ask:

The goal is not to eliminate tacit knowledge. It is to prevent “because I know” from becoming the only evidence the organisation can preserve.

11. Three-point estimation makes uncertainty explicit

Three-point estimation uses multiple plausible values rather than one deterministic guess.

A common structure asks for:

These values can be used as a range directly or combined through a chosen calculation.

A simple triangular mean is:

(O + M + P) / 3

A commonly taught PERT-style weighted mean is:

(O + 4M + P) / 6

The formula does not create reliable inputs automatically. The deeper value of three-point estimation is the discussion it forces about what favourable and unfavourable conditions actually look like.

PMI’s published process descriptions include three-point estimating among recognised techniques for duration and cost estimation. Source: PMI, PMBOK Guide Sixth Edition errata PDF, Estimate Activity Durations extract.

12. Ranges are often more honest than points

Early estimates should often be communicated as ranges.

“About six to nine weeks under the current scope assumptions” communicates something different from “52 days.”

The second value may look more professional because it is precise. It can actually be less informative if the project is not mature enough to support that precision.

Range width should reflect uncertainty. As design, scope and evidence improve, the range may legitimately narrow.

A narrow range in a high-uncertainty project should be treated as a claim that requires evidence, not as a sign of confidence by itself.

13. Confidence belongs beside the estimate

Two estimates can have the same central value and very different confidence.

Estimate A: 12 weeks based on detailed work packages, stable requirements and recent historical performance.

Estimate B: 12 weeks based on an early concept, one expert opinion and an assumption that a supplier interface will be straightforward.

Reporting only “12 weeks” loses critical information.

Confidence can be described qualitatively or quantitatively, but it should be linked to evidence such as scope maturity, historical data quality, design stability and unresolved risk.

14. Effort estimation is not duration estimation

Effort estimates the amount of work. Duration estimates elapsed working time.

A task requiring 40 person-hours does not necessarily take one person one week.

It may take two specialists 20 hours each. Or it may take one person two weeks because the work depends on customer feedback between steps. Or it may require ten calendar days because one machine processes only a limited batch per day.

Duration therefore depends on effort plus resource availability, sequencing, waiting, calendars, productivity, handoffs and constraints.

Project Schedule Management owns the time network. Project Estimation supplies credible effort and duration inputs to that network.

15. More people do not always reduce duration proportionally

Parallel capacity works only where work can actually be divided.

Some work is inherently sequential. Some requires one accountable specialist. Some becomes slower when more people increase communication and integration overhead.

A ten-day estimate should not become five days automatically because two people are assigned.

Before compressing duration through staffing, identify:

Project Resource Management is where capacity assumptions become actual allocation decisions.

16. Cost estimation is broader than labour

Labour can be a major cost, but complete project cost may include much more.

Project Cost Management owns budgeting, commitments, actuals, forecasting and cost control. This article owns the upstream discipline of constructing the estimate that those controls depend on.

17. Estimate maturity should increase through the project

An estimate at concept stage and an estimate after detailed design should not be expected to have the same accuracy.

Early estimates support screening and strategic choice. Later estimates support commitments, procurement and control.

PMI estimating material explicitly treats estimation as a living process rather than one event. The project should re-estimate when new information materially changes the model.

This might occur after:

The estimate should become more evidence-rich as the project becomes more real.

18. Re-estimation is not automatically failure

Projects sometimes resist updating estimates because a changed number appears to admit that the original estimate was wrong.

That mindset encourages stale forecasts.

If scope, evidence or risk changes, an unchanged estimate may be less professional than an updated one.

The useful question is not “Did the estimate move?” It is “Can we explain why it moved, and did the new information arrive when it reasonably could have?”

This preserves accountability without demanding impossible foresight.

19. Forecast accuracy should be learned, not assumed

An organisation becomes better at estimation when it compares estimates with actual outcomes systematically.

For comparable work, track:

Over time, the organisation can discover whether certain project types are systematically underestimated, which teams estimate consistently, where risk allowances are insufficient and which parameters are genuinely predictive.

This is one of the ways Project Management Maturity converts experience into institutional capability.

20. Estimation error is not one thing

An estimate can miss for several reasons:

These causes imply different remedies.

Improving estimation requires diagnosing the source of error rather than demanding that estimators “be more accurate” in the abstract.

21. The planning fallacy

Teams naturally focus on the specific plan they intend to execute.

This inside view can underweight ordinary disruption: clarification, rework, approval delay, integration, absence, failed tests and coordination.

The outside view asks what happened to comparable work historically.

Strong estimating combines both views. The inside view explains the current design. The outside view challenges whether the resulting estimate is unusually optimistic relative to experience.

22. Anchoring

Estimates can be distorted by the first number introduced.

If an executive says, “Surely this is a three-month job,” later estimates may unconsciously cluster near three months even when evidence points elsewhere.

One defence is independent estimation before group discussion.

Another is to begin with data, reference classes or decomposition rather than the desired deadline.

Targets can still be discussed afterward. The sequence matters because evidence should challenge the target rather than being forced to justify it.

23. Strategic underestimation

Some estimates are not merely optimistic. They are shaped by incentives.

A team may believe a low estimate increases the chance of approval. A supplier may price aggressively to win. A sponsor may prefer a date that fits a public commitment. A business case may need a certain cost to remain attractive.

Governance should therefore consider independence, estimate challenge and traceable assumptions where incentives are strong.

Project Assurance can provide a separate view before major commitments.

24. Contingency is not hidden padding

Estimators sometimes add unrecorded extra time or cost to protect themselves from uncertainty.

This can make planning opaque.

A stronger system separates the base estimate from explicit contingency associated with known uncertainty and risk.

The exact treatment depends on the organisation and project type. The important principle is that uncertainty should be visible enough for governance to understand what the estimate contains.

Project Risk Management provides the uncertainty model; estimating converts part of that uncertainty into expected effort, duration or cost implications where appropriate.

25. Reserve analysis

Reserve analysis asks how much additional time or cost should be held for uncertainty.

The reserve should reflect the actual exposure rather than one arbitrary percentage used for every project.

Projects with mature repetitive work may need relatively modest allowance. Novel, integrated or externally dependent work may require broader protection.

As uncertainty retires, reserves can be reviewed rather than automatically consumed.

26. Monte Carlo simulation and probabilistic estimates

For complex projects, uncertainty can be modelled probabilistically.

Instead of one duration for each uncertain activity, the model uses distributions or ranges and runs many simulated outcomes.

The result can support statements such as:

“Under the modelled assumptions, 30 June is associated with a lower completion probability than 31 July.”

This is more decision-useful than presenting one date with hidden uncertainty.

The simulation is only as credible as its network logic, distributions, correlations and assumptions. Mathematical complexity does not remove model risk.

The GAO cost and schedule guides both emphasise risk and uncertainty analysis as part of reliable estimating and scheduling practice. Source: U.S. GAO, Schedule Assessment Guide.

27. Sensitivity analysis reveals what controls the estimate

A project should know which assumptions move the estimate most.

If a ten-percent change in testing effort barely affects the completion date but a two-week supplier slip changes the entire schedule, management attention should reflect that difference.

Sensitivity analysis helps distinguish the assumptions that deserve the strongest validation from those with limited consequence.

This is especially useful before irreversible decisions because not all uncertainty deserves equal research effort.

28. Estimate assumptions should be managed explicitly

Every estimate depends on assumptions.

Examples include:

If the estimate depends strongly on an assumption, that assumption deserves validation or risk treatment.

Assumptions should not be buried in explanatory notes nobody revisits. They belong in the project’s active control system.

29. Estimate at the right level of detail

Too little detail hides important work. Too much detail creates false control and maintenance burden.

A useful estimating level is one at which the work is sufficiently understood for meaningful assumptions and accountability, but not decomposed beyond the point where the apparent precision exceeds the knowledge available.

Early phases may use deliverables or major work packages. Later phases may estimate activities or detailed quantities.

The estimate should become more granular as the work becomes more knowable.

30. Estimate integration effort explicitly

Projects often estimate components well and integration poorly.

Five teams may each estimate their own deliverable accurately while nobody estimates:

The work exists even when no component owner naturally claims it.

Project Integration Management and Project Dependency Management can help reveal this hidden effort.

31. Rework belongs somewhere in the model

Some estimating cultures assume every activity succeeds first time.

That may be realistic for stable repetitive work. It may be unrealistic for novel design, software integration, research or iterative content production.

Do not simply add a generic rework percentage without thought. Instead ask what defect, review or learning behaviour is normal for this type of work and how historical actuals reflect it.

Where rework is driven by identifiable risk, connect it to that risk rather than hiding it inside the base effort.

32. Estimate the handoffs, not only the hands-on work

A reviewer may need four hours to inspect a document, but the review may consume four days of elapsed time because the reviewer is unavailable until Thursday and one day is needed for clarification afterward.

The hands-on effort is not the entire scheduling consequence.

Estimate waiting, queueing, approval and dependency timing where they materially control the plan.

This is one reason project duration cannot be calculated by dividing total effort by headcount.

33. Supplier estimates require commercial interpretation

A supplier bid is evidence, but it is not neutral truth.

The supplier may estimate within a particular scope boundary, pricing strategy, commercial incentive or contractual assumption.

Compare supplier estimates with internal estimates, market data and historical performance where available.

Also distinguish price from project cost. A contract price may exclude client integration work, internal resources, transition, assurance, contingency or downstream operating cost.

Project Procurement Management should interpret the supplier estimate inside the commercial architecture rather than copying it directly into the project forecast.

34. Agile estimation

Agile teams often estimate differently because detailed scope is intentionally allowed to evolve.

Common approaches include relative sizing, story points, throughput and empirical forecasting.

Story points represent relative effort, complexity and uncertainty rather than literal hours. Atlassian’s current Agile guidance describes story points as a relative measure of effort that considers complexity, amount of work and uncertainty. Source: Atlassian, Agile estimation and story points.

Story points should not be converted mechanically into individual productivity targets. Their value is local team planning and shared understanding.

Agile Project Management owns the broader adaptive system. This article owns the estimation logic that remains necessary even when detailed scope is flexible.

35. Throughput-based forecasting

When work items are sufficiently comparable and historical flow data exists, teams can forecast using observed throughput.

If a team completes a variable number of items each week, the historical distribution can support probabilistic forecasts for a backlog rather than converting every item into hours.

This approach works best when item definition and process conditions are reasonably stable.

A change in team composition, item type, quality threshold or workflow may make historical throughput less predictive.

36. Estimating novel work

Novel work is difficult because historical analogues are weak and design uncertainty is high.

Instead of forcing a precise estimate, the project can estimate the next learning step.

For example:

The output of that work is not only a prototype. It is improved estimation evidence.

This is often more honest than pretending the project can predict the full solution before the critical uncertainty has been tested.

37. Estimating research and creative work

Research, writing and creative work can be estimated, but the model should respect discovery.

Effort may depend on source availability, novelty, review depth, number of claims, feedback cycles and required verification.

A word-count rate alone can be misleading because 5,000 words of synthesis from settled material differs radically from 5,000 words requiring primary-source reconciliation or technical modelling.

Estimate the real drivers: evidence complexity, structure, review, revision and publishing controls.

38. A worked example: estimating a researched learning guide

Consider a fictional commission for a researched educational guide. The purpose is to estimate effort, duration and cost under visible assumptions.

The team identifies five work packages:

Work packageEffort estimatePrimary basis
Research and evidence packet14–22 hoursAnalogous guides adjusted for higher source complexity.
Structure and outline4–7 hoursExpert judgement and recent actuals.
Drafting18–28 hoursParametric reference using comparable accepted longforms, adjusted for topic novelty.
Editorial and evidence review8–14 hoursBottom-up review tasks.
Corrections, staging and verification6–10 hoursHistorical range from comparable releases.

Adding the ranges produces a gross effort range of 50–81 hours before considering overlap, specialist availability or additional risk allowance.

That is not yet the duration.

The reviewer is available only three afternoons each week. Research and outline can overlap partly. Drafting cannot finish until a key source question is resolved. Publication verification needs a separate operator.

Under those constraints, 50–81 hours of effort might translate into a duration of two to three working weeks rather than six to ten working days.

If the project uses an internal blended labour rate of $80 per hour purely for illustration, the labour component would range from $4,000 to $6,480. That still would not represent complete project cost if external licences, specialist review or media are required.

The example demonstrates why effort, duration and cost should be estimated as related but separate quantities.

39. Three-point example

Suppose the team estimates the editorial review as:

A simple triangular mean is 12 hours.

A PERT-style weighted mean is approximately 11.5 hours.

The useful information is not the difference between 12 and 11.5. It is the spread from 8 to 17 and the reasons behind it.

Perhaps the pessimistic case assumes extensive source correction. That tells the project which uncertainty deserves attention before review begins.

40. Estimate quality through independent challenge

High-consequence estimates deserve review by someone who did not build them.

Independent challenge can ask:

The review should not force conservatism automatically. It should improve calibration.

41. Estimation and project requirements

An estimate is only as stable as the requirements it assumes.

The newly published Project Requirements Management guide explains how needs become traceable and testable commitments.

When requirements remain unresolved, the estimate should represent that uncertainty rather than assume one convenient interpretation.

If one requirement could imply either a minor configuration or a custom integration, produce scenarios or ranges until the requirement is resolved.

42. Estimation and project dependencies

Dependencies affect duration even when they do not increase hands-on effort.

A three-hour approval can consume two weeks if the approving board meets fortnightly. A supplier input can control a critical milestone even if the project performs no effort while waiting.

Project Dependency Management helps make the receiving condition and required date explicit before estimates are converted into schedules.

43. Estimation and project issues

Once an issue occurs, the project may need to re-estimate remaining work.

The newly published Project Issue Management guide separates active problems from future risk.

If a test failure creates rework, the remaining estimate should reflect the actual diagnosis and repair path rather than preserve the old number for appearance.

44. Estimation and change control

Approved change should trigger estimate impact analysis where relevant.

One scope change can affect effort, duration, cost, resources, testing, suppliers and operational transition.

Project Change Control authorises the changed commitment. Estimation quantifies the likely consequence before authority chooses.

45. Estimation and project planning

Estimation is one input to planning, not a substitute for planning.

Project Planning integrates scope, dependencies, resources, quality, risk, governance and transition.

A highly accurate estimate of individual tasks does not create a credible delivery plan if the sequence, resource constraints or acceptance rules are wrong.

46. Estimation and AI

AI can improve estimation by retrieving historical analogues, extracting quantities, identifying omitted work, generating scenarios, comparing estimate assumptions and analysing actual performance.

AI can also produce false precision quickly.

A model may confidently estimate a task without access to real productivity data, local constraints or the actual requirement state.

A strong AI-assisted estimation workflow therefore separates suggestion from evidence:

AI Project Management develops the wider governance boundary.

47. Common failure: estimate equals deadline

A stakeholder announces a date and asks the project to “estimate to it.”

The date may be a valid target. The estimate should still describe what current evidence predicts.

If the target and estimate differ, show the gap and identify what must change: scope, resource, sequence, quality approach or risk tolerance.

48. Common failure: averaging expert opinions without understanding disagreement

Three experts estimate 10, 20 and 50 days. The team reports 27 days.

The arithmetic hides the real information: why does one expert believe 50?

Perhaps that expert knows about an interface problem the others missed.

Investigate disagreement before averaging it away.

49. Common failure: copying historical actuals without normalising them

Historical data can contain changed rates, different scope, unusual overtime, one-off defects, inflation or accounting differences.

Use history as evidence, not as an unquestioned template.

50. Common failure: detailed estimates before scope maturity

Teams sometimes respond to uncertainty by estimating at extreme detail.

This can produce thousands of numbers whose total appears precise while the project still does not know what it is building.

Use ranges and scenarios until the scope supports finer detail.

51. Common failure: estimate excludes management and coordination

Teams estimate only production tasks and omit planning, governance, meetings, integration, assurance, procurement, reporting, training and closure.

Those activities still consume capacity.

52. Common failure: estimates are never calibrated

The same estimating method is used year after year without comparing predicted and actual performance.

An organisation that does not learn from actuals is paying repeatedly for the same uncertainty.

53. Common failure: uncertainty disappears in the executive summary

The estimating team produces a range and confidence discussion. The steering paper reports one number.

That compression can change the meaning of the estimate.

Executive communication should simplify without erasing the uncertainty relevant to the decision.

54. A practical estimation workflow

  1. Define the object: identify exactly what effort, duration, cost or resource demand is being estimated.
  2. Assess maturity: understand scope, requirements, design, risks and available evidence.
  3. Select method: choose analogous, parametric, bottom-up, top-down, expert judgement, three-point or a combination.
  4. Gather evidence: use historical actuals, reference classes, quantities, supplier data and expert knowledge.
  5. Document assumptions: state what must be true for the estimate to remain credible.
  6. Represent uncertainty: use ranges, scenarios or probability where useful.
  7. Separate dimensions: distinguish effort, duration, resources and cost.
  8. Check integration: include coordination, handoffs, testing, transition and management work.
  9. Challenge: compare against outside evidence and independent judgement.
  10. Record basis: preserve method, data, assumptions, exclusions and estimate date.
  11. Use for decision: explain what the estimate implies for funding, schedule, scope or risk.
  12. Re-estimate: update when new information changes the model materially.
  13. Calibrate: compare estimates with actuals and improve the organisational estimating system.

This is a practical teaching sequence, not a mandatory professional standard. Different industries organise estimating differently. The underlying discipline remains transferable.

55. A practical estimation review

56. The deeper idea

Project estimation is organised humility about the future.

The project must act before it knows everything. It still needs budgets, dates, people, suppliers and commitments. Estimation creates a disciplined bridge between incomplete knowledge and necessary decision.

The strongest estimate is not the number that never changes. It is the estimate whose logic is visible, whose uncertainty matches the evidence, whose assumptions can be tested and whose accuracy improves as the organisation learns.

False precision tries to make uncertainty disappear from the page. Professional estimation does something harder: it keeps uncertainty visible without surrendering the obligation to decide.

Sources and boundaries

The estimating methods and reliability principles in this article were checked against current public PMI, U.S. GAO, APM and practitioner resources in September 2026. The worked examples, calculations, review questions and teaching sequence are original explanatory material. They should be adapted to the project’s industry, contractual environment, accounting rules, risk model and governance.

  1. Project Management Institute — Estimation is not an event, it’s a process! Discusses analogous, parametric and bottom-up estimating and the importance of scope, risk and historical data.
  2. U.S. Government Accountability Office — Cost Estimating and Assessment Guide. Provides a structured methodology for reliable cost estimates, including technical baselines, assumptions, data, sensitivity, risk and updating with actual costs.
  3. U.S. Government Accountability Office — Schedule Assessment Guide. Covers reliable schedule construction and schedule risk.
  4. Association for Project Management — What is project controls? Places estimating within the wider analytical discipline of scope, time, cost, risk, change and performance control.
  5. Atlassian — Project estimation: methods and best practices. Current overview of common project-estimation methods and practical team use.
  6. Asana — Project estimation methods and best practices. Current practitioner overview of top-down, bottom-up, three-point and parametric methods.

Continue the Project Management series

Explore the connected learning guides

Choose the question that brought you here. Open one useful guide, try a small task, and stop when you have what you need.

Take one question further

The same learning habit can travel across subjects, while each subject keeps its own methods. These routes help you notice a difficulty, understand one part of it, and return to something you can do.

A word is familiar, but using it is difficult.

Move from recognising a word to retrieving it in a new context. Understand vocabulary plateaus.

Try it without the guide: Choose one word you already know. Close the guide and use it in a new sentence. Explain why it fits; try another context tomorrow.

A piece of writing has ideas, but the reader loses the thread.

Make the order of events and the links between sentences clear. Explore composition writing.

Try it without the guide: Choose one short paragraph. Read the relevant explanation, close it, and revise the paragraph. Ask someone to tell you what happened and why.

The Mathematics seems familiar, but marks still disappear.

Find the first point where the working stops being reliable. Find Secondary 4 A-Math mark leakage.

Try it without the guide: For a Secondary 4 A-Math question you have attempted, locate the first uncertain line. Repair that step, then try a comparable question without the worked answer.

A Science fact is remembered, but the explanation is incomplete.

Connect the evidence to a scientific idea and the resulting change. Follow the Primary Science learning route.

Try it without the guide: Choose a familiar Primary Science example. Explain the evidence, the idea and the result without notes. Then change one condition and explain your prediction.

Two accounts of the world seem to disagree.

Check the question, source, date and evidence before combining claims. Explore the World Knowledge research library.

Try it without the guide: Take one claim. Find the source best placed to support it, note its date, and state what remains uncertain. Return to your original question.

There is plenty of help, but independence is hard to see.

Check what the learner can understand and do after support is removed. Understand how education works.

Try it without the guide: Choose one small task the child has practised. Agree on a calm, brief attempt without prompts. Use what happens to choose one next step, then stop.

For the structure behind these connections, read the eduKateSingapore runtime manifest and the eduKate ecosystem boot contract. The reader map describes public navigation; those manifests preserve the wider ownership and return rules.

eduKate Asia

Subscribe to
our newsletter

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading