A technology and
implementation plan
for Feddy.
Feddy was a fictional online retailer selling products including luxury goods, with ambitions to grow into additional markets. I proposed the technology that could support its customers and employees, then planned relocation and system implementation activities.
I completed the reports, diagrams, workbook, schedule, and presentation myself. Task assignments used fictional team members.
The output was a project plan. Customer growth and satisfaction were expected benefits; no live store was deployed or commercial results measured.
How the documents fit together
- Requirements
- The business needs, proposed scope, and risks.
- Infrastructure & diagrams
- Hardware, software, security, and the intended customer process.
- Excel workbook
- Equipment quantities, unit prices, subtotals, and an estimate.
- Project schedule
- Activities, dates, durations, dependencies, and fictional resources.
- Presentation
- A summary of goals, proposed benefits, costs, and timing for leadership.
From my Microsoft Project export
The relocation portion of my original schedule shows task durations, planned dates, dependencies, and fictional resource assignments. The excerpt below is reproduced as submitted.

Looking back, I would review the manual scheduling and resource warnings visible in the export before using a schedule like this as an execution baseline.
Three parts of the plan
Readable reconstructions from the original submissions. Figures and dates are historical academic estimates, not live business records.
Equipment cost estimates
The workbook connected each equipment quantity to a unit price. It provided a view of proposed purchases, rather than evidence of real spending.
| Equipment | Unit price | Quantity | Subtotal |
|---|---|---|---|
| Laptops | $900 | 11 | $9,900 |
| Desktops | $1,300 | 10 | $13,000 |
| Routers | $3,500 | 2 | $7,000 |
Calculation: Unit price × quantity = subtotal. The original laptop row uses the Excel formula =C3*D3.
Selected equipment only; these rows are not the complete project budget. Source: original bill of materials workbook.
Relocation task dependencies
This excerpt shows a finish-to-start chain from the proposed relocation schedule. Each listed task follows the completion of the previous one.
| ID | Task | Duration | Planned date | Predecessor |
|---|---|---|---|---|
| 9 | Pack boxes | 1 day | May 5, 2022 | — |
| 10 | Disconnect computers | 1 day | May 6, 2022 | 9 |
| 11 | Disassemble furniture | 1 day | May 9, 2022 | 10 |
| 12 | Move by truck | 1 day | May 10, 2022 | 11 |
Planning principle: A late predecessor can delay its dependent tasks. The effect on project completion depends on the full schedule and available float.
Dates are planned dates in a simulation, not records of a real move. Task wording has been lightly shortened for readability.
Proposed customer purchase flow
My original infrastructure report included a diagram of account access, browsing, the cart, checkout, payment, and order confirmation. Mapping the route helped describe the intended behavior before development.
- BrowseFind a product
- CartAdd selected items
- CheckoutProvide shipping & payment details
- ConfirmationReceive order confirmation
The original diagram also included decision branches. This simplified summary shows the purchase path; continuing to browse is another customer choice.
Web reconstruction based on the original infrastructure report. It illustrates a proposed process, not a working storefront.
I would start with a better demand estimate.
My original infrastructure assumptions were too ambitious for a small business. Today, I would estimate normal and peak usage, compare hosting options, and justify capacity before choosing equipment.
I would also tighten the project boundaries and reconcile the reports, costs, and schedule. The plan should show how capacity can grow with demand, without paying for unnecessary equipment upfront.
What I took from the project: understand why the technology is needed, explain the estimated cost, and plan how to put it into use.