| Course | MGT 505 Managing in an Age of Information Technology Change |
|---|---|
| Module | Module 4 |
| Paper type | MBA estimating paper |
| Length | About 1,035 words, 6 pages |
| Format | APA 7 student paper |
| School | Aspen University |
| Program | Master of Business Administration |
| Updated | October 2026 |
Free sample paper for MGT 505 Module 4
Four Months, Seven Months or Nine? Estimating a Website Rebuild for an Online Musical Instrument Retailer
Student Name
Master of Business Administration, Aspen University
MGT 505: Managing in an Age of Information Technology Change
Instructor Name
Month Day, Year
Four Months, Seven Months or Nine? Estimating a Website Rebuild for an Online Musical Instrument Retailer
Music Row Gear, a composite online retailer in Nashville, Tennessee, sells guitars, amplifiers, keyboards and recording equipment to musicians across the country, with about $38 million in annual sales. Its website, built eight years ago, is slow on phones, and its checkout fails often enough that about 6% of carts are abandoned at payment. The owners want a new site live by September, before the holiday season. Asked for an estimate, the four-person development team said four months. The owners asked the operations manager, an MBA student, whether that estimate could be trusted and what to plan around.
How Software Estimates Are Made
Jørgensen (2004) reviewed studies of expert estimation of software development effort, the most common approach, in which experienced developers judge how long work will take. He found that expert estimates were not systematically less accurate than formal models and were sometimes better, especially when experts had relevant experience. But they tended toward optimism, and they were easily influenced by irrelevant anchors, such as a customer's desired deadline. Accuracy improved when estimators used historical data from similar projects, broke the work into parts, combined estimates from several people and gave ranges rather than single numbers.
Model-Based Estimation
Boehm (1981) developed one of the best-known approaches to estimating software cost, relating effort to the size of the software and adjusting for factors such as product complexity, required reliability, team capability and experience and schedule pressure. Models of this kind force estimators to state their assumptions about size and conditions, which makes the estimate open to challenge. Their weakness is that size itself must be estimated, often from incomplete requirements.
Three Estimates
| Method | Basis | Estimate |
|---|---|---|
| Team's expert estimate | Developers' judgment, given the September goal | 4 months |
| Size-based model | About 140 pages and components, team capability adjustments, high reliability needed for payments | 8 months |
| Past projects | Company's last four projects ran an average of 70% over first estimates; applied to 4 months | about 7 months |
| Combined range | Weighted toward history and model | 6 to 9 months, most likely 7 |
Why the Team's Number Is Low
Jørgensen's findings suggest two reasons. The September goal was stated before the team estimated, acting as an anchor. And the team estimated only development, not testing, data migration from the old site or the payment provider's review, which past projects show took weeks. Breaking the work into parts revealed these missing pieces.
Breaking Down the Work
Following Jørgensen's advice to divide the work, the operations manager listed the major parts with the team: product catalog and search, about 2 months; product pages and reviews, about 1.5 months; cart and checkout, about 1.5 months; customer accounts, about 1 month; data migration of 9,000 products and 120,000 customer records, about 1 month; payment provider review and security testing, about 1 month; and performance testing on phones, about half a month. Some parts can run in parallel, but the total effort far exceeds what four people can do in four months. The breakdown alone moved the team's own estimate to about six months.
Assumptions Behind the Range
The seven-month most-likely estimate assumes the team stays at four developers, the scope does not grow beyond the list above, the payment provider's review takes no more than four weeks and the product data can be migrated without major cleanup. If the owners add features, such as a used-gear marketplace they have discussed, the estimate grows. If data cleanup proves heavy, migration could take twice as long.
Comparing With the Last Project
The company's last major project, a new inventory system three years ago, was estimated at three months and took five and a half. The team then also estimated only development and forgot data cleanup, which took six weeks. Using that history is exactly the outside view Jørgensen recommends, and it explains why the past-projects estimate carries weight in the combined range.
Can More People Speed It Up?
The owners asked whether hiring three contractors could hold September. Brooks (1995) warned that people and months are not interchangeable in software: new people must learn the code and the business, and communication paths multiply as a team grows. Adding contractors early, for clearly separable work such as product page templates, might save a few weeks; adding them late would likely cost time.
The Cost of Being Wrong
Planning around four months has real costs if it proves wrong. A rushed September launch during preparation for the holiday season could break checkout when sales are highest; a 2% drop in conversion over November and December would cost about $250,000 in margin. Planning around seven months, with a smaller September release, protects the busiest season.
Communicating the Range to the Owners
Owners understandably want one date. The operations manager will present the estimate as a most-likely date with a range and the three or four factors that would move it, and will report at each checkpoint which way those factors have moved. This turns the estimate from a promise that will be broken into a forecast that is updated, which builds trust between the owners and the team rather than eroding it each time a date slips.
A Schedule With Checkpoints
The schedule targets a January launch, avoiding a risky change during the holiday peak. Instead, the team will deliver a smaller release by September: a rebuilt checkout on the existing site, addressing the abandoned carts that cost the most revenue. Checkpoints after design, after the first working product pages and after payment testing will revise the estimate, narrowing the range as uncertainty falls.
What the Team Learned
The exercise also changed how the team estimates. From now on, every estimate will list its parts, include testing and migration, compare with similar past work and be given as a range before anyone mentions a target date.
Conclusion
The team's four-month estimate reflects common patterns of optimism and anchoring that Jørgensen's review describes. A size-based estimate grounded in Boehm's work and the company's own history point to about seven months, and Brooks's warning limits how much extra people can help. A range, a smaller early release and checkpoints give the owners an honest plan.
References
Boehm, B. W. (1981). Software engineering economics. Prentice-Hall.
Brooks, F. P., Jr. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.
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
MGT 505 Module 4 instructions, in plain terms
Estimating and scheduling technology work is the subject of Module 4 in Aspen's MGT 505. Students typically build an estimate for a real or realistic project and explain how they would schedule and protect it. Your classroom's Module 4 instructions take priority; this example estimates one retailer's website rebuild. Describe the project and any existing estimate, including how it was produced. Explain research on how software estimates are made and why they go wrong. Produce more than one estimate using different methods. Combine them into a range with stated assumptions. Build a schedule with checkpoints, and explain how adding people would or would not change it.
How this MGT 505 Module 4 example is built
The paper opens with Music Row Gear, which sells guitars, keyboards and recording equipment online with $38 million in sales. Its four-person team estimated a rebuild of the website and checkout in four months, aiming for a September launch before the holiday season. Jørgensen's Journal of Systems and Software review found that expert estimation is widely used and can match models, but that estimators tend toward optimism and are swayed by anchors. Boehm's book on software engineering economics explains how size, complexity and team factors drive effort. Brooks's book warns that adding people to a late project can delay it. A table compares the team's four months, a size-based estimate of eight and the company's past projects, which ran 70% over first estimates, suggesting about seven. The schedule targets January, with September used for a smaller checkout upgrade.
MGT 505 Module 4 rubric: what earns full marks
Estimating papers are graded on using more than one method, explaining the research behind each, stating assumptions and giving a range rather than a single date. This example compares a team estimate, a model-based estimate and an estimate from past projects, then combines them. Jørgensen's review explains why the team's estimate is likely optimistic. Boehm's work grounds the size-based estimate. Brooks's warning shapes the response to the owners' request to add contractors late in the work. The schedule includes checkpoints where the estimate will be revised, and the paper shows the cost of planning around an optimistic date.
MGT 505 Module 4 help: mistakes that cost marks
Estimating papers often accept one number from the team or invent a precise date. Use at least two methods and compare them with past results. Another weakness is ignoring optimism and anchoring, which research shows bias estimates downward. State assumptions, such as team size and scope. Give a range and explain what would move the date. Do not assume more people means proportionally less time. Set checkpoints where the estimate is revised. Finally, explain the business options the range creates, such as launching a smaller release first. Break the work into parts before estimating, and show what being wrong would cost.
Write yours, or have the desk draft it
This paper is an original model document written by our desk, not a submitted student paper and not an official Aspen University document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.
More MGT 505 and Master of Business Administration sample papers
- MGT 505 Module 1: The IT Environment and the Manager's Role
- MGT 505 Module 2: IT Department Problems and Symptoms
- MGT 505 Module 3: The Nature of Software Projects
- MGT 505 Module 5: Managing Technical Professionals
- MGT 505 Module 6: Vendors, Outsourcing and Cloud Services
- MGT 505 Module 7: IT Governance and Alignment
- MGT 505 Module 8: Rescuing a Troubled IT Project
- MGT 530 Module 8: A Personal Leadership Philosophy
- MGT 645 Module 8: Uncertainty and Tailoring
- MGT 646 Module 5: Cost and Budget
- MGT 647 Module 4: Shared Leadership
MGT 505 Module 4 questions, answered
What does MGT 505 Module 4 usually ask for?
Aspen's MGT 505 covers estimating and scheduling technology work in this module, so an MBA paper producing and defending an estimate for a project is typical. Look at your classroom prompt.
Are expert estimates reliable for software?
Jørgensen found expert estimation can be as accurate as models but tends toward optimism, especially when anchored by early figures or deadlines.
Why not just add more developers?
Brooks observed that adding people to a late software project often delays it, because new people need training and coordination grows.
Where can I find a free MGT 505 Module 4 sample paper?
The example above estimates an online retailer's website rebuild three ways and produces a range-based schedule with checkpoints.
Should a software estimate be one date?
No. A range with stated assumptions, revised at checkpoints, gives managers a more honest basis for decisions.