MGT 646 Module 5 Cost and Budget Example

Fourteen Million Dollars, Branch by Branch: Estimating and Budgeting SmartSync Without Fooling Ourselves

Student Name

Master of Business Administration, Aspen University

MGT 646: Project Management Organizational Framework

Instructor Name

Month Day, Year

Fourteen Million Dollars, Branch by Branch: Estimating and Budgeting SmartSync Without Fooling Ourselves

The SmartSync charter assumed $14 million. The WBS now shows what that money must buy, and the schedule shows when. This module tests whether the figure is enough and turns it into a budget that the team can manage against. Every figure is an assumption standing in for the course case file, but the reasoning applies to whatever numbers a class receives.

Choosing a Method for Each Branch

No single estimating method suits the whole project. Where owners know the work in detail, as in the app and cloud update branches, estimates are built bottom up from work packages in the WBS dictionary. Tooling is estimated by analogy with NexTech's last countertop product, adjusted for the more complex enclosure. Labeling uses a parametric rate: 40,000 clips at a quoted $1.10 per clip with two-person review. For the riskiest packages, such as model compression and certification, owners gave optimistic, most likely and pessimistic figures, and the budget uses the weighted average of the three.

The Optimism in Expert Judgment

Jørgensen (2004) pulled together the research on how experienced developers judge the effort a software task will take. He found that expert judgment was the most common method in practice and was often at least as accurate as formal estimation models, especially when experts had relevant domain knowledge. But experts tended toward optimism, were influenced by irrelevant information such as a customer's hoped for budget, and were often more confident than their accuracy justified. He proposed practical remedies: asking estimators to justify estimates, combining estimates from several independent experts, using checklists and giving feedback on past accuracy.

SmartSync applies three of these. The firmware and machine learning estimates were made independently by two engineers each, and the differences discussed. Owners filled in a short checklist covering testing, integration, documentation and rework. And owners were shown how their estimates on NexTech's last product compared with actual cost.

What the Research Says About Methods

Jørgensen and Shepperd (2007) systematically reviewed several hundred journal papers on software cost estimation and classified them by topic, method and research approach. They found that research concentrated on formal estimation models, especially regression, while expert judgment, though common in practice, received less attention, and that many studies used old or unrepresentative data sets. The review suggests treating any single published method with caution and checking estimates against an organization's own history where it exists.

Why Budgets Come in Low

Flyvbjerg et al. (2002) examined 258 transport infrastructure projects and found costs underestimated in almost nine of every ten, with an average overrun for rail of 45%. The pattern had not improved over seventy years. They argued that such consistent underestimation could not be explained by honest error and pointed to strategic misrepresentation: estimates are kept low to win approval. A product launch at a private firm is not a public railway, but the same pressure exists when a team wants its project funded. The SmartSync sponsor was told plainly that the first bottom-up total came to $13.1 million before reserves, and that a budget that fits exactly is one to doubt.

The Budget

Project Cost and Unit Cost

Two different cost targets run through the case and should not be confused. The project budget of $14 million pays for designing, building and launching SmartSync. The unit cost target of $72, set in the charter, is what each device should cost to manufacture once production runs. Decisions in the project trade one against the other. A more expensive enclosure tool with more cavities raises the project budget but lowers unit cost. A cheaper chip lowers unit cost but may force more spending on model compression. The project manager reports both measures to the sponsor, because a project that finishes under budget with a device that costs $85 to make has not succeeded.

Reviewing the Estimate

Before the budget went to the sponsor, the finance partner and an engineering manager from the other product line reviewed it independently. They questioned three items: the tooling analogy, since the earlier product had a simpler shape; the labeling rate, which assumed no relabeling; and the launch budget, which had no allowance for retailer promotion fees. The tooling estimate rose by $120,000, a 10% relabeling allowance was added and promotion fees were moved into the launch branch from marketing's budget, where they would have been forgotten.

Spending Over Time

Spending is light in the first six months, about $2.5 million, mostly salaries and data collection. It peaks between months seven and twelve, about $6.5 million, when tooling, validation builds, labeling and partner integration overlap. The last six months, about $3.4 million, cover certification, the pilot run and launch. Inventory for the first production run is funded by operations, not the project.

Controlling Costs

The project manager may spend contingency on the risks it was set aside for and reports each use. Management reserve requires the sponsor's approval. Monthly reports compare spending with the time-phased plan by branch. From the first validation build onward, the report also shows earned value, so the sponsor sees whether money spent matches work completed and not merely whether spending follows the calendar. Branch owners explain any variance above 10% in a sentence or two, and the project manager tracks the remaining contingency against the expected cost of open risks, which Module 6 will estimate. Purchase orders above $50,000 need the project manager's signature, and commitments to the tool maker and the labeling firm are recorded when signed, not when invoiced, so the budget shows money already promised.

Conclusion

Jørgensen's findings on expert estimates, Jørgensen and Shepperd's review of methods and Flyvbjerg and colleagues' evidence of systematic underestimation shaped a budget with a clear basis for each figure and reserves for both known and unknown risks.

References

Flyvbjerg, B., Holm, M. S., & Buhl, S. (2002). Underestimating costs in public works projects: Error or lie? Journal of the American Planning Association, 68(3), 279-295. https://doi.org/10.1080/01944360208976273

Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1-2), 37-60. https://doi.org/10.1016/S0164-1212(02)00156-5

Jørgensen, M., & Shepperd, M. (2007). A systematic review of software development cost estimation studies. IEEE Transactions on Software Engineering, 33(1), 33-53. https://doi.org/10.1109/TSE.2007.256943